網(wǎng)絡丟包現(xiàn)象分析處理指導書

1、“網(wǎng)絡丟包現(xiàn)象是常見的網(wǎng)絡故障，但弓I起丟包的原因卻多種多樣、 千奇百怪。因此對于此類故障的解決，要求處理人員洞悉網(wǎng)絡基礎理 論、了解不同廠家產(chǎn)品特性，有耐心、深入地進行分析定位?！币灰?一網(wǎng)絡丟包現(xiàn)象分析處理指導書摘錄從今天開始，本A(ipdata)將陸續(xù)發(fā)布系列網(wǎng)絡丟包問題分析處理 的技術文章。該系列文章來源于網(wǎng)絡丟包現(xiàn)象分析處理指導書， 主要分成三大部分：第一部分：講解從產(chǎn)生網(wǎng)絡丟包問題的原因來看，網(wǎng)絡丟包問題大致 可以分為六大類因素，1、網(wǎng)絡設備軟、硬件問題；2、線路傳輸質(zhì) 量差引起丟包；3、網(wǎng)絡設備配置不合理導致丟包；4、網(wǎng)絡設計不 合理導致丟包；5、人為攻擊、廣播泛濫造成的丟包；6

2、、網(wǎng)絡環(huán)境 造成的丟包。對于每類丟包原因配置以大量的案例進行詳細的說明。第二部分：主要有三方面的內(nèi)容，一是深入剖析網(wǎng)絡丟包現(xiàn)象并加以 總結；二是網(wǎng)絡丟包的一般處理步驟;最后就是講解網(wǎng)絡故障處理中 相關工具使用的注意事項。第三部分：四個故障案例處理過程分析。應該說是對前面兩部分內(nèi)容 的一個綜合應用。網(wǎng)絡丟包問題往往是沒有規(guī)律的故障，對于沒有固定規(guī)律的故障，咱 們技術工程師往往有吃力不討好的痛苦!如本手稿中環(huán)境因素導致丟 包案例中的電源浪涌，時值北方的冬季，加之故障這個魔鬼出現(xiàn)的時 間是晚上7:00-9:00這個時段，現(xiàn)場工程師在用戶單元樓道可以用 饑寒交迫來形容！網(wǎng)絡丟包現(xiàn)象分類：網(wǎng)絡設備軟、硬

3、件問題導致丟包首先對出現(xiàn)過丟包的案例進行描述并給出解決辦法，同時對丟包問題 進行分類，主要加強大家對丟包現(xiàn)象的感性認識。在后續(xù)的章節(jié)中再 做深入的剖析，并提供問題的解決思路。1、uHammer24百兆光口/電口模塊問題問題描述：uHammer24芯片為C版且PCB為2.33版的設備百 兆端口模塊第25 口，在高溫及常溫下會出現(xiàn)嚴重丟包，高溫條件下 尤為明顯。C 版(PCB v2.33)uHammer24 port 25丟包示意圖問題解釋：uHammer24的硬件分B版和C版，C版uHammer24 的百兆端口模塊25 口的接口電路（千兆端口不受影響）在高溫條件 下（50C以上）不穩(wěn)定，造成丟包

4、；B版在高溫條件下（達到60C） 仍不會出現(xiàn)丟包。問題解決：正確識別B版和C版設備。C版設備盡量使用在不用百 兆端口模塊的環(huán)境，如果一定要使用百兆模塊的話，則建議更換B 版設備或采用PCB為2.44/2.55的設備。備注：此類丟包由于硬件芯片（產(chǎn)品序列號的第九到第十二位為 “A233”）離散性較大引起，產(chǎn)品的PCB已做修改，新生產(chǎn)的設備， 同樣為C版，如果產(chǎn)品序列號的第九到第十二位為入244或“入255 則不存在此bug。重要提示：如果出現(xiàn)某個端口丟包，建議更換端口做測試，查看丟包 現(xiàn)象是否是個別端口問題。問題描述：部分uHammer1008v (或者VDSL modem)由于晶振品質(zhì)問題，導

5、致與uHammer3100互連，距離較長時，出現(xiàn)嚴重 丟包或同步不上。問題解釋：晶振品質(zhì)不好，產(chǎn)生的脈沖信號在長距離傳輸時崎變較大， 使得接收端無法識別。問題解決：uHammer1008v(VDSL modem)更換品質(zhì)較好的晶 振。備注：此類丟包也屬于暫時性問題，更換硬件器件后將不再復現(xiàn)。網(wǎng)絡的拓撲如下GvrJ ID. lT7.2tt&.124UMGvrJ ID. lT7.2tt&.124UMQirj2IDLl77.1Aa.1tflflTr*L L l-申匕I/ hs“ huinghrt P-22 ki44ihviCFTX JFriS蛙#侶小MM FlbufkrrtiFtrt 2*121Lm

6、.2VVrJJCrt 2*121Lm.2VVrJJC2核心交換機，F(xiàn)lex16i匯聚了RiverSto ne3000 ( L3)核心交換機，F(xiàn)lex16i匯聚了1S41272I. 177.29L L63?Z720幾臺接入層交換機u2, Flex16i只作為二層透傳，所有用戶的網(wǎng)關均指向Rs3000。網(wǎng)絡穩(wěn)定運行了3天后，F(xiàn)lex16i的下連用戶出 現(xiàn) 5%丟包。Test pc ping 210.177.208.163或 164 均出現(xiàn) 5% 左右的丟包。Rs3000上ping server出現(xiàn)5%的報文出現(xiàn)延時時 間達到1秒?？梢耘袛?，客戶端丟包是由于icmp報文超時的緣故。問題解釋：為了更準

