x bridge by the kernel. The packet is then switched, based on destination Media access control (MAC) address, to the appropriate bridge port-in our case the vNIC of the VNF. The VNF then receives the packet on its vNIC and copies the packet into its memory for further processing. The same steps are repeated for each packet as it arrives at the pNIC and once again in the reverse direction when packets go from the VNF to the pNIC card after processing. Figure 10.8 provides the topology and performance results associated with this approach. Early measurements indicated that the Linux-bridging environment was fairly limited in terms of what it could do. It could switch packets based on layer 2 information such as MAC address or VLAN tags, but that is about it. In essence, using the default Linux bridge approach does not pro- vide the necessary capabilities to implement granular traffic policy controls as it traverses through the virtual environment. This lack of granular matching/forwarding criteria also contributes to another problem with Linux bridges: service chain complexity. When creating a service chain of multiple VNFs, multiple Linux bridges need to be used in order to keep the traffic segregated. Building the Network of the Future Linux Bridge LINUX BRIDGE KERNEL PKTGEN PKTGEN Frame Size (bytes) Throughput (Mbps) Throughput (kpps) FIGURE 10.8 Performance results with Linux bridge. The performance of the Linux bridge was good, but not as good as DPDK-based OVS. The Linux bridge is a kernel mode feature, SO any packet that needs to go from one VM to another, or to/from VM to pNIC, needs to be copied between user space and kernel space. This causes a high amount of context switching in the kernel, which degrades performance. 10.2.3.2 Virtual Switch (OVS)-Based Approach Another option for virtual networking is the virtual switch approach. This provides a better fea- ture-set with support for features such as VXLAN, OpenFlow, GRE, QoS, NetFlow, and granular matching/forwarding criteria. Traffic flows can be stati