【前言】

　　【本篇為原創】網路遙感，Network telemetry，為什麼叫“telemetry”呢？我個人的理解是將網路中的資料進行一種“採集”，也就是實際上是一種網路資料的採集手段。由於工作需要，接觸了一些網路遙感方面的技術，本篇文章就來談一談主流的網路遙感技術。本篇文章會介紹傳統網路中基於“流”的遙感技術，以思科的Netflow技術為代表和IETF的IPFIX標準，再到最近比較流行的INT技術，INT技術會著重介紹思科的IOAM和華為的PBT兩種。

【場景】

　　網路遙感是一種網路資訊採集技術，目的是為了採集網路中的資訊，網路越大，出了問題越難排查，因此需要一些技術對網路進行史實的流量分析監控或是可以自動化排查網路中的“斷路”，並且在DCN網路中（Datacenter Network）更需要一套手段來實現對網路的監控與探測，對網路的實時監控需要一套技術來實現，那麼網路遙感就是用來解決這個問題而誕生的一種技術。網路遙感一般分為兩種，分別是主動探測和被動探測。被動探測以思科的Netflow

【主動探測】

　　主動探測，顧名思義，就是“主動去探測網路中的狀態”，為代表的以微軟Everflow系統中的guided probe元件為代表，微軟於2016年在SIGCOMM發了一篇名為《Packet-Level Telemetry in Large Datacenter Networks》文章，這篇文章主要介紹了微軟的一套實現資料包級別的網路遙感技術，感興趣的可以去google一下，我個人覺得寫的非常好的一篇文章。其中提到了一個重要元件，叫做“guided probe”

圖1.典型的虛擬網路拓撲

　　圖1是一個典型的虛擬網路拓撲，虛擬機器A到虛擬機器B需要經過三個虛擬交換機，兩個虛擬路由器，那麼假設某一時刻“正在發生”虛擬機器A到虛擬機器B發生了“斷路”導致虛擬機器A到虛擬機器B的業務流量不通，怎麼定位到具體發生故障的位置以及發生故障的原因呢？

　　微軟的guided probe和vmware的traceflow就是做這個事情的。guided probe會在VM A注入一種“探測資料包”，然後在網元上設定一些“探測識別點”，這個資料包每經過一個網元都會上傳狀態資訊，例如圖2.

圖2.主動探測的一種實現

　　以圖2為例，我在每一個網元的輸入和輸出設定一些“探測識別點”，“探測資料包”經過“探測識別點”會向控制器上傳狀態資訊，那麼假設虛擬機器A到虛擬機器B中的虛擬交換機3的輸入出發生故障，那麼最終上傳的資訊會缺少“虛擬交換機3的OUT”，那麼控制器就可以判斷出虛擬交換機3處存在“正在發生“的故障，那麼就可以通過北向通道告知管理面，管理面再告知使用者，或直接發出告警。

　　當然還不止這樣，如果資料面是自家公司研發的話還有一種升級的玩法，如果可以感知到“某條具體的背景流發生了斷路”，“流“可以用5-tuple來標識（src ip、dst ip、src port、dst port、l4 protocol或者加上tos），那麼我便在注入探測資料包的時候，拿出現“斷流”的背景流量作為模板，構造出與出現“斷路”的背景流量相同的資料包進行主動探測，並且如果資料面是自家公司研發的話，完全可以在資料面轉發中的丟包處設定“探測識別點”，那麼這樣不僅知道出現斷流的背景流具體的斷流位置，還可以知道斷流的原因，這樣可以直接告訴使用者“xxx條流量出現了斷流，在xxx的位置，斷流丟包的原因是xxx”，例如圖3是VMWare的Traceflow的顯示結果。

圖3.VMWare的Traceflow使用效果圖

　　上述流程便是主動探測的大多數實現，微軟的Everflow、Vmware的Traceflow以及華為的FusionNetDoctor都是這樣實現的（這裡我一定要吹一波Vmware，做的真的有點好，真尼瑪炫酷...）但是主動探測同樣存在一些致命缺點：

