An Access Control List (ACL) is generically a method for doing pattern matching on protocol information. There are many reasons for doing this type of pattern matching, such as restricting access for security reasons, as well as restricting routing tables for performance reasons.
Cisco has several different general kinds of access-lists. The most common are the numbered ACLs, which we summarize in Table 19-1. But there are also named access-lists, reflexive access-lists, timed access-lists, context-based access-lists, and rate-limit access-lists. Within each of these general categories, there are many different types of ACLs that match on different protocol information. When working with route filtering, it is often easiest to work with prefix lists, which are another type of ACL that we discuss in more detail in Chapters 6, 7, 8, and 9.
You can apply an ACL in many different ways. Applied to an interface, you can use it to accept or reject incoming or outgoing packets, based on protocol information such as source or destination address, port number, protocol number, and so forth. Applied to a routing protocol, this same ACL might prevent the router from sharing information about this particular route. And applied to a route-map, the ACL could just identify packets that need to be tagged or treated differently.
Table 19-1 shows all of the current ranges for numbered access-lists. Cisco periodically adds new ranges to this list, so earlier IOS levels may not support all of these ACL types. Also bear in mind that if your IOS feature set doesn't support a particular protocol such as IPX, XNS, or AppleTalk, then the corresponding ACL type will also not be available.
| Numeric range | Access list type |
|---|---|
| 199 | Standard IP ACL |
| 100199 | Extended IP ACL |
| 200299 | Ethernet Type Code ACL |
| 700799 | 48-bit MAC Address ACL |
| 1,1001,199 | Extended 48-bit MAC Address ACL |
| 1,3001,999 | Standard IP ACL, expanded range |
| 2,0002,699 | Extended IP ACL, expanded range |
| 2,7002,999 | SS7 (Voice) ACL |
Some of these ranges deal with protocols or technologies that are beyond the scope of this book. This book's primary focus is on IP based technologies, so this chapter will not discuss ACL types that are intended for use with other protocols.
A named ACL is really just another way of writing either a Standard or Extended IP ACL. Named ACLs can make your configuration files considerably easier to read. Some commands that use an ACL for pattern matching will not accept named ACLs, but for the most part, named ACLs are interchangeable with normal IP ACLs. Their chief advantage is that you can nest other ACLs inside of a named ACL for greater flexibility.
Reflexive ACLs are more sophisticated objects that can contain temporary entries. Reflexive ACLs need to be nested inside of named ACLs. A reflexive ACL has two parts that are generally nested in two different named ACLs. One part watches for packets of a particular type by using normal extended IP ACL syntax. As soon as the router sees this packet, it activates a matching rule in another ACL. This allows you to do things like permitting inbound traffic of a particular type only after the router sees an initial outbound packet of the matching type.
However, reflexive ACLs are somewhat limited in their scope because they are not able to read into the IP packets. Many applications have more complicated behavior, such as using dynamically generated port numbers. To handle this type of situation, Cisco has developed another type of ACL called Context-Based Access Control (CBAC), which we discuss in Chapter 27.
Like reflexive ACLs, CBAC works by turning on and off temporary access-list rules. However, CBAC actively monitors applications using a stateful inspection algorithm that allows the router to react to the application and dynamically create new ACL rules. It can also watch for unusual application behavior and dynamically disable the corresponding temporary ACL rules.
You should always remember that every ACL ends with an implicit deny all clause. This means that if you are matching items (packets, for example) with an ACL, and the item fails to match any of the explicitly listed clauses of the ACL and falls off the end, it is the same as if the item matched an explicit deny clause. For this reason, if you are trying to block certain unwanted packets, for example, but you want to allow all others to pass, you must remember to include a permit all statement at the end of the ACL.
For more information on ACLs in general, we encourage the reader to refer to Cisco IOS Access Lists by Jeff Sedayao (O'Reilly).