從今天開始，本人(ipdata)將陸續發佈系列網絡丟包問題分析處理的技術文章。該系列文章來源於《網絡丟包現象分析處理指導書》，主要分成三大部分：
第一部分：講解從產生網絡丟包問題的原因來看，網絡丟包問題大致可以分爲六大類因素，1、網絡設備軟、硬件問題；2、線路傳輸質量差引起丟包；3、網絡設備配置不合理導致丟包；4、網絡設計不合理導致丟包；5、人爲***、廣播氾濫造成的丟包；6、網絡環境造成的丟包。對於每類丟包原因配置以大量的案例進行詳細的說明。
第二部分：主要有三方面的內容，一是深入剖析網絡丟包現象並加以總結；二是網絡丟包的一般處理步驟；最後就是講解網絡故障處理中相關工具使用的注意事項。
第三部分：四個故障案例處理過程分析。應該說是對前面兩部分內容的一個綜合應用。
該系列文章的原始版本是原GW的HB老大當年的手稿，經過與原作者協商，同意在[url]www.ipdata.cn[/url]網站上發佈。爲此非常感謝HB，對HB的無私精神表示深深的感謝。
網絡丟包問題往往是沒有規律的故障，對於沒有固定規律的故障，咱們技術工程師往往有吃力不討好的痛苦！如本手稿中環境因素導致丟包案例中的電源浪涌，時值北方的冬季，加之故障這個魔鬼出現的時間是晚上7:00-9:00這個時段，現場工程師在用戶單元樓道可以用飢寒交迫來形容！在此感謝爲本手冊付出了無數心血的原GW技術資源部的XDJM，正是他們的加班熬夜，將經歷過故障進行總結，纔能有今天這份珍貴的手冊。
本手冊是在原《網絡丟包現象分析處理指導書》基礎上進行部分的改動，謹此獻給所有原GW技術資源部的XDJM，獻給那段美好的光陰！獻給那段偶們一起共同奮鬥的歲月！
網絡丟包現象分類：網絡設備軟、硬件問題導致丟包
首先對出現過丟包的案例進行描述並給出解決辦法，同時對丟包問題進行分類，主要加強大家對丟包現象的感性認識。在後續的章節中再做深入的剖析，並提供問題的解決思路。
1、uHammer24百兆光口/電口模塊問題
問題描述：uHammer24 芯片爲C版且PCB爲2.33版的設備百兆端口模塊第25口，在高溫及常溫下會出現嚴重丟包，高溫條件下尤爲明顯。
C版(PCB v2.33)uHammer24 port 25丟包示意圖
C版(PCB v2.33)uHammer24 port 25丟包示意圖
問題解釋：uHammer24的硬件分B版和C版，C版uHammer24的百兆端口模塊25口的接口電路（千兆端口不受影響）在高溫條件下（50ºC以上）不穩定,造成丟包；B版在高溫條件下（達到60ºC）仍不會出現丟包。
問題解決：正確識別B版和C版設備。C版設備儘量使用在不用百兆端口模塊的環境，如果一定要使用百兆模塊的話，則建議更換B版設備或採用PCB爲2.44/2.55的設備。
備註：此類丟包由於硬件芯片（產品序列號的第九到第十二位爲“A233”）離散性較大引起，產品的PCB已做修改，新生產的設備，同樣爲C版，如果產品序列號的第九到第十二位爲“A244”或“A255”則不存在此bug。
重要提示：如果出現某個端口丟包，建議更換端口做測試，查看丟包現象是否是個別端口問題。
問題描述：部分uHammer1008v（或者VDSL modem）由於晶振品質問題，導致與uHammer3100互連，距離較長時，出現嚴重丟包或同步不上。
問題解釋：晶振品質不好，產生的脈衝信號在長距離傳輸時崎變較大，使得接收端無法識別。
問題解決：uHammer1008v(VDSL modem)更換品質較好的晶振。
備註：此類丟包也屬於暫時性問題，更換硬件器件後將不再復現。
網絡的拓撲如下
RiverStone3000（L3）作爲網絡的核心交換機，Flex16i匯聚了20幾臺接入層交換機u2，Flex16i只作爲二層透傳，所有用戶的網關均指向Rs3000。網絡穩定運行了3天后，Flex16i的下連用戶出現5％丟包。Test pc ping 210.177.208.163或164均出現5％左右的丟包。Rs3000上ping server 出現5％的報文出現延時時間達到1秒。可以判斷，客戶端丟包是由於icmp報文超時的緣故。xiong2127 51cto技術博客
RiverStone3000（L3）作爲網絡的核心交換機，Flex16i匯聚了20幾臺接入層交換機u2，Flex16i只作爲二層透傳，所有用戶的網關均指向Rs3000。網絡穩定運行了3天后，Flex16i的下連用戶出現5％丟包。Test pc ping 210.177.208.163或164均出現5％左右的丟包。Rs3000上ping server 出現5％的報文出現延時時間達到1秒。可以判斷，客戶端丟包是由於icmp報文超時的緣故。xiong2127 51cto技術博客
問題解釋：爲了更準確地定位問題，做了如下測試環境。
用Test pc ping pc2同樣出現5％的丟包率。Rs3000 ping test u2 5％報文的延時在1秒左右。在測試過程中，測試過Flex16i同一設備（510芯片）和不同設備（510芯片）下的二層用戶互ping，同樣出現5％丟包。顯然可以排除光纖、u2等其他設備引起該問題。實際環境和測試環境中RS3000直接pingFLex16i的IP地址均沒有出現報文延時時間長的現象。但ping Flex16i下連的u2則出現5％左右的報文延時長。因此，可以判斷問題出現在Flex16i的二層轉發上。
問題解決：將Flex16i reboot，故障依然；將Flex16i關電重啓，故障消失，網絡恢復正常！熱啓動和冷啓動對於Flex16i來說，其硬件的初始化過程不一樣，冷啓動對硬件的初始化處理比較徹底，是否硬件還存在深層的Bug，需要研發人員做進一步的定位。
備註：雖然該故障定位在Flex16i上，但是是什麼原因引起Flex16i的二層轉發異常，並未能給出一個圓滿的答案，不能不說是個遺憾。不過，這裏要強調的是故障的定位處理，事實上這樣的工作已經有利於研發對產品的改進工作了。
問題描述：uHammer24 軟件版本爲v1.323以下的版本的部分設備存在着14、18、22端口嚴重丟包，下連用戶上網速度慢。在v1.323版本出現個別端口丟包的現象已很少見（到目前爲止市場上反饋過2例v1.323 port 14有丟包現象），升級爲v1.4版本可以徹底解決。
問題解釋：某些u24的phy芯片對時鐘很敏感，如果交換機主板硬件出現頻差，則phy芯片工作就不正常。目前v1.323版本中通過定期寫寄存器去修正頻差產生的影響。但是V1.323中輪循的時間過長，phy芯片的寄存器沒有及時得到更新，所以會產生很明顯的link down現象。在v1.4版本中，縮短了輪詢時間，到目前爲止未發現個別端口丟包現象。
問題解決：升級到v1.4版本可徹底解決此問題。
備註：對於新上設備，要求最低可用版本V1.323。
問題描述：Flex5010 v1.0網段表設置算法缺乏考慮路由最長匹配原則，當路由條目存在多個匹配信息時，容易出現數據包循環轉發，表現爲用戶上網速度慢、丟包甚至網絡不通。拓撲結構見下圖：(爲了說明問題，網絡拓撲已做簡化)
上圖爲一大型行政機關的網絡拓撲圖，該單位網絡爲專網，與Internet沒有互連，採用10.0.0.0/8的地址段。其中Flex5010以千兆光口與Big800互連，Big800端分配到10.94.0.0/16的網段，Flex5010端分配到10.95.0.0/16的網段。
Flex5010軟件路由表存在的條目如下：
10.94.101.4/30直連
10.95.1.0/24直連
10.95.2.0/24下一跳10.95.1.253
10.0.0.0/8下一跳10.94.101.5
10.94.101.4/30直連
10.95.1.0/24直連
10.95.2.0/24下一跳10.95.1.253
10.0.0.0/8下一跳10.94.101.5
而Flex5010v1.0的硬件網段表在開機時是空白的，只有當軟件路由表的路由條目使用過一次後，纔將其置入硬件網段表中。同時，一個報文在Flex5010路由時，是先去匹配硬件網段表，如果匹配不到纔去匹配軟件路由表。
考慮一種特殊的情況：10.0.0.0/8的路由早於10.95.2.0/24置入硬件網段表。即此時的硬件網段表只有一項：
10.0.0.0/8下一跳10.94.101.5
10.0.0.0/8下一跳10.94.101.5
此時，當Flex5010下連的一臺主機（10.95.1.1）去與10.95.2.0/24網段的設備通信時，則會出現:10.95.1.1發給10.95.2.0/24的報文到達Flex5010後，Flex5010查找硬件網段表，首先匹配到10.0.0.0/8的條目，因此該報文轉發給10.94.101.5(Big800),Big800查找路由表，發現該報文應該轉發給Flex5010，Flex5010再此將報文轉發給Big800，於是，此類報文在Flex5010和Big800之間循環轉發，指導TTL值爲0，設備纔將報文丟棄。
由於大量的廢棄報文在Big800和Flex5010的鏈路傳送（一個上述的報文在該鏈路需要轉發250多遍），因此造成鏈路擁塞，網絡丟包、不通。
問題解釋：先激活先置表的算法違背了最長匹配算法，因此，在多路由匹配的環境下會出現上述問題。
問題解決：OS爲 v1.1以上版本可解決此問題。V1.1不再採用先激活先置入網段表的算法，而是一開始則將所有路由條目置入網段表中（除了路由條目超過16條的情況）；如果路由條目超過16條則放棄網段表不用完全走軟路由（關於路由條目超過16條後如何充分發揮Flex5010的硬件資源請詳見《Flex5010硬件表設置方案》。
備註：此類問題由於是設備軟件bug引起，因此準確定位問題比較困難。往往通過捕獲鏈路上的數據流定位出現問題的設備，再深入分析設備的硬件、軟件路由信息，任務、進程等等，最終才能確定問題所在。