網(wǎng)絡丟包診斷與分析的現(xiàn)實與理想
自從有了網(wǎng)絡便有了網(wǎng)絡故障，網(wǎng)絡故障的***體現(xiàn)是丟包。如何對丟包進行診斷一直是一個令工程師頭疼的問題，可關(guān)注丟包原因分析的人卻非常的少。
現(xiàn)實
目前對于網(wǎng)絡中出現(xiàn)丟包的傳統(tǒng)處理步驟如下：
- 首先，確定丟包的設備。
- 然后，確定報文在該設備的處理流程。
- ***，一一核對對應處理流程的轉(zhuǎn)發(fā)表項(從軟件表項到硬件表項)。
也許你會覺得一一核對轉(zhuǎn)發(fā)流程表項太慢太麻煩，熟悉芯片的處理流程和功能之后你會找到如下一種處理方式：
- 首先，還是要確定丟包的設備。
- 然后，利用芯片提供的一些diagnosis功能進行確認，例如Broadcom的Flexible Counter，Mediatek的drop statitics等。
- ***，根據(jù)硬件的丟包原因去確認丟包的真實原因。
雖然看起來步驟很明確，但是執(zhí)行這些步驟需要對其中的流程以及機制了解的非常清楚，才能準確的診斷出丟包的原因。目前各個廠商對于丟包的診斷沒有更進一步的手段和方案。
為什么會這樣
是什么導致了網(wǎng)絡診斷的手段在長時間都沒有什么實質(zhì)性的發(fā)展呢?主要是因為以下幾個方面：
NOS本身的封閉性
- NOS廠商不愿暴露更多的細節(jié)給客戶
- NOS以前都是一些專用的系統(tǒng)，無法提供像服務器上一些便捷的手段如tcpdump
- NOS架構(gòu)通常都是mips/ppc架構(gòu)，其計算能力無法與x86相比
芯片廠商提供的diagnosis具有相當?shù)木窒扌浴?/strong>
- Flexible counter提供一個基于丟包原因的統(tǒng)計，可以基于端口統(tǒng)計多個丟包原因的報文個數(shù)。但是如果你想知道具體的丟包原因需要調(diào)整reason bitmap，需要對照手冊進行調(diào)整bitmap。
- Drop statics提供了端口丟包的統(tǒng)計，同時提供了丟包的reason status bitmap(即發(fā)生的丟包原因)。但是可惜的這個reason status bitmap是全局的，不是基于端口的，存在一定的干擾性。
理想
想象一下當你發(fā)現(xiàn)網(wǎng)絡不通的時候，你打開一個應用程序，這個程序告訴你，你的某個報文在網(wǎng)絡中的某一臺設備的某個口上因為某種原因丟棄了，然后你核對對應配置，發(fā)現(xiàn)配置被人修改了，然后修改配置后就通了。前后用不上幾分鐘就能解決問題。相比傳統(tǒng)的兩種方式，是不是要簡便的多了?
為什么這么做
看到這里人們不禁要問了，為什么傳統(tǒng)的網(wǎng)絡廠商都沒有這么做，應該是沒有辦法做到這樣的吧?
而今是一個開放網(wǎng)絡操作系統(tǒng)盛行的時代，隨之一起而來的是白盒交換機，白盒交換機的控制面CPU不再是局限在傳統(tǒng)的mips/ppc的架構(gòu)，支持x86、ARM的有，而交換機服務器化的趨勢也在醞釀，可以預計將來x86的交換機將會大行其道。
總的來看這個時代有兩個重要的趨勢：
- 開放性，用戶將會越來越注重系統(tǒng)的開發(fā)以及開發(fā)性。
- x86釋放了強大的計算能力，如何利用?
診斷與分析的難度和開放網(wǎng)絡的趨勢使得開發(fā)便利的診斷分析成為了一種必要，同時這也是一個機會。
怎么做
理想是一步步實現(xiàn)的，要實現(xiàn)這個理想需按如下幾步走：
- 能夠在控制臺上通過show命令看到最近一段時間內(nèi)的丟包的基本信息，并能夠?qū)⑦@些基本信息導出。
- 在控制臺上通過show命令看到最近一段時間內(nèi)丟包的詳細信息，并支持導出的基本信息的解析(wireshark插件)。
- 部署應用程序收集并按照規(guī)則統(tǒng)計丟包的信息。
一小步
對于丟包我們首先想到的是用戶關(guān)注是哪個端口在發(fā)生丟包，其丟包原因是什么，因此對show命令的內(nèi)容進行了如下的定義。
在設備上緩存這些丟包的case，并更新其***發(fā)現(xiàn)的時間。
接下來就是如何獲取這些丟包的信息，針對數(shù)據(jù)中心場景下20多種丟包原因進行分析，首先將其分為兩類：
- 情況一：丟包，cpu可以獲取原始報文的
- 情況二：丟包，cpu無法獲取原始報文的
情況一
通常轉(zhuǎn)發(fā)流水線中的大部分的丟包都可以獲取到其丟棄的原始報文，對應的有：
- 報文攜帶的VLAN未創(chuàng)建
- 端口不在對應的VLAN中
- 路由查找失敗
- l3 mtu檢查失敗
- stp 狀態(tài)
- 其他等
對于這些的丟包情況，可以從芯片獲取其原始的報文進行分析然后歸類統(tǒng)計。
情況二
在整個轉(zhuǎn)發(fā)流水線中也存在部分的丟包是無法提供原始報文的，對應的有：
- 超過buffer水線丟包
- 解析錯誤丟包
- 包校驗錯誤丟包
- ingress mtu丟包(看mtu檢查實現(xiàn)的方式而定)
對于這些丟包情況，可以從芯片的狀態(tài)信息中獲取對應的狀態(tài)，然后進行歸類統(tǒng)計。
同時為了支持將信息導出以為后續(xù)的分析提供支持，定義了agent導出丟包信息的格式，如下：
上述結(jié)構(gòu)中包含了截斷的前128字節(jié)的報文(如果能有原始報文)，這里主要是提供給應用程序分析使用。
進一步
完成***步之后，對于部分場景依然只能得到一個模糊的丟包的原因，只能對應上直接原因，對于找到根本原因還差一步，例如l3 lookup miss，如果無法知道報文的目的口ip，那么就無法繼續(xù)分析下去，因此，用戶查看對應的報文的詳細信息的需要在此時變的非常重要。
同樣我們需要分析報文信息哪些在這種場景下對用戶是必要的，分析的結(jié)果如下：
- 二層頭信息，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對應最近一個丟包的報文的解析結(jié)果。在cli上就可以通過命令將對應的信息以以下格式展示出來。
以上給出了三個示例，其中兩個是可以獲取到原始的丟棄的報文信息的，另一個是無法獲取的。
同樣對于導出的信息，也需要支持解析，通過wireshark的lua插件進行展示，展示的結(jié)果如下所示。
一大步
將全網(wǎng)的丟包信息全部匯集到一個collector上進行統(tǒng)計分析，然后提供以下方式的統(tǒng)計顯示，并可盡量還原其對應的流量大小。
- 基于物理設備統(tǒng)計。
- 基于源目的ip的統(tǒng)計。
- 基于源目的端口的統(tǒng)計。
- 基于丟包原因的統(tǒng)計。
通過這些統(tǒng)計的方式可以發(fā)現(xiàn)網(wǎng)絡中存在的危險和配置問題(like kill all possible warning in coding)，整個網(wǎng)絡盡在掌握。
擁有了這個網(wǎng)絡診斷分析功能之后，我們只需要簡單的兩步就可以確定丟包的原因：
- show sdrop查看丟包的基本信息。
- 如果***步還是沒有提供足夠的信息，那么show sdrop detail中的包含的報文的相關(guān)信息將會準確提示其原因。
云啟科技的ConnetOS已經(jīng)完成了前面的兩階段，第三階段正在規(guī)劃中，wireshark插件已經(jīng)開放到github，可前往了解更多。
作者簡介：陳虎，云啟科技高級系統(tǒng)工程師 曾參與多款高端交換機的研發(fā)，熟悉Broadcom、Dune、Mediatek系列芯片的架構(gòu)及轉(zhuǎn)發(fā)流水線。
