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

理想

想象一下當(dāng)你發(fā)現(xiàn)網(wǎng)絡(luò)不通的時(shí)候，你打開一個應(yīng)用程序，這個程序告訴你，你的某個報(bào)文在網(wǎng)絡(luò)中的某一臺設(shè)備的某個口上因?yàn)槟撤N原因丟棄了，然后你核對對應(yīng)配置，發(fā)現(xiàn)配置被人修改了，然后修改配置后就通了。前后用不上幾分鐘就能解決問題。相比傳統(tǒng)的兩種方式，是不是要簡便的多了?

為什么這么做

看到這里人們不禁要問了，為什么傳統(tǒng)的網(wǎng)絡(luò)廠商都沒有這么做，應(yīng)該是沒有辦法做到這樣的吧?

而今是一個開放網(wǎng)絡(luò)操作系統(tǒng)盛行的時(shí)代，隨之一起而來的是白盒交換機(jī)，白盒交換機(jī)的控制面CPU不再是局限在傳統(tǒng)的mips/ppc的架構(gòu)，支持x86、ARM的有，而交換機(jī)服務(wù)器化的趨勢也在醞釀，可以預(yù)計(jì)將來x86的交換機(jī)將會大行其道。

總的來看這個時(shí)代有兩個重要的趨勢：

• 開放性，用戶將會越來越注重系統(tǒng)的開發(fā)以及開發(fā)性。
• x86釋放了強(qiáng)大的計(jì)算能力，如何利用?

診斷與分析的難度和開放網(wǎng)絡(luò)的趨勢使得開發(fā)便利的診斷分析成為了一種必要，同時(shí)這也是一個機(jī)會。

怎么做

理想是一步步實(shí)現(xiàn)的，要實(shí)現(xiàn)這個理想需按如下幾步走：

• 能夠在控制臺上通過show命令看到最近一段時(shí)間內(nèi)的丟包的基本信息，并能夠?qū)⑦@些基本信息導(dǎo)出。
• 在控制臺上通過show命令看到最近一段時(shí)間內(nèi)丟包的詳細(xì)信息，并支持導(dǎo)出的基本信息的解析(wireshark插件)。
• 部署應(yīng)用程序收集并按照規(guī)則統(tǒng)計(jì)丟包的信息。

一小步

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

在設(shè)備上緩存這些丟包的case，并更新其***發(fā)現(xiàn)的時(shí)間。

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

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

情況一

通常轉(zhuǎn)發(fā)流水線中的大部分的丟包都可以獲取到其丟棄的原始報(bào)文，對應(yīng)的有：

• 報(bào)文攜帶的VLAN未創(chuàng)建
• 端口不在對應(yīng)的VLAN中
• 路由查找失敗
• l3 mtu檢查失敗
• stp 狀態(tài)
• 其他等

對于這些的丟包情況，可以從芯片獲取其原始的報(bào)文進(jìn)行分析然后歸類統(tǒng)計(jì)。

情況二

在整個轉(zhuǎn)發(fā)流水線中也存在部分的丟包是無法提供原始報(bào)文的，對應(yīng)的有：

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

對于這些丟包情況，可以從芯片的狀態(tài)信息中獲取對應(yīng)的狀態(tài)，然后進(jìn)行歸類統(tǒng)計(jì)。

同時(shí)為了支持將信息導(dǎo)出以為后續(xù)的分析提供支持，定義了agent導(dǎo)出丟包信息的格式，如下：

上述結(jié)構(gòu)中包含了截?cái)嗟那?28字節(jié)的報(bào)文(如果能有原始報(bào)文)，這里主要是提供給應(yīng)用程序分析使用。

進(jìn)一步

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

同樣我們需要分析報(bào)文信息哪些在這種場景下對用戶是必要的，分析的結(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。

于是在設(shè)備的緩存的丟包c(diǎn)ase中不僅保存了丟包的metadata信息，還保存了該case對應(yīng)最近一個丟包的報(bào)文的解析結(jié)果。在cli上就可以通過命令將對應(yīng)的信息以以下格式展示出來。

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

同樣對于導(dǎo)出的信息，也需要支持解析，通過wireshark的lua插件進(jìn)行展示，展示的結(jié)果如下所示。

一大步

將全網(wǎng)的丟包信息全部匯集到一個collector上進(jìn)行統(tǒng)計(jì)分析，然后提供以下方式的統(tǒng)計(jì)顯示，并可盡量還原其對應(yīng)的流量大小。

• 基于物理設(shè)備統(tǒng)計(jì)。
• 基于源目的ip的統(tǒng)計(jì)。
• 基于源目的端口的統(tǒng)計(jì)。
• 基于丟包原因的統(tǒng)計(jì)。

通過這些統(tǒng)計(jì)的方式可以發(fā)現(xiàn)網(wǎng)絡(luò)中存在的危險(xiǎn)和配置問題(like kill all possible warning in coding)，整個網(wǎng)絡(luò)盡在掌握。

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

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

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

作者簡介：陳虎，云啟科技高級系統(tǒng)工程師 曾參與多款高端交換機(jī)的研發(fā)，熟悉Broadcom、Dune、Mediatek系列芯片的架構(gòu)及轉(zhuǎn)發(fā)流水線。