Monitoring network traffic is not one size fits all. If your organisation uses a virtualisation platform like VMware or KVM, some network traffic never leaves the host. For example, two virtual machines (VMs) on the same host communicate using a virtual switch (vSwitch) which means the software performs network switching. 

If you use virtualisation and you only monitor the physical wire, your application, security, and network monitoring tools may miss all of the virtualisation traffic. How much traffic you miss depends on how much of your data center environment is virtualised and how much east-west traffic moves within your data center or the cloud.

What is your virtualisation percentage?

Server virtualisation accounts for a majority of compute resources. Gartner estimated that 75% of all workloads were virtualised in 2015. Only 20% of businesses are this heavily virtualised, but it does highlight the continued trend towards more virtual computing.

To calculate your organisation’s virtualisation percentage, add up all of your VMs and divide by the total number of all servers (VMs + non-virtualized servers). For example, if you have 500 VMs running on 50 physical servers and an additional 50 servers with no virtualisation, you are 91% virtualised (500 / (500+50) = 500/550 = .909091).

> See also: When flash alone is not enough: how to be VM-aware with your storage

The higher your virtualisation percentage, the more virtual monitoring you need

No matter where you are with virtualisation, one thing is true – the greater your percentage of virtualisation, the more you should rethink network monitoring to maintain application performance, security, and compliance.

Since a significant portion of virtual machine traffic never touches a physical link, virtual monitoring can help in analysing the VM to VM communication buried deep inside of physical hosts.

On average, east-west traffic (server to server), accounts for about 75% of the traffic in your data center. How much east-west traffic skips a physical wire depends, in part, on your virtualisation percentage.

Virtual monitoring is not the same as physical monitoring

When you monitor a physical network, the impact is largely isolated to a one-time topology or switch configuration change. Network taps or SPAN ports copy traffic and forward it directly to an analysis tool or a dedicated monitoring network.

Dedicated monitoring networks are separate from the inline path of traffic on the production network. This isolation of physical monitoring makes it possible to limit the effect monitoring has on your network resources. However, this isolation does not exist in virtualisation.

Virtualiastion creates hardware functions in software. Virtualisation uses physical host resources to perform compute and networking functions. If you want to monitor your virtualised environment, you will need to make a copy of the virtual network traffic.

This means you will consume CPU, memory, and network resources to make a copy of the traffic. This could have consequences. For instance, using resources to copy and filter packets may change the number of VMs you can run on a host. It could also affect the performance of the applications you are monitoring. We have seen increases in host utilisation from 2% to 30%.

You have options to copy virtual network traffic

There are multiple options to copy virtual network traffic. None of them are perfect and there are trade-offs with each. Some you can run in the public cloud, some you cannot. Some may support VM motion but are not flexible to deploy.

Some options may require you use a particular version of VMware or a specific type of vSwitch. Choosing the best option for you depends on the application you are monitoring, where you are running the application, the virtualisation solution you are using, and the outcome you want to receive.

The beauty is you are not restricted – you can use one option across your entire environment or some combination of all five.

Put the vSwitch in promiscuous mode

This option copies all vSwitch traffic and forwards it to all attached VMs. A special VM is setup on the same host to collect all the packet copies and perform basic filtering. Placing the vSwitch in promiscuous mode can be a security concern because it essentially turns the vSwitch into a virtual hub.

This means any VM connected to the vSwitch could listen to all traffic. The upside is that it is flexible to deploy, easy to scale, and is supported by vMotion. Beware though, copying all traffic moving across a vSwitch can use a lot of host resources.

Use vSwitch port mirroring

This option copies vSwitch traffic on one port and forwards it to another port. A special VM is setup on the destination port to collect packet copies. This method is similar to configuring a SPAN port on a physical switch.

Configuration could become burdensome if you have a large number of vSwitches or applications you want to monitor. However, it can be easy to configure especially when you need to perform temporary monitoring.

Add a tap agent to a monitored VM

This option uses the monitored VM itself to copy packets moving through the virtual NIC. Add a tap agent into an application or into the virtual machine operating system and it will 'sniff' the network data moving to and from it.

This option natively supports vMotion because configuration happens in the VM, not the vSwitch. It will work in just about any environment including a public or private cloud. However, it can adversely affect the host resources and the application being monitored as the VM is responsible for copying and storing all those packets.

Remote control vSwitch infrastructure

This options copies select packets on the vSwitch, based on rules you define, and forwards them to a virtual or physical destination. This option is similar to option 2, but instead of manual configuration of each vSwitch, an orchestrator VM is deployed that communicates with the vSwitches via an API to automatically configure ports and set the filtering rules you defined. While this option can offer superior configuration control, not all virtualisation platform versions support it.

> See also: Network virtualisation: security challenge or security lifesaver?

Flow steering

This option uses a control to instruct the virtual switching layer to steer VM to VM traffic to another packet-capture-and-copy VM, first. Flow steering differs from the other four options because it adds an additional failure node in the application data path between the VMs.

However, it does offer high flexibility, control, and automation capabilities and works in the public cloud.

Choosing your visibility strategy

You have calculated your virtualisation percentage. You have explored different ways to copy virtualisation traffic for monitoring. You probably have a good idea how much of your virtualisation traffic you have and how much of it never touches a security or network monitoring tool.

Your next step is to ask yourself: What application traffic do I need to see? How much of the traffic do I need to see? And will I adversely affect the application if I copy its traffic?

Your answers will help guide you towards choosing the best visibility strategy for your virtualised environment.

Sourced from Jason Landry, senior solutions marketing manager, Ixia