Basic ACL Configuration

Configuration of ACLs is a two-step process:

Step 1. Create your ACL rules.

Step 2. Activate your ACL rules.

The following sections cover the configuration of ACL rules and their activation. This is an overview process concerning ACLs. Configuring specific types of ACLs, such as extended, reflexive, CBAC, and others, is covered in later chapters.

Creating ACLs

For each protocol that you want to filter, such as IP and IPX, you need to create a separate ACL. Each ACL is basically a grouping of statements that define your filtering rules, where either a number or name is used to group the statements. When using numbers, you cannot just choose any random number to assign to the grouping of your ACL statements. Instead, Cisco has reserved ranges of numbers for different protocols. Table 6-1 lists the numbers that you can use for the various protocols that support ACLs.

Table 6-1. ACL Numbering


ACL Numbers

Standard IP

1?99, 1300?1999

Extended IP

100?199, 2000?2699

Ethernet type code


Transparent bridging protocol type


Source route bridging protocol type


Ethernet MAC addresses


Transparent bridging vendor code


Source route bridging vendor code


Extended transparent bridging




Standard XNS


Extended XNS




Standard IPX


Extended IPX




Standard vines


Extended vines


Simple vines


The numbers (or names) listed in Table 6-1 are used to group multiple ACL statements in the same group. This enables you to create detailed filtering rules to enforce your security policies.

Generically, the following is the command to create a grouping of ACL statements that use numbers to differentiate between different groups:

Router(config)# access-list ACL_# permit | deny conditions

As you can see from this syntax, the number appears first, followed by the action and, finally, the conditions. Each type of ACL has its own set of valid conditions. These are covered in subsequent chapters on traffic filtering.

Here are some helpful tips when building your ACLs:

  • Before creating your ACLs, make sure that you have a picture of the topology of your network in front of you, along with a list of your security policies that you will be enforcing.

  • Put your list of security policies in order from most to least restrictive. Then use this list to build your ACL commands.

  • With ACL statements that have the same level of restriction, put the statement(s) that are used more often before the ones used less often. This ensures that commonly matched statements are processed first, reducing the burden on your router.

  • ACLs support remarks. This enables you to put a brief description before or after any command in your ACL grouping. Use this feature to make your ACL more readable and easier to reference.

  • Always create your ACL and then apply it to an interface. By default, empty ACLs permit all traffic. Plus, if you have Telnetted into a router and pasted in an ACL from a text editor, your Telnet connection could break if the empty ACL already was activated on the interface you were using for the Telnet connection.

ACLs and Remarks

One of the neat and handy features of ACLs is the capability to insert a description before or after an ACL statement in a grouping. This can be useful if you are looking at an ACL later trying to figure out why certain commands are listed in that order.

As an example, one of my clients had a very extensive ACL with more than 500 lines. Administrators were modifying the ACL weekly to fit changing conditions in their network. Because many people were modifying the ACL, an administrator coming in after the fact did not know what was changed, why it was changed, and when it was changed. In one situation, an administrator added an entry in the ACL over the course of the holiday to allow users to access specific internal resources so that they could work at home while enjoying time with their families. This would allow them to complete a critical project on time. Unfortunately, another administrator noticed this apparent hole in the ACL configuration and removed it. Of course, this caused problems for users over the holiday break because they could not access their resources from home. It took more than 3 days to track down this problem and fix it.

Activating ACLs

The statements in the ACL grouping will have no impact on the router until you activate them. When you are filtering traffic traveling through the router, you do this by activating the ACL on an interface with the following command:

Router(config)# interface type [slot_#/]port_#

Router(config-if)# protocol_name access-group ACL_#_or_name in | out

For example, if you wanted to activate an IP ACL on your interface, you would use the keyword ip for the protocol_name. Following this, you must specify either the name or number of the ACL that you are activating. Finally, you must specify the direction that the Cisco IOS will use when filtering traffic. If you specify in, the Cisco IOS uses the ACL to filter traffic as packets come into the interface (see Figure 6-2 for the processing of inbound ACLs); if you specify out, the Cisco IOS uses the ACL to filter traffic before it leaves the interface (see Figure 6-3 for the processing of outbound ACLs).

