next up previous contents
Next: Bibliography Up: Using NAT Previous: Virtual Routes

Performance

For testing the performance I used the following setup:





The procedure was not meant to produce highly accurate numbers, it should just give an impression of the delays we can expect when using NAT. The conditions in networks are mostly that complex I did not see much sense in trying to be more accurate. The numbers obtained are good enough for getting a feeling for what it means to have a NAT router, and that is all they are for.

I measured five different setups:

1.
The NAT module has not been inserted into the kernel.
2.
The NAT module has been inserted into the kernel, but there are no NAT rules (the chain is empty).

3.
There is exactly one (bidirectional) rule in the chain:
ipnatadm -I -i -b -S 1.1.1.1/32 -M 1.1.1.3/32

The result is the NAT router and Host 2 see Host 1's IP as 1.1.1.3, and not 1.1.1.1.

4.
There are four NAT rules in the chain:
ipnatadm -I -i -W eth0 -S 1.1.1.1/32 -M 55.55.55.55/32
ipnatadm -O -i -W eth0 -D 55.55.55.55/32 -N 1.1.1.1/32

ipnatadm -I -i -W eth1 -D 1.1.1.1/32 -N 55.55.55.55/32
ipnatadm -O -i -W eth1 -S 55.55.55.55/32 -M 1.1.1.1/32
route add -net 55.55.55.0 netmask 255.255.255.0 eth0

The result of the first two rules is essentially the same as above, the difference is that instead of making one of the two rules bidirectional we specify everything 'manually', also, we convert Host 1's IP to 55.55.55.55 and not to 1.1.1.3, but that does not make any difference. The other two rules reverse the first two rules, so that Host 2 still sees Host 1 as having the address 1.1.1.1. This setup shall test the worst case, where a packet has to be translated twice, when the NAT router receives it and just before it is going to be sent out again.
Note that we need to establish a route for network 55.55.55.0, since Host 1's IP will be one of that network when the routing decision has to be made.

5.
The same as above, but there are 46 (garbage) rules right before the four 'real' rules, so that the algorithm has to scan through all the 46 rules first (which do not match any packet), making this a 50-rules test.
Unlike firewall rules, in reality there will almost never be that many NAT rules, because mostly one (static or dynamic) rule per network is sufficient.
ipnatadm -I -i -b -S 123.123.123.0/24 -N 42.42.42.0/24
.
. (this one [garbage]rule repeated 46 times)
.
ipnatadm -I -i -W eth0 -S 1.1.1.1/32 -M 55.55.55.55/32
ipnatadm -O -i -W eth0 -D 55.55.55.55/32 -N 1.1.1.1/32

ipnatadm -I -i -W eth1 -D 1.1.1.1/32 -N 55.55.55.55/32
ipnatadm -O -i -W eth1 -S 55.55.55.55/32 -M 1.1.1.1/32
route add -net 55.55.55.0 netmask 255.255.255.0 eth0

The following tables show the numbers I obtained. There are two rows for each setup. The upper one shows the numbers when I transferred the 20 MB file from Host 2 to Host 1, the lower row is for the transfer from Host 1 to Host 2. I always completed one direction before I started taking numbers for the other one. Swap space was unused on both hosts, there where only the basic processes running.

Table 1: raw numbers from 'time '-command



# t1 t2 t3 t4 t5 t6 average
  7|c|seconds            
1 43.43 43.27 39.05 36.94 37.88 37.90 39.75
  40.39 41.31 39.66 37.29 34.95 34.80 38.07
2 40.57 38.86 36.17 37.70 35.94 37.08 37.72
  40.24 41.06 40.10 35.68 35.22 34.42 37.79
3 45.70 44.64 42.25 38.84 39.86 38.79 41.68
  40.54 43.03 39.43 37.42 35.85 35.44 38.62
4 49.27 48.96 41.85 39.97 39.20 39.94 43.20
  41.57 42.19 40.73 36.44 35.79 36.25 38.83
5 52.90 44.45 43.21 44.88 45.11 48.35 46.48
  45.82 45.80 42.39 40.75 41.02 41.93 42.95



Table 2: numbers calculated from Table 1



# t1 t2 t3 t4 t5 t6 average
  7|c|Kbytes/sec (ca.)            
1 482 484 536 567 553 553 527
  519 507 528 562 599 602 550
2 516 539 579 556 583 565 555
  520 510 522 587 595 608 554
3 458 469 496 539 525 540 502
  517 487 531 560 584 591 542
4 425 428 500 524 534 524 485
  504 496 514 575 585 578 539
5 396 471 485 467 464 433 451
  457 457 494 514 510 499 487



It is interesting to note that even on the tiny private and closed network used for the tests there is a wide variation in the numbers. However, the general direction is clear. All test transfers started slow and became gradually faster, here we see TCP's slow-start algorithm at work. I have intentionally chosen a setup where the hosts and not the network are the bottleneck, because otherwise obviously the numbers would be worthless. I did no tests with virtual servers, because first I did not expect any surprises, i.e. completely different numbers, and second, I have implemented the structure that stores the dynamic client data as a list, which should be replaced by a more sophisticated structure like hashes or a binary tree anyway, i.e. testing the performance at this early stage does not make much sense. The list, however, was the choice in order to not complicate my very first virtual server implementation unnecessarily in addition it made bug tracking easier. Third, testing only the algorithm used for selecting a real server to map a client to is not useful since this choice is done just once while the list of clients (however it gets stored and searched) needs to be searched for every single packet.


next up previous contents
Next: Bibliography Up: Using NAT Previous: Virtual Routes
Michael Hasenstein
8/22/1997