What to Tap Virtually, and What Not to Tap Virtually? That Is the Next Question!

Virtual TAPs (or vTAPs) are software solutions designed to copy virtual-machine traffic data and provide clear network visibility. But virtualization isn’t a catch-all solution.

As a follow up to part one of this blog series, “To NFV, or Not to NFV? That Is the Question!,” we will assume that a fully virtualized or partially virtualized (hybrid physical and virtual) network has either been deployed or selected for deployment — or is being considered. (Note: Once again, the terms virtual, virtualized and virtualization also include containers or containerization.)

When adopting network function virtualization (NFV), monitoring the operation, performance and security of the network is as, if not more, important than it is for physical networks due to the added complexity and openness introduced. Therefore, traffic visibility is key for any digital transformation of your network, and 5G mobile core networks are no exception for service providers.

The next question is whether the traffic visibility and management components should be virtualized as well. Many network and security operations professionals believe that if any portion of their network is virtualized, then the complete performance management and security of that portion of the network should also be virtualized… including traffic acquisition.

While it may seem logical to virtualize monitoring tools and security applications along with the network functions, this isn’t entirely necessary. For example, both dedicated hardware or a virtualized tool can be used to monitor physical and virtual network functions and to acquire traffic. 

Whether traffic acquisition (tapping) and brokering should be virtualized should be given the same type of consideration as any network function when it comes to virtualization — possibly more. 

Virtualizing the traffic acquisition (tapping) and brokering of packets within a virtual environment (whether performance and security monitoring is virtualized or not) may also seem to be a logical approach, and in many cases is probably a good choice. However, as per the old saying, “You don’t get something for nothing,” there are trade-offs to be made around accessing the traffic using virtual techniques and brokering the packets within NFVs — often with significant impacts on the virtual host and other virtualized network functions (VNFs).

There have been some developments within virtual hosts, such as network interface card (NIC) mirroring, this technology allows for offloading bandwidth utilization for copied traffic from a virtual switch (vSwitch), but this relies on specific NICs being installed and the capability being supported in the virtual host environment.

A Pragmatic Approach to Virtual Tapping

As with the decisions on how much of your network functions to virtualize, instead of going all out and virtualizing all of your traffic access, packet brokering and monitoring and security, a pragmatic approach should also be taken — examining the necessity and impact of virtualizing traffic access, forwarding and monitoring.

Understanding exactly what you want to monitor, why you need to monitor and how many monitoring applications are needed is critical. This will help you understand the resource demands in terms of processing resources (CPU, memory) and traffic-handling resources (bits per second, packets per second).

The act of creating a copy of traffic within a virtual host can present many challenges:

• The virtual environment may be closed or locked down by the VNF vendor, possibly preventing access to built-in traffic mirroring capabilities and not allowing a third-party agent to be installed
• The virtual host’s API may be locked down, blocking access to virtual instance creation and movement, thereby preventing automated orchestration of traffic acquisition
• Creating and forwarding copies of traffic within the virtual host typically adds to capacity usage within the vSwitch
• Tunneling of large packets can result in fragmentation or truncation due to the network’s MTU being exceeded
• Traffic may be encrypted, requiring a lot of processing resources to decrypt for application monitoring and security visibility purposes

Other considerations include:

• Do you have existing monitoring or security applications or tools that can be reused?
• Are all your monitoring and security applications and tools virtualized?
• Is the movement (motion) of virtual instances or containers for any VNF restricted to the same physical location?
• Should separate (to the VNFs) virtual hosted environments be used to host the virtualized packet brokering and monitoring tools and applications?

Understanding these issues and answering the above questions will better inform you on how best to access and broker your traffic for performance management and security monitoring purposes.

Next, let’s see how to make the right choices — to virtualize your visibility components or not — based on your specific environment.

Making Measured Choices

As shown in Figure 1, in a typical 4G LTE CUPS network, there will likely be multiple NFV environments and hosts, and multiple geographical locations. Each interface between the various network functions needs to be monitored, and therefore the traffic needs to be acquired on these logical interfaces. Just because there is a VNF on each of these interfaces doesn’t mean that we need to use virtual methods to acquire the traffic, since some of the interfaces go out to the physical world.

Tapping

