MPLS VPN轉發(fā)故障分析

■ 浙江 盛建平

編者按：近期某企業(yè)分公司在演練時，中斷MPLS VPN業(yè)務主線路，發(fā)現(xiàn)網(wǎng)點業(yè)務終端無法登錄生產(chǎn)系統(tǒng)，在經(jīng)過排查后解決了隱性故障。

MPLS VPN作為運營商的常用技術，目前在大型企業(yè)中也常有使用，近期某企業(yè)分公司在演練時，中斷業(yè)務主線路，發(fā)現(xiàn)網(wǎng)點業(yè)務終端無法登錄生產(chǎn)系統(tǒng)，但網(wǎng)點辦公PC可以正常訪問總部各系統(tǒng)。

網(wǎng)絡架構

該企業(yè)MPLS VPN域有兩個實例，分別為業(yè)務網(wǎng)實例和辦公網(wǎng)實例。正常情況下，兩個實例各走一條廣域網(wǎng)線路，實現(xiàn)流量負載分擔。當廣域網(wǎng)線路1中斷時，業(yè)務數(shù)據(jù)流會自動切換到線路2，實現(xiàn)自動備份。

但本次演練發(fā)現(xiàn)，中斷線路1，業(yè)務數(shù)據(jù)流切換到線路2后，網(wǎng)點業(yè)務終端卻無法登錄生產(chǎn)系統(tǒng)，如果日間網(wǎng)點在辦理業(yè)務時線路1中斷，處置不當則會引起較大風險。

圖1 網(wǎng)絡架構圖

故障分析

中斷廣域網(wǎng)線路1后，引起網(wǎng)點業(yè)務終端登錄異常，因兩個端點未發(fā)生變化，一般是網(wǎng)絡路徑上某個位置出現(xiàn)問題引起數(shù)據(jù)包傳輸異常。

首先進行網(wǎng)絡連通性測試，發(fā)現(xiàn)網(wǎng)點業(yè)務終端到總部生產(chǎn)服務器ping測試正常，Telnet端口測試也正常。會不會是線路切換后，導致數(shù)據(jù)流路徑發(fā)生變化，從而引起本次故障呢？

檢查發(fā)現(xiàn)，線路中斷時，總部和分公司數(shù)據(jù)流路徑均未發(fā)生變化，于是將排查方向重點定位到MPLS VPN域內的4臺路由器。

因分公司業(yè)務數(shù)據(jù)是從AR03離開MPLS域的，嘗試斷開分公司AR03與AR04之間的連線，從MPLS域中隔離分公司AR03，使業(yè)務數(shù)據(jù)流也從分公司AR04離開MPLS域，此時網(wǎng)點業(yè)務終端登錄生產(chǎn)系統(tǒng)正常。

問題初步定位，但檢查分公司AR03與AR04之間的物理連線及設備配置，均未發(fā)現(xiàn)問題，調整該連線的MTU值，故障依舊。

再次從整體來分析業(yè)務、辦公數(shù)據(jù)流的走向，發(fā)現(xiàn)當廣域網(wǎng)線路1中斷時，總部到分公司的辦公數(shù)據(jù)流路徑為：總部AR01→AR02→分公司AR04，然后離開MPLS域進行正常的路由轉發(fā)。而總部到分公司的業(yè)務數(shù)據(jù)流路徑為：總部AR01→AR02→分公司AR04 →AR03，比辦公數(shù)據(jù)流多了一跳。從MPLS數(shù)據(jù)包轉發(fā)層面分析，我們把目光投向

【】【】

了廣域網(wǎng)線路2。

故障解決

MPLS VPN數(shù)據(jù)包會封裝兩層標簽，外層為公網(wǎng)標簽，內層為VPN實例標簽。在進行MPLS數(shù)據(jù)包轉發(fā)時，需要注意倒數(shù)第二跳彈出機制。

在本案中，當線路1中斷時，業(yè)務、辦公數(shù)據(jù)流從總部AR01進入MPLS VPN域，封裝兩層標簽后，發(fā)送給AR02。總部AR02收到業(yè)務數(shù)據(jù)包時，進行正常的標簽交換，然后通過線路2轉發(fā)給分公司AR04（此時數(shù)據(jù)包仍有兩層標簽）；而AR02收到辦公數(shù)據(jù)包進行標簽交換時發(fā)現(xiàn)，出站標簽是一個特殊的標簽3，意味著需要將數(shù)據(jù)包的頂層標簽彈出（倒數(shù)第二跳彈出機制），然后通過線路2轉發(fā)給分公司AR04（此時數(shù)據(jù)包僅有一層標簽）。由于業(yè)務、辦公數(shù)據(jù)包在線路2上傳輸時封裝的標簽層數(shù)不同，數(shù)據(jù)包的大小就有區(qū)別。封裝一層標簽時，數(shù)據(jù)包極限大小為1500+18+4=1522，封裝二層標簽則為1526，會不會線路2只能傳輸1522字節(jié)的數(shù)據(jù)包，而不能傳輸1526字節(jié)的數(shù)據(jù)包呢？

帶著這個疑問咨詢了線路2的運營商。原來該運營商默認線路MTU值為1522，并未對該企業(yè)運行MPLS VPN的需求進行調整，從而引起“大包”轉發(fā)故障。后續(xù)廣域網(wǎng)線路2的運營商調整線路MTU值為1526后，故障解決。