深信服设备双机/集群后Lan口的MAC地址小结

深信服设备双机后lan的IP对应的mac地址到底是什么？虚机mac地址？:白眼:主机mac地址？

其实不同的设备的mac地址规则却不一致，有些是固定的，有些却可以灵活调整，下面针对常用的设备做一个小结:冷漠:

AC主备模式:

mac地址为主机的mac地址

AF主备模式 :

mac地址为虚拟mac地址

AD主备模式:  

mac地址默认为主机mac地址，当开启mac同步后为虚拟mac地址

WOC主备模式:

mac地址为主机的mac地址

SSLVPN主备模式/负载均衡/单臂集群：

mac地址为虚拟mac地址

aDesk/aCloud/aBos集群：

集群IP的mac地址为主控的mac地址

正常场景下其实无需关注这个mac地址，但有时候会出现一些很妖的问题，此时就需要用到这个知识点来帮助你排错。

某项目中碰到过checkpoint的防火墙接在AD的后端并且映射了VPN端口提供服务，AD双机上架时没采用mac地址同步，当AD切换到备机时，发现防火墙可以正常上网，但vpn服务起不来。针对AD备机的接口抓包，发现有外网进来的包却没有收到防火墙的回包(此时基本已经判定了跟深信服没有关系了)，进入防火墙命令行后发现也可以正常学习到备机的mac地址，但vpn服务始终起不来，多次重启IKE服务也是没有效果，后进入AD主机的接口抓包发现，防火墙VPN端口的数据包还是一直发送给AD主机???

遂得出结论，这防火墙机制存在问题啊，设备arp表都已经刷新了，vpn的数据包却不会重连！还是在给老的mac地址发包 ，那问题点也找了，防火墙的技术那边一时也懵逼了，不知道咋整，那怎么办呢？ 没办法我们看看能不能适应适应改改咯，打开AD的mac地址同步，再次切换发现还是不行，抓包一看，设备还在给主机的mac地址发，被逼的没有办法了，当然是重启大法好，重启了防火墙后重新抓包发现已经是回给虚拟mac地址了，再次进行双机切换后，VPN可以正常在线，算是解决了这个问题。

总结:正常的设备在双机切换后，不管是用虚拟mac或者真实设备mac场景，其实都可以刷新过来的，但不排除某些设备的某些服务可能存在一点点问题会刷不过来。再发散联想下，如果销售卖的是两台AC或者WOC放前面的话，啧啧啧，项目就有的搞了，找到了大锅并及时甩给下联设备，我们就安心的配合搞吧。