RSS
  Demystifying Cisco Access Control Lists |
|
Changing Lists in Midstream
Another approach is to copy and paste the list into an editor or word processor, then reload it. You will have to get rid of the old version before pasting the new version into the router, otherwise the new version will just be appended to the end of the old version. To remove a configuration statement from a Cisco router, enter the statement again preceded by a "no." But with access lists, you only need to re-enter one of the statements in the list, preceded by a "no," and the entire list will be removed. The disadvantages to this approach is that no access list will be in place while you go through the process, and, if you make a mistake and unintentionally deny access to a host or service, you may have to turn
off the list while you figure out what you did wrong.
We've found that the best way to change an access list is to edit the old list with your word processor, then rename it before applying it to the interface. For example: 1. Copy the original access list after displaying it with the "show config" command and paste it into your word processor. 2. Use search and replace to change the access list number to a new number. 3. Edit the list. 4. Go into "config" mode and copy and paste the new list of statements back into the router. 5. Designate the interface where you are changing the list. Then using the "ip access-group xxx in/out" command, apply the new list (you don't have to turn off the old list by issuing the command with a "no" in front of it. The old list will be turned off automatically when you turn on the new list. This means that you can have only one access list per interface.) 6. If there are problems with your new list, simply reapply the old list by entering the "ip access-gr oup xxx in/out" command again using the old list number. Performance Issues Access list filters exact a toll on router performance. Some of the performance-enhancing features Cisco has built into its routers will not work when access lists are used. As a result, features such as fast switching, autonomous switching, distributed switching and optimal switching will not be utilized, forcing many of the packets to be process-switched. This can burden your router's main CPU. You will want to keep an eye on the router's CPU utilization using the "show process CPU," command and watch for packets dropped at the interface. Cisco's NetFlow feature apparently does support access lists, but its new express forwarding will not support access lists. This is a good reason to do your filtering just on routers at the edge of your network and avoid it at the core, where you might have higher concentrations of traffic.
A more obvious issue is that the longer your access list, the more work your router will have t o perform every time a packet has to be processed. The size of the list probably will not hurt you quite as much as the performance penalties we just described, but you should try to locate the most-likely matches at the top of your lists. One way to ensure that most of the incoming packets are matched on the first line of the list is to put in a rule that allows all TCP established or ACK (acknowledged) packets. Established packets are those that are the result of an already established session. Generally, the majority of network packets are established. Because it's very unlikely that these packets can be harmful, even if they are spoofed, you may want to consider letting them all in right off the bat. You might want to try your access list with and without this rule, and observe changes in the CPU utilization. The following statement at the top of your access list allows all established packets: access-list 101 permit tcp 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.0 established If you have many access lists, take a look at Check Point Software Technologies' Router Management Module, available with its Firewall-1 product. It lets you centrally manage the configuration of access lists on Bay, Cisco and 3Com routers via a GUI. And Cisco's Netsys Enterprise Solver product will help you check for errors in access lists as well as their impact on connectivity. Peter Morrissey is a network systems programmer at Syracuse University. He can be reached at ppmorris@syr.edu. |
 |
 |
|
Other Workshops
|
