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 processThere
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
switchingFast 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 switchingThe 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 switchingThis 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 forwardingCEF 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 detailsAnother 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 encryptionEncryption 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
performanceTo 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 1999Compiled by Clive Morris