Using

U​se either the switch CLI or an offline text editor to create an ACL. The CLI method is recommended for creating short ACLs.

​

Using the CLI to create an ACL

​

Inserting or adding an ACE to an ACL

These rules apply to all IPv4 ACEs you create or edit using the CLI:

• Named IPv4 ACLs:

​Add an ACE to the end of a named ACE by using the ip access-list command to enter the Named ACL ( nacl) context and entering the ACE without the sequence number.

For example, if you wanted to add a "permit" ACL at the end of a list named "List-1" to allow traffic from the device at 10.10.10.100:

switch(config)# ip access-list standard List-1
 
switch(config-std-nacl)# permit host 10.10.10.100

Insert an ACE anywhere in a named ACL by specifying a sequence number. For example, if you wanted to insert a new ACE as line 15 between lines 10 and 20 in an existing ACL named "List-2" to deny IPv4 traffic from the device at 10.10.10.77:

switch(config)# ip access-list standard List-2
 
switch(config-std-nacl)# 15 deny host 10.10.10.77

​

• Numbered IPv4 ACLs

Add an ACE to the end of a numbered ACL by using the access-list <1 - 99 | [100 - 199>] command.

​

For example, if you wanted to add a "permit" ACE at the end of a list identified with the number "11" to allow IPv4 traffic from the device at 10.10.10.100:

switch(config)# access-list 11 permit host 10.10.10.100

To insert an ACE anywhere in a numbered ACL, use the same process as described above for inserting an ACE anywhere in a named ACL. For example, to insert an ACE denying IPv4 traffic from the host at 10.10.10.77 as line 52 in an existing ACL identified (named) with the number 11:

switch(config)# ip access-list standard 99
 
switch(config-std-nacl)# 52 deny host 10.10.10.77

• Duplicate ACEs are not allowed in the same ACL. Attempting to enter a duplicate ACE displays the Duplicate access control entry message.

	NOTE: After a numbered ACL has been created (using access-list 1-99 | 100-199), it can be managed as either a named or numbered ACL.

​

Deleting an ACE

Deleting an ACE: Enter the ACL context and delete the sequence number for the unwanted ACE. (To view the sequence numbers of the ACEs in a list, use show access-list <acl-name-str> config.)

​

Duplicating an ACE

Duplicate ACEs are not allowed in the same ACL. Attempting to enter a duplicate ACE displays the Duplicate access control entry message.

​

Creating or editing an ACL offline

The section titled Editing an existing ACL describes how to use the CLI to edit an ACL, and is most applicable in cases where the ACL is short or there is only a minor editing task to perform. The offline method provides an alternative to using the CLI for creating or extensively editing a large ACL. This section describes how to:

​

• move an existing ACL to a TFTP server

• use a text (.txt) file format to create a new ACL or edit an existing ACL offline

• use TFTP to load an offline ACL into the switch’s running-config

For longer ACLs that may be difficult or time-consuming to accurately create or edit in the CLI, you can use the offline method described in this section.

	NOTE: Beginning with software release K_12_XX or later, copy commands that used either tftp or xmodem, also include an option to use usb as a source or destination device for file transfers. So although the following example highlights tftp, bear in mind that xmodem or usb can also be used to transfer ACLs to and from the switch.

​

1. Begin by doing one of the following:

   ​

   • To edit one or more existing ACLs, use copy command—output tftp to copy the current version of the ACL configuration to a file in your TFTP server. For example, to copy the ACL configuration to a file named acl-02.txt in the TFTP directory on a server at 10.28.227.2:

     ​

     ​

     switch# copy command-output 'show access-list config' tftp 10.28.227.2 acl02.txt pc
     

   • To create a new ACL, just open a text (.txt) file in the appropriate directory on a TFTP server accessible to the switch.

