MTU即最大傳輸單元（Maximum Transmission Unit），該 值 是TCP/IP協(xié) 議中的一個(gè)重要參數(shù)值，用于描述協(xié)議數(shù)據(jù)單元承載的有效數(shù)據(jù)大小。MSS（Maximum Segment Size，最大報(bào)文長(zhǎng)度），是TCP協(xié)議定義的一個(gè)選項(xiàng)，MSS選項(xiàng)用于在TCP連接建立時(shí)，收發(fā)雙方協(xié)商通信時(shí)每一個(gè)報(bào)文段所能承載的最大數(shù)據(jù)長(zhǎng)度。超過MSS值的TCP報(bào)文在傳輸過程終將會(huì)被分段。對(duì)于不同類型的網(wǎng)絡(luò)，甚至同種類型網(wǎng)絡(luò)中不同品牌網(wǎng)絡(luò)設(shè)備默認(rèn)定義MTU/MSS的大小都可能不同，設(shè)置合適的MTU/MSS值，可以解決部分“網(wǎng)站打不開”、“網(wǎng)速慢”等問題。本文就是由于一個(gè)典型的MTU/MSS值差異導(dǎo)致網(wǎng)站無法訪問的典型案例。

網(wǎng)絡(luò)結(jié)構(gòu)

筆者單位的網(wǎng)絡(luò)結(jié)構(gòu)如圖1所示，這是一個(gè)構(gòu)建在共享網(wǎng)絡(luò)上的星型VPN網(wǎng)絡(luò)。核心路由器與每一個(gè)分支節(jié)點(diǎn)的接入路由器之間構(gòu)建隧道模式的IPSec VPN網(wǎng)絡(luò)，所有分支節(jié)點(diǎn)之間的通信均通過核心路由器中轉(zhuǎn)，網(wǎng)絡(luò)中主要承載數(shù)據(jù)業(yè)務(wù)和視頻會(huì)商業(yè)務(wù)。為了便于業(yè)務(wù)管理和保證視頻會(huì)商質(zhì)量，將每一個(gè)節(jié)點(diǎn)的局域網(wǎng)劃分為為20和30的兩個(gè)VLAN，兩個(gè)VLAN之間通過路由器以單臂路由形式互通。在核心路由器出接口配置服務(wù)質(zhì)量控制，使視頻會(huì)商業(yè)務(wù)能夠擁有足夠的帶寬保證。

故障現(xiàn)象

由于工作需要，近來網(wǎng)絡(luò)中新增了若干分支節(jié)點(diǎn)。為了減少兼容性問題，新增節(jié)點(diǎn)的網(wǎng)絡(luò)設(shè)備也采用與現(xiàn)有設(shè)備統(tǒng)一品牌產(chǎn)品。但是，由于原有設(shè)備型號(hào)已經(jīng)停產(chǎn)，只能選擇該品牌設(shè)備的后續(xù)型號(hào)。

采購(gòu)設(shè)備到貨后，VPN很快就搭建完成。新增設(shè)備部署IPSec VPN時(shí)，除配置安全提議過程中有少數(shù)命令發(fā)生變化外，其余配置變化不大，這就是選擇統(tǒng)一品牌設(shè)備組網(wǎng)的好處。新增分支節(jié)點(diǎn)網(wǎng)絡(luò)中數(shù)據(jù)業(yè)務(wù)和視頻會(huì)商業(yè)務(wù)均工作正常，但奇怪的是，中心節(jié)點(diǎn)始終無法通過網(wǎng)絡(luò)訪問分支節(jié)點(diǎn)的視頻會(huì)商設(shè)備的Web管理頁(yè)面。為排查問題，詳細(xì)對(duì)比了新老設(shè)備構(gòu)建VPN的安全提議、安全策略和默認(rèn)參數(shù)配置，均未發(fā)現(xiàn)不同。在中心節(jié)點(diǎn)使用telnet工具連接新增分支節(jié)點(diǎn)的TCP 80端口，有正常響應(yīng)。

故障分析

