The way you'd usually use NISTNet is to install the software on a Linux-based router installed in your test environment. The router would have a number of network interfaces configured. For example, you might have two Ethernet interfaces configured, each supporting a different IP network. You'd place your test hosts on either side of the router and configure NISTNet to exhibit the characteristics you wish to model and run your test.
The primary module is
nistnet.o, which is the main body of the
network emulation code that augments the normal IP forwarding routines in the
kernel. The first thing you need to do is to load the module. You can use
either insmod or modprobe to do this:
When the module is loaded you will be able try out the client. You must have root permissions to run the client programs. While the text mode interface is convenient for scripting purposes, I find the X11 client much easier to use. The X11 client is called xnistnet.
When you first start the xnistnet client you will be presented with a large display looking something like that of figure 1.
Figure 1. NISTNet GUI client (click on image for full size view).
Each row of the display represents an emulation rule. In the left-hand panel, you configure the hosts or services that must match for that rule to apply when forwarding. You may specify host or network addresses, protocols such as TCP and UDP, and ports by name or by number. You must supply both a source and destination pattern, and rules are not bidirectional; that is, you must configure a rule for each direction. The rules for configuring a pattern are simple enough, but don't look it initially.
In the right-hand panel you configure the actual conditions that will be applied when that rule is matched, and in the right-most fields you are able to see some running statistics for the connections represented by the rule.
More comprehensive instructions and explanations of each of the fields are supplied with the package, so there is little point in reproducing them here. Instead, let's look at a simple example.
Let's imagine that our lab setup is built of three Linux machines. One, the
NISTNet router, has an Ethernet interface and a PPP interface to another Linux
machine with a null modem link at 33.6 kilobits/second. The third Linux machine
is on the Ethernet network and has the IP address of
that we'll use to send test traffic to the PPP-connected Linux machine, which
has the address
192.168.2.1. Our test environment is illustrated in
Figure 2. Example test environment.
We'll illustrate the capability of NISTNet using a simple ping test. In practice you'd probably be using something much more relevant to your application. In a stable state, no rules configured, our ping test looks like:
ping -c 10 -i 2 -s 1460 192.168.2.1PING 192.168.2.1 (192.168.2.1): 1460 data bytes 1468 bytes from 192.168.2.1: icmp_seq=0 ttl=254 time=1097.6 ms 1468 bytes from 192.168.2.1: icmp_seq=1 ttl=254 time=1064.4 ms 1468 bytes from 192.168.2.1: icmp_seq=2 ttl=254 time=1057.2 ms 1468 bytes from 192.168.2.1: icmp_seq=3 ttl=254 time=1021.9 ms 1468 bytes from 192.168.2.1: icmp_seq=4 ttl=254 time=1004.6 ms 1468 bytes from 192.168.2.1: icmp_seq=5 ttl=254 time=1004.8 ms 1468 bytes from 192.168.2.1: icmp_seq=6 ttl=254 time=1053.1 ms 1468 bytes from 192.168.2.1: icmp_seq=7 ttl=254 time=1056.1 ms 1468 bytes from 192.168.2.1: icmp_seq=8 ttl=254 time=1018.9 ms 1468 bytes from 192.168.2.1: icmp_seq=9 ttl=254 time=1062.7 ms --- 192.168.2.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 1004.6/1044.1/1097.6 ms
Let's add a rule that will insert a 500 millisecond delay in datagrams in
the forward direction only. To do this we start the xnistnet client
and enter the address of our source machine,
192.168.1.1, into the
source field of a rule, and the destination address,
the destination field of the same rule. We then enter
500 into the
field labelled "
Delay (mS)" in the right-hand panel, and hit the
"Update" button to activate it. When we now look at our ping test we see:
ping -c 10 -i 2 -s 1460 192.168.2.1PING 192.168.2.1 (192.168.2.1): 1460 data bytes 1468 bytes from 192.168.2.1: icmp_seq=0 ttl=254 time=1566.8 ms 1468 bytes from 192.168.2.1: icmp_seq=1 ttl=254 time=1602.2 ms 1468 bytes from 192.168.2.1: icmp_seq=2 ttl=254 time=1552.5 ms 1468 bytes from 192.168.2.1: icmp_seq=3 ttl=254 time=1524.8 ms 1468 bytes from 192.168.2.1: icmp_seq=4 ttl=254 time=1515.1 ms 1468 bytes from 192.168.2.1: icmp_seq=5 ttl=254 time=1515.4 ms 1468 bytes from 192.168.2.1: icmp_seq=6 ttl=254 time=1517.0 ms 1468 bytes from 192.168.2.1: icmp_seq=7 ttl=254 time=1537.3 ms 1468 bytes from 192.168.2.1: icmp_seq=8 ttl=254 time=1517.8 ms 1468 bytes from 192.168.2.1: icmp_seq=9 ttl=254 time=1518.9 ms --- 192.168.2.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 1515.1/1536.7/1602.2 ms
It's easy to see that that did precisely what was expected of it.