Which Cisco IOS command can be used to document the use of a specific ACL

IP access lists provide many benefits for securing a network and achieving nonsecurity goals, such as determining quality of service (QoS) factors or limiting debug command output. This module describes how to create standard, extended, named, and numbered IP access lists. An access list can be referenced by a name or a number. Standard access lists filter on only the source address in IP packets. Extended access lists can filter on source address, destination address, and other fields in an IP packet.

After you create an access list, you must apply it to something in order for it to have any effect. This module describes how to apply an access list to an interface. However, there are many other uses for access lists, which are mentioned in this module and described in other modules and in other configuration guides for various technologies.

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 www.cisco.com/go/cfn. An account on Cisco.com is not required.

The following restrictions apply when configuring IPv4 and IPv6 access control lists (ACLs) on Cisco ASR 903 Series Aggregation Services Routers:

Application control engine (ACE)-specific counters are not supported.
Layer 3 IPv4 and IPv6 ACLs are not supported on the same interface.
MAC ACLs are not supported on Ethernet flow points (EFPs) or trunk EFP interfaces to which Layer 3 IPv4 or IPv6 ACLs are applied.
A maximum of 500 ACEs per ACL are supported.
IPv4 and IPv6 ACLs are not currently supported on EFP interfaces. IPv4 and IPv6 ACLs are supported on physical interfaces, bridge-domain interfaces, and port-channel interfaces.

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 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.
Organize your access list so that more specific references in a network or subnet appear before more general ones.
A packet will match the first ACE in the ACL. Thus, a permit ip any any will match all packets, ignoring all subsequent ACES.
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-list command, 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 can delete an entry from a named access list. Use the no permit or 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.

You can include comments or remarks about entries in any IP access list. An access list remark is an optional remark before or after an access list entry that describes the entry so that you do not have to interpret the purpose of the entry. Each remark is limited to 100 characters in length.

The remark can go before or after a permit or deny statement. Be consistent about where you add remarks. Users may be confused if some remarks precede the associated permit or deny statements and some remarks follow the associated statements.

The following is an example of a remark that describes function of the subsequent deny statement:

ip access-list extended telnetting remark Do not allow host1 subnet to telnet out deny tcp host 172.16.2.88 any eq telnet

Beyond the basic steps to create a standard or extended access list, you can enhance your access lists as mentioned below. Each of these methods is described completely in the Refining an IP Access List module.

You can impose dates and times when permit or deny statements in an extended access list are in effect, making your access list more granular and specific to an absolute or periodic time period.
After you create a named or numbered access list, you might want to add entries or change the order of the entries, known as resequencing an access list.
You can achieve finer granularity when filtering packets by filtering on noninitial fragments of packets.

This section describes the general ways to create a standard or extended access list using either a name or a number. Access lists are very flexible; the tasks simply illustrate one permit command and one deny command to provide you the command syntax of each. Only you can determine how many permit and deny commands you need and their order.

Note

The first two tasks in this module create an access list; you must apply the access list in order for it to function. If you want to apply the access list to an interface, perform the task “Applying the Access List to an Interface”.

If you want to filter on source address only, a standard access list is simple and sufficient. There are two alternative types of standard access list: named and numbered. Named access lists allow you to identify your access lists with a more intuitive name rather than a number, and they also support more features than numbered access lists.

Use a standard, named access list if you need to filter on source address only. This task illustrates one permit statement and one deny statement, but the actual statements you use and their order depend on what you want to filter or allow. Define your permit and deny statements in the order that achieves your filtering goals.