在這個(gè)組網(wǎng)方案中，新增節(jié)點(diǎn)與網(wǎng)絡(luò)中原有節(jié)點(diǎn)的差異是造成視頻設(shè)備Web管理頁(yè)面無法訪問的直接原因，這一點(diǎn)是十分明確的。解決這一故障的關(guān)鍵也在于找出新老節(jié)點(diǎn)之間的這種差異。

為了佐證上述判斷，做一個(gè)簡(jiǎn)單的測(cè)試。由新增節(jié)點(diǎn)分別訪問新老節(jié)點(diǎn)的視頻設(shè)備Web管理頁(yè)面，我們發(fā)現(xiàn)，無論是新舊節(jié)點(diǎn)，都無法遠(yuǎn)程訪問新節(jié)點(diǎn)的視頻設(shè)備Web管理頁(yè)面。那么，在訪問過程中到底發(fā)生了什么呢？這就需要用到抓包工具了。圖2是訪問新節(jié)點(diǎn)視頻會(huì)商設(shè)備Web管理頁(yè)面時(shí)的WireShark工具抓包截圖。

通過抓包發(fā)現(xiàn)，此次Web訪問過程中，完成了一次TCP三次握手，先后發(fā)出了兩次http數(shù)據(jù)get請(qǐng)求，并得到了一次響應(yīng)。第二次的get請(qǐng)求之后就發(fā)生了“Tcp Previous segment not captured”后續(xù)數(shù)據(jù)丟失，直至發(fā)送FIN指令終止連接。通過這次抓包可以看出，Web訪問實(shí)際上在網(wǎng)絡(luò)中已經(jīng)發(fā)生，但是由于某種原因?qū)е潞罄m(xù)數(shù)據(jù)丟失，才造成了我們無法訪問Web頁(yè)面的事實(shí)。

為排除網(wǎng)絡(luò)安全設(shè)備阻斷HTTP數(shù)據(jù)傳輸?shù)目赡?，我們做了一個(gè)試驗(yàn)。將一臺(tái)視頻會(huì)商設(shè)備直接接到核心路由器的一個(gè)以太網(wǎng)接口，并訪問該設(shè)備的Web管理頁(yè)面，發(fā)現(xiàn)可以正常訪問Web頁(yè)面。這就排除中心節(jié)點(diǎn)安全設(shè)備攔截了那些數(shù)據(jù)表的可能。

找出這些后續(xù)數(shù)據(jù)報(bào)文被攔截的位置，是查找問題的一條途徑。由于IPSec VPN采用的是隧道模式，數(shù)據(jù)在隧道中傳輸過程中是被加密的，很難定位數(shù)據(jù)報(bào)文被攔截的準(zhǔn)確位置。另一條途徑就是通過兩次http請(qǐng)求后響應(yīng)數(shù)據(jù)報(bào)文的差異，來分析后續(xù)數(shù)據(jù)報(bào)文被丟棄的原因。

通過對(duì)TCP協(xié)議的摘要信息進(jìn)行比較，除了索引號(hào)外，最大區(qū)別就在于TCP數(shù)據(jù)報(bào)文長(zhǎng)度。第一次響應(yīng)的TCP數(shù)據(jù)報(bào)文大小為451，而被丟棄的數(shù)據(jù)報(bào)文是1460。接下來出場(chǎng)的就是ping工具，格式為“ping -f -l[承載數(shù)據(jù)大小] IP地址 ]”，“-f” 參數(shù)強(qiáng)制 ICMP協(xié)議數(shù)據(jù)負(fù)載不會(huì)被拆分。經(jīng)過反復(fù)嘗試，發(fā)現(xiàn)承載數(shù)據(jù)為1415是一個(gè)分界點(diǎn)。

只有小于等于1415的負(fù)載能夠通過VPN網(wǎng)絡(luò)。而在原有分支節(jié)點(diǎn)和中心節(jié)點(diǎn)網(wǎng)絡(luò)中，這個(gè)分界點(diǎn)是1472。有了這一結(jié)論，嘗試對(duì)視頻會(huì)商設(shè)備的MTU進(jìn)行修改，將其改為1400，再訪問其Web，果然管理頁(yè)面正常打開了。

