Access Control List
Access lists filter network traffic by controlling the forwarding or blocking of packets at the interface of a device. A device examines each packet to determine whether to forward or drop that packet, based on the criteria specified in access lists.
The criteria that can
be specified in an access list include the source address of the traffic, the
destination address of the traffic, and the upper-layer protocol.
Some users might
successfully evade basic access lists because these lists require no
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.
Use Cisco Feature
Navigator to find information about platform support and Cisco software image
support. To access Cisco Feature Navigator, go to
An account on Cisco.com is not required.
Information About Access Control Lists
Definition of an Access
An access list is a
sequential list consisting of at least one
statement and possibly one or more
statements. In the case of IP access lists, the statements can apply to IP
addresses, upper-layer IP protocols, or other fields in IP packets. The access
list is identified and referenced by a name or a number. Access list acts as a
packet filter, filtering packets based on the criteria defined in the access
An access list may be
configured, but it does not take effect until the access list is either applied
to an interface, a virtual terminal line (vty), or referenced by some command
that accepts an access list. Multiple commands can reference the same access
configuration example shows how to create an IP access list named
branchoffices. The ACL is applied to serial interface 0 on incoming packets. No
sources other than those on the networks specified by each source address and
mask pair can access this interface. The destinations for packets coming from
sources on network 172.20.7.0 are unrestricted. The destination for packets
coming from sources on network 172.29.2.0 must be 172.25.5.4.
ip access-list extended branchoffices
10 permit 172.20.7.0 0.0.0.3 any
20 permit 172.29.2.0 0.0.0.255 host 172.25.5.4
interface serial 0
ip access-group branchoffices in
Functions of an Access Control List
There are many reasons to configure access lists; for example, to restrict contents of routing updates or to provide traffic flow control. One of the most important reasons to configure access lists is to provide security for your network, which is the focus of this module.
Use access lists to provide a basic level of security for accessing your network. If you do not configure access lists on your device, all packets passing through the device are allowed access to all parts of your network.
Access lists can allow a host to access a part of your network and prevent another host from accessing the same area. In the figure below, Host A is allowed to access the Human Resources network, but Host B is prevented from accessing the Human Resources network.
You can also use access lists to define the type of traffic that is forwarded or blocked at device interfaces. For example, you can permit e-mail traffic to be routed but at the same time block all Telnet traffic.
Purpose of IP Access Lists
Access lists perform packet filtering to control which packets move through the network and where. Such control can help limit network traffic and restrict the access of users and devices to the network. Access lists have many uses, and therefore many commands accept a reference to an access list in their command syntax. Access lists can be used to do the following:
Filter incoming packets on an interface.
Filter outgoing packets on an interface.
Limit debug output based on an address or protocol.
Control virtual terminal line access.
Identify or classify traffic for advanced features, such as congestion avoidance, congestion management, and priority and custom queuing.
Reasons to Configure
There are many
reasons to configure access lists; for example, you can use access lists to
restrict contents of switching updates or to provide traffic flow control. One
of the most important reasons to configure access lists is to provide a basic
level of security for your network by controlling access to it. If you do not
configure access lists on your device, all packets passing through the device
could be allowed onto all parts of your network.
An access list can
allow one host to access a part of your network and prevent another host from
accessing the same area. For example, by applying an appropriate access list to
interfaces of a device, Host A is allowed to access the human resources network
and Host B is prevented from accessing the human resources network.
You can use access
lists on a device that is positioned between two parts of your network, to
control traffic entering or exiting a specific part of your internal network.
To provide some
security benefits of access lists, you should at least configure access lists
on border devices—devices located at the edges of your networks. Such an access
list provides a basic buffer from the outside network or from a less controlled
area of your own network into a more sensitive area of your network. On these
border devices, you should configure access lists for each network protocol
configured on the device interfaces. You can configure access lists so that
inbound traffic or outbound traffic or both are filtered on an interface.
Access lists are
defined on a per-protocol basis. In other words, you should define access lists
for every protocol enabled on an interface if you want to control traffic flow
for that protocol.
Software Processing of an Access List
The following general steps describe how the an access list is processed when it is applied to an interface, a vty, or referenced by any command. These steps apply to an access list that has 13 or fewer access list entries.
The software receives an IP packet and tests parts of each packet being filtered against the conditions in the access list, one condition (permit or deny statement) at a time. For example, the software tests the source and destination addresses of the packet against the source and destination addresses in a permit or denystatement.
If a packet does not match an access list statement, the packet is then tested against the next statement in the list.
If a packet and an access list statement match, the rest of the statements in the list are skipped and the packet is permitted or denied as specified in the matched statement. The first entry that the packet matches determines whether the software permits or denies the packet. That is, after the first match, no subsequent entries are considered.
If no conditions match, the software drops the packet. This is because each access list ends with an unwritten, implicit deny statement. That is, if the packet has not been permitted by the time it was tested against each statement, it is denied.
An access list with more than 13 entries is processed using a trie-based lookup algorithm. This process will happen automatically; it does not need to be configured.
Access List Rules
The following rules
apply to access control lists (ACLs):
Only one access
list per interface, per protocol, and per direction is allowed.
An access list
must contain at least one
statement or all packets are denied entry into the network.
The order in which
access list conditions or match criteria are configured is important. While
deciding whether to forward or block a packet, Cisco software tests the packet
against each criteria statement in the order in which these statements are
created. After a match is found, no more criteria statements are checked. The
specified in a different order can result in a packet being passed under one
circumstance and denied in another circumstance.
If an access list
is referenced by a name, but the access list does not exist, all packets pass.
An interface or command with an empty access list applied to it permits all
traffic into the network.
lists and extended access lists cannot have the same name.
Inbound access lists process packets before packets are sent to an outbound interface. Inbound access lists that have filtering criteria that deny packet access to a network saves the overhead of a route lookup. Packets that are permitted access to a network based on the configured filtering criteria are processed for routing. For inbound access lists, when you configure a permit statement, packets are processed after they are received, and when you configure a deny statement, packets are discarded.
lists process packets before they leave the device. Incoming packets are routed
to the outbound interface and then processed by the outbound access list. For
outbound access lists, when you configure a
statement, packets are sent to the output buffer, and when you configure a
packets are discarded.
An access list
can control traffic arriving at a device or leaving a device, but not traffic
originating at a device.
Helpful Hints for Creating IP Access Lists
The following tips will help you avoid unintended consequences and help you create more efficient access lists.
Create the access list before applying it to an interface (or elsewhere), because if you apply a nonexistent access list to an interface and then proceed to configure the access list, the first statement is put into effect, and the implicit deny statement that follows could cause you immediate access problems.
Another reason to configure an access list before applying it is because an interface with an empty access list applied to it permits all traffic.
All access lists need at least one permit statement; otherwise, all packets are denied and no traffic passes.
Because the software stops testing conditions after it encounters the first match (to either a permit or deny statement), you will reduce processing time and resources if you put the statements that packets are most likely to match at the beginning of the access list. Place more frequently occurring conditions before less frequent conditions.
Organize your access list so that more specific references in a network or subnet appear before more general ones.
Use the statement permit any any if you want to allow all other packets not already denied. Using the statement permit any any in effect avoids denying all other packets with the implicit deny statement at the end of an access list. Do not make your first access list entry permit any any because all traffic will get through; no packets will reach the subsequent testing. In fact, once you specify permit any any, all traffic not already denied will get through.
Although all access lists end with an implicit deny statement, we recommend use of an explicit deny statement (for example, deny ip any any). On most platforms, you can display the count of packets denied by issuing the show access-listcommand, thus finding out more information about who your access list is disallowing. Only packets denied by explicit deny statements are counted, which is why the explicit deny statement will yield more complete data for you.
While you are creating an access list or after it is created, you might want to delete an entry.
You cannot delete an entry from a numbered access list; trying to do so will delete the entire access list. If you need to delete an entry, you need to delete the entire access list and start over.
You can delete an entry from a named access list. Use the no permitor no deny command to delete the appropriate entry.
In order to make the purpose of individual statements more scannable and easily understood at a glance, you can write a helpful remark before or after any statement by using the remark command.
If you want to deny access to a particular host or network and find out if someone from that network or host is attempting to gain access, include the log keyword with the corresponding deny statement so that the packets denied from that source are logged for you.
This hint applies to the placement of your access list. When trying to save resources, remember that an inbound access list applies the filter conditions before the routing table lookup. An outbound access list applies the filter conditions after the routing table lookup.
IP Packet Fields You Can Filter to Control Access
You can use an extended access list to filter on any of the following fields in an IP packet. Source address and destination address are the two most frequently specified fields on which to base an access list:
Source address--Specifies a source address to control packets coming from certain networking devices or hosts.
Destination address--Specifies a destination address to control packets being sent to certain networking devices or hosts.
Source and Destination Addresses
Source and destination address fields in an IP packet are two typical fields on which to base an access list. Specify source addresses to control the packets being sent from certain networking devices or hosts. Specify destination addresses to control the packets being sent to certain networking devices or hosts.
Wildcard Mask for Addresses in an Access List
Address filtering uses wildcard masking to indicate to the software whether to check or ignore corresponding IP address bits when comparing the address bits in an access list entry to a packet being submitted to the access list. By carefully setting wildcard masks, you can specify one or more IP addresses for permit or deny tests.
Wildcard masking for IP address bits uses the number 1 and the number 0 to specify how the software treats the corresponding IP address bits. A wildcard mask is sometimes referred to as an inverted mask because a 1 and 0 mean the opposite of what they mean in a subnet (network) mask.
If you do not supply a wildcard mask with a source or destination address in an access list statement, the software assumes an implicit wildcard mask of 0.0.0.0, meaning all values must match.
Unlike subnet masks, which require contiguous bits indicating network and subnet to be ones, wildcard masks allow noncontiguous bits in the mask.
The table below shows examples of IP addresses and masks from an access list, along with the corresponding addresses that are considered a match.
Table 1 Sample IP Addresses, Wildcard Masks, and Match Results
All addresses will match the access list conditions.
Only host 172.18.5.2 matches
Only subnet 172.18.8.0/29 matches
Only subnet 172.18.8.8/29 matches
Only subnet 172.18.8.15/30 matches
0.0.254.255 (noncontiguous bits in mask)
Matches any even-numbered network in the range of 10.1.2.0 to 10.1.254.0
Access List Sequence Numbers
The ability to apply sequence numbers to IP access list entries simplifies access list changes. Prior to the IP Access List Entry Sequence Numbering feature, there was no way to specify the position of an entry within an access list. If you wanted to insert an entry in the middle of an existing list, all of the entries after the desired position had to be removed, then the new entry was added, and then all the removed entries had to be reentered. This method was cumbersome and error prone.
This feature allows users to add sequence numbers to access list entries and resequence them. When you add a new entry, you specify the sequence number so that it is in a desired position in the access list. If necessary, entries currently in the access list can be resequenced to create room to insert the new entry.
ACL Supported Types
The switch supports IP ACLs and Ethernet (MAC) ACLs:
IP ACLs filter IPv4 traffic, including TCP, User Datagram Protocol (UDP), Internet Group Management Protocol (IGMP), and Internet Control Message Protocol (ICMP).
Ethernet ACLs filter non-IP traffic.
The switch supports three
types of ACLs to filter traffic:
Port ACLs access-control traffic
entering a Layer 2 interface. You can apply port ACLs to a Layer 2 interface in
each direction to each access list type — IPv4 and MAC.
VLAN ACLs or VLAN maps access-control all packets
(bridged and routed). You can use VLAN maps to filter traffic between devices
in the same VLAN. VLAN maps are configured to provide access control based on
Layer 3 addresses for IPv4. Unsupported protocols are access-controlled through
MAC addresses using Ethernet ACEs. After a VLAN map is applied to a VLAN, all
packets (routed or bridged) entering the VLAN are checked against the VLAN map.
Packets can either enter the VLAN through a switch port or through a routed
port after being routed.
ACLs are ACLs that are applied to Layer 2 interfaces on a switch. Port ACLs are
supported only on physical interfaces and not on EtherChannel interfaces. Port
ACLs can be applied to the interface
inbound direction. The following access lists are supported:
Standard IP access lists
using source addresses
Extended IP access lists
using source and destination addresses and optional protocol type information
MAC extended access lists
using source and destination MAC addresses and optional protocol type
The switch examines ACLs on
an interface and permits or denies packet forwarding based on how the packet
matches the entries in the ACL. In this way, ACLs control access to a network
or to part of a network.
Figure 2. Using ACLs to
Control Traffic in a Network. This is an
example of using port ACLs to control access to a network when all workstations
are in the same VLAN. ACLs applied at the Layer 2 input would allow Host A to
access the Human Resources network, but prevent Host B from accessing the same
network. Port ACLs can only be applied to Layer 2 interfaces in the inbound
When you apply a port ACL to
a trunk port, the ACL filters traffic on all VLANs present on the trunk port.
When you apply a port ACL to a port with voice VLAN, the ACL filters traffic on
both data and voice VLANs.
With port ACLs, you can
filter IP traffic by using IP access lists and non-IP traffic by using MAC
addresses. You can filter both IP and non-IP traffic on the same Layer 2
interface by applying both an IP access list and a MAC access list to the
You cannot apply more than
one IP access list and one MAC access list to a Layer 2 interface. If an IP
access list or MAC access list is already configured on a Layer 2 interface and
you apply a new IP access list or MAC access list to the interface, the new ACL
replaces the previously configured one.
Access Control Entries
An ACL contains an ordered list of access control entries (ACEs). Each ACE specifies permit or deny and a set of conditions the packet must satisfy in order to match the ACE. The meaning of permit or deny depends on the context in which the ACL is used.
ACEs and Fragmented and Unfragmented Traffic
IP packets can be fragmented
as they cross the network. When this happens, only the fragment containing the
beginning of the packet contains the Layer 4 information, such as TCP or UDP
port numbers, ICMP type and code, and so on. All other fragments are missing
Some access control entries
(ACEs) do not check Layer 4 information and therefore can be applied to all
packet fragments. ACEs that do test Layer 4 information cannot be applied in
the standard manner to most of the fragments in a fragmented IP packet. When
the fragment contains no Layer 4 information and the ACE tests some Layer 4
information, the matching rules are modified:
ACEs and Fragmented and Unfragmented Traffic Examples
Consider access list 102,
configured with these commands, applied to three fragmented packets:
Switch(config)# access-list 102 permit tcp any host 10.1.1.1 eq smtp
Switch(config)# access-list 102 deny tcp any host 10.1.1.2 eq telnet
Switch(config)# access-list 102 permit tcp any host 10.1.1.2
Switch(config)# access-list 102 deny tcp any any
In the first and second ACEs
in the examples, the
eq keyword after the
destination address means to test for the TCP-destination-port well-known
numbers equaling Simple Mail Transfer Protocol (SMTP) and Telnet, respectively.
Packet A is a TCP packet from
host 10.2.2.2., port 65000, going to host 10.1.1.1 on the SMTP port. If this
packet is fragmented, the first fragment matches the first ACE (a permit) as if
it were a complete packet because all Layer 4 information is present. The
remaining fragments also match the first ACE, even though they do not contain
the SMTP port information, because the first ACE only checks Layer 3
information when applied to fragments. The information in this example is that
the packet is TCP and that the destination is 10.1.1.1.
Packet B is from host
10.2.2.2, port 65001, going to host 10.1.1.2 on the Telnet port. If this packet
is fragmented, the first fragment matches the second ACE (a deny) because all
Layer 3 and Layer 4 information is present. The remaining fragments in the
packet do not match the second ACE because they are missing Layer 4
information. Instead, they match the third ACE (a permit).
Because the first fragment
was denied, host 10.1.1.2 cannot reassemble a complete packet, so packet B is
effectively denied. However, the later fragments that are permitted will
consume bandwidth on the network and resources of host 10.1.1.2 as it tries to
reassemble the packet.
Fragmented packet C is from
host 10.2.2.2, port 65001, going to host 10.1.1.3, port ftp. If this packet is
fragmented, the first fragment matches the fourth ACE (a deny). All other
fragments also match the fourth ACE because that ACE does not check any Layer 4
information and because Layer 3 information in all fragments shows that they
are being sent to host 10.1.1.3, and the earlier permit ACEs were checking