1. 只能探測正在發生的故障。如果故障是時斷時續的，那主動探測這種手段就無能為力了。
2. 探測的力度有限，例如正在發生的故障是丟包，並且丟包是隻丟一部分，那麼發出的探測資料包很有可能沒有被丟，呈現出與現實世界不通的結果。（但是這種方法可以批量注入來觀察）
3. 無法回溯。這點與第一點基本相同，如果斷流是某個過去的時間點發生的，例如半夜，那主動探測便無法得知過去某個時間點出現斷路的原因與位置了。
4. 需要在資料面設定探測識別點，探測識別點識別探測資料包不能影響正常的資料面轉發效能。

　　微軟的Everflow中提到，這種主動探測主要就是探測正在發生的斷路，因為正在發生的斷路的故障優先順序最高，能實現這點已經足夠，沒辦法指望單純的一種技術來應付所有場景。

　　當然主動探測以後我會寫一篇專門的文章來講解其中存在的一些技術難點和實現方法。

【被動探測】

　　被動探測是與主動探測相對應的一種探測，被動探測的定義是在“不影響當前網路流量的情況下進行探測”，由於主動探測“注入探測資料包”會對當前網路中的流量做出一些影響（出現了一條新的流量）。被動探測以思科的Netflow作為代表，但是近年來也有一些新的技術分別亮相，比如思科提出的INT技術以及其具體應用IOAM，以及華為根據思科IOAM技術進行優化提出的PBT技術。由於被動探測的技術內容比主動探測的內容複雜一些，因此接下來會分別介紹，先介紹Netflow技術。

【Netflow】

　　Netflow技術由思科與1996年提出（和我同一年生....），到現在已經過了24年，已經是一種非常成熟的技術了，並且各家根據思科Netflow的思想還發展處了一些方言版本，例如jFlow，sFlow等等等等。Netflow的架構常常如圖4所示。

圖4.Netflow架構圖

　　只要是基於Netflow的採集技術（其實不光是Netflow，主要是流量採集技術基本都差不多...），無論做成什麼樣，做的多大，基本都離不開Netflow架構的這幾個元件。

• Netflow Exporter。Netflow匯出器，用處是將流資料通過Netflow協議進行匯出至Netflow Collector中。
• Netflow Collector。Netflow收集器，用處是將Netflow資料包收上來後進行解析，解析出流資料後存至Flow Storage中。
• Flow Storage。流資料庫，存解析後的Netflow資料，通常流資料庫用的基本以TSDB為主（時序資料庫），因為需要常常回溯某個時間點，或過去一段時間內流量分佈的變化與狀態資訊，因此TSDB更適合，比較流行的有influxDB、Prometheus。
• Analyzer/Monitor。分析器，用於對流資料庫中的資料進行分析與呈現。

　　當然還有一個最終要的元件便是Netflow裝置的Flow cache。在Netflow裝置中會存在一張表，這張表會存放流的資訊，如圖

圖5.Netflow Main Cache原理圖

　　原理也非常簡單，即：

當某條流的資料包第一次進入當前Netflow裝置後，Netflow裝置會根據此資料包的5-tuple資訊（這裡隨意定義）提取並在Netflow cache中新增一條Flow Entry，這條Flow Entry便代表此條流，那麼便可以統計這條流的資訊，並定時（Netflow cache通常都有老化機制）匯出封裝為Netflow協議資料包送往Netflow Collector

　　Netflow技術的原理非常簡單，就是採集流資訊，上傳，然後分析。當然Netflow也有缺點，便是：

1. 採集粒度為“流”，無法到達更細粒度的“資料包”，所以統計丟包、時延有一定難度。
2. 會給Netflow裝置帶來效能損耗，效能的損耗往往會帶來“觀察者效應”。比如某一網路現象，拿網路擁塞或丟包為例，原本網路中不會有擁塞或丟包，但是由於開啟了Netflow採集功能，採集功能消耗Netflow裝置的效能，導致Netflwo裝置處理網路流量的效能下降，進而產生了擁塞或丟包，那麼便是“觀察者效應”，最終的結果並不是已經存在的，而是由於去“觀察”這一動作才會發生，不觀察就不會發生，那麼這種情況就比較蛋疼。而效能問題又會帶來如下幾種問題。
   • 效能下降導致在DCN網路無法對每一個數據包都進行更新Flow cache，所以往往會存在取樣頻率一說，比較常見的是“每100個數據包採集第一個資料包”，用這種方法來降低效能消耗，但是這種方法又會產生額外的問題，比如在網路中通常會存在一些“大象流”和“老鼠流”，大象流的代表如FTP資料流，這些流量的特點是量大，持續一段時間後就會消失；而“老鼠流”的一些代表是一些控制協議或者是協商協議，這些流量的特點是量少，但是會一直持續，可靠性要求較高。但是如果存在取樣頻率，很可能會出現採集不到“老鼠流”，最後看起來就是“大象流”覆蓋了“老鼠流”，只能看見有FTP協議流量，其他一些TCP協議流量看不到。
