最近，花了一下午時間去調試一個VoIP問題，而這本應該一個簡單的SIP連接問題。我會省略一些繁瑣的細節，但是最終結論是在從運營商通過網關向SIP轉發數據包時產生了不對稱的呼叫質量問題。

實際上，這種還不是最嚴重的問題。現實中，這個問題會導致4,500毫秒延遲和74%的丟包率，但是這個問題只會出現在一個方向上。現在要解決這個問題并不難——只需要在一個恰當的位置部署一個專門嗅探數據包的應用就可以診斷問題，如Wireshark。然后就可以確定是要從電話還是網關開始修復問題。然而，問題是現在面對的是SDN路由。

但是，實際上并不是純粹意義的SDN技術在作怪，而是因為在網關附近網絡中定義的軟件是由控制器編程管理。這還不是所謂路由的全部問題——路由定義、ACL及其他允許VoIP流量根據需要進行修改的元素也都由控制器管理。

需要一定的時間才能確定應該在何處分析流量，因為以前的數據包嗅探工具還不支持4-7層虛擬化。那么，在軟件定義網絡中，哪些技術將會替代最可信和最不可或缺的資源呢?由虛擬MAC手工收集的數據是一個，還有呢?

虛擬網絡的深度數據包檢測

粗略看，這一直都不是問題。有許多SDN解決方案支持應用層流量監控，并且帶有NetFlow工具和應用防火墻分析功能。然而，實踐中管理員定義網絡中還有一些新的復雜問題。

確實，有越來越多的網絡設備內置了深度數據包檢測(DPI)，但是將數據輸送到不同分析位置又會進一步放大數據存儲的問題，首先就是NetFlow。在虛擬網絡中，實現應用感知并不需要大數據，而且SDN控制器并不一定要實現Map Reduce才能發現vHaystack的Skype流量。

在***層面上，一段時間里我們的網絡一直在關注于應用程序，而最近一段時間則關注于感知應用的存在。在SDN領域中，我們的網絡及其管理工具都必須感知應用和策略。vWireshark v0.1版本如何在策略中區分出不同應用流量并根據策略限制這些流量傳輸呢?管理應該如何根據虛擬通道的策略定義來創建用于劃分數據包捕捉方式的流量過濾器呢?我們是否需要讓 SDN控制器創建大量的虛擬端口鏡像呢?如果在10G以上的規模，事情會變得很糟糕。

蠻荒之地：在應用服務器NIC上執行監控

人們很容易忽視一個適合感知應用網絡監控的位置：應用服務器的NIC。現在的應用程序故障修復確實很有難度——在一些終端設備上很難實現，在設備上或客戶機OS連接宿主虛擬交換機的虛擬機上嗅探數據包是很有幫助的。這并不需要改變SDN網絡配置——事實上，SDN讓服務層DPI更具吸引力，因為在NIC上，虛擬化并不會產生任何影響。這里可以得到最原始的流量，其中包含所有需要的訪問信息。

在遷移到SDN時，很可能你現有的網絡性能監控解決方案本身已經支持服務器端DPI，并且還帶有許多你都不知道的特性。你完全沒有必要丟掉之前所使用的指標，特別是在感知應用網絡方法本身已經很成熟的條件下。

隨著網絡變得越來越復雜，實現DPI可能保證清晰的應用服務交付指標。對于云與混合型網絡，這一點是毋庸置疑的，因為這些環境中唯一可靠的訪問就在應用服務器上。

對于我遇到的VoIP問題，實際上是一種關于流量圖QoS不滿足要求的典型情況。錯誤的策略將返回的流量標記為***流量，同時還給它綁定了隊列及硬丟棄指令。我當時挺幸運，因為它正好處于網關控制器的下游，不然我現在可能還沒法解決問題，沒有任何一名管理員愿意遇到這種問題。