修改視頻設(shè)備MTU值起到了限制承載數(shù)據(jù)大小的目的，但這不是問題的癥結(jié)，問題仍在新增加的路由器上。因?yàn)槲覀儾荒苊看卧黾右粋€(gè)設(shè)備都去調(diào)整設(shè)備的MTU值，這樣太不人性化了。MTU只是規(guī)定了這個(gè)設(shè)備的TCP數(shù)據(jù)報(bào)最大負(fù)載，只有像使用ping -f時(shí)明確配置了報(bào)文不分段的情況下，超過協(xié)商值的數(shù)據(jù)報(bào)文將會(huì)被丟棄。

顯然，視頻會(huì)商設(shè)備的Web頁(yè)面不太可能進(jìn)行這種配置，那么問題就很可能出現(xiàn)在報(bào)文分段尺寸上。默認(rèn)情況下，MSS值通常被設(shè)為1460，即超過載荷超過1460bit時(shí)數(shù)據(jù)報(bào)文將會(huì)在進(jìn)行IP封裝時(shí)被分段。我們之前使用Wireshark進(jìn)行抓包比較時(shí)也發(fā)現(xiàn)，被丟棄的數(shù)據(jù)報(bào)文大小一致。試想，如果以1460的MSS來拆分TCP報(bào)文，那么產(chǎn)生的IP報(bào)文將無法通過載荷只有1415bit的IPSec隧道。這也能夠解釋為什么客戶端和服務(wù)器之間完成了TCP協(xié)議的三次握手和HTTP協(xié)議的兩次get通信，并在報(bào)文丟失后發(fā)送了FIN信號(hào)終止連接。因?yàn)?，這些報(bào)文承載數(shù)據(jù)長(zhǎng)度都很小，遠(yuǎn)遠(yuǎn)沒有達(dá)到1415bit的最大傳輸單元的尺寸。

為什新增分支節(jié)點(diǎn)可以訪問原有節(jié)點(diǎn)的Web管理頁(yè)面呢？我想那是因?yàn)樵性O(shè)備的最大分段長(zhǎng)度是小于1415的，產(chǎn)生的分段報(bào)文能夠正常通過隧道。

故障解決

已經(jīng)明確了問題的癥結(jié)所在，所要做的就是調(diào)整新增節(jié)點(diǎn)路由設(shè)備出口的MSS，通過調(diào)整TCP報(bào)文分段保證產(chǎn)生的T報(bào)文長(zhǎng)度小于VPN隧道最大傳輸單元長(zhǎng)度，即可防止長(zhǎng)生超過限制的超大數(shù)據(jù)載荷。

具體做法是，在新增節(jié)點(diǎn)路由器外網(wǎng)口配置“tcp mss1400”，將路由器最大分段長(zhǎng)度設(shè)為1400，這樣超過1400bit的載荷TCP報(bào)文將會(huì)被拆分。經(jīng)測(cè)試，調(diào)整后所有節(jié)點(diǎn)的視頻設(shè)備Web管理頁(yè)面均可以正常訪問了，至此問題圓滿解決。

經(jīng)驗(yàn)總結(jié)

其實(shí)，MTU長(zhǎng)度差異導(dǎo)致的網(wǎng)絡(luò)故障在日常維護(hù)中也是時(shí)常會(huì)遇到的。對(duì)于本案例來說，新增節(jié)點(diǎn)時(shí)選擇同一品牌產(chǎn)品的目的，就是盡可能減少設(shè)備兼容性問題。然而，因?yàn)椴煌瑫r(shí)期的產(chǎn)品技術(shù)實(shí)現(xiàn)細(xì)節(jié)上的差異，卻造成了組網(wǎng)過程中的怪異現(xiàn)象。

對(duì)于這樣的問題，要求維護(hù)人員能夠準(zhǔn)確理清數(shù)據(jù)流向，綜合利用多種工具和方法，定位故障，盡可能在網(wǎng)絡(luò)基礎(chǔ)設(shè)施層面解決問題。不要將解決問題的著力點(diǎn)放到終端服務(wù)中，否則結(jié)果很可能是摁倒了葫蘆瓢又起。