3. Netflow協議上傳的資訊有限，儘管Netflow v9已經支援模板的方式去採集資料，但是仍然是有限的，並且無法採集一些企業的私有資料，並且Netflow v9的傳輸層協議為UDP協議，UDP協議本身可靠性較差，一旦出現上傳資訊丟失，還得額外處理。
4. Netflow協議存在太多的方言版本，例如sFlow、jFlow，相容性會有一定的問題，並且Netflow協議屬於思科提出的一種流量匯出協議，並不是一種標準。

　　Netflow的缺點中，第一種其實並不是Netflow技術的缺陷，而是基於“流”的網路資訊取樣的共性缺陷，第三種為Netflow這種傳輸層協議在設計的時候出現的缺陷，而第二種更偏向於“哲學”問題，“想看的更多就得花費更多的代價”，不想付出代價還想對網路進行細粒度的觀察，是不可能的，就好比“你不能要一把槍射程又長，精度又高，為例又大，體積又小，射擊速度又高”，這是不現實的。

【IPFIX】

　　IPFIX協議，IETF提出的一種“標準流資訊匯出協議”，目的就是為了替代Netflow v9協議和眾多的方言版本協議，可以看做是未來的趨勢，大多數廠商都已經相容IPFIX協議，例如思科、華三、華為的交換機，VMware同樣將IPFIX匯出協議作為一種標準的流資訊匯出協議。

但是要注意的是IPFIX協議只是一種“資訊匯出協議”，目的是為了替代Netflow架構中的Exporter到Collector中的資訊匯出協議，但是整體架構基本如Netflow架構。IPFIX協議由Netflow v9協議發展而來，Netflow協議中的協議頭的version為9，意味Netflow v9，而IPFIX協議中的協議頭與Netflow v9基本一致，並且version為a（10），也就是Netflow v10，如圖6.

圖6.IPFIX頭格式和Netflow v9頭格式對比

　　而IPFIX作為IETF推出的標準流資訊協議，在Netflow v9的基礎上做了如下的改進：

1. IPFIX的傳輸層協議較於Netflow v9支援更加多樣化，支援UDP、TCP、SCTP協議作為傳輸層協議的選擇；（這點請見RFC 7011的10.1節）
2. IPFIX相較於Netflow v9協議新增了企業欄位、變長內容等新特性，可以支援一些企業內部私有的資料匯出（這個是我認為最方便的一點特性）；（rfc 7012有詳細解釋）
3. IPFIX協議的模板內容相較於Netflow v9增加了非常多，可以匯出更多的資訊。（同見rfc 7012）

　　可以看到，IPFIX相較於思科的Netflow更是一種協議標準，其中的企業欄位可以很好的相容一些方言版本的流資訊匯出協議，解決了很多相容的麻煩，並且從功能的角度講，IPFIX是相容Netflow v9的（注意這裡的功能值指的是匯出內容上IPFIX要更全於Netflow v9），但是單純從協議的角度講是沒法相容的（也就是仍然得增加IPFIX的開發量）。

【INT】

　　INT技術是最近幾年一種新型的網路遙感技術，全稱是Inband Network Telemetry，意味“帶內網路遙感技術”，是由思科提出的一個技術，INT是一種技術手段，一種思想，在思科產品中的應用叫做IOAM（inband OAM）那麼這裡就有一個新的概念，什麼是“inband”？inband的意思直譯是“帶內”，但是“帶內“又如何理解呢？

