Very nice, thanks. I hate the UI of these tools ("tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match ip dport 22 0xffff flowid 10:1"), so this will come in handy for my use cases, which are usually more something like "simulate a bad network".
If you desire to simulate a bad network you would really appreciate the power of dummynet on FreeBSD. It is very simple to simulate links with specific bandwidth, delay, and packet loss.
Looks cool, though I was hoping to see something that would allow one to specify IP addresses, for use in a router application. I use tc on my Debian-based router, but I know just enough to be dangerous and am never completely confident in applying new rules. Would be great to have an easy to use wrapper that makes the common cases straightforward.
Just a reminder for everyone wanting to simulate a bad network connection: setting a static packet-loss percentage, latency, and bandwidth limit does not accomplish that task. Real networks suck due to wireless interference and bufferbloat, which aren't simulated by tools this simple. Optimizing your software to perform well under this simulation may help it work well on a satellite link, but could be counterproductive for common real-world problems.
are there tools or applicable models out there that do represent the other factors you mention? I've been looking recently at ways to smoke-test my network app (probably separated into parts using docker containers) under adverse network conditions.
There was a nice looking python library that wrapped things that I can't seem to find at the moment. There's https://pypi.python.org/pypi/atcd/0.1.0, but I don't think that's what I was thinking of.
Direct use of queuing disciplines lets you create bloated buffers and use features of TBF and netem that aren't exposed through this simple wrapper. If you're testing at line rate, bfifo suffices to create bufferbloat, and TBF lets you do rate limiting with the kinds of burst allowances used by many cable ISPs. The IFB module is used to do ingress shaping, which is totally not addressed by this tcconfig tool.
For packet loss, you really just need to create competing traffic in order to cause congestion, preferably realistically bursty competition. Dropping packets based on a fixed probability isn't a realistic simulation of any common real-world cause of packet loss, and generating competing traffic is probably easier than figuring out the right way to approximate its effect using the other loss models implemented by netem (and again not exposed through this simple tool). Simulating the behavior of WiFi under congestion and interference is hard, and I don't think the stock Linux kernel (or any other mainstream OS) has adequate tools to emulate layer 2 retransmits, packet aggregation, and the periodic interference of microwave ovens.