White Paper: The cost of security on Cisco Routers

With security threats on the Internet and within your own network, you can protect your data further by using Access Control...

With security threats on the Internet and within your own network, you can protect your data further by using Access Control Lists

With all the possible security threats lurking on the Internet and within your own network, it seems as though you can't do enough to protect your data and your systems. For starters, you certainly should be scanning for vulnerabilities, hardening your hosts and installing firewalls when necessary. An obvious way to complement these tactics is to provide some additional filtering with ACLs and accounting. It's important to keep in mind, however, that when you start adding ACLs, you increase the processing burden on the router. And if your router is overworked, the additional ACLs may be just enough to put it out of commission.

At Syracuse University, we've been using Cisco's IOS (Internetwork Operating Systems) for more than five years and have found that there are concessions that must be made when enabling ACLs on Cisco's enterprise routers, such as the 7500, 7200 and 8510 models. In this article, we'll present some recent findings from some 7200 testing we've performed.

Don't get lost in the process

There is nothing mysterious about the way routers forward packets. Packets received on an interface are processed by the main CPU. Each packet is copied into memory and the routing table is consulted to determine the direction to forward the packet. Once the correct route and corresponding interface are chosen, packets are copied out of memory, onto the appropriate network.

Of course, other tasks are involved, such as keeping the routing tables updated, but the forwarding process is performed for every single packet that traverses through the router. In Cisco parlance, the forwarding process is referred to as Process Switching. Cisco is constantly inventing new schemes to improve packet-forwarding performance and all these schemes have different performance implications that vary based on whether ACLs are used.

Although the different switching methods employed can be a little confusing, one thing is clear: you would not want to push any traffic through a Cisco router that involves Process Switching. A Cisco 7500 using Process Switching is capable of forwarding only about 10,000 packets per second. Fortunately, Process Switching is rarely employed. Instead, a number of other switching techniques - including Fast Switching, Optimum Switching, Distributed Switching and Cisco Express Forwarding (CEF) - are more commonly used.

Fast switching

Fast Switching takes advantage of a route cache, which optimises the lookup of the forwarding information. Although Fast Switching still relies on the main processor to perform the forwarding, unlike Process Switching it interrupts the processor instead of waiting for its scheduled time. Additionally, Fast Switching is guaranteed to handle the packet in 16 cycles.

Optimum switching

The default switching method for Cisco's 7500 and 7200 routers is called Optimum Switching. It is almost identical to Fast Switching. Optimum Switching is guaranteed to take place in four cycles and the most recent entries are kept on the top of the table.

Distributed switching

This technique takes advantage of the local VIP2 processors in the Cisco 7513. VIP2 cards are installed, one per slot, providing more potential CPU cycles than would be available on the main processor, the Route Switch Processor (RSP). With Distributed Switching, the local processor on the VIP2 still has to copy the packet into the main processor memory, so there is some reliance on the RSP. ACLs cannot use Distributed Switching.

Cisco express forwarding

CEF is the fastest type of switching available on the Cisco platform. This switching model requires a specific model VIP2 card (VIP2-50), which has a faster CPU and more memory than the standard VIP2. The additional memory is necessary as the whole routing table is distributed to each VIP2 card. The VIP2 card has all the information it requires to forward the packet, without having to touch the main CPU. Cisco's 8510 offers a similar technique, however, its switching is accomplished via ASICs built into each line card. ACLs cannot use CEF either.

Our ongoing tests have proved that there are significant performance penalties once you enable ACLs, especially long ones such as the 200-line list that we used in our tests. This is because an access list cannot always take advantage of the fastest switching technique that might otherwise be available on the router.

Fortunately, there is another switching method that boosts the performance of access lists. This scheme, known as NetFlow Switching, has the added benefit of providing detailed accounting statistics, which can be invaluable for tracking down the source of security breaches. NetFlow Switching is available on both the 7200 and 7500 platforms, as well as on some of Cisco's lower-end units.

NetFlow will watch for TCP flows based on IP address and TCP port pairs. As soon as a unique flow is identified, a corresponding entry is made in the flow table. In fact, every time a packet is forwarded, it's first checked for a match in the flow table. If a match is present, the packet is immediately forwarded. When a packet in the flow arrives with the FIN bit turned on, it is removed from the cache. In cases where a packet with the FIN bit never shows up because a host is disconnected or rebooting, the flow entry is automatically removed after a settable time-out. User Datagram Protocol (UDP) flows must always time out because UDP is incapable of indicating the end of a session with a FIN bit.

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 "authorised" 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 capitalise even further on the overhead of setting up the flow.

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 utilisation reports, we did not find any significant performance difference. We have a 39-line access list on the router's High-Speed Serial Interface (HSSI). Note, however, that our CPU utilisation was fairly low before making changes: It was approximately 20,000 packets per second using about 30 per cent of our T3 and averaging 20 per cent utilisation.

The cost of encryption

Encryption is another common tool used to provide security on a network. However, before you implement encryption, you should realise 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 utilisation, 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 5Mbit/s to 30Mbit/s range, depending on the packet size. Our preliminary testing showed that the ESA card has very little impact on CPU utilisation.

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. 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.

( Network Computing 1999

Compiled by Clive Morris

This was last published in October 1999

Read more on Networking hardware

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.