　　我個人的理解是：類似於Netflow或是IPFIX這類流監控技術，可以稱之為”outband“，也就是帶外。舉個生活中的例子，帶外就好比你是一個監控人，你在監控這條流的狀態，你仍然處於一個旁觀者的位置，既然是在一個旁觀者的位置，那麼觀測的方法和觀測的位置勢必會對觀測的結果有很大誤差；而怎麼最大化消除這種誤差呢？生後中的經驗告訴我們叫做”設身處地“，也就是我們把自己擺在當事人的視角去看待事情，那麼我們可以看到更多有關事情的真面目，而inband就是這樣，inband Network telemetry就是這麼實現的，將旁觀者監測流，改為將檢測資訊植入到資料包內部，這樣就相當於監測點掛載到了流中的每一個數據包，那麼這樣資料包所經歷的，必然是監測點所經歷的。

圖7.INT的實現方式

　　如圖7所示，INT的實現方式就是將監測檢查點插入到資料包的內部，也就是途中的OAM層，INT通常的做法就是將資料包的頭（header）和資料包內部資料（payload）之間插入一塊OAM層，那麼這個資料包就從一個普通的網路資料包變成了一個被我們打上”標記“的資料包。再舉個例子，相信看過動物世界節目的朋友都知道，海洋學家為了監測一些動物的行為軌跡，會在海洋動物身上裝上遙感器，比如海龜、海豚、企鵝之類的，那麼最後海洋學家就可以回收海豚的探測器，並根據探測器中記錄的資料來分析這個海豚的行動軌跡，海豚的行為特徵。那麼INT就是這個原理，間圖8.

圖8.INT技術監測網路狀況的原理示意

　　如圖8中的例子，一個數據包（就好比一隻海豚）進入”起點“網元裝置（被科學家捕獲）後，被插上了OAM層（被裝上了探測器），而後資料包經過每一個網元（每一片海洋），都會將探測資訊插入到OAM層中（被探測器記錄），包括網元對資料包的行為，是轉發還是丟棄（海豚死亡），最後資料包到達終點後，資料包中的OAM層被剝離出來，通過資訊匯出協議上傳到遠端的分析伺服器（探測器被科學家回收分析資料）。那麼這裡有一個問題，網元裝置，也就是OAM域內的傳輸節點怎麼知道要收集哪些資訊呢？

 圖8.IOAM資料包中的OAM層

　　實際上，OAM層是由兩部分組成的，一部分叫做instruction，也就是指令，另一部分就是data，也就是資料，指令中會攜帶需要收集的資訊，translation node只需要根據指令把相應的資訊塞入data部分中即可完成資料的收集。

　　可以看到INT技術本身的原理還是非常簡單的，就是在資料包內部插入一個自定義的層，然後記錄經過每一個網元的資訊，最後再將探測資訊上傳至遠端的分析伺服器。那麼INT技術會帶來什麼樣的優勢，或者換句話說，可以怎麼應用這種技術呢？

1. 資料包粒度級別的丟包監測，由於監測的粒度從流變成了更細粒度的包，那麼理想情況下，INT技術是可以得知網路中丟包的情況以及丟包的原因還有丟包的位置。
2. 捕獲網路中的jitter現象，網路中經常會出現一些jitter，jitter的特徵往往是短暫難以捕獲的，而由於INT技術是一種帶內技術，那麼理想情況下仍然是可以捕獲到網路中的時延或是丟包的jitter。
3. 智慧路由和選路，根據OAM資料資訊，可以得知網路中的每一條鏈路的時延、頻寬以及丟包情況，那麼就可以根據這些資料進行智慧選路，將一些重要的流量進行重新reroute。

　　但是INT技術同樣帶來一些顯而易見的缺點，以傳統的INT技術，也就是思科的IOAM為例：

1. DCN網路或者是運營商網路中，資料包數量巨大，對每一個數據包進行插入OAM層，並進行監測，會產生巨量的資訊，這麼多巨量的資訊該如何壓縮、去重分析？
2. ”起點裝置“（在INT技術中被稱為encapsulation node）要對每一個數據包進行插入一個新的OAM層，這會產生巨大的效能消耗，如果是轉發裝置的轉發過程是軟體實現的，那對轉發效能更是毀滅性的打擊（你需要不斷的申請新的空間，並將原有的資料包進行拷貝，然後再插入一個新的層，事實上思科也注意到了這一點，所以在encapsulation node插入新的OAM層時有兩種實現，這點以後在詳細分析INT時再說）。
3. 轉發裝置需要不停的將探測資料插入到資料包內部，並對資料包的checksum需要重新計算，同樣是一個性能消耗點。
4. IOAM技術中，轉發節點會不斷的向hdr與payload間插入OAM層，那麼考慮到資料包會被分片，OAM層的長度必然有限制，也進一步等於OAM資料包所經過的轉發裝置（在IOAM技術中，這些轉發裝置所組成的域稱之為OAM域，OAM domain）不能太多。