If we consider the upper VNFs (MME, SGW-C, PGW-C) in Figure 1, these are the control plane functions within the 4G LTE CUPS network shown. By definition, control plane traffic is comparatively low in volume and not very latency-sensitive. Therefore, it is a no-brainer to virtually tap the traffic at the logical interfaces (S11, S5-C/S8-C) between the VNFs.

It may also make good sense to virtually tap the external logical interfaces (S1-MME, Sxa, Sxb), as long as it is clear that doing so will use up extra bandwidth within the virtual host. The alternative would be to use physical TAPs instead, which places no resource demands on the virtual hosts, but requires physical installation — although no power is required if it is a fiber TAP.

Virtual tapping is probably the right choice for the control plane, and there are several choices for mirroring, depending on the vendor, hypervisor and virtual switch that’s being used. These include:

• Mirroring by the vSwitch (see Figure 2)
• Mirroring directed by an agent in the hypervisor
• Mirroring agent co-residing with VNF (see Figure 2)
• Separate mirroring agent in own virtual machine or container
• Mirroring via an NIC

In contrast, if we consider the lower VNFs (SGW-U, PGW-U), which are the user plane functions, these typically carry a much higher volume of traffic. A portion of this traffic (voice, video, audio) also tends to be latency-sensitive. Therefore, it makes more sense to use an external physical TAP for the logical user plane interfaces (S1U, SGi, VxLTE/RCS).

Since we are already physically tapping these two interfaces, the control plan interfaces (Sxa, Sxb) could also be physically tapped, despite not having much traffic volume. The main challenge is the intervening interfaces (S5-U/S8-U), which are virtual, and the only way to gain access to these is to use a virtual method, although it is user plane traffic. This is where the lowest overhead solution, such as NIC mirroring, may need to be employed.

It is at this time that your network engineering team may need to be included in a discussion about physically separating the two VNFs into their own dedicated virtual hosting environments, at which time you can once again physically tap between these hosts.

Packet Brokering

Once the actual tapping methods have been decided, the next step is to decide on whether network packet brokering is required and, if so, whether or not it should be virtualized as well (as in Figure 3).

When selecting a network tapping and packet brokering solution, you will need to find one that can handle both physical and virtual traffic access and brokering under a single common management and orchestration system. This will enable you to manage and configure traffic acquisition easily and seamlessly, regardless of whether it is being accessed physically or virtually, or whether the monitoring is being done virtually or physically.

With a virtual network packet broker (vNPB), the aggregation capability is great for accumulating traffic from multiple VNFs, VNF instances or containers. In addition, the vNPB’s filtering and load balancing capabilities can be very useful to help minimize the impact on switch bandwidth and tool resources. Although replication is a very powerful packet brokering feature, it does need to be recognized that for every copy, more bandwidth in the vSwitch will be used up, unless something like NIC mirroring is available.

In addition to the above base brokering functions, there may also be the need to perform more advanced functions, such as protocol header stripping, packet de-duplication, control and user plane correlation and NetFlow generation. Each one of these functions will take varying amounts of resources to perform.

Therefore, it may make more sense in high traffic volume situations to use a separate (physical or virtual) packet broker. A separate packet broker can receive traffic feeds from virtual tapping or packet brokering, as well as from physical TAPs, and will offload all processing and traffic handling for monitoring purposes.

The Take-Away

When selecting a network tapping and packet brokering solution, you should find one that can handle both physical and virtual traffic access and brokering under a single common management and orchestration system. This full-solution approach will enable you to manage and configure traffic acquisition easily and seamlessly, regardless of whether it is being accessed physically or virtually, or whether the monitoring is being done virtually or physically.

Similar to how you decided to virtualize network functions, a measured tap-network approach is the best way to decide which performance management and security monitoring functions to virtualize when building out or “digitally transforming” your network.   

Likewise, a measured and pragmatic approach is extremely important when deciding how to access copies of traffic from your virtual network and how to selectively forward the traffic to the monitoring tools and applications. It will help you answer that key question of “What to tap virtually, and what not to tap virtually?” It will also help you to improve your capacity planning for your virtual network hosts.

To learn more about solutions for acquiring virtual network traffic, take a look at the GigaVUE^® Cloud Suite offerings from Gigamon.

---

Further Reading:

• “The Art of Scrying — How Network Visibility Helps Enterprises ‘See’“
• “Yes, You Can Run Fast and Stay Secure During Uncertain Times“
• “Everything You Wanted to Know About Complete Network Visibility, but Were Afraid to Ask“