The downside of virtual probing approach in mobile networks

Firstly, we must define which virtual environment we are talking about – the Public Cloud, private cloud, NFV or the combination of these three.

We want to touch only NFV first, “Network Function Virtualization“.

NFV is not really a cloud solution, it is just virtualization of network functions on standard hardware “servers”. NFV uses the components and building block as the cloud but there is a big difference in terms of the application.

NFV applications are still these big monolithic applications which need a lot of resources in terms of RAM and CPU. These applications are not breathing as a cloud application does.

The reason being that for a real cloud application you need a stateless connection between the entities, and today’s telecoms protocols are not stateless at all.

We will see a change with the real rollout of 5G when also the core infrastructure is 5G but this will last a while. We will stay a long while with this monolithic applications.

What is a Probe? A Probe is, in fact, a disassembler which reads network information and transfers it back to the original input “metadata”. But as we all know the minimum requirement for disassembling would be the same amount of resources as assembling. Therefore, a probe is a very resourceful hungry device.

The intention of probe vendors is to get as much performance out of these devices. To get the best performance it is important to avoid any other function which is not necessary on the probe. This was the reason why Windows as probe os was never a success.

For probes to get the relevant traffic, it needs smart network visibility solution which we offer at Cubro. In legacy networks, we use network TAPs, aggregators, NPB “network packet brokers” to feed the relevant data to the probe. In a massive network environment, this could be a complex installation but it is typically an advantage because such a system can feed different probing systems for different purposes.

In modern networks, with a combination of real and virtual environments, it is much more complex. If we are inside the NFV environment, we don’t have physical links anymore and we have virtual network links transported on a real physical network but encapsulated in other network layers.

There are three options to solve this issue:

1) Use a modern visibility approach which gives you all the information from the network you need to fulfil all your monitoring needs.

(Tip: See Cubro’s solution for Overlay Networks and Visibility automation)

2) Try to use virtual probes

This approach sounds very simple. Due to the complex visibility needs, we can run the probe on the same hypervisor as the virtual network device. Although it might sound like a perfect idea, there are some serious issues if you take a deep look.

1. We know a probe is a very resource intensive device. To run such a device on the same hardware would reduce the performance of the virtual network device for sure. It might be possible to compensate for this issue by using bigger server hardware but there is always a limit.
2. How is the monitored traffic fed to the virtual probe? This is done by a virtual TAP but a virtual TAP is not a TAP. This is a software which makes a copy of the traffic and sends it via a tunnel to the probe software. This also happens on the same hardware. We have now the network function itself, the TAP and the probe – this means the hardware must handle the same packet several times!
3. We know from the general physics approach that, to get a precise and trustful measurement result, the measurement device should never be a part of the measured system itself.
4. Security is the buzzword these days. How can anybody be assured that this probe “piece of software” is not compromised in any way? With a hardware probe, the communication from and to the probe is done via a network and this network can be monitored. In the case of an application running on the same hypervisor, it is nearly impossible to track what software is doing.

Besides the four points mentioned above which target any virtual probing approach in mobile networks, there are also some technical points which make virtual probing not really a good solution. I want to mention only a few points but there is much more when you look deep into it.

a: In LTE networks, some protocol messages are ciphered. To decode these messages it is needed to decode messages from another protocol stack first. It is an extremely time-critical challenge for a probe to handle all these different messages nearly at the same time to get a good result.

With hardware probes, typically the visibility system provides all these different messages in real time “less than 1 ms” to the probe. This is a deterministic approach – every packet is transported with the same delay to the probe. On virtual systems, this is much more complicated because many different software on different layers must interwork to get this done, and we all know Software is per definition not deterministic

b: Traffic growth and load balancing in LTE and 5G is also a big contradiction of virtual mobile probes. In vEPC there are many servers used to run the GW application. Today, with network traffic in the TB range ten or more servers are easily needed to handle that traffic. And these servers are loaded to the maximum with their original work and there are no resources for probes. The second challenge is load balancing. It happens that the session moves from one virtual GW to another Virtual GW. In this case, the traffic must be rerouted to the probe where the session has started. If not, then correlation would be very complex later.

3) Use the Cubro solution

Overlay monitoring and visibility automation approach can solve the challenges on the visibility site. Once this is achieved, you can use the high-performance probes up to 1 TB to solve the performance issue and get a cost-efficient and sustainable solution.

Written by: Christian Ferenz, CEO, Cubro Network Visibility (c.ferenz@cubro.com)