2. Use a text editor to create or edit the ACLs in the *.txt ASCII file format.

   ​If you are replacing an ACL on the switch with a new ACL that uses the same number or name syntax, begin the command file with a no ip access-list command to remove the earlier version of the ACL from the switch running-config file. Otherwise, the switch appends the new ACEs in the ACL you download to the existing ACL.

   For example, if you planned to use the copy command to replace ACL "List-120", place this command at the beginning of the edited file:

   ​

   ​

   no ip access-list extended List-120

   ​

   An offline ACL file designed to replace an existing ACL

   ​

3. Use copy tftp command-file to download the file as a list of commands to the switch.

​Example

Suppose you want to create an extended ACL for an RACL application to fulfill the following requirements (Assume a subnet mask of 255.255.255.0 and a TFTP server at 10.10.10.1.):

​

• ID: "LIST-20-IN"

• Deny Telnet access to a server at 10.10.10.100 on VLAN 10 from these three addresses on VLAN 20 with ACL logging:

  ​

  • 10.10.20.17

  • 10.10.20.23

  • 10.10.20.40

• Allow any access to the server from all other addresses on VLAN 20:

• Permit internet access to these two address on VLAN 20, but deny access to all other addresses on VLAN 20 (without ACL logging).

  ​

  • 10.10.20.98

  • 10.10.20.21

• Deny all other IPv4 traffic from VLAN 20 to VLAN 10.

• Deny all IPv4 traffic from VLAN 30 (10.10.30.0) to the server at 10.10.10.100 on VLAN 10 (without ACL logging), but allow any other IPv4 traffic from VLAN 30 to VLAN 10.

• Deny all other inbound IPv4 traffic to VLAN 20. (Hint: The Implicit Deny can achieve this objective.)

​

1. Create a .txt file with the content shown in the following figure.

   ​

   A .txt file designed for creating an ACL

   ​

2. After copying the above .txt file to a TFTP server the switch can access, execute the following command:

   ​

   copy tftp command-file 10.10.10.1 LIST-20-IN.txt pc

   In this example, the CLI shows the following output to indicate that the ACL was successfully downloaded to the switch:

   	NOTE: If a transport error occurs, the switch does not execute the command and the ACL is not configured.

   ​

   Using copy tftp command-file to configure an ACL in the switch

   ​

3. In this example, the command to assign the ACL to a VLAN was included in the .txt command file. If this is not done in your applications, the next step is to manually assign the new ACL to the intended VLAN.

   ​

   vlan <vid> ip access-group <identifier> in

4. Use the show run or show access-list config command to inspect the switch configuration to ensure that the ACL was properly downloaded.

   ​

   Verifying the .txt file download to the switch

   ​

5. If the configuration appears satisfactory, save it to the startup-config file:

   ​

   switch(config)# write memory
   

​Syntax

​This action uses a sequence number to specify where to insert a new ACE into an existing sequence of ACLs.

​Syntax

To insert a new ACE between existing ACEs in a list:

For example, inserting a new ACE between the ACEs numbered 10 and 20 requires a sequence number in the range of 11-19 for the new ACE.

​

Inserting an ACE in an existing ACL

​

In the following example, the first two ACEs entered become lines 10 and 20 in the list. The third ACE entered is configured with a sequence number of 15 and is inserted between lines 10 and 20.

​

Inserting an ACE into an existing sequence

​

​This action uses ACL sequence numbers to delete ACEs from an ACL.

​Syntax

​

Deleting an ACE from any ACL

​

This action reconfigures the starting sequence number for ACEs in an ACL, and resets the numeric interval between sequence numbers for ACEs configured in the ACL.

​Syntax

This example resequences the "My-List" ACL at the bottom of figure so that the list begins with line 100 and uses a sequence interval of 100.

​

Viewing and resequencing an ACL

A remark is numbered in the same way as an ACE, and uses the same sequence number as the ACE to which it refers. This operation requires that the remark for a given ACE be entered prior to entering the ACE itself.

​Syntax

​Syntax

