Network Computingwww.networkcomputing.com

The benefit of this scheme is that if you have an access list on the interface, only the first packet in the flow scans the access list for a match. Once an entry is made in the flow table it is "authorized" to allow all succeeding packets in the flow to go through, without consulting the access list. Obviously, the longer your access list, the more you will benefit from NetFlow. In addition, having more packets in a given flow will capitalize even further on the overhead of setting up the flow. Both of these factors were also obvious in our testing results. (See "ACL Performance With NetFlow," at left, for the test results.)

More Details Another advantage of NetFlow is that detailed accounting data is available for each and every flow. For example, if you experience a security violation, you are given a record of all the IP address pairs that might have been involved. And, if you want to use the information for billing purposes, the bytes used in each flow also are provided. In addition, you get a summary of general protocol usage for all the flows.

This data can be automatically exported to a third-party application running on a server.

If you run NetFlow on a 7500 (with Distributed Switching enabled), your network will benefit, because the NetFlow process can be handled on the VIP2 processors. Without NetFlow, the VIP2 processors cannot help access list performance at all. Note, however, that NetFlow will not work with CEF on the 7500 or the 8510. But later this quarter, a daughter card to boost ACL processing performance for each 8510 line card is expected to be available for purchase.

We recently enabled NetFlow on our Internet router at Syracuse University. Our Cisco 7200 model NPE200 connects us to the Internet via a T3 and it connects to our campus network via Fast Ethernet. Using Concord Communications' Network Health software, run before and after CPU utilization reports, we did not find any significant performance difference. We have a 39-line access list on the router's HSSI (High-Speed Serial Interface). Note, however, that our CPU utilization was fairly low before making changes: It was approximately 20,000 packets per second using about 30 percent of our T3, and averaging 20 percent utilization.

The Cost of Encryption Encryption is another common tool used to provide security on a network. However, before you implement encryption, you should realize that it's a much more CPU-intensive process than that involved with ACLs. And though NetFlow can speed up the process of determining to which packets you will apply the encryption, it won't assist with the encryption process itself.

Although we did not gather "before" and "after" encryption performance data, we did probe Cisco's recommendations. An RSP card on a Cisco 7500, or the NPE processor on a 7200, is capable of keeping pace with one or two T1s or E2s. Of course, performance will vary depending on how much CPU is being consumed by other tasks. For example, if your CPU is already subject to very high utilization, you obviously shouldn't consider adding encryption to the load.

On the other hand, if your RSP card or NPE processor is idling at a very low rate, you could get away with a bit more encryption. And if you have a VIP2-40 or better, you can expect the same relative performance from each VIP slot, which will offload the main CPU. Additionally, you can add an ESA (Encryption Service Adapter) to any of the above configurations to achieve performance in the 5-Mbps to 30-Mbps range, depending on the packet size. Our preliminary testing showed that the ESA card has very little impact on CPU utilization.

Testing ACL Performance To determine what would happen to the performance on a Cisco router when access lists are added, we configured a Netcom SmartBits SMB-2000 with MS-7710 cards to generate a known load (see "Our Test Environment," at left). The SmartBits offered us the ability to blast precise amounts of TCP packets across one of our Cisco 7200 NPE200 routers. At the time we gathered performance data, the router ran IOS version 11.2(11)P.

We connected the two Fast Ethernet ports on the router to two Fast Ethernet cards on our SmartBits in full-duplex mode. The SmartBits sent symmetric streams of packets in each direction through the router. By varying the gap between each packet, we were able to control the number of packets per second that were sent. We used maximum throughput as our gauge for each test condition, which is defined as the most packets per second that can be sent before one packet is dropped.

We began our tests with a baseline that contained no ACLs. We then added a simple one-line ACL to each of the two interfaces. The ACL permitted any packets ("access-list 103 permit ip any any") and found that there was indeed a performance hit--just by turning on ACLs. Next we turned off ACLs on one interface and added a 25-line and a 200-line ACL to the other interface. Our ACL was designed such that every bit in every line of the list had to be examined. We found a dramatic performance hit when we added the 200-line ACL.

Using NetFlow, we varied the number of packets per flow. For example, with the two-packet flow, we sent a packet with the SYN bit turned on. Next we sent two ACK (acknowledgement) packets, followed by a packet with the FIN bit, which would clear the entry from the flow cache table. The cache entry would be set up based upon the source and destination IP addresses, as well as the source and destination ports. Packets would then be forwarded without having to consult the access list, with the last packet causing the flow cache entry to be deleted and forcing a new entry when the next packet arrived.

While we were able to force the router to add a new cache entry for every flow, we had only one entry in the cache at any given time. We found that this configuration set us up for optimal performance conditions with the flow cache. With NetFlow running on Syracuse University's Internet router, we noticed and suspected that performance would not be quite as good with this many cache entries.

Peter Morrissey is a network systems programmer at Syracuse University and a contributing editor to Network Computing. He can be reached at ppmorris@syr.edu.