無法獲取網關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設備還有問題，全是淚呀。