Network emulation: the problem of configuration factors
The Network Emulation is a relevant technology when making tests related to the behaviour of our platform.
Let’s look at these situations:
- We have developed a new application and wondered how it will behave when we put it into production, considering the conditions of our network segments.
- Let’s say we have a new application and wonder how it will behave considering that we have potential users in two remote branches and that in branch A we have a bandwidth and in branch B we have a much lower bandwidth available.
- Let’s suppose we have a new application but in this case we have 50 links that differ in technology, bandwidth, level of lost packets, damaged packets, latency, etc.
- We are evaluating hiring a communications link with a certain bandwidth capacity and technology and wondering how our applications will react.
- We’re planning to contract a cloud service or we’re considering moving to mixed cloud architecture and wondering what performance our users will see.
- We are sure that the bandwidth level of a link is not sufficient but we are not sure what exactly is the level we should contract.
All these situations are part of the day-to-day work of the IT managers and all are responded to by developing the necessary tests.
However, when we propose to do these tests, two options arise: simulation and emulation of networks. These are two concepts that are often used interchangeably but are actually very different.
In network simulation the basic idea is to use a system to create a virtual model of the network.
The resulting model will have to include aspects such as the type of network, its topology or the configurations of the equipment that compose it, including workstations, telephones, servers, switches, routers, firewalls, etc.
Once an initial model has been defined, the necessary modifications can be made to validate the effect that a specific change could have when applied to the real network.
Network simulators handle the maxim that their usefulness will always be directly proportional to the level of similarity between the virtual model and the real network.
In general, we must assume that achieving a good level of similarity starts with having a good simulator and devoting many hours of work to establishing and maintaining the model.
The use of network simulators is usually related to the proof of concept of new network devices, the proof of the effect that will have the inclusion of a new protocol or a network solution that involves the reconfiguration of equipment, etc.
If you want to learn more about this topic of network simulation, then check the following document.
On the other hand we have the Network Emulation, which offers a less abstract vision than the simulation since it starts from copying or reproducing the behaviour of the network to then replace it or replicate it in a test environment.
In other words, emulators are devices that allow us to reproduce the working conditions of a network segment or a communications link and whose purpose is to be integrated into the real platform during a testing process.
The following image shows how a network emulator is used to reproduce the working conditions of a WAN link:
Description: WAN Link Emulator
Although emulation can be applied to LAN segments, actually when we talk about network emulation we should generally understand that it is about emulation of WAN links.
If you are evaluating a network emulator and require emulating LAN segments, you must validate in the emulator documentation whether it is actually capable of supporting LAN emulation; it’s the same when emulating wireless segments.
Not all network emulators have a scope that encompasses all possible network technologies.
Once the issue of the scope of the emulator has been resolved, there is the aspect of its capacity.
Thus, we see that many promote the number of links that can simultaneously emulate, so that, theoretically, with the same device we can emulate our entire network platform.
The use of emulators is usually related to the concept tests of communications links, application tests depending on the network platform that will support them, and so on.
At this point we understand the difference between network simulation and emulation; on the one hand the creation of a virtual network model and on the other the use of a device to replicate network conditions.
Let’s review the case of network emulators and their possible relationship with monitoring tools.
The problem of configuration factors
The configuration of a network emulator involves setting certain parameters or attributes that describe the behaviour of the segment to be emulated.
General attributes such as the contracted bandwidth are necessary, but also elements such as latency and the level of packet loss allow for a more realistic emulation.
It is interesting to think that these configuration attributes are those elements that describe the behaviour of the link, many of which are considered as disturbances or faults.
Let us also bear in mind that precision is one of the most important characteristics of network emulators, understood as the ability of the emulator to accurately replicate all the factors that describe the network segment to be emulated.
Manufacturers then strive to generate emulators that include a large number of configuration factors in the hope of making their products ever more accurate.
The factors included in the configuration of an emulator depend, of course, on the manufacturer; however, in most emulators we get the following:
|Corrupt or damaged packages|
|Level of delay in package delivery|
|Jitter or variability in delivery time|
Based on these factors and depending on the guidance required in the test, specific factors may be required, such as those associated with video transmission or wireless segments, for example.
However, it is not always easy to have these attributes and to have their values as close as possible to reality.
For those links that are already in production, it may be a little simpler, but it requires measuring these attributes and developing the work of preserving historical data and generating statistics about it.
If we are evaluating the possible acquisition of a communications link to obtain these values is more complicated and sometimes we must be satisfied only with theoretical data.
One point that makes it even more complex to collect reliable data on configuration factors is that these factors are not static in time. That is to say, in a network segment or in a WAN link the latency is not the same during all the hours of the day or during all the days of the week.
It is then clear that the level of knowledge about the platform, the management of historical data and the analysis of that data are crucial for the success of a testing plan based on network emulators.
In fact there is a maxim that becomes the great goal of the emulator-based testing world: We have to bring real-world conditions into the testing environment.
Then the thing is how to get those real-world conditions.
Network Emulators and Monitoring Tools
The visualization capacity of a general purpose-monitoring tool like Pandora FMS can offer us all the necessary knowledge about the network behaviour.
We refer here to the possibility of obtaining information on each element of the platform, whether network devices, communications links, and behaviour of LAN segments, servers, applications, services and even processes.
So, besides all the benefits inherent to the development of a monitoring platform based on Pandora FMS, it is possible to use it to define the configuration parameters for the different test scenarios that will be evaluated using network emulation.
For example, let’s say we need information about the behaviour of the available bandwidth in a communications link.
Well, using Pandora FMS we can get this information. You can read this interesting article.
Now let’s think about how we can get information about lost packages. Well, having Pandora FMS is perfectly viable and the following article explains how.
So we could go on with all the configuration factors.
Now that we have resolved the aspect of how to get the real world data to configure our emulators remains the aspect of measuring the results.
This issue is based on the fact that emulators replicate the network and allow testing, but a process of measuring the results must be established.
Let’s say, for example, that we are evaluating the behaviour of a new application and the impact that this putting into production may have on the rest of the platform.
Once the emulator is configured and the tests are active, it is necessary to measure the behaviour of the application in question and of the other applications, as well as parameters such as the performance of the associated servers, the level of affectation of other network segments, etc.
These tests would require a very exhaustive work if they were done individually, but using a monitoring platform like Pandora FMS already installed and intoned could be much simpler.
Finally, we can say that the challenge of establishing test schemes using network emulators is naturally integrated to the work developed by a monitoring platform like Pandora FMS.
Do you want to know Pandora FMS better? If you have more than 100 devices to monitor you can contact Pandora FMS Enterprise staff through the following form.
And if you have a smaller number of devices you can use the OpenSource version of Pandora FMS, of which you will find more information here.
El equipo de redacción de Pandora FMS está formado por un conjunto de escritores y profesionales de las TI con una cosa en común: su pasión por la monitorización de sistemas informáticos.
Pandora FMS’s editorial team is made up of a group of writers and IT professionals with one thing in common: their passion for computer system monitoring.