看清ARP,輕鬆排除網絡故障

 最近,我單位碰到一個非常奇怪的問題,一臺P4品牌電腦,內置英特爾網卡,一直以來用得挺好,瀏覽因特網,內網的通信都很正常。突然有一天,發現這臺計算機在瀏覽因特網時時通時斷,ping因特網上的地址時,也是通一下,斷一下,但ping內網時什麼問題也沒有,和內網的通信也非常正常,就是和因特網通信時有這種現象,非常令人費解。這臺電腦的IP地址爲192.168.24.55,防火牆的IP地址爲192.168.24.7。

    故障分析:檢查物理鏈路
    我單位所有訪問因特網的電腦都是通過Netscreen NS25防火牆來連接的,如果說是防火牆的問題,那其他的電腦訪問因特網都挺正常,沒有時通時斷的現象。根據這臺電腦ping的現象來看,問題似乎應該在下三層,而時通時斷的現象好像是典型的物理層的問題,那麼首先開始檢查鏈路。
    這臺電腦接在一臺Cisco三層交換機的某一個端口上,防火牆也接在這臺三層交換機上,在三層交換機上啓用了路由,配置上肯定沒有問題。先檢查電腦到交換機的網線,如果說這根網線有問題,那麼這臺電腦與內網的通信也應該有問題,通過對這根網線的測試證實沒有問題。防火牆到交換機的跳線就更應該沒有問題了,因爲其他的電腦都沒有問題。由此可以判斷鏈路是沒有問題的,網卡會有問題嗎?肯定也不會,因爲它跟內網的通信是正常的,所以網卡肯定也沒有問題。那麼就可以排除物理層的問題了。
   故障分析:模擬數據通信
    再看網絡層,這臺電腦能夠訪問因特網,只不過有丟包而已,似乎網絡層也不應該有問題,那麼所有問題似乎就集中在數據鏈路層了。數據鏈路層的問題會是哪裏呢?思考了幾天,毫無頭緒,最後只好仔細地想一想網絡通信的過程,看能不能找到問題。
    假設這臺電腦有一個數據包需要發送到因特網,那麼首先它會檢查目的地址與本機地址是否在一個網絡中,如果不在一個網絡中,就會將數據包發送給默認網關。本案例中目的IP爲因特網地址,肯定不在一個網絡中,所以數據包會發送給默認網關。在這裏默認網關爲那臺Cisco三層交換機,IP地址爲192.168.24.10。這時192.168.24.55這臺電腦會檢查本機的ARP表,查找192.168.24.10所對應的MAC地址,如果在ARP表中沒有發現相應的ARP表項,它就會發送一個ARP請求包,並將它發送給網絡中的所有設備來獲得192.168.24.10的MAC地址。由於ARP請求包是以廣播方式發送的,網絡中的所有設備都會接收到這個包,然後傳送給網絡層檢驗。
    當Cisco三層交換機接收到這個ARP請求時,就會檢查本機的IP地址和ARP請求包中的目的IP地址是否相同,如果相同,交換機就會做出ARP應答,將它的MAC地址發送給源,也就是192.168.24.55這臺電腦。這臺電腦收到ARP應答包後,就會將交換機的IP地址(192.168.24.10)和MAC地址寫入ARP表,然後將交換機的MAC地址作爲目的MAC地址封裝到數據包中,並將數據包發送到交換機。交換機在收到數據包後,就會檢查目的IP是否在本網段中,若發現不在本網段中,就會查找路由表,看看有沒有到目的IP的路由條目,如果沒有,就會將數據包發送給默認路由。在本案例中這臺交換機的默認路由是那臺IP爲192.168.24.7的防火牆。所以交換機就會發送一個ARP廣播,以獲得防火牆的MAC地址。防火牆做出ARP應答後,交換機就會將防火牆的MAC地址作爲目的MAC地址封裝到數據包中,數據包就會發送到防火牆,然後防火牆就會又重複上述過程,將數據包發送給因特網上的目的地址。這一切過程都是正常的,沒有什麼問題。在電腦和交換機的ARP表中都能找到相應的ARP記錄,用tracert命令跟蹤路由也是正常的。那問題究竟在什麼地方呢?看來還得繼續分析。
   故障分析:過濾ARP表
    在數據包到達了因特網上的目的地址之後,響應的數據包要返回到這臺電腦,那麼它也應該重複前面的過程。返回數據包先到達防火牆,在防火牆的ARP表中尋找目的IP地址所對應的MAC地址,如果沒有,就會發送ARP請求,得到目的電腦的MAC地址,將電腦的IP地址和MAC地址寫入防火牆的ARP表,封裝後發送給這臺電腦。這一切看起來都是正常的,但爲什麼會出現時通時斷的現象呢?由這臺電腦在內網都是正常的現象來判斷,在三層交換機上應該是沒有問題的,只是在訪問因特網時纔出現問題,最後決定從防火牆上開始檢查。
    Telnet上防火牆,檢查防火牆配置,一切正常;檢查端口,一切正常;檢查路由表,也是一切正常。疑惑中,似乎不知該從哪裏下手了。突然間,想起來爲了防止內網用戶盜用IP地址上網,在防火牆上做了IP地址和MAC地址的綁定!對,檢查ARP表。於是輸入命令get arp,顯示一大串ARP表的信息,竟然全部是IP地址和MAC地址的靜態綁定的信息,僅有一條動態的,那是防火牆的下一跳的IP地址和下一跳的MAC地址的信息,就是沒有192.168.24.55的ARP表項,難道是ARP表的問題?似乎看到了一線希望!
    於是決定先清除幾個靜態綁定的ARP表項試試。先用unset arp命令一連清除了6條靜態綁定的ARP表項,然後在那臺電腦上ping因特網的地址,居然不丟包了!?困擾我幾天的問題難道就這樣解決了嗎?我簡直有點不敢相信,又讓我的同事在這臺電腦上面測試一下,登錄QQ,瀏覽網頁,收發郵件……居然一切正常,再也沒有原來時通時斷的現象了!再Telnet到防火牆上,執行get arp命令一看,192.168.24.55那臺電腦的ARP表項赫然在目。看來問題真的解決了!高興之餘坐下來再好好想一想原因吧。
    故障溯源
    這臺Netscreen NS 25防火牆最多支持128個ARP表項,如果不進行靜態綁定,ARP表項會不斷地進行更新,超時的自動會刪掉,所以不會出現ARP表項被佔滿的情況。而如果是靜態綁定,那麼它永遠就不會被清除,永遠會佔據一個ARP表項,留給動態使用的ARP表項空間就會越來越少,直到全部佔滿,導致我所碰到的情況。那麼既然如此,有朋友會問了,既然都佔滿了,其他的電腦就會完全不通,爲什麼會出現時通時斷的現象呢?於是我將ARP表項數了一下,靜態綁定的剛好達到127個,剩下一個給防火牆的下一跳的地址佔用了,注意這個是動態的,當它的更新時間到了之後,就被刪掉了,那臺電腦就佔用了這個表項,於是網絡就通了,因爲還有其他的電腦在不斷地訪問因特網,所以192.168.24.55的ARP表項一到達更新時間馬上就會被防火牆的下一跳的地址所佔用,這時網絡就不通了。其實在這時,我單位的所有機器在訪問因特網時都會出現時通時斷的現象,只不過防火牆的下一跳的地址佔用ARP表項的時間長,因特網中斷的時間在大家能夠忍受的範圍內,都沒有發覺罷了。因爲防火牆的下一跳的地址佔用ARP表項的時間長,192.168.24.55的ARP表項寫不進ARP表,產生超時,所以它不通的時間就長一些,就出現時通時斷的現象了。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章