案例：是誰丟了數據包？

某位工程師遇到一個疑難案例：更換用戶出口的設備後，用戶連不上 IPTV 伺服器，排查發現是城域網中的設備丟包了，城域網中的設備不計其數，對穩定性要求也非常嚴格，不可能一台台排查，怎麼辦呢？

我接到這個 case，發現還是蠻有趣的，寫下來分享給大家。

中醫講究望聞問切，我們來學習一下中醫的做法診斷網路故障。

望

先來看看網路的拓撲圖：

我們可以輕易發現，鏈路上變化的只有用戶出口的設備，由一台普通的路由器更換成一台防火牆設備，然後就發生了故障，此時基本可以把問題定位在這台新換上去的防火牆上了，它應該就是罪魁禍首。（此時應該拿起電話，找到設備客服，說：「你們設備有故障啊，拉一台新的過來~」，哈哈哈哈）

聞

聽聽機器運轉的噪音，思考一下人生，由於沒去現場，聞就算了。

問

問一下其他的工程師做了什麼排查。

根據工程師反饋：

• 普通路由器（正常情況）：PPPoE 撥號正常，若要使用 IPTV 還需要進行二次認證，二次認證也正常，可以正常觀看 IPTV 。
• 防火牆（不正常情況）：PPPoE 撥號正常，IPTV 二次認證失敗，無法使用 IPTV。
• 防火牆配置靜態 NAT ，故障依舊。

應該可以排除 NAT 導致的故障，而且原來的路由器也是有 NAT 的，原來的路由器能正常二次認證沒有問題，那也不應該是 NAT 導致的問題。再者，二次認證是在 TCP 上進行的，TCP過 NAT 完全沒有問題。那麼問題出在哪裡呢？

這種時候當然要抓個包看看了！

切

網路如人體，非常複雜，很多時候不可能打開來仔細的看看到底發生了，但就像醫生有聽診器一樣，工程師們有抓包工具，可以探聽網路上發生了什麼，我們來給網路號號脈。

抓包點：

為了便於敘述，抓包點從左到右分別編號為 1、2、3。

簡單介紹一下抓包發現的情況：

• 2、3 抓包文件除源目 IP 、源目埠外，數據一致（NAT正常現象）
• IPTV 二次認證時 1 點處發出一數據包，未到達 2 點，隨後 1 點多次重傳，均未能到達 2 點。

也就是說，到用戶側防火牆前面的包都到用戶側防火牆後面去了，防火牆並沒有攔下任何的包，毫無疑問，包被城域網的設備丟了。

我們剛剛開始的時候懷疑是防火牆丟了包，防火牆是罪魁禍首，現在發現防火牆沒有丟掉任何的包。那麼是誰丟了數據包？為什麼換了一台用戶側出口設備城域網就開始丟包了呢？城域網難道還挑設備的嗎？

設備商之間有不為人知的交易？（大誤！）

換上那台正常的普通路由器，再抓一次包，問題消失了。

這到底是為什麼呢？

大家可以自己先猜一猜再看後面的分析，真的挺有意思的。

密

封

線

內

不

要

答

題

病情分析

一句話： Maximum segment size （MSS） 惹的禍。

比較正常情況和非正常情況下的 3 處的抓包，發現 TCP 握手時，MSS 值不一樣，正常時 MSS 值為1440，不正常時 MSS 值為1460。

由於這樣那樣的原因，正常的時候沒能在 IPTV 平台出口抓包，但分析別的抓包文件，可以輕易知道，機頂盒和平台的 TCP 的 MSS 值均為1460。

那麼 MSS 值決定了什麼呢？摘錄一段 TCP/IP 詳解中的內容。

最大報文段長度（MSS）表示 TCP 傳往另一端的最大塊的數據的長度。當一個連接建立時，連接的雙方都要通告各自的 MSS 。

也就是說，MSS 值指的是TCP 每個報文段的最大的 Payload 的長度。那這個長度的變化為什麼會導致城域網中的設備丟包呢？

複習一下 TCP/IP 協議以及PPPoE的頭部長度：

• IP 頭部 20 byte
• TCP 頭部 20 byte
• PPPoE 頭部 8 byte

那如果 TCP 報文段里的數據長度是 1460 會發生什麼呢？

1460 + 20 + 20 = 1500

1500 這個值非常熟悉，乙太網 MTU 值。也就是說，默認情況下， IPTV 平台會發送一個 1500 的 IP 包給機頂盒。

回去看一下拓撲圖，機頂盒和 IPTV 平台之間有一台 MSE ，他要把 IP 包封裝成 PPPoE 發過去，這裡問題來了。

1460 + 20 + 20 + 8 = 1508 > 1500

那已經超過了鏈路的 MTU 值，可以判斷，MSE 丟了數據包。

而普通路由器打開了 TCP-MSS 值修改，當兩端進行 TCP 協商時，偷偷的把 MSS 值改成了 1440 ，避免了超過鏈路MTU 的情況。

這裡還有一個疑問是：為什麼 MSE 不進行 IP 分片，而是直接丟包呢？

打開 1 點處的抓包文件，可以發現，IPTV 平台發出包的 DF 位為 1 ，MSE 看見設置了 DF 位，自然就不會進行 IP 分片了。

處方

開啟防火牆的修改 TCP-MSS 功能，設置值為 1452 或更小。

上醫治未病

當鏈路上的設備會有某些封裝導致包變長的時候，要注意檢查 TCP-MSS 值修改有沒有正確配置。儘可能的去避免 IP 分片。

作者：冇創意

禁止轉載。