最近，花了一下午时间去调试一个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不满足要求的典型情况。错误的策略将返回的流量标记为***流量，同时还给它绑定了队列及硬丢弃指令。我当时挺幸运，因为它正好处于网关控制器的下游，不然我现在可能还没法解决问题，没有任何一名管理员愿意遇到这种问题。
