Whatever happened to NetEm, the open source Network Emulator?
Why doesn’t everyone just use Netem?
Netem, short for “Network Emulator” , is a Linux networking tool that allows for the simulation of network properties. It’s part of the Linux kernel’s tc or Traffic Control system. It can be used to add delay, packet loss, duplication and reordering to packets going out from a specific network interface.
Netem allows developers and network administrators to test how applications and services would perform under a variety of network conditions. However, given the complexity of today’s network installations, is Netem still relevant? Consider the following:
Netem is Difficult for Most Engineers
Netem is a challenge for those engineers who aren’t familiar with the operating system kernel. For example, here is the command line syntax for adding packet loss.
The following command sets the enp7s0 network interface transmission to randomly drop 1% of the packets:
sudo tc qdisc add dev enp7s0 root netem loss 1%
And if you want to add packet loss with a success rate, you’d use this:
sudo tc qdisc add dev enp7s0 root netem loss 1% 30%
This syntax in and of itself creates a number of questions for new users. Is this interface that’s sending out the packets on the same system where netem is installed? Where are the impaired packets going? How is that set up and configured? What’s the source traffic for those packets? What exactly does success rate mean? Does it mean that 30% of the packets are going through?
If you’re an engineer who is well-versed in netem and the Linux kernel, you’d be able to answer those questions…eventually. But at what cost in terms of time? And would that time be better spent determining how a product would perform under various conditions before it is deployed or released?
But a deluge of questions is just the beginning.
Open Source Help Leaves Much to Be Desired
Open source help and advice, especially in regards to netem, leaves much to be desired. Many of the links no longer function or provide advice that is outright wrong. For instance, when asked about figuring out the values for a specific network scenario, this site provides the following advice:
Q. How can I find out the timings of a network and make my own rules?
A. The best method we found is to simply ping the host on the real network you are looking to emulate. Lets say, ping the remote host 20 times with 100 packets per iteration. Then look at the packet loss, jitter and delays. Then set up your netem to look like the same profile. With just a few iterations you should be able to get the delay products spot on.
IWL has written detailed explanations as to why this is incorrect (and what to do instead, both here and here.) These articles go into greater detail on what the limitations are and why network speed tests can be faulty.
A lot of the help that is available is confusing, incorrect or even unavailable for Netem. This creates a difficult barrier in an already challenging task. Surprisingly, we’ve only begun to scratch the surface.
Netem Isn’t Always Accurate
Keep in mind that Netem is embedded in the operating system itself. It’s not tuned for the underlying hardware in any way. This creates a “timing wobble” for some of the network impairments. For instance, if the user sets Netem packet delay to be 20 ms, the actual delay can be off by as much as 20%. This level of inaccuracy has a ripple effect that would invalidate the results of many other cases.
Speed Isn’t Everything
Many startups (and some established companies) have seized on the opportunity to create their own commercial network emulators. The problem, however, is that these companies are headed by hardware engineers who don’t have the depth of network protocol knowledge needed to deal with the challenges and issues that arise. Their number one priority? High speed network interfaces. 100 Gigs is infinitely better than a measly 10 gigs, so what else is there to consider?
As a result, they port Neem to their custom hardware, add a slick graphical interface and believe they’ve got a real network emulator on their hands.
Unfortunately, nothing could be further from the truth. The challenge in creating one’s own commercial network emulator by repackaging netem and adding a shiny new coat of paint is that these companies lack a crucial understanding of how to validate network accuracy. Testing how applications or devices perform under different network conditions is the key way to ensure that you can accurately replicate.
Why Use IWL Products Over Netem?
At IWL, we have designed, engineered, tested, and validated our own impairment engine. Our network simulators are designed for accurate, precise replication of real world network issues. This makes it easy for users to depend on complex network scenarios with no Linux kernel or tc experience needed.
Our emulators also go beyond Netem’s core capabilities and give developers and network engineers more granular control over network conditions. This control allows for the ability to emulate more complex network topologies while supporting a larger range of protocols and scenarios.
All of these features are backed by our comprehensive support and documentation for our products, along with unparalleled scalability and integration. When you need to create robust testing environments that closely mimic real-world network conditions while having precise control over each parameter, there is simply no comparison between Netem and IWL network simulators.
Rely on precise, adaptive network emulators that have undergone refinements and optimizations over the last two decades to achieve the kind of accuracy and control that today’s network engineers rely on in optimizing their own products. Contact us today to learn more about our broad range of network simulators and how we can help you test and deploy your products with certainty.
Read More: Optimizing Network Performance with Dynamic Bandwidth Simulation
Read More: Harnessing Statistical Probabilities in Network Emulation for Realistic Testing
Read More: Advanced Impairments: Custom Packet Manipulation in Network Emulation
