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.
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.
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 (firstname.lastname@example.org)