Access control lists (ACLs) are used to filter packets traveling over the network according to rules set at the router level. They can be set to filter traffic based on source or destination IP addresses, protocol and port number, reference NAT information, filter debugging commands, and work with route maps. ACLs can be applied to any of your router’s interfaces, including the Telnet ports.

Types of Access Lists

  • Standard Numbered Access List: This type of list is a very basic form of ACL that is very easy to configure but have a limited range of options. Standard Numbered Access Lists filter according to the source IP address or network. Their configuration lines are numbered in the range between 1 and 99.
  • Extended Numbered Access List: This type of list gives you a more robust range of options but is more difficult to configure and troubleshoot. Extended Numbered Access Lists can filter according to destination or source IP address or network, protocol, and port number. It uses the range 100-199 to number its configuration lines.
  • Named Access Lists: These lists associate a list of filters with a name, which makes them easier for network administrators to recognize when working with a router configuration. You can set named access lists as extended or standard at the initial configuration line.

Port Numbers

The common port numbers used in ACLs are necessary to know when taking a CCNA exam and when working out in the real world.


Some General Rules for Creating Access Control Lists

  • Use one ACL per interface per direction. It may be tempting to have each rule, or category of rules that you make up in your head, on its own ACL. However, that can get confusing if you have to find that one rule that messes up your ACL settings or somebody else has to make sense of your ACLs. One access control list for each interface and direction should be enough.
  • The lines are processed from the top down. The ACL will move down the list until it finds a match. If you have a line that tells the router to allow traffic from the network at, but then you go back and add a line below it to deny traffic from, it will continue to merrily allow traffic from the network without bothering to check that new rule you added. That means placing the “deny” rule above the “allow” rule so that the ACL sees it first.
  • There is an automatic “Deny All” rule at the bottom of every ACL. This is a security measure that can’t be removed, so if you don’t want the ACL to automatically drop packets that it can’t match with any rule you set, simply add an “Allow All” rule at the very end of your ACL list.
  • The router won’t filter traffic that it generates. This can make testing your ACLs tricky if you’re trying to do it directly from your router. For this reason, experienced network administrators will test their ACLs from another machine.
  • Don’t forget to pause ACL lists before editing them. This is especially true for standard and extended access lists. To edit your ACL, use the no ip access-group <name or number of your access list> in command to pause it. To reactivate your ACL list, use the command ip access-group <name or number of your access list> in. To double-check that your entries were made successfully, use the show ip access-lists command. On a related note, some administrators have actually deleted their ACLs altogether, and then had to plug their lists back in. This isn’t necessary when you can simply pause it.
  • You can reuse the same ACL on several interfaces. In most cases, you will have the same ACL policy throughout the entire network. For this reason, many administrators have their ACL lists saved in their favorite text editor, like Notepad, so they can simply copy-and-paste as needed. If you are copy-and-pasting your configuration from a text file, make sure you have an exclamation mark (!) between each line of configuration so the router knows to do a carriage return. The same ACL can be applied to several interfaces as needed.
  • Be concise. Making your ACLs as brief as possible will save you some typing and troubleshooting when your ACL starts blocking or allowing something it shouldn’t. It also saves router resources when it doesn’t have to move through a long ACL list.
  • Arrange your ACLs for best use of resources. Cisco recommends placing Extended ACLs as close to the source as possible and Standard ACLs as close to the destination as possible. However, some network administrators place all types of ACLs as close to the source as possible to stop packets from being routed if they’re just going to be dropped by the ACL anyway.

Wildcard Masks

Wildcard masks are an essential part of many tasks such as managing Access Control Lists and helping some routing protocols run smoothly. They provide a way to tell routers which parts of an IP or network address to match. Wildcard masks work at the binary level using 1s to tell the router to ignore the digit and 0s to tell the router to match the digit. In human-readable form, wildcard masks have the same format as subnet masks and can be calculated by subtracting the subnet mask from A wildcard mask is necessary if you are configuring your ACL to match entire subnets or networks. The command would look something like:

Router(config)# access-list 1 permit

Router(config)# access-list 1 deny

This configures the access list to allow traffic from the subnet with a subnet mask of but deny traffic from the subnet of with the same subnet mask.

Configuring ACL to allow or deny specific hosts is a little easier if you’re using standard access lists because you don’t have to calculate for wildcard masks. Just make sure you don’t mix up the commands for allowing subnets and allowing hosts. The command for hosts looks like, Router(config)# access-list 1 permit host

Configuring for Extended ACLs

Remember what I said about extended lists being a bit tricker to manage? To configure them, you need to know the service or protocol, the source network or host, the destination network or host, and the port number you want to allow or deny for each entry. The command will look something like:

access-list <access list number between 100 and 199> permit/deny <service or protocol> <source network or host IP address> <Wildcard for the source network if applicable> <destination network or host IP address> <Wildcard for the destination network if applicable> <port>

If the entry is meant to apply to any source or destination network and/or host, you can substitute the word “any” for the source or destination address as applicable. So a typical command might look like:

access-list 101 deny tcp host eq telnet

access-list 100 permit tcp any host eq ftp established

Configuring Named ACLs

You can configure live Named ACLs that haven’t been paused, making them convenient if you are prone to forgetting to reactivate your ACLs when you are finished configuring them. The syntax for configuring named ACLs is a little different. First you tell the router that you want to configure a named ACL, and at the same time, tell it whether you want the ACL to be standard or extended: ip access-list extended YourACLName.

Your router prompt should now look like Router(config-ext-nacl)#. You can now configure your new named ACL with commands like, deny tcp any any eq 80.

Assign ACLs to Interfaces

You’re going to waste a lot of effort if you have all your ACLs configured but never assign them to interfaces. Common mistakes include disabling ACLs and then forgetting to enable them again and assigning the wrong ACL to a particular interface. First, you access the interface that you want to assign an ACL to with a command like interface e0/0. Then you can assign the ACL you want with the command ip access-group 101 in.

Configuring ACLs does take practice, so it helps to practice in a laboratory setting. There’s no need to be embarrassed by having to learn because even experienced networking professionals can be thrown by an ACL that hasn’t been configured correctly. You can call it “testing the new ACLs” if somebody walks in on you.

Some Books To Check Out


More Networking Supplies on eBay

Unfortunaly, this xml/rss feed does not work correctly...