To associate a remark with a specific ACE, enter the remark first, and then enter the ACE.

	NOTE: After a numbered ACL has been created (using access-list 1-99 | 100-199), it can be managed as either a named or numbered ACL. For example, in an existing ACL with a numeric identifier of "115", either of the following command sets adds an ACE denying IPv4 traffic from any source to a host at 10.10.10.100: ​ switch(config)# access-list 115 deny ip host 10.10.10.100 switch(config)# ip access-list extended 115 switch(config-ext-nacl)# deny ip any 10.10.10.100

To include a remark for an ACE that is appended to the end of the current ACL, enter the remark first, then enter the related ACE. This results in the remark and the subsequent ACE having the same sequence number. For example, to add remarks using the "Named-ACL" (nacl) context:

​

Appending a remark and its related ACE to the end of an ACL

You can also perform the operation illustrated in Appending a remark and its related ACE to the end of an ACL by using the numbered, access-list

syntax shown at the beginning of this section.

See Operating notes for remarks, for more details.

To insert an ACE with a remark within an ACL by specifying a sequence number, insert the numbered remark first, then, using the same sequence number, insert the ACE. This operation applies only to ACLs accessed using the "Named-ACL" (nacl) context.

​

Inserting remarks

​

If a sequence number is already assigned to an ACE in a list, you cannot insert a remark by assigning it to the same number. (To configure a remark with the same number as a given ACE, the remark must be configured first.) To assign a remark to the same number as an existing ACE:

If you want to remove a remark, but want to retain the ACE, do the following:​

ACL logging enables the switch to generate a message when IP traffic meets the criteria for a match with an ACE that results in an explicit “deny” or “permit” action. You can use ACL logging to help:

The switch sends ACL messages to and optionally to the current console, Telnet, or SSH session. You can use logging <> to configure up to six server destinations.

For more information, see Enabling ACL logging on the switch.

When the switch detects a packet match with an ACE and the ACE includes either the deny or permit action, and the optional log parameter, an ACL log message is sent to the designated debug destination.

The first time a packet matches an ACE with deny or permit and log configured, the message is sent immediately to the destination and the switch starts a wait period of approximately five minutes. (The exact duration of the period depends on how the packets are internally routed.) At the end of the collection period, the switch sends a single-line summary of any additional “deny” or “permit” matches for that ACE (and any other “deny” or “permit” ACEs for which the switch detected a match).

If no further log messages are generated in the wait-period, the switch suspends the timer and resets itself to send a message as soon as a new “deny” or “permit” match occurs. If subsequent packets matching the already logged ACL entries are detected, then a new logged event is generated that summarizes the number of packets that matched each specific entry (with the time period). The data in the message includes the information illustrated in the following figure.

​

Content of a message generated by an ACL-Deny action

​

​Example

Suppose you want to configure the following operation:

This example assumes that IPv4 routing is already configured on the switch.

​

ACL log application

​

​

Commands for applying an ACL with logging to ACL log application

​

​ACL statistics counters provide a means for monitoring ACL performance by using counters to display the current number of matches the switch has detected for each ACE in an ACL assigned to a switch interface. This can help in determining whether a particular traffic type is being filtered by the intended ACE in an assigned list, or if traffic from a particular device or network is being filtered as intended.

	NOTE: This section describes the command for monitoring static ACL performance. To monitor RADIUS-assigned ACL performance, use either of the following commands: ​ show access-list radius <all port-list> show port-access <authenticator mac-based web-based> clients <port-list> detailed See Show RADIUS-assigned ACL activity.

​Syntax

​

IPv6 and IPv4 ACL activity

​

​

ACL performance monitoring

The following figures show a sample of performance monitoring output for an IPv6 ACL assigned as a VACL.

​

IPv6 ACL performance monitoring output

​

IPv4 ACL assigned as a VACL performance monitoring output

