Software-defined networking (SDN) and network functions virtualization (NFV) promise numerous benefits, but adding layers of network abstraction come at a cost: visibility into the traffic traversing the links at the physical layer.
The migration to ever-faster networks is compounding this challenge because virtually no network monitoring, management or security tool today is capable of operating at 40Gbps or 100Gbps. Network packet brokers (NPBs), also known as network visibility controllers, address this challenge by capturing, filtering, aggregating and optimizing traffic. This enables 1Gbps and 10Gbps performance management and security systems to operate in 40/100Gbps networks.
But can these physical NPBs work effectively in virtual network infrastructures? And can NPB functionality itself become virtualized for operation with a "white box" switch in a software-defined network?
The answer to the first question depends on the requirements of the tools and protocol(s) used to create the virtual network traffic flows. Many network and application performance management and security tools require isolation of individual flows or sessions from the aggregate traffic on the physical links.
To accommodate this need, NPBs have long supported a variety of network segmentation, encapsulation and tunneling protocols, such as Virtual LANs, Multi-Protocol Label Switching and the GPRS Tunneling Protocol.
But more important than any single protocol (especially with the ecosystem of protocols growing constantly) is the ability to inspect and identify packets from Layers 2 through 7, combined with the flexibility to configure and program the NPB to strip and slice packets to optimize monitoring applications, and to support emerging protocols, such as VXLAN.
NPBs must also support other methods being used to provide visibility into traffic flows in virtualized infrastructures. For example, both Cisco and VMware virtual switches make available application programming interfaces (APIs) for the virtual mirror or SPAN ports. The vSwitch in the host server directs traffic from the virtual SPAN port to the physical monitoring infrastructure, thereby providing both physical and virtual network visibility in a single, high-performance, out-of-band visibility plane or monitoring fabric.
This configuration has the advantage of not requiring a virtual machine devoted to network monitoring, so it does not consume any precious host resources, and a fully agentless approach places no additional load on the hypervisor. But it has the disadvantage of risking packet time-stamps becoming inaccurate when the vSwitch gets overloaded, even though the virtual SPAN port load is significantly less than running the vSwitch in promiscuous mode. Despite this limitation, virtual SPAN capability does facilitate visibility into traffic among virtual applications that remains exclusively within the vSwitch.
The use of a separate physical element, such as a management NIC, to direct traffic from the virtual SPAN port avoids two additional problems with software-only approaches: full visibility cannot be assured based on the use of best-effort delivery to forward copied traffic over the same ports used for network traffic; and the use of generic routing encapsulation (GRE) to isolate the copied traffic results in the fragmentation of jumbo packets based on the need to comply with the network's maximum transmission unit (MTU).
Sign up for CIO Asia eNewsletters.