Editing ACLs

You can use two methods to edit groupings of ACL statements:

  • Use a text editor for Cisco IOS versions earlier than 12.2(14)S and 12.3(2)T.

  • Add, modify, and delete specific ACL entries in Cisco IOS versions 12.2(14)S and 12.3(2)T.

Before Cisco IOS 12.2(14)S and 12.3(2)T, editing ACLs was not a simple process. You could not delete a specific entry (unless the ACL was named), you could not insert an ACL into a specific place in the list (entries always were added to the bottom of the list), and you could not modify an existing entry in the list. Instead, you had to follow these steps to edit your ACL:

Step 1. Either copy the active configuration to a TFTP server (copy running-config tftp or scp?the latter is more secure) and use a text editor, such as Notepad, Wordpad, or any common editor, to extract the ACL statements; or execute the show running-config command, select the ACL statements, and paste them into a text editor.

Step 2. From the text editor, make your ACL changes.

Step 3. Select and copy your changes in your text editor, log back into the router, and access Configuration mode (configure terminal).

Step 4. Go into the interface or interfaces where the ACL was applied, and remove its application (no ip access-group).

Step 5. Delete the access list (no access-list); otherwise, if you pasted in the updated ACL configuration, you would be adding your text editor ACL to the end of the existing ACL on the router. Remember that order is important.

Step 6. Paste your ACL into the router (or use the copy tftp running-config or scp commands to pull in your ACL from your TFTP server).

Step 7. Reactivate the ACL on your router's interface or interfaces (ip access-group).

Step 8. Test your ACL configuration.


One problem with the previous approach is that you briefly face a security issue: Between the time that you deactivate the old ACL and reactivate the new ACL, all traffic is allowed through the interface. If this is a concern, when fixing your ACL, give it a different name or number than the one currently being used on the router. Then you can paste your new ACL on the router, remove the old ACL on the interface, and activate the new ACL on the interface. This leaves the interface open for only a second or two between the deactivation and activation of the two ACLs.

Starting with Cisco IOS versions 12.2(14)S and 12.3(2)T, you no longer have to perform these steps when modifying ACLs. Cisco has listened to its customer base and implemented an ACL feature that enables you to modify a specific statement in an ACL, delete one, or insert one at any point in the list. (Since Cisco introduced ACLs in the early 1990s, I have been complaining to any Cisco employee who would listen to me about this annoying approach to editing existing ACLs.) With the new ACL-editing feature, if you need to make only a minor change, such as modify an incorrect line, you can do this with a single command instead of the first seven steps listed earlier. This feature, called sequenced ACLs, is discussed in Chapter 7.


With either method, you need to take care that you do not accidentally lock yourself out of the router when you are configuring the router through Telnet. If you Telnet into the router, delete the ACL, and paste it back in, you inadvertently could lock yourself out. For example, assume that you have an ACL in which the first statement is to permit web traffic for certain users. You have fixed this ACL and deleted the old ACL on the router. You currently are Telnetted into the router through Ethernet0, where this ACL is applied inbound. If you do not remove this empty ACL before pasting in your fixed ACL, you will lock yourself out.

When you paste in the ACL, the router processes each statement in the ACL. As soon as one valid statement is pasted into the router's configuration, the Cisco IOS immediately uses the implicit deny (the ACL is no longer empty and already has been activated on the interface). If your Telnet connection is not permitted with the first statement, you have just locked yourself out of the router through Telnet. This is a very common occurrence, and I sometimes repeat this mistake. Therefore, closely examine your ACL before pasting it in, deactivate the ACL on the interface, paste in your ACL (or make your change with sequenced ACLs), and then reactivate the ACL.

Of course, if this is a perimeter router, you should not be using the public interface when Telnetting in the router, so you should not have to remove its application. However, when you delete and paste in the ACL, the applied empty ACL briefly permits all traffic. Therefore, if you are really paranoid, disable the public interface before making any ACL changes. An absolute must is to test your changes to ensure that your ACL configuration meets your security policies.