Really nice list. Back in the day when I started out and did a bit of CCNA material I used the proprietary Cisco Packet Tracer a lot. Ultimatively I did not follow the networking route for various reasons, but if I would have, then GNS3 would have been my simulator of choice. You can load the original Cisco firmware into it (if you can get hold of it) and really study in depth.
eve-NG is still the easiest to use IMHO, me and many of my coworkers used it to prepare for our CCNA/CCNP/CCIE certifications.
I would swap it in an instant for an equally user-friendly open-source one though, if there was anything comparable, as some of the features lacking in eve-NG Community were really annoying to deal with (e.g. no connection to a real, physical network and/or the internet)
I used to use a network Emulator+Physics/Traffic Simulator called NCTUns to research vehicle networking back in 2010.
I remember it was pretty cool. If I recall correctly, I could run several instances of all kinds of networking gear, configure wireless interfaces, place physical barriers, roads, etc... then I could see how packets and routing tables would behave while the emulated instances of routers/switches/APs moved around the physical world.
Pausing the would, clicking on a little car, and serialing into a particular router that was running Cisco IOS was always pretty mind blowing to me though.
They had all kinds of custom protocols that could route network traffic depending on which direction the traffic was flowing: you didn't want packets to get stuck in loops, hopping back and forth between oncoming traffic. Especially in sparse environments.
I don't know what happened to it, it looks like it got spun off into a commercial company:
If you're using a tool that drives headless chrome, there's also programmatic access to Network.emulateNetworkConditions... the same knobs used for network throttling in the Chrome dev tools network tab.
+1 for GNS3. I used it to mimic my home network (MikroTik gear) and test out VLAN configs. Great tool, quick to learn, easy to use, works flawlessly on Linux!
CORE has been updated twice since the list was created. It’s actively maintained. CORE emulates mobile, changing networks like IoT devices, phones, or network-connected vehicles.
Does anyone know if any of these tools support emulating wifi radios such that a person could test, say, hostapd configurations, independently or in the context of a network to make sure all the pieces are working together? (That is, without ever connecting anything to a live wireless card)
Dumb question, has anyone tried LLMs for network design? I got a CCNA few years ago and I remember being surprised that most of that stuff wasn't automated already. I feel like most things that CCNA or even CCNP require can be done by a LLM if it's trained on enough examples.
Thank you for this list. I started my career with Opnet (Riverbed purchased them in 2013) and IIRC the license cost mid five figures per year. This list tipped me to OmNet++ which may provide a similar DES environment. I look forward to checking it out.
Does anyone have recommendations if you want to simulate poor/unreliable/slow networks in order to ensure a client application handles these scenarios? Would a network emulator be the appropriate tool for this?
Couple this with inserting pf as a transparent firewall and you can make a good hop become all sorts of crappy. And you can do this on very low end hardware with just a pair of NICs.
Brian Linkletter's website is one of the best portal if you want to learn network simulation and emulation.
From the provided list, I think the most promising and realistic open source network simulator and emulator is Mininet due to its lightweight approach capable of running off-the-shelf Linux OS and software. In addition it has thriving eco-system that made it unique, accessible and prime for wide adoption for examples:
a) It's currently actively being used to simulate and emulate smart city project by its original author to improve urban networking [1],[2].
b) It has open learning materials resources from open source book (Mininet-WiFi) and open lab instructions manual (Mininet-SDN) [3],[4].
c) Its lightweight feature enabling it to simulate very large number of nodes using the nested containers capability as demonstrated by extensions created by third party simulation tools namely NestedNet and ComNetsEmu [5],[6],[7],[8].
The most important and most useful thing is the hardest to obtain: latency simulators.
I just want an IPv4/IPv6 proxy that does nothing other than delay, rate-limit, and/or drop packets.
This is a critical aspect of application performance that all developers just ignore because it's such a PITA to simulate.
Your loopback adapter has a latency of 30 microseconds, but that same web-to-database connection might traverse multiple switches, routers, firewalls, and load balancers and have a latency of over 1,000 microseconds (1ms) in production. That's thirty times worse, and I'm not even talking about zone-redundant deployments, regional-to-region failover, or any such thing!
Ditto with web apps, where every developer mistakenly believes that their Angular or React monstrosity is "performant"... because it is... on their own machine. With loopback networking. Try that over a 3G connection... in rural India. Not Indiana. India.
> I just want an IPv4/IPv6 proxy that does nothing other than delay, rate-limit, and/or drop packets.
Built-in into linux kernel, althought it's per interface unless you get dirty with traffic shaping tools.
Also you probably dont want proxy as support for proxy servers can be pretty iffy across software stack.
> Your loopback adapter has a latency of 30 microseconds, but that same web-to-database connection might traverse multiple switches, routers, firewalls, and load balancers and have a latency of over 1,000 microseconds (1ms) in production. That's thirty times worse, and I'm not even talking about zone-redundant deployments, regional-to-region failover, or any such thing!
Reminds me of a time when COVID hit and the suddenly-remote developers were suprised the time to start of their application went from 5 to 30 minutes (they connected their app to DB server on dev environment to not carry big-ass database with them)...
> Ditto with web apps, where every developer mistakenly believes that their Angular or React monstrosity is "performant"... because it is... on their own machine. With loopback networking. Try that over a 3G connection... in rural India. Not Indiana. India.
And that reminds me of this time frontend developers loading 700MB of data to load the site and not noticing that, but sending ticket to ops "server is a bit slow, could you give it more cores?". Said developers were working in office that had direct connection to data center 500m away with sub-ms latency and plenty of bandwidth.
I had many times pondered traffic shaping frontend devs connection to like 10Mbit after that... maybe 56kbit for repeat offenders.
> I just want an IPv4/IPv6 proxy that does nothing other than delay, rate-limit, and/or drop packets.
About 15 years ago I needed to emulate a network over a satellite link. We had limited amount of time on the dish and it was a fairly costly affair. We had a small rack of hardware together with a bunch of measuring instruments that would be in the field for data acquisition. It would be sending back data home where it would be processed and then sent back into the field. The (limited) bandwidth reserved and the inherent latency on the link gave us some interesting issues to deal with, but it required a few iterations to get things working smoothly.
The rack had a Linux box which acted as a router (among other things), and while it was in the office we'd just hook it up via ethernet. So I used tc[0] on there to introduce a fixed latency on transmission and cap the outgoing bandwith to whatever was available on the link. I did the same on the homestation for outgoing traffic but there I just used an old box with two ethernet ports and set it up as a bridge.
For dropping packets I used iptables, and some other things.
It requires some familiarity with the LARTC[1], which isn't the most readable document, and how things work in Linux. It gave us exactly what we needed without having to pay for time on the dish for testing.
It's been over a decade and the details are extremely vague, but I'm sure that if you want to you could mark certain packets with netfilter and then delay those packets somehow, rather than just delay the entire network device. I remember that with iptables we used to mark packets from SSH in the mangle table and then use that mark with tc to give traffic marked priority on the outgoing device.
It's not exactly a proxy, but back in the day it worked for that specific use case.
tc is the way to go if the options are sufficient. You can bridge two interfaces (also virtual ones) in a VM and set qdiscs. Also works asynchronously, e.g., different rules for up/downlink. Instead of a VM setup one could use a cheap linux/openWrt router or an SBC-type board.
Huh? FreeBSD had this 15 years ago already (if not more). Thingie is called DUMMYNET. Imunes utilizes netgraph thingie that can be connected thro pipes (DUMMYNET) to emulate whatever delay, bandwidth and BER you want. Very handy thing
to check out how your stuff will behave on dialup for example.
IPFW dummy net in FreeBSD was amazing for this. I haven't used it in 20 years. On my home DSL line in the 90s I would get so many hack attempts that it was becoming a nuisance, so I filtered ICMP through a dummy net that both delayed and dropped 10% of the packets. Hack attempts went to zero in 3 days.
For web apps, chrome has a throttling tool in the dev tools. Not sure how sophisticated it is, but I've used occasionally to recreate bugs only noticed by clients on slower connections.
Your proxy adding latency is a very good idea. I'm wondering what it would be wrote in. Go, so you can integrate it easily on a k8s as a side container or else ? Rust, so it can be performant and at low level ? Nim, so it can be easy to write and performant ?
I think that can't be that difficult to write, but maybe I'm wrong.
I will look into it but I don't promise anything. I think it is a good pet/side project.
That doesn't matter for the client through. As long as the data can come in a single small file, for example the <3KB HTML file for the tab I'm writing this on, what the server is doing doesn't matter.
Not sure their tech stack (I'm sure there's a post on it somewhere) but there was a forum software way back that would compile replies and such into static html pages when the submit button was hit, on the assumption that they would be read a lot more times than written to. Worked pretty well from what I recall.
