最近， 碰到一個非常奇怪的問題， 一臺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表， 產生超時， 所以它不通的時間就長一些， 就出現時通時斷的現象了。