For a given ACE in an assigned ACL, the counter increments by 1 each time the switch detects a packet that matches the criteria in that ACE, and maintains a running total of the matches since the last counter reset. For example, in ACL line 10 below, there has been a total of 37 matches on the ACE since the last time the ACL’s counters were reset.

Total ( 37) 10 permit icmp ::/0 fe80::20:2/128 128

	NOTE: This ACL monitoring feature does not include hits on the “implicit deny” that is included at the end of all ACLs.

Using the clear statistics command:

​

IPv6 ACL performance monitoring output after zero

​

Where the same IPv6 ACL is assigned to multiple interfaces, the switch maintains a separate instance of each ACE counter in the ACL. When there is a match with traffic on one of the ACL's assigned interfaces, only the affected ACE counters for that interface are incremented. Other instances of the same ACL applied to other interfaces are not affected.

	NOTE: These examples of counters use small values to help illustrate counter operation. The counters in real-time network applications are generally much more active and show higher values.

For example, suppose that:

​

ACL "V6-01" and command for PACL assignment on port B2

​

​

Application to filter traffic inbound on port B2

​

Using the topology in Application to filter traffic inbound on port B2, a workstation at FE80::20:117 on port B2 attempting to ping and Telnet to the workstation at FE80::20:2 is filtered through the PACL instance of the "V6-01" ACL assigned to port B2, resulting in the following:

​

Ping and telnet from FE80::20:117 to FE80::20:2 filtered by the assignment of "V6-01" as a PACL on port B2

​

​

Resulting ACE hits on ACL "V6-01"

​

	NOTE: IPv4 ACE counters assigned as RACLs operate differently than described above. For more information, see Using IPv4 counters with multiple interface assignments .

Where the same IPv4 ACL is assigned to multiple interfaces as a VLAN ACL (VACL) or port ACL (PACL), the switch maintains a separate instance of ACE counters for each interface assignment. Thus, when there is a match with traffic on one of the ACL's VACL- or PACL -assigned interfaces, only the ACE counter in the affected instance of the ACL is incremented. However, if an ACL has multiple assignments as an RACL, then a match with an ACE in any RACL instance of the ACL increments that same counter on all RACL-assigned instances of that ACL. (The ACE counters for VACL and PACL instances of an ACL are not affected by counter activity in RACL instances of the same ACL.)

For example, suppose that an IPv4 ACL named "Test-1" is configured to block Telnet access to a server at 10.10.20.12 on VLAN 20, and that the Test-1 ACL is assigned to VLANs as follows:

​

ACL "Test-1" and interface assignment commands

​

​

Using the same ACL for VACL and RACL applications

​

In the above case:

Using the network in Access Granted page, a device at 10.10.20.4 on VLAN 20 attempting to ping and Telnet to 10.10.20.12 is filtered through the VACL instance of the "Test-1" ACL on VLAN 20 and results in the following:

​

Ping and telnet from 10.10.20.4 to 10.10.20.2 filtered by the assignment of "Test-1" as a VACL on VLAN 20

​

​

Resulting ACE hits on ACL "Test-1"

​

However, using a device at 10.10.30.11 on VLAN 50 for attempts to ping and Telnet to 10.10.20.12 requires routing, and filters the attempts through the RACL instance of the "Test-1" ACL on VLAN 50.

​

Ping and telnet from 10.10.30.11 to 10.10.20.2 filtered by the assignment of "Test-1" as a RACL on VLAN 30

​

This action has an identical effect on the counters in all RACL instances of the "Test-1" ACL configured and assigned to interfaces on the same switch. In this example, it means that the RACL assignments of "Test-1" on VLANs 50 and 70 are incremented by the above action occurring on VLAN 50.

​

Resulting ACE hits on the VLAN 30 RACL assignment of the "Test-1" ACL

​

​

Resulting ACE hits on the VLAN 70 RACL assignment of the "Test-1" ACL

​

Note that the ACE counters for the VACL assignment of the "Test-1" ACL on VLAN 20 are not affected by ACE hits on the RACL assignments of the same ACL.