The technical name for an acces list is access control list (ACL) and individual entries in an access control list are called access control entries (ACEs). ACEs are also known as access list statements. The term access control lists isn’t often used in practice and these lists are typically referred to simply as access lists or ACLs. An access list is simply a list of conditions or statements that categorize and match packets in a number of interesting ways.
Access lists are primarily used as simple filters to permit or deny packets through interfaces in order to exercise control on traffic flowing through the network. But this is not the only use of access lists and they can also be used in situations that don’t necessarily involve filtering packets. I have listed a few of those other uses of access lists here:
Management Access You can use access lists to control which hosts can remotely manage your router using Telnet or SSH by applying access lists to VTY lines using the access-class statement in line configuration mode.
Route Advertisement You can use access lists to control which routes or networks will or will not be advertised by dynamic routing protocols like RIP, EIGRP, or OSPF. In such situations, access lists are defined in the same manner but the difference is where you apply those access lists. When access lists are used to control route advertisements they are called distribute lists.
Debug Output Cisco IOS debug commands are very useful for deep network troubleshooting but these commands often produce a lot of output which can be difficult to read and interpret. You can define access lists to identify interesting packets and use the access lists with debug command to display only the output that relates to interesting traffic.
Encryption When encrypting traffic between two routers or a router and a firewall, you must tell the router what traffic to encrypt, what traffic to send unencrypted, and what traffic to drop. Access lists are a natural choice to match or identify interesting traffic for these operations.
You should be able to appreciate the variety of ways in which access lists are used. We will not cover all of these other uses of ACLs in this chapter. However, you will see these uses of ACLs in more advanced Cisco certification exams as you move on in your career. Our coverage of access lists will focus on their use as traffic filters
When you’re creating access lists (or any configuration, for that matter), it’s a good idea to create them first in a text editor like Notepad, and then once you’ve worked out all the details, try them in a lab environment. Keep in mind that access lists are traffic filters applied to interfaces and anytime you’re working on filters, you risk causing an outage to a production network.
As you have learned, access lists are the means whereby Cisco devices categorize and match packets and have several applications. The good news here is that regardless the specific application of access lists, they are defined the same way. Access lists are a very important topic for your CCNA exam so we will go into great depth while covering access lists in the next several sections.
Access Lists Statements
An access list is basically a sequential listing of statements also known as access control entries (ACEs). Each entry in an access list defines a specific condition that packets are compared against before taking the specified action. Each access list statement specifies a permit or deny action to be taken if a packet matches the associated condition. Please see Table 9-1 for a few simple examples of access list statements:
Table 9-1 Simple Access List Statements
|Access List Statement||Description|
|permit host 172.16.34.2||Match packets with a source IP address of 172.16.34.2 only and permit those packets.|
|deny host 172.16.34.24||Match packets with a source IP address of 172.16.34.24 only and deny those packets.|
|permit any||Match and permit any and all packets.|
There can be several permit and deny statements in an access list. A packet is compared with each statement one by one in a sequential order. That is, it’ll start with the first line of the access list, then go to line 2, then line 3, and so on. If the packet matches the condition on a line of the access list, the packet is acted upon and no further comparisons take place. There is also an implicit “deny” at the end of each access list. Which means that if a packet doesn’t match the condition on any of the lines in the access list, the packet will be discarded.
If you have some exposure to computer programming or scripting, you would be able to appreciate that access lists are much like a series of if-then statements found in many programming languages. When a given condition in the if-then statement is met, then a given action is taken. If the specific condition isn’t met, no action is taken and the next statement is evaluated.
Named versus Numbered
Access lists on Cisco devices can be either named or numbered. Named access lists are referenced with a name such as UET or CertificationKits. Numbered access lists are the older method, where each ACL is defined by a number such as 1 or 104. In practice, both numbered and named access lists are widely used but I personally believe named access lists make your configuration more readable and less cryptic. Some devices such as certain Cisco Nexus switches don’t support numbered access lists at all. I would advise using named access lists in the real world where possible, but for the sake of your CCNA exam you should be thoroughly familiar with both formats.
What are Wildcard Masks?
Wildcard masks, also known as inverse masks, are used in many devices for creating access lists. Wildcards are used with IP addresses in IP access lists to specify a single host, a network, a subnet, or a supernet in order to control what should be permitted or denied. These masks are typically written in dotted decimal notation just like regular IP addresses and are quite confusing at first simply because they’re the opposite, in binary, of subnet masks.
Subnet masks used while configuring IP addresses on interfaces start with 255 and have the large values on the left side, for example, IP address 192.168.2.29 with subnet mask 255.255.255.0. Wildcard masks for IP access lists are the reverse, for example, 0.0.0.255. In other words, the wildcard mask you would use to match a range that is described with a subnet mask of 255.255.255.0 would be 0.0.0.255.
When the value of a wildcard mask is broken down into binary (0s and 1s), the results determines which address bits (binary digits) are to be considered in processing the traffic, and which address bits are to be ignored. A 0 in a wildcard mask indicates that the corresponding address bit must be considered (matched); a 1 in the wildcard mask is a “don’t care” meaning that the value of the corresponding address bit doesn’t matter. The following table further explains the concept.
Table 9-2 Wildcard Mask Example
|11000000.11001000.00000002.00000000||Network address (binary)|
|11111111.11111111.11111111.00000000||Subnet mask (binary)|
|00000000.00000000.00000000.11111111||Wildcard mask (binary)|
For class A, B, and C subnet masks, the conversion to wildcard masks is easily done by replacing all 0s with 255s, and all 255s with 0s.
Table 9-3 Classful Wildcard Masks
|Subnet Mask||Matching Wildcard Mask|
While this conversion seems pretty straightforward, in the real world, networks are often not designed on classful boundaries. As an example, consider a subnet mask of 255.255.240.0 whose corresponding wildcard mask works out to be 0.0.15.255.
There is a simple procedure to figuring out all wildcard masks, and it is easier than you might think. Here it is using the subnet mask 255.255.240.0:
- Replace all 0 octets in the subnet mask with 255 and all 255 octets with 0 for a result of 0.0.240.255. Do not change octets that are neither 0 nor 255.
- Calculate the number of host addresses provided by 240 in the third octet of subnet mask 255.255.240.0 yielding 16 hosts.
- The wildcard mask will be a derivative of the number of host addresses provided by the subnet mask minus one. As 16 – 1 = 15, replace this value for the third octet not changed in step 1.
- The resulting wildcard mask is 0.15.255.255.
If it all seems overwhelming at first don’t be afraid, as the more you work with inverse masks, the easier it becomes.
Table 9-4 Sample Wildcard Masks
|Wildcard Mask||Wildcard Mask in Binary||Description|
|0.0.0.0||00000000.00000000.00000000.00000000||The entire IP address must match.|
|0.0.0.255||00000000.00000000.00000000.11111111||Just the first 24 bits or 3 octets must match.|
|0.0.255.255||00000000.00000000.11111111.11111111||Just the first 16 bits or 2 octets must match.|
|0.255.255.255||00000000.11111111.11111111.11111111||Just the first 8 bits or 1 octet must match.|
|255.255.255.255||11111111.11111111.11111111.11111111||Matches any and all addresses automatically.|
|0.0.0.1||00000000.00000000.00000000.00000001||Just the first 31 bits must match.|
|0.0.3.255||00000000.00000000.00000011.11111111||Just the first 22 bits must match.|
|0.31.255.255||00000000.00011111.11111111.11111111||Just the first 11 bits must match.|
Where to Apply Access Lists?
When access lists are used as packet filters, they can be applied to either inbound or outbound traffic on any interface. Applying an access list to an interface in a certain direction causes the router to compare every packet crossing that interface in the specified direction and then either forward or discard the packet based on permit or deny action in the access control entry (ACE) that matched the packet.
If the access list is applied inbound, when the router receives a packet, the Cisco IOS Software checks the access list’s permit or deny statements for a match. If the packet is permitted, the software continues to process the packet. If the packet is denied, the software simply drops the packet. If the access list is applied outbound, after receiving and routing a packet to the outbound interface, the software checks the access list’s permit or deny statements for a match. If the packet is permitted, the software transmits the packet. If the packet is denied, the software just discards the packet. However, access lists that are applied to routers interfaces do not filter traffic that originates from that router itself.
Access lists can be applied to an interface in either inbound or outbound direction. Figure 9-1 shows a simple router with just two interfaces, Fa0/0 and Fa0/1. I have labeled the points where an access list could be applied. Keep in mind that these directions are from the device’s viewpoint. Another way to understand the devices viewpoint is as if you were standing in the center of it.
Figure 9-1 Access List Application Points
As you have seen, an access lists can be applied to an interface in either an inbound or outbound direction and the direction is from the device’s viewpoint. In practice however, access lists should almost always be applied inbound on an interface and there are good reasons for that which we will cover later.
When you are trying to filter traffic you usually want to prevent it from getting into the network or to a device. Applying access lists to the inbound side of an interface keeps the packets from entering the device, thus saving processing time. When a packet is allowed into a device, then switched to another interface only to de dropped by an outbound access list, the resources used to switch the packet have been wasted.
You can configure standard or extended access lists on any router in your network. But it makes more sense to place standard access lists as close to the destination as possible. It is so because a standard access list can only filter on the basis of source IP address. If it is placed near the source, you may block the source IP address for your entire network rather than for a smaller portion of your network. Extended access lists provide more granular control and you can specify exactly what you want to filter. By placing extended access lists near the source you will conserve bandwidth and router resources.
Access List Logging
Access list logging is accomplished using the optional log keyword used with the access-list command when the access list is created. The log keyword causes an informational logging message about the packet that matches the entry to be sent to the console. The log message includes the access list number, whether the packet was permitted or denied, the source address, and the number of packets. As a large number of packets would typically match an access list, the message is generated for the first packet that matches, and then at 5-minute intervals, including the number of packets permitted or denied in the last 5-minute interval.
Access List Remarks
You can include comments or remarks about individual entries in a named IP access list. An access list remark is simply an optional comment before or after an access list entry that describes the entry in plain language, so you don’t have to interpret the purpose of the entry by its command syntax.
The remark can go before or after a permit or deny statement, but you should be consistent about where you put your remarks so that it is clear which remark describes which statement. It could be confusing to have some remarks before the associated permit or deny statements and some remarks after the associated statement.
Types of Access Lists
Cisco IOS Software supports the following types of access lists for Internet Protocol (IP):
Standard Access Lists Standard access lists use source IP addresses for matching packets.
Extended Access Lists Extended access lists use source and destination IP addresses for matching packets and optional protocol type information for finer granularity of control.
Reflexive Access Lists Reflexive access lists allow IP packets to be filtered based on session information. Reflexive access lists contain temporary entries, something not found in standard and extended access lists, and are nested within extended named access lists.
Time-based Access Lists Time-based access lists, as the name indicates, are not active all the time but rather are triggered by a time function.
Table 9-5 Packet Matching Criteria for Access Lists
|Packet Matching Criteria||Standard ACL||Extended ACL|
|Source IP address||Yes||Yes|
|Destination IP address||No||Yes|
|Protocol (TCP, UDP, ICMP, EIGRP, OSPF etc.)||No||Yes|
|QoS parameters (ToS, IP Precedence, DSCP)||No||Yes|