　　IOAM的軟體實現可以去看VPP的原始碼，VPP 17.xx版本以後的版本中都帶有IPv6的IOAM實現。

【PBT】

　　PBT（Postcards-Based Telemetry）技術本質上也是INT技術，是由華為提出的一種基於思科IOAM技術的”升級版“，可以理解為一種優化版，華為主要是針對IOAM缺陷中的第2條、第3條以及第4條進行了優化，並且華為推出了兩種優化版，一種是PBT-I，另外一種是PBT-M，前者為超級版，後者為相容版。那麼PBT是怎麼做的呢？其實PBT的優化有點類似與之前說的主動探測的包注入技術。既然PBT技術本質上和IOAM技術並無不同，同樣拿海豚的例子來舉例：

• IOAM：一條海豚被海洋學家捕獲，海洋學家向海豚身上裝了一個探測器，探測器不能聯網，但是有內建硬碟，海豚帶著這個探測器遊遍太平洋，每經過一片海域，探測器就會收集資訊，然後一年後被海洋學家蹲點捕獲，拆掉探測器，海洋學家根據探測器的內建硬碟中的資料進行分析。
• PBT：一條海豚被海洋學家捕獲，海洋學家向海豚身上裝了一個探測器，探測器內部沒有硬碟，但是有通訊模組，海豚帶著這個探測器遊遍太平洋，每經過一片海域，探測器就會收集資訊並立刻傳給遠端的海洋學家的伺服器，海洋學家根據伺服器接收的資料就可以分析，或者是可以先將資料儲存到資料中心，等一年過後，海洋學家捕獲了海豚，考慮到保護海洋動物的責任感，拆除了探測器，並根據資料中心完整的資料進行分析。

　　可以看到，PBT和IOAM技術最大的不同是PBT是沒有攜帶OAM探測資料的，而是沒經過一個轉發節點（嚴格來說是OAM域內的translate node）都會立刻上傳資訊，具體如PBT-I技術的實現原理可以如圖9所示。

 圖9.PBT-I技術的實現原理

　　那麼PBT-T的原理敘述如下，資料包經過OAM域（可以理解為INT的監測域），並進入“起始節點”（encapsulation node），起始節點對資料包進行標記，注意這裡是標記，並不是插入OAM層，和主動探測中的包注入技術相同，那麼被標記的資料包，接下來可以稱之為PBT探測資料包，接下來PBT探測資料包經過OAM域中每一個網路裝置（translation node），傳輸節點都會去檢查資料包中的標記位，觀察是否時PBT探測資料包，如果是PBT探測資料包，則立刻上傳監測資料。

　　但是這裡仍然有一個問題，既然從原始的IOAM資料包的“監測模板” + “監測資料”縮小到只有1個bit的標記位，那麼裝置怎麼知道要收集並上傳那些資訊呢？這個地方可以通過類似於ipfix的模板來實現，也就是實現管裡面或者控制面向OAM域中的每一個傳輸節點下配置通知收集哪些資訊。這樣的話，管控面需要對OAM域中的所有節點下發資料收集的模板配置，而不像IOAM一樣，只需要給encapsulation node下發資料收集的模板配置就好了。

　　那麼根據上述的原理介紹，我們至少可以知道，PBT-I相較於IOAM做了如下幾種較為明顯的改進：

1. 收集的資料多少不再受限於資料包的長度，因為收集的資料不再插入在資料包的內部。
2. 不用對每一個數據包進行十分浪費效能的插入收集資料，重新計算checksum等操作，對於ipv4資料包，只需要看一下ipv4 header中的標記為，例如TOS中的reserve bit，就可以知道要上傳哪些資訊。

　　光這兩點改進，其實就已經是質變了，尤其是第二條的改進，大大的增加了INT技術在軟體轉發平臺上的可行性（軟體實現的轉發平臺最怕的就是對資料包進行重新分配記憶體+記憶體拷貝+重新計算checksum，這些會帶來大量的效能消耗），但是世界上沒有一種完美的技術，PBT-I技術的改進同樣帶來了其他的缺點：