7、確地定位問題，做了如下測試環(huán)境。用 Test pc ping pc2 同樣出現(xiàn) 5% 的丟包率Rs3000 ping test u2 5%報文的延時在1秒左右。在測試過程中，測試過Flex16i同一設 備（510芯片）和不同設備（510芯片）下的二層用戶互ping,同 樣出現(xiàn)5%丟包。顯然可以排除光纖、u2等其他設備引起該問題。實際環(huán)境和測試環(huán)境中RS3000直接pingFLex16i的IP地址均沒有出現(xiàn)報文延時時間長的現(xiàn)象。但ping Flex16i下連的u2則出現(xiàn) 5%左右的報文延時長。因此，可以判斷問題出現(xiàn)在Flex16i的二層 轉發(fā)上。問題解決：將Flex16i reboot,故障依然

8、；將Flex16i關電重啟，故障消失，網(wǎng)絡恢復正常！熱啟動和冷啟動對于Flex16i來說，其硬 件的初始化過程不一樣，冷啟動對硬件的初始化處理比較徹底，是否 硬件還存在深層的Bug，需要研發(fā)人員做進一步的定位。備注：雖然該故障定位在Flex16i上，但是是什么原因引起Flex16i 的二層轉發(fā)異常，并未能給出一個圓滿的答案，不能不說是個遺憾。 不過，這里要強調(diào)的是故障的定位處理，事實上這樣的工作已經(jīng)有利 于研發(fā)對產(chǎn)品的改進工作了。問題描述：uHammer24軟件版本為vl.323以下的版本的部分設 備存在著14、18、22端口嚴重丟包，下連用戶上網(wǎng)速度慢。在 vl.323版本出現(xiàn)個別端口丟包的

9、現(xiàn)象已很少見（到目前為止市場上 反饋過2例v1.323port14有丟包現(xiàn)象），升級為v1.4版本可以 徹底解決。問題解釋：某些u24的phy芯片對時鐘很敏感，如果交換機主板硬 件出現(xiàn)頻差，則phy芯片工作就不正常。目前v1.323版本中通過 定期寫寄存器去修正頻差產(chǎn)生的影響。但是V1.323中輪循的時間過 長，phy芯片的寄存器沒有及時得到更新，所以會產(chǎn)生很明顯的link down現(xiàn)象。在v1.4版本中，縮短了輪詢時間，到目前為止未發(fā)現(xiàn) 個別端口丟包現(xiàn)象。問題解決：升級到v1.4版本可徹底解決此問題。備注：對于新上設備，要求最低可用版本V1.323。問題描述：Flex5010 v1.0網(wǎng)段表

10、設置算法缺乏考慮路由最長匹配 原則，當路由條目存在多個匹配信息時，容易出現(xiàn)數(shù)據(jù)包循環(huán)轉發(fā)， 表現(xiàn)為用戶上網(wǎng)速度慢、丟包甚至網(wǎng)絡不通。拓撲結構見下圖：（為 了說明問題，網(wǎng)絡拓撲已做簡偈上圖為一大型行政機關的網(wǎng)絡拓撲圖，該單位網(wǎng)絡為專網(wǎng)，與Internet沒有互連，采用10.0.0.0/8的地址段。其中Flex5010 以千兆光口與Big800互連，Big800端分配到10.94.0.0/16的網(wǎng) 段，F(xiàn)lex5010端分配到10.95.0.0/16的網(wǎng)段。Flex5010軟件路由表存在的條目如下:10.94.101.4/30 直連10.95.1.0/24 直連10.95.2.0/24 下一跳 1

11、0.95.1.25310.0.0.0/8 下一跳 10.94.101.5而Flex5010v1.0的硬件網(wǎng)段表在開機時是空白的，只有當軟件路 由表的路由條目使用過一次后，才將其置入硬件網(wǎng)段表中。同時，- 個報文在Flex5010路由時，是先去匹配硬件網(wǎng)段表，如果匹配不到 才去匹配軟件路由表?？紤]一種特殊的情況：10.0.0.0/8的路由早于10.95.2.0/24置入 硬件網(wǎng)段表。即此時的硬件網(wǎng)段表只有一項： 10.0.0.0/8 下一跳 10.94.101.5此時，當Flex5010下連的一臺主機(10.95.1.1)去與 10.95.2.0/24網(wǎng)段的設備通信時，則會出現(xiàn)：10.95.1.

12、1發(fā)給 10.95.2.0/24的報文到達Flex5010后，F(xiàn)lex5010查找硬件網(wǎng)段 表，首先匹配到10.0.0.0/8的條目，因此該報文轉發(fā)給 10.94.101.5(Big800),Big800查找路由表，發(fā)現(xiàn)該報文應該轉發(fā) 給Flex5010，F(xiàn)lex5010再此將報文轉發(fā)給Big800，于是，此類 報文在Flex5010和Big800之間循環(huán)轉發(fā)，指導TTL值為0，設 備才將報文丟棄。由于大量的廢棄報文在Big800和Flex5010的鏈路傳送（一個上述 的報文在該鏈路需要轉發(fā)250多遍），因此造成鏈路擁塞，網(wǎng)絡丟 包、不通。問題解釋：先激活先置表的算法違背了最長匹配算法，因此，在多路 由匹配的環(huán)境下會出現(xiàn)上述問題。問題解決：OS為v1.1以上版本可解決此問題。V1.1不再采用先 激活先置入網(wǎng)段表的算法，而是一開始則將所有路由條目置入網(wǎng)段表 中