-
null
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Note ● For complete information about configuring Cisco IOS ACLs, see this publication:
http://www.cisco.com/en/US/docs/ios-xml/ios/sec_data_acl/configuration/15-sy/sec-data-acl-15-sy-book.html
http://www.cisco.com/en/US/products/ps11846/prod_command_reference_list.html
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum
With the ip unreachables command enabled (which is the default), the switch drops most of the denied packets in hardware and sends only a small number of packets to the RP to be dropped in software, which generates ICMP-unreachable messages.
The ip unreachables command does not impact the hardware behavior for ACL drop packets and the leaking of ACL deny packets is enabled by default. You can enter the no ip unreachables interface configuration command to disable ICMP unreachable messages.
With named ACLs, the ACL merge is triggered only when the user exits the named-acl configuration mode. However, with numbered ACLs, the ACL merge is triggered for every ACE definition and results in a number of intermediate merges during ACL configuration.
You can specify these types of operations:
We recommend that you do not specify more than ten different operations on the same ACL. If you exceed this number, each new operation might cause the affected ACE to be translated into more than one ACE.
Use the following two guidelines to determine Layer 4 operation usage:
Note There is no limit to the use of “eq” operators as the “eq” operator does not use a logical operator unit (LOU) or a Layer 4 operation bit. See the “Determining Logical Operation Unit Usage” section for a description of LOUs.
Logical operation units (LOUs) are registers that store operator-operand couples. All ACLs use LOUs. There can be up to 104 LOUs and each LOU can store two different operator-operand couples, making the total number of LOU registers to be 208. LOU usage per Layer 4 operation is as follows:
For example, this ACL would use a single LOU to store two different operator-operand couples:
A more detailed example follows:
ACLs can be processed in hardware by the Policy Feature Card (PFC), any Distributed Forwarding Cards (DFCs), or in software by the route processor (RP):
Note Idle timeout is not configurable. Cisco IOS Release 15.4SY does not support the access-enable host timeout command.
– Internetwork Packet Exchange (IPX) access lists
– Protocol type-code access list
Note IP packets with a header length of less than five will not be access controlled.
Note See the “Restrictions for eFSU” section for information about some release-specific restrictions.
PBACLs provide the capability to apply access control policies across object groups. An object group is a group of users or servers.
You define an object group as a group of IP addresses or as a group of protocol ports. You then create access control entries (ACEs) that apply a policy (such as permit or deny) to the object group. For example, a policy-based ACE can permit a group of users to access a group of servers.
An ACE defined using a group name is equivalent to multiple ACEs (one applied to each entry in the object group). The system expands the PBACL ACE into multiple Cisco IOS ACEs (one ACE for each entry in the group) and populates the ACEs in the TCAM. Therefore, the PBACL feature reduces the number of entries you need to configure but does not reduce TCAM usage.
If you make changes in group membership, or change the contents of an ACE that uses an access group, the system updates the ACEs in the TCAM. The following types of changes trigger the update:
You configure a PBACL using extended Cisco IOS ACL configuration commands. As with regular ACEs, you can associate the same access policy with one or more interfaces.
When you configure an ACE, you can use an object group to define the source, the destination, or both.
To create or modify a PBACL IP address object group, perform this task:
The following example creates an object group with three hosts and a network address:
To create or modify a PBACL protocol port object group, perform this task:
The following example creates a port object group that matches protocol port 100 and any port greater than 200, except 300:
To configure an ACL to use a PBACL object group, perform this task:
The following example creates an access list that permits packets from the users in myAG if the protocol ports match the ports specified in myPG:
To configure a PBACL on an interface, use the ip access-group command. The command syntax and usage is the same as for Cisco IOS ACLs. For additional information, see the “Restrictions for Cisco IOS ACLs” section.
The following example shows how to associate access list my-pbacl-policy with VLAN 100:
IPv6 OG ACLs provide the capability to apply access control policies across object groups. An object group is a group of users or servers.
You define an object group as a group of IPv6 addresses or as a group of protocol ports. You then create access control entries (ACEs) that apply a policy (such as permit or deny) to the object group. For example, a policy-based ACE can permit a group of users to access a group of servers.
An ACE defined using a group name is equivalent to multiple ACEs (one applied to each entry in the object group). The system expands the IPv6 OG ACL ACE into multiple Cisco IOS ACEs (one ACE for each entry in the group) and populates the ACEs in the TCAM. Therefore, the IPv6 OG ACL feature reduces the number of entries you need to configure but does not reduce TCAM usage.
If you make changes in group membership, or change the contents of an ACE that uses an access group, the system updates the ACEs in the TCAM. The following types of changes trigger the update:
You configure a IPv6 OG ACL using extended Cisco IOS ACL configuration commands. As with regular ACEs, you can associate the same access policy with one or more interfaces.
When you configure an ACE, you can use an object group to define the source, the destination, or both.
To create or modify a IPv6 OG ACL IPv6 address object group, perform this task:
The following example creates an object group with hosts and a network address:
To create or modify a IPv6 OG ACL protocol object group, perform this task:
The following example creates a protocol object group:
To configure an ACL to use a IPv6 OG ACL object group, perform this task:
The following example creates an access list that permits packets from the users in myAG if the protocol ports match the ports specified in myPG:
To configure a IPv6 OG ACL on an interface, use the ipv6 traffic-filter access-list-name {in | out} command in interface mode. The command syntax and usage is the same as for Cisco IOS ACLs. For additional information, see the “Restrictions for Cisco IOS ACLs” section.
Note You can use MAC ACLs with VLAN ACLs (VACLs). For more information, see Chapter74, “VLAN ACLs (VACLs)”
Protocol-independent MAC ACL filtering applies MAC ACLs to all ingress traffic types (for example, IPv4 traffic, IPv6 traffic, and MPLS traffic, in addition to MAC-layer traffic).
You can configure these interface types for protocol-independent MAC ACL filtering:
Ingress traffic permitted or denied by a MAC ACL on an interface configured for protocol-independent MAC ACL filtering is processed by egress interfaces as MAC-layer traffic. You cannot apply egress IP ACLs to traffic that was permitted or denied by a MAC ACL on an interface configured for protocol-independent MAC ACL filtering.
To configure protocol-independent MAC ACL filtering, perform this task:
This example shows how to configure VLAN interface 4018 for protocol-independent MAC ACL filtering and how to verify the configuration:
This example shows how to configure Gigabit Ethernet interface 6/1 for protocol-independent MAC ACL filtering and how to verify the configuration:
This example shows how to configure Gigabit Ethernet interface 3/24, subinterface 4000, for protocol-independent MAC ACL filtering and how to verify the configuration:
You can globally enable or disable VLAN-based QoS filtering in MAC ACLs. VLAN-based QoS filtering in MAC ACLs is disabled by default.
To enable VLAN-based QoS filtering in MAC ACLs, perform this task:
To disable VLAN-based QoS filtering in MAC ACLs, perform this task:
|
|
---|---|
You can configure named ACLs that filter IP, IPX, DECnet, AppleTalk, VINES, or XNS traffic based on MAC addresses.
You can configure MAC ACLs that do VLAN-based filtering or CoS-based filtering or both.
You can globally enable or disable VLAN-based QoS filtering in MAC ACLs (disabled by default).
To configure a MAC ACL, perform this task:
– 0x0600—xns-idp—Xerox XNS IDP
– 0x0BAD—vines-ip—Banyan VINES IP
– 0x0baf—vines-echo—Banyan VINES Echo
– 0x6000—etype-6000—DEC unassigned, experimental
– 0x6001—mop-dump—DEC Maintenance Operation Protocol (MOP) Dump/Load Assistance
– 0x6002—mop-console—DEC MOP Remote Console
– 0x6003—decnet-iv—DEC DECnet Phase IV Route
– 0x6004—lat—DEC Local Area Transport (LAT)
– 0x6005—diagnostic—DEC DECnet Diagnostics
– 0x6007—lavc-sca—DEC Local-Area VAX Cluster (LAVC), SCA
– 0x0800—ip—Malformed, invalid, or deliberately corrupt IP frames
– 0x8038—dec-spanning—DEC LANBridge Management
– 0x8040—netbios—DEC PATHWORKS DECnet NETBIOS Emulation
– 0x8041—msdos—DEC Local Area System Transport
– 0x8042—etype-8042—DEC unassigned
– 0x809B—appletalk—Kinetics EtherTalk (AppleTalk over Ethernet)
– 0x80F3—aarp—Kinetics AppleTalk Address Resolution Protocol (AARP)
This example shows how to create a MAC-Layer ACL named mac_layer that denies dec-phase-iv traffic with source address 0000.4700.0001 and destination address 0000.4700.0009, but permits all other traffic:
This section describes how to configure ARP ACLs. You can configure named ACLs that filter ARP traffic (EtherType 0x0806). To configure an ARP ACL, perform this task:
|
|
|
---|---|---|
Router(config-arp-nacl)# { permit | deny } { ip { any | host sender_ip | sender_ip sender_ip_wildcardmask } mac any |
This example shows how to create an ARP ACL named arp_filtering that only permits ARP traffic from IP address 1.1.1.1:
– ACLs used to filter traffic for other features (for example, QoS)
– ACLs for unicast reverse path forwarding (uRPF) check exceptions
– Exception packets (for example, TTL failure and MTU failure)
– Packets addressed at Layer 3 to the router
– Packets sent to the RP to generate ICMP unreachable messages
– Packets being processed by features not accelerated in hardware
OAL provides hardware support for ACL logging. Unless you configure OAL, packets that require logging are processed completely in software on the RP. OAL permits or drops packets in hardware on the PFC or DFC and uses an optimized routine to send information to the RP to generate the logging messages.
To configure global OAL parameters, perform this task:
|
|
---|---|
Router(config)# logging ip access-list cache {{ entries number_of_entries } | { interval seconds } | { rate-limit number_of_packets } | { threshold number_of_packets }} |
– Sets the maximum number of entries cached.
– Range: 0–1,048,576 (entered without commas).
– Sets the maximum time interval before an entry is sent to be logged. Also if the entry is inactive for this duration it is removed from the cache.
– Range: 5–86,400 (1440 minutes or 24 hours, entered without commas).
– Default: 300 seconds (5 minutes).
– Sets the number of packets logged per second in software.
– Range: 10–1,000,000 (entered without commas).
– Default: 0 (rate limiting is off and all packets are logged).
– Sets the number of packet matches before an entry is logged.
– Range: 1–1,000,000 (entered without commas).
– Default: 0 (logging is not triggered by the number of packet matches).
To configure OAL on an interface, perform this task:
|
|
|
---|---|---|
To display OAL information, perform this task:
|
|
---|---|
|
To clear cached OAL entries, perform this task:
|
|
---|---|
|
In other releases, when a new feature is applied on an interface configured along with other features, and if the new feature does not fit in the TCAM, then existing features are also affected and removed from the TCAM. To incrementally update the feature and see whether the feature fits into the TCAM without installing it, the switch provides a Dry Run support, where applications can send regular requests to test whether the request can be programmed successfully or not. The switch receives the dry run request and calculates the total TCAM resources required for the request and compares those resources against the available free resources. If the request fits in successfully, then the switch returns a success, else the switch returns a failure. The Dry Run support helps applications make intelligent decisions.
To configure the Dry Run support, perform this task:
|
|
|
---|---|---|
Router(dry-run-config)# {default | exit | ip | no | validate} |
||
Router(dry-run-config)# ip access-list {extended | standard} acl_name |
The following example configures the dry run support for a session with an existing ACL RACL10K:
Using the hardware ACL statistics, the hardware counters for a given ACL are gathered, aggregated, and displayed in the IOS access-list output.
The ACE hit count is retrieved from the hardware and can be viewed using the following commands:
show ip access-list and show ipv6 access-list
Hardware statistics is disabled by default. To enable or disable hardware statistics, enter the command for hardware statistics.
The following example enables hardware statistics for ACL racl1:
The following example displays the hardware statistics for ACL racl1:
The hardware statistics for each ACE is seen after the acl hw hit count string and indicates the number of packets switched in hardware.
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
Participate in the Technical Documentation Ideas forum