Introduction

An Access Control List (ACL) is generically a method for doing pattern matching based on protocol information. There are many reasons for doing this type of pattern matching, such as restricting access for security reasons or restricting routing tables for performance reasons.

Cisco has several different general kinds of access lists. The most common are the numbered ACLs, which are summarized in Table 19-1. But there are also named access lists, reflexive access lists, context-based access lists, and rate-limit access lists. There are even timed access lists that can have different effects at different times of day, although we will not cover them in this book. 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 discussed in more detail in Chapter 6, Chapter 7, Chapter 8 and Chapter 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 a 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, the corresponding ACL type will also be unavailable.

Table 19-1. Numbered access list types

Numeric range	Access list type
1 - 99	Standard IP ACL
100 - 199	Extended IP ACL
200 - 299	Ethernet type code ACL
300 - 399	DECNET ACL
400 - 499	XNS ACL
500 - 599	Extended XNS ACL
600 - 699	AppleTalk ACL
700 - 799	48-bit MAC address ACL
800 - 899	IPX ACL
900 - 999	Extended IPX ACL
1000 - 1099	IPX service advertisement protocol
1100 - 1199	Extended 48-bit MAC address ACL
1200 - 1299	IPX NLSP ACL
1300 - 1999	Standard IP ACL, expanded range
2000 - 2699	Extended IP ACL, expanded range
2700 - 2999	SS7 (Voice) ACL

Clearly many 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 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 payloads of 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).

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 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, refer to Cisco IOS Access Lists (O'Reilly).