Missing Link in ENTERPRISE NETWORKING
By: Tony Fortunato | 11 April 2017
Tony Fortunato explains how he tested a legacy Cisco ISR's performance.
In my previous blog, I explained how I confirmed that my client's wireless equipment would be able to handle a planned increase in bandwidth of a wireless WAN at a remote site. My next step in this network upgrade project was testing the router to make sure it also can handle 100 Mbps, up from 60 Mbps.
The client's router is a Cisco Integrated Services Router 2821, which is no longer supported by Cisco. Unfortunately, my client can't afford to replace equipment as soon as it is out of support. Like most small IT shops, this company runs equipment until it fails.
To start, I went to Cisco's website and found a performance table that showed it could handle 87 Mbps using Fast/CEF switching. However, the table also shows that the tests were performed using 64- byte packets. Most links have a variety of packet sizes, so 64 bytes is a bit too low for our purposes. Not only is the packet size an issue, but depending on the router's configuration, performance will change.
The best thing I could do was to take a backup router that has the same configuration and specifications as the production router and run some of my own tests. I did not have access to traffic generation or service-level test tools, so I simply used two laptops running iperf. Using Windows laptops isn't optimal, but that's all that I had.
My first test is to establish a baseline of laptop performance. I removed all unnecessary protocols from the laptop network adapters, leaving only IPv4, and disabled the WiFi adapters since the wireless adapters had internet access and the testing was conducted via their gigabit Ethernet ports. I disabled the firewall and made sure no applications were running in the background. Finally, I connected the laptops directly to one another using a patch cable. Since Microsoft uses Automatic Private IP Addressing when DHCP is not present, I didn't have to bother with static IP addresses. My goal with this test is to ensure that the laptops can generate more than 100 Mbps since that is the proposed new service speed.
When using the iperf server, I configured the window size for 65 kilobytes to maximize throughput since the default was 8K. The client was configured with the same window size parameter and a -r to perform a download in addition to the default upload test.
In these kinds of situations, I prefer to run five tests to get a representative sample. Sometimes I drop the highest and lowest values to eliminate any anomalies, but decided not to in this case.
Cross-over cable test
Server command; iperf -s -w 65k
Client command; iperf -c darth -w 65k -r
This shows that the laptops can clearly generate more than 100 Mbps on a consistent basis.
Router with routing test
With this next test, I configured the test router the same way as the production router with the exception of NAT. I wanted to perform a NAT test separately, to better document its impact on performance.
The laptops required static IP addresses and a default gateway to traverse the router.
Since this testing used laptops running Microsoft Windows, these results were effectively the same as the first. Since iperf will use the largest packet available, this test also proves that we get more throughput than Cisco documented.
The last test involved NAT, so I added the applicable NAT commands and static maps. Unfortunately iperf was unable to perform a download (-r), so I simply reversed client and server roles.
Iperf through router with NAT
These results are the most interesting of all since you can clearly see that performance decreases and that one interface out performs the other depending on its role (inside vs outside).
In the end, I proved that the existing router can handle the 100 Mbps service using some laptops, iperf, and a consistent methodology.