最近公司好像開年不太順利，用戶的設(shè)備是一臺接著一臺出問題，網(wǎng)絡(luò)是不斷的出現(xiàn)小故障，作為一名售后工程師，自然像是消防隊員到處救火去，主要想寫兩個小案例，總結(jié)一下整個故障處理的過程。

成都創(chuàng)新互聯(lián)公司成立于2013年，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項目成都網(wǎng)站制作、網(wǎng)站設(shè)計網(wǎng)站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元鐵西做網(wǎng)站,已為上家服務(wù),為鐵西各地企業(yè)和個人服務(wù),聯(lián)系電話:028-86922220

案例一、某vlan業(yè)務(wù)網(wǎng)絡(luò)斷網(wǎng)

用戶A的網(wǎng)絡(luò)經(jīng)歷了一次環(huán)路，直接導(dǎo)致全網(wǎng)絡(luò)癱瘓無法正常訪問，環(huán)路解決后發(fā)現(xiàn)其中一個VLAN的用戶不能夠獲取到網(wǎng)關(guān)的MAC地址表，導(dǎo)致ping網(wǎng)關(guān)延時或丟包，同時網(wǎng)絡(luò)內(nèi)也ping不正常。

起初認為可能是ARP***，變進行了VLAN的抓包，發(fā)現(xiàn)網(wǎng)絡(luò)里有ARP掃描或者請求風暴但是都不大，都是一些正常的訪問，因此終端的ARP欺騙被排除。

難道是網(wǎng)絡(luò)內(nèi)的病毒***泛濫，通過抓包和網(wǎng)內(nèi)的主動威脅發(fā)現(xiàn)設(shè)備沒有發(fā)現(xiàn)異常，初步排除此問題。

沒有好的辦法，先把終端的ip/mac進行了手工綁定。

然后判斷是該VLAN的交換機可能存在問題，便查看配置，發(fā)現(xiàn)配置沒有打的異常，然后在凌晨準備挨個拔線測試，問題出在哪個交換機（該vlan有四臺）按照設(shè)計思路都拔掉后，發(fā)現(xiàn)故障依然，我的去，這是什么問題，難道是核心65有問題了，找了個CCIE看看吧，配置沒什么問題，其他的網(wǎng)段都能夠正常去PING通該網(wǎng)關(guān)，自己VLAN的卻無法ping通，奇怪了，決定重啟交換機，發(fā)現(xiàn)重啟過程中還壞了一臺，真實不走運呀。

重啟后故障依然存在，這時候好像這有一個原因了交換機可能存在問題，難道因為大量的環(huán)路，交換機備沖癱了？但是有四臺，四臺有兩條鏈路通過光電轉(zhuǎn)換連接到65核心。

換了一臺新交換機，測試一下，發(fā)現(xiàn)故障沒有這么明顯，而且好了很多，初步判斷可能是交換機出現(xiàn)問題。（此刻已經(jīng)凌晨4點半，就這樣吧）

回頭我問了其他的人，這個癥狀，他們告訴我應(yīng)該重啟光電轉(zhuǎn)換器，真正的問題可能就在這里，還沒有去驗證。

案例二radware 備機出現(xiàn)業(yè)務(wù)流量

用戶的網(wǎng)絡(luò)出口采用了我們的radware鏈路負載均衡設(shè)備，雖然已經(jīng)很古老了，但是對用戶的網(wǎng)絡(luò)和業(yè)務(wù)發(fā)揮了重要的作用。主要發(fā)現(xiàn)問題是，用戶的radware采用主備模式，通過VRRP進行雙機判斷，發(fā)現(xiàn)備機上有某個測試網(wǎng)段有業(yè)務(wù)流量，而這個網(wǎng)段用戶剛剛進行了調(diào)整。

對產(chǎn)品還不熟悉，提前一個晚上進行了學(xué)習(xí)。

由于沒有打的策略變動，初步判斷是不是用戶的設(shè)備配置需要重新刷一便，把備機設(shè)備導(dǎo)出，然后倒入，在重啟設(shè)備，發(fā)現(xiàn)故障依然存在。

這個時候再考慮是不是雙機的問題，對比主機配置，雙機存在點問題，但是判斷不出是什么問題，決定將VRRP配置和Smart NAT刪除重新配置下。

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

Interface Grouping:主設(shè)備選擇enable，表示在一個端口出現(xiàn)問題的時候進行整體設(shè)備切換，備用設(shè)備通常使用默認的disable狀態(tài)。

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

第二思路是重新建Static NAT就是一對一的映射，不改變端口，并且是雙向的NAT

由于用戶最近的操作就是新建了NAT，所有決定重建下，在選擇NAT 模式時同事眼疾手快，發(fā)現(xiàn)備機用戶新建的模式不對選擇了regular 應(yīng)該選擇backup

好像問題找到了呀，由于配置的錯誤導(dǎo)致Smart NAT不正確，看來問題就出在這里。

搞好了，終于可以打道回府了，但是還有WAF和抗Dos設(shè)備還有問題，全是淚呀。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

本文題目：無法獲取網(wǎng)關(guān)MAC地址表/radware備機流量——在不斷的應(yīng)急中提高-創(chuàng)新互聯(lián)
URL網(wǎng)址：http://weahome.cn/article/hshjj.html