dummynet is a flexible tool for bandwidth management and for testing networking protocols. It is implemented in FreeBSD but is easily portable to other protocol stacks. There is also a one-floppy version of FreeBSD which includes dummynet and a lot of other goodies, see below. It works by intercepting packets in their way through the protocol stack, and passing them through one or more pipes which simulate the effects of bandwidth limitations, propagation delays, bounded-size queues, packet losses, etc. Each pipe can be configured separately, and packets are forwarded to the appropriate pipe using the ipfw packet filter. Thus you can apply different limitations/delays to different traffic according to the ipfw rules (e.g. selecting on protocols, addresses and ports ranges, interfaces, etc.).
How to use it
There are several ways to run dummynet: · in the machine where you are running your applications, by intercepting incoming or outgoing traffic; · you can run dummynet on a machine acting as a router between two or more networks, intercepting traffic going through the router; · finally, you can run dummynet on a machine acting as a bridge, without even the need to configure a router or changing addresses. You just need to split your cable and put a box in the middle! You have the option to run dummynet on a full FreeBSD install, or (for the last two cases at least) to use a one-floppy version of FreeBSD, called PicoBSD.
Use
Dummynet is heavily based on the ipfw package for packet selection. ipfw allows the selection of IP packets (and only them) based on a combination of source and destination addresses and ports, protocol types (e.g. UDP, TCP, ICMP, ...), interface, and direction (in or out). The packet filter can be programmed through a sequence of rules, which are applied in sequence to packets until a match is found. The rule specify the action to be taken, one of them being forward the packet to a dummynet pipe. Multiple rules can point to the same pipe. A pipe simulates the presence of a communication path, with bandwidth limitations, propagation delays, and bounded-size queues. You can define all these parameters independently for each pipe, e.g. ipfw pipe 1 config bw 256Kbit/s delay 300ms queue 10
ipfw pipe 2 config bw 128KByte/s
ipfw pipe 3 config bw 80Kbit/s delay 100ms
ipfw pipe 4 config plr 0.001 you define four pipes with different features (each pipe is identified by a unique, non-zero number). In particular the second one has no delay and unlimited buffers (virtually; in practice there is a configurable hard limit of 100 to avoid consuming all of your memory for packets queued on a pipe). The third one has no bandwidth and buffer limitations, but introduces a delay on packet forwarding. The fourth pipe simulates a lossy path with a packet loss rate (plr) of 0.1% This feature can be useful for testing purposes. You can omit parameters that are not needed, and issue a command multiple time to reconfigure the features of a pipe on the fly. The usual suffixes of K (1000 bits/s), KB (1000 Bytes/s), M (1000000 bit/s), MB (1000000 Bytes/s) can be used to specify the bandwidth, whereas the "ms" after the delay is just ignored. Queue size is in buffers. The routing of packets to pipes is done by specifying the action pipe NN to send the packet to a pipe. E.g.: ipfw add pipe 2 tcp from my_ip port 80 to any
ipfw add pipe 3 icmp from any to any
ipfw add pipe 1 ip from any to 224.0.0.0/4 out
ipfw add pipe 4 ip from any to any via lo0 the first rule limits outgoing Web traffic, the second one acts on ICMP requests making your machine appear very badly connected, the third one acts on all outgoing multicast traffic, and the fourth one passes loopback traffic through the lossy pipe defined above. You can of course intermix these with other ipfw rules (including SKIPTO actions). Once a packet has matched a rule with ``pipe'' action, it is forwarded to the appropriate pipe (where it can be just delayed, or even dropped if the queue is already full). On exit from the pipe, the packet is passed again to ip_input() or ip_output(), depending on its direction, and checked against ipfw rules starting from the next one after the matching rule. The presence of the SKIPTO rule makes it possible to construct arbitrary distribution graphs. Operation The ipfw code is used to select packets that must be subject to band width/queue/delay/losses, and returns the identifier of the ``pipe'' de scribing such limitations. Selected packets are first queued in a bounded size queue, from which they are extracted at the programmed rate and passed to a second queue where delay is simulated. At the output from the second queue packets are reinjected into the protocol stack at the same point they came from (i.e. ip_input(), ip_output(), bdg_forward() ). Depending on the setting of the sysctl variable sys.net.inet.ipfw.one_pass Packets coming from a pipe can be either forwarded to their destination, or passed again through the ipfw rules, starting from the one after the matching rule. dummynet performs its task once per timer tick. The granularity of opera tion is thus controlled by the kernel option options HZ whose default value (100) means a granularity of 10ms. For an accurate simulation of high data rates it might be necessary to reduce the timer granularity to 1ms or less. Consider, however, that some interfaces using programmed I/O may require a considerable time to output packets. So, re ducing the granularity too much might actually cause ticks to be missed thus reducing the accuracy of operation.
Kernel Options
The following options in the kernel configuration file are related to dummynet operation: IPFIREWALL - enable ipfirewall (required for dummynet). IPFIREWALL_VERBOSE - enable firewall output. IPFIREWALL_VERBOSE_LIMIT - limit firewall output. DUMMYNET - enable dummynet operation. NMBCLUSTER - set the amount of network packet buffers HZ - sets the timer granularity Generally, the following options are required: options IPFIREWALL options DUMMYNET additionally, one may want to increase the number of mbuf clusters (used to store network packets) according to the sum of the bandwidth-delay products and queue sizes of all configured pipes.
SYSCTL Variables
net.inet.ip.fw.one_pass is set to 1 if we want packets to pass through the firewall code only once. net.link.ether.bridge_ipfw is set if we want bridged packets to pass through the firewall code.
Commands
The following socket options are used to manage pipes: IP_DUMMYNET_CONFIGURE updates a pipe configuration (or creates a new one. IP_DUMMYNET_DEL deletes all pipes having the matching rule number. IP_DUMMYNET_GET returns the pipes matching the number. IP_FW_FLUSH flushes the pipes matching the number. When the kernel security level is greater than 2, only IP_DUMMYNET_GET is allowed.
History
dummynet was initially implemented as a testing tool for TCP congestion control by Luigi Rizzo, as described on ACM Computer Communication Review, Jan.97 issue. Later it has been then modified to work at the ip and bridging level, and integrated with the IPFW packet filter. |
