MPLS標簽引發網絡故障

筆者所在單位有多個分支機構，各分支機構通過租用運營商的線路連接至筆者所在單位的城域網路由器，再通過地址轉換設備使用統一的互聯網出口訪問互聯網。單位對外發布業務的服務器部署于DMZ區，通過邊緣層的防火墻發布至外網。各分支機構通過互聯網訪問發布的業務。圖1是內部網絡拓撲圖。

圖1 網絡拓撲結構

故障現象

單位發布了一套視頻學習系統供業務培訓使用，系統部署于DMZ區，通過防火墻向互聯網發布，分支機構通過公網訪問該系統。系統上線后，部分分支反映用戶在客戶端播放視頻時出現卡頓的現象，但是從客戶端能正常Ping通系統的公網地址202.x.x.36。位于筆者單位內部的用戶能正常訪問該系統。

圖2 抓包信息

排障思路

根據故障現象及和分支維護人員的溝通，筆者分析故障的可能原因如下。

1.服務器性能不足。

2.網絡、安全設備性能不足。

3.到各分支鏈路帶寬不足。

4.運營商城域網線路問題。

排障過程

1.監測服務器。在服務器上對CPU、內存、存儲、網絡進行檢測，服務器使用率比較低，系統運行正常。

2.監測網絡、安全設備。對服務器接入網絡、核心交換機、防火墻的CPU、內存、包轉發進行檢測，也在合理的范圍內。防火墻的安全策略也沒有問題，上網行為審計設備沒有限制帶寬。鑒于筆者所在單位內部的用戶能正常通過公網訪問視頻，可基本排除中心服務器端出現故障的可能。

3.監測各分支鏈路帶寬。登錄到分支路由器，分支路由器上的CPU、內存使用率也很低，端口無明顯錯誤報文，端口數據流量不高，線路也比較穩定。

4.經監測以上幾個方面從表面看都沒有問題，沒有辦法，筆者到其中一個分支，觀察故障現象。在該分支上 Ping系統的公網地址沒有問題，但是看視頻時確實卡頓，只能通過抓包的方式分析故障原因。

故障解決

分別在故障分支客戶端上抓包，發現有大量的要求重傳的報文和丟失的報文（如圖2）。

與在中心端客戶端所抓的包文做比較，在中心端的抓包沒有此現象。

通過對比兩者的抓包結果和兩者的網絡區別，突然想到，分支到中心端的線路是專線線路，會不會是運行商的MPLS線路呢，這樣的話，數據包就會在運營商的網絡設備上打上MPLS標簽，數據包很有可能超過網絡設備的MTU值，就會造成數據包分片，甚至部分分片的數據包丟失。馬上聯系運營商確認，結果確實如此。

馬上查閱相關資料，使用兩種方式解決此問題。

一是在客戶端通過Ping -l 加上字節數到服務器確認兩者的MTU，然后在Windows 操作系統下通過netsh interface ipv4 set subinterface "本地連接"mtu=1480 store=persistent命令修改了客戶端的MTU值，重啟電腦再查看服務器視頻，視頻能夠流暢播放了。

二是在分支機構的接入路由器接口上通過“tcp mss 884”命令將MSS值改為884字節，所有的電腦都能正常播放視頻了。

故障分析

由于中心到分支使用了嵌套的MPLS網絡，在IP包前封裝了MPLS標簽，導致MTU的增大超過了1500字節，進而使報文被分片處理，導致了訪問服務器效率降低。同時，被分片的的字節過小的話，會被安全設備當做攻擊報文而丟棄。修改MTU值或MSS值后，報文不會被分包處理，提高了訪問效率。