Cisco ONS 15454 SONET/SDH ML-Series Multilayer Ethernet Card Software Feature and Configuration Guide, Release 4.0

Configuring Access Control Lists

This chapter describes the access control list (ACL) features built into the ML-Series card. This chapter contains the following major sections:

•Understanding ACLs

•ML-Series ACL Support

•Modifying ACL TCAM Size

•Monitoring and Verifying ACL

Understanding ACLs

ACLs provide network control and security, allowing you to filter packet flow into or out of ML-Series interfaces. ACLs, which are sometimes called filters, allow you to restrict network use by certain users or devices. ACLs are created for each protocol and are applied on the interface for either inbound or outbound traffic. ACLs do not apply to outbound Control Plane traffic. Only one ACL filter can be applied per direction per (sub)interface.

When creating ACLs, you define criteria to apply to each packet processed by the ML-Series card; the ML-Series card decides whether to forward or block the packet based on whether or not the packet matches the criteria in your list. Packets that do not match any criteria in your list are automatically blocked by the implicit "deny all traffic" criteria statement at the end of every ACL.

ML-Series ACL Support

Both control-plane and data-plane ACLs are supported on the ML-Series card.

• Control-plane ACLs: ACLs used to filter control data that is processed by the CPU of the ML-Series card (for example, distribution of routing information, IGMP joins, and so on).

• Data-plane ACLs: ACLs used to filter user data being routed or bridged through the ML Series in hardware (for example, denying access to a host, and so on). These ACLs are applied to an interface in the input or output direction using the ip access-group command.

The following apply when using data-plane ACLs on the ML-Series card:

•ACLs are supported on all interface types, including bridged interfaces.

•Reflexive and dynamic ACLs are not supported on the ML-Series card.

•Access violations accounting is not supported on the ML-Series card.

•ACL logging is supported only for packets going to the CPU, not for switched packets.

•IP Standard ACLs applied to bridged egress interfaces are not supported in the data-plane. Whenbridging, ACLs are only supported on ingress.

IP ACLs

The following ACL styles for IP are supported:

•Standard IP ACLs: These use source addresses for matching operations.

•Extended IP ACLs (control plane only): These use source and destination addresses for matching operations and optional protocol type and port numbers for finer granularity of control.

•Named ACLs: These use source addresses for matching operations.

Note By default, the end of the ACL contains an implicit deny statement for everything if it did not find a match before reaching the end. With standard ACLs, if you omit the mask from an associated IP host address ACL specification, 0.0.0.0 is assumed to be the mask.

After creating an ACL, you must apply it to an interface, as shown in the "Applying the ACL to an Interface" section.

Named IP ACLs

You can identify IP ACLs with a name, but it must be an alphanumeric string. Named IP ACLs allow you to configure more IP ACLs in a router than if you used numbered ACLs. If you identify your ACL with an alphabetic rather than a numeric string, the mode and command syntax are slightly different.

Consider the following before configuring named ACLs:

•A standard ACL and an extended ACL cannot have the same name.

•Numbered ACLs are also available, as described in the "Creating Numbered Standard and Extended IP ACLs" section.

User Guidelines

Keep the following in mind when you configure IP network access control:

•You can program ACL entries into ternary content addressable memory (TCAM).

•You do not have to enter a deny everything statement at the end of your ACL; it is implicit.

•You can enter ACL entries in any order without any performance impact.

•For every eight TCAM entries, the ML-Series card uses one entry for TCAM management purposes.

•Do not set up conditions that result in packets getting lost. This situation can happen when a device or interface is configured to advertise services on a network that has ACLs that deny these packets.

•IP Standard ACLs applied to bridged egress interfaces are not supported in the data-plane. When bridging, ACLs are only supported on ingress.

Creating IP ACLs

The following sections describe how to create numbered standard, extended, and named standard IP ACLs:

•Creating Numbered Standard and Extended IP ACLs

•Creating Named Standard IP ACLs

•Creating Named Extended IP ACLs (Control Plane Only)

•Applying the ACL to an Interface

Creating Numbered Standard and Extended IP ACLs

Table 15-1 list the global configuration commands used to create numbered standard and extended IP ACLs.

Router(config)# access-list 
access-list-number  
{deny | permit} source [source-wildcard]

Router(config)# access-list 
access-list-number {deny | permit}  
any

Router(config)# access-list 
access-list-number {deny | permit} protocol 
source source-wildcard destination 
destination-wildcard [precedence 
precedence] [tos tos]

Router(config)# access-list 
access-list-number {deny | permit} protocol 
any any

Router(config)# access-list 
access-list-number {deny | permit} protocol 
host source host destination

Creating Named Standard IP ACLs

To create a named standard IP ACL, perform the following procedure, beginning in global configuration mode:

Router(config)# ip access-list standard 
name

Router(config-std-nac1)# deny {source 
[source-wildcard] | any}

permit {source [source-wildcard] | any}

Router(config)# exit

Creating Named Extended IP ACLs (Control Plane Only)

To create a named extended IP ACL, perform the following tasks, beginning in global configuration mode:

Router(config)# ip access-list extended 
name

Router(config-ext-nacl)# {deny | permit} 
protocol source source-wildcard destination 
destination-wildcard [precedence 
precedence] [tos tos]  
 
{deny | permit} protocol any any

 
{deny | permit} protocol host source host 
destination

Applying the ACL to an Interface

After you create an ACL, you can apply it to one or more interfaces. ACLs can be applied on either the inbound or the outbound direction of an interface. When controlling access to an interface, you can use a name or number. If a standard ACL is applied, the ML-Series card compares the source IP address with the ACL. To apply an ACL to one or more interfaces, use the command in Table 15-2.

Note IP Standard ACLs applied to bridged egress interfaces are not supported in the data-plane. When bridging, ACLs are only supported on ingress.

ip access-group {access-list-number | name} {in | out}

Modifying ACL TCAM Size

You can change the TCAM size by entering the sdm access-list command. For more information on ACL TCAM sizes, see the "Configuring Access Control List Size in TCAM" section on page 14-3.

Note To increase the ACL TCAM size, you must decrease another region's TCAM size, such as IP, IP multicast, or L2 switching.

Caution You will need to increase the TCAM size if you see the following error message:
Warning:Programming TCAM entries failed
Please remove last ACL command to re-activate ACL operation.
!<ACL number or name> <IP or IPX> <INPUT_ACL or OUTPUT_ACL> from TCAM group for !<interface>
Please see the documentation to see if TCAM space can be
increased on this platform to alleviate the problem.

Monitoring and Verifying ACL

Use the following command to monitor and verify ACLs:

Router# show ip access-lists 1

Standard IP access list 1

    permit 192.168.1.1

    permit 192.168.1.2