自從有了網絡便有了網絡故障，網絡故障的最大展現是丢包。如何對丢包進行診斷一直是一個令工程師頭疼的問題，可關注丢包原因分析的人卻非常的少。
現實
目前對于網絡中出現丢包的傳統處理步驟如下：
首先，确定丢包的裝置。
然後，确定封包在該裝置的處理流程。
最後，一一核對對應處理流程的轉發表項(從軟體表項到硬體表項)。
也許你會覺得一一核對轉發流程表項太慢太麻煩，熟悉晶片的處理流程和功能之後你會找到如下一種處理方式：
首先，還是要确定丢包的裝置。
然後，利用晶片提供的一些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，可前往了解更多。
作者：陳虎
來源：51cto