自從有了網絡便有了網絡故障，網絡故障的***體現是丟包。如何對丟包進行診斷一直是一個令工程師頭疼的問題，可關注丟包原因分析的人卻非常的少。

現實

目前對于網絡中出現丟包的傳統處理步驟如下：

• 首先，確定丟包的設備。
• 然后，確定報文在該設備的處理流程。
• ***，一一核對對應處理流程的轉發表項(從軟件表項到硬件表項)。

[[192263]]

也許你會覺得一一核對轉發流程表項太慢太麻煩，熟悉芯片的處理流程和功能之后你會找到如下一種處理方式：

• 首先，還是要確定丟包的設備。
• 然后，利用芯片提供的一些diagnosis功能進行確認，例如Broadcom的Flexible Counter，Mediatek的drop statitics等。
• ***，根據硬件的丟包原因去確認丟包的真實原因。

雖然看起來步驟很明確，但是執行這些步驟需要對其中的流程以及機制了解的非常清楚，才能準確的診斷出丟包的原因。目前各個廠商對于丟包的診斷沒有更進一步的手段和方案。

為什么會這樣

是什么導致了網絡診斷的手段在長時間都沒有什么實質性的發展呢?主要是因為以下幾個方面：

NOS本身的封閉性

• NOS廠商不愿暴露更多的細節給客戶
• NOS以前都是一些專用的系統，無法提供像服務器上一些便捷的手段如tcpdump
• NOS架構通常都是mips/ppc架構，其計算能力無法與x86相比

芯片廠商提供的diagnosis具有相當的局限性。

• Flexible counter提供一個基于丟包原因的統計，可以基于端口統計多個丟包原因的報文個數。但是如果你想知道具體的丟包原因需要調整reason bitmap，需要對照手冊進行調整bitmap。
• Drop statics提供了端口丟包的統計，同時提供了丟包的reason status bitmap(即發生的丟包原因)。但是可惜的這個reason status bitmap是全局的，不是基于端口的，存在一定的干擾性。

理想

想象一下當你發現網絡不通的時候，你打開一個應用程序，這個程序告訴你，你的某個報文在網絡中的某一臺設備的某個口上因為某種原因丟棄了，然后你核對對應配置，發現配置被人修改了，然后修改配置后就通了。前后用不上幾分鐘就能解決問題。相比傳統的兩種方式，是不是要簡便的多了?

為什么這么做

看到這里人們不禁要問了，為什么傳統的網絡廠商都沒有這么做，應該是沒有辦法做到這樣的吧?

而今是一個開放網絡操作系統盛行的時代，隨之一起而來的是白盒交換機，白盒交換機的控制面CPU不再是局限在傳統的mips/ppc的架構，支持x86、ARM的有，而交換機服務器化的趨勢也在醞釀，可以預計將來x86的交換機將會大行其道。

總的來看這個時代有兩個重要的趨勢：

• 開放性，用戶將會越來越注重系統的開發以及開發性。
• x86釋放了強大的計算能力，如何利用?

診斷與分析的難度和開放網絡的趨勢使得開發便利的診斷分析成為了一種必要，同時這也是一個機會。

怎么做

理想是一步步實現的，要實現這個理想需按如下幾步走：

• 能夠在控制臺上通過show命令看到最近一段時間內的丟包的基本信息，并能夠將這些基本信息導出。
• 在控制臺上通過show命令看到最近一段時間內丟包的詳細信息，并支持導出的基本信息的解析(wireshark插件)。
• 部署應用程序收集并按照規則統計丟包的信息。

一小步

對于丟包我們首先想到的是用戶關注是哪個端口在發生丟包，其丟包原因是什么，因此對show命令的內容進行了如下的定義。

在設備上緩存這些丟包的case，并更新其***發現的時間。

接下來就是如何獲取這些丟包的信息，針對數據中心場景下20多種丟包原因進行分析，首先將其分為兩類：

• 情況一：丟包，cpu可以獲取原始報文的
• 情況二：丟包，cpu無法獲取原始報文的

情況一

通常轉發流水線中的大部分的丟包都可以獲取到其丟棄的原始報文，對應的有：

• 報文攜帶的VLAN未創建
• 端口不在對應的VLAN中
• 路由查找失敗
• l3 mtu檢查失敗
• stp 狀態
• 其他等

對于這些的丟包情況，可以從芯片獲取其原始的報文進行分析然后歸類統計。

情況二

在整個轉發流水線中也存在部分的丟包是無法提供原始報文的，對應的有：

• 超過buffer水線丟包
• 解析錯誤丟包
• 包校驗錯誤丟包
• ingress mtu丟包(看mtu檢查實現的方式而定)

對于這些丟包情況，可以從芯片的狀態信息中獲取對應的狀態，然后進行歸類統計。

同時為了支持將信息導出以為后續的分析提供支持，定義了agent導出丟包信息的格式，如下：

上述結構中包含了截斷的前128字節的報文(如果能有原始報文)，這里主要是提供給應用程序分析使用。

進一步

完成***步之后，對于部分場景依然只能得到一個模糊的丟包的原因，只能對應上直接原因，對于找到根本原因還差一步，例如l3 lookup miss，如果無法知道報文的目的口ip，那么就無法繼續分析下去，因此，用戶查看對應的報文的詳細信息的需要在此時變的非常重要。

同樣我們需要分析報文信息哪些在這種場景下對用戶是必要的，分析的結果如下：

• 二層頭信息，smac、dmac、etype、length。
• 802.1q tag信息，tpid、VLAN id。
• 三層頭信息，sip、dip、tos、ip length、ttl、ip protocol。
• arp頭信息，smac、tmac、sip、tip、op_code。
• 四層頭信息，source port、dest port。

于是在設備的緩存的丟包case中不僅保存了丟包的metadata信息，還保存了該case對應最近一個丟包的報文的解析結果。在cli上就可以通過命令將對應的信息以以下格式展示出來。

以上給出了三個示例，其中兩個是可以獲取到原始的丟棄的報文信息的，另一個是無法獲取的。

同樣對于導出的信息，也需要支持解析，通過wireshark的lua插件進行展示，展示的結果如下所示。

一大步

將全網的丟包信息全部匯集到一個collector上進行統計分析，然后提供以下方式的統計顯示，并可盡量還原其對應的流量大小。

• 基于物理設備統計。
• 基于源目的ip的統計。
• 基于源目的端口的統計。
• 基于丟包原因的統計。

通過這些統計的方式可以發現網絡中存在的危險和配置問題(like kill all possible warning in coding)，整個網絡盡在掌握。

擁有了這個網絡診斷分析功能之后，我們只需要簡單的兩步就可以確定丟包的原因：

• show sdrop查看丟包的基本信息。
• 如果***步還是沒有提供足夠的信息，那么show sdrop detail中的包含的報文的相關信息將會準確提示其原因。

云啟科技的ConnetOS已經完成了前面的兩階段，第三階段正在規劃中，wireshark插件已經開放到github，可前往了解更多。

作者簡介：陳虎，云啟科技高級系統工程師 曾參與多款高端交換機的研發，熟悉Broadcom、Dune、Mediatek系列芯片的架構及轉發流水線。