1. 管控面需要對OAM域中所有的節點下發模板配置資訊，告知OAM域中的節點碰見PBT探測資料包要上報哪些資訊。
2. 由於沒經過一個translate node都需要上傳資訊，所以上傳的資訊次數會進一步變多，這樣同樣帶來了某一個節點上傳的資訊丟失的風險。
3. 需要時間同步和資訊重組，即一個PBT探測資料包經過了n個網元，如何將這n個網元上傳的資訊進行聯絡組裝。
4. 不靈活，沒辦法定製化，例如網路中有A、B、C、D、E五條流，其中我需要對A、B兩條流收集的資訊集合為M，對C、D、E三條流收集的資訊集合為N。但是標記位只有一個，沒有辦法進行更細粒度的進行區分。

　　雖然帶來了這幾個缺點，但是PBT-I的改進確實讓人看到了軟體實現INT技術的可行性。說完了PBT-I，接著說說“折中版”PBT-M，華為提出的draft中同樣承認了PBT-I技術做得太絕，導致了上述幾個問題的出現，那麼能不能稍微做的不那麼絕，來個折中點的方案呢？所以就來了PBT-M這種折中版本。

　　PBT-M相較於PBT-I技術，沒有完全捨棄OAM層，而相比於IOAM技術，又放棄了在OAM層中插入探測資料，因此PBT-M就是相當於IOAM與PBT-I的折中，即：

　　資料包第一次經過encapsulation node，同樣會插入OAM層，但是，直插入instruction，不插入data，相當於只插入收集指令，用於告知當前PBT探測資料包經過的每一個網元，要給這個資料包收集什麼樣的資訊，然後再將這個資訊匯出至遠端的分析伺服器。那麼根據這個特徵，我們可以知道，實際上PBT-M時對PBT-T的4條缺點中的1、4進行了優化，管控面只需要給encapsulation node下發配置即可，舉個例子，網路中有A、B、C、D、E五條流，其中我需要對A、B兩條流收集的資訊集合為M，對C、D、E三條流收集的資訊集合為N。A、B兩條流的資料包經過encapsulation node時，encapsulation node根據管控面下發的配置，對A、B中插入OAM層，instruction為M，對C、D、E插入OAM層，instruction為N，倘若A流的資料包經過translation node時，translation node根據內建的OAM層中的instruction M就知道該上傳instruction M所對應的資料，這樣靈活性大大加強。不過PBT-M這種折中版仍然會帶來IOAM技術中的缺點2，也就是encapsulation node需要對這個資料包插入OAM層，對軟體實現來說仍然不友好。

【總結-說一說我自己的一些看法】

1. 主動包注入技術只能排查當前正在發生的一些網路故障，因此侷限性較大，但是效能消耗小且易用，但是診斷的粒度很細，可以立刻得到網路中正在發生的故障、故障位置以及故障原因
2. Netflow或是IPFIX這種傳統的基於流的被動網路探測技術，相較於主動探測技術性能消耗要大，並且存在測不準有誤差的情況，粒度也不盡人意，但是作為一種監控出身的技術，仍然是主流且容易實現的一種技術。
3. INT技術對於網路探測可以說是吊打Netflow或是IPFIX這種基於流的被動監測技術，但是INT技術中的IOAM技術目前看來不適合軟體實現，當然barefoot推出了支援INT技術的轉發晶片，讓IOAM技術可以得以應用，不過晶片的價格感人，據說一片要8000刀（去搶吧...），目前barefoot已經被intel收購，後續什麼情況還猶未可知，目前IOAM這種INT技術的具體實現更多的都是基於硬體實現，然後與P4程式設計打組合拳。
4. INT技術中的PBT技術，目前對軟體實現比較友好的是PBT-I，當然對於PBT-M技術而言，如果encapsulation node是支援INT的硬體轉發裝置，那麼PBT-M的靈活性確實是要比PBT-I更勝一籌的。

唉，網路遙感技術這塊領域，大佬打架，我等渣渣只能吃瓜了....

先站一個坑，以後再慢慢具體說一說這些技術的一些具體細節，以及該怎麼實