无法获取网关MAC地址表/radware备机流量——在不断的应急中提高
最近公司好像开年不太顺利,用户的设备是一台接着一台出问题,网络是不断的出现小故障,作为一名售后工程师,自然像是消防队员到处救火去,主要想写两个小案例,总结一下整个故障处理的过程。
创新互联是少有的做网站、网站制作、营销型企业网站、微信平台小程序开发、手机APP,开发、制作、设计、卖链接、推广优化一站式服务网络公司,自2013年起,坚持透明化,价格低,无套路经营理念。让网页惊喜每一位访客多年来深受用户好评
案例一、某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设备还有问题,全是泪呀。
当前题目:无法获取网关MAC地址表/radware备机流量——在不断的应急中提高
新闻来源:http://scyanting.com/article/gccooc.html