无法获取网关MAC地址表/radware备机流量——在不断的应急中提高

最近公司好像开年不太顺利，用户的设备是一台接着一台出问题，网络是不断的出现小故障，作为一名售后工程师，自然像是消防队员到处救火去，主要想写两个小案例，总结一下整个故障处理的过程。

案例一、某vlan业务网络断网

用户A的网络经历了一次环路，直接导致全网络瘫痪无法正常访问，环路解决后发现其中一个VLAN的用户不能够获取到网关的MAC地址表，导致ping网关延时或丢包，同时网络内也ping不正常。

起初认为可能是ARP***，变进行了VLAN的抓包，发现网络里有ARP扫描或者请求风暴但是都不大，都是一些正常的访问，因此终端的ARP欺骗被排除。

难道是网络内的病毒***泛滥，通过抓包和网内的主动威胁发现设备没有发现异常，初步排除此问题。

没有好的办法，先把终端的ip/mac进行了手工绑定。

然后判断是该VLAN的交换机可能存在问题，便查看配置，发现配置没有打的异常，然后在凌晨准备挨个拔线测试，问题出在哪个交换机（该vlan有四台）按照设计思路都拔掉后，发现故障依然，我的去，这是什么问题，难道是核心65有问题了，找了个CCIE看看吧，配置没什么问题，其他的网段都能够正常去PING通该网关，自己VLAN的却无法ping通，奇怪了，决定重启交换机，发现重启过程中还坏了一台，真实不走运呀。

重启后故障依然存在，这时候好像这有一个原因了交换机可能存在问题，难道因为大量的环路，交换机备冲瘫了？但是有四台，四台有两条链路通过光电转换连接到65核心。

换了一台新交换机，测试一下，发现故障没有这么明显，而且好了很多，初步判断可能是交换机出现问题。（此刻已经凌晨4点半，就这样吧）

回头我问了其他的人，这个症状，他们告诉我应该重启光电转换器，真正的问题可能就在这里，还没有去验证。

案例二radware 备机出现业务流量

用户的网络出口采用了我们的radware链路负载均衡设备，虽然已经很古老了，但是对用户的网络和业务发挥了重要的作用。主要发现问题是，用户的radware采用主备模式，通过VRRP进行双机判断，发现备机上有某个测试网段有业务流量，而这个网段用户刚刚进行了调整。

对产品还不熟悉，提前一个晚上进行了学习。

由于没有打的策略变动，初步判断是不是用户的设备配置需要重新刷一便，把备机设备导出，然后倒入，在重启设备，发现故障依然存在。

这个时候再考虑是不是双机的问题，对比主机配置，双机存在点问题，但是判断不出是什么问题，决定将VRRP配置和Smart NAT删除重新配置下。

radware的主备是通过LinkProof > Redundancy > Global Configuration  >. 冗余全局配置表，

Interface Grouping: 主设备选择enable，表示在一个端口出现问题的时候进行整体设备切换，备用设备通常使用默认的disable状态。

思路是删除VRRP-VR Table 然后从新建VR Table,重新添加associated ip

第二思路是重新建Static NAT就是一对一的映射，不改变端口，并且是双向的NAT

由于用户最近的操作就是新建了NAT，所有决定重建下，在选择NAT 模式时同事眼疾手快，发现备机用户新建的模式不对选择了regular 应该选择backup

好像问题找到了呀，由于配置的错误导致Smart NAT不正确，看来问题就出在这里。

搞好了，终于可以打道回府了，但是还有WAF和抗Dos设备还有问题，全是泪呀。