SYSTEM ADMINISTRATOR GUIDE     35/1543-CRA 119 1170/1-V1 Uen B    

Configuring ACLs

© Copyright Ericsson AB 2009. All rights reserved.

Disclaimer

No part of this document may be reproduced in any form without the written permission of the copyright owner. The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

SmartEdge is a registered trademark of Telefonaktiebolaget L M Ericsson.

Contents

1Overview
1.1IP ACLs
1.2Policy ACLs

2

Configuration and Operations Tasks
2.1Configuration Guidelines
2.2Configure an IP ACL
2.3Apply an IP ACL
2.4Enable ACL Counters or Logging for a Subscriber
2.5Modify IP ACL Conditions in Real Time
2.6Configure a Policy ACL
2.7Apply a Policy ACL
2.8Modify Policy ACL Conditions in Real Time
2.9Operations Tasks

3

Configuration Examples
3.1Configure an ACL Statement
3.2Add an ACL Statement
3.3Resequence ACL Statements
3.4Configure an Absolute Time Condition Statement
3.5Configure a Periodic Time Condition Statement
3.6Configure an IP ACL
3.7Configure a Policy ACL Associated with a Forward Policy
3.8Configure a Policy ACL Associated with a NAT Policy
3.9Configure a Policy ACL Associated with a QoS Policing Policy


1   Overview

This document provides an overview of the access control lists (ACLs) features supported by the SmartEdge® router and describes the tasks used to configure, monitor, and administer ACLs. This document also provides configuration examples of ACLs.

ACLs on the SmartEdge router are described in the following subsections:

Note:  
In the following descriptions, the term, controller card, applies to the Cross-Connect Route Processor (XCRP) or the XCRP Version 3 (XCRP3) Controller card, unless otherwise noted.

1.1   IP ACLs

IP ACLs are lists of packet filters used to control the type of service that packets should receive. All IP ACLs are defined within a context. The following sections describe IP ACLs:

1.1.1   IP ACL Applications

Using an IP ACL, you can filter traffic on traffic card circuits, the Ethernet management port, subscriber circuits, and administrative traffic.

1.1.1.1   Traffic Card Circuits

To filter packets in either the inbound or outbound direction on traffic card circuits, you apply an IP ACL to the interface to which the circuits are bound.

1.1.1.2   Ethernet Management Port

To filter packets in either the inbound or outbound direction on the Ethernet management port on the active controller card, you apply an IP ACL to the interface to which the management port is bound. Both inbound and outbound filters are supported.

1.1.1.3   Subscriber Circuits

To filter packets in either the inbound or outbound direction for a subscriber circuit, you apply an IP ACL to the subscriber record, a named subscriber profile, or the default subscriber profile. Both inbound and outbound filters are supported.

1.1.1.4   Administrative

To filter inbound packets that are delivered to the kernel, you apply an IP ACL to a context. These ACLs are independent of the interface and circuit on which they were received.

Note:  
To ensure that all inbound packets are filtered before being delivered to the kernel, you must apply an IP ACL to each context that you have configured.

1.1.2   IP ACL Statements

In IP ACL each statement (referred to as a rule) defines the action, either permit or deny, to be taken for a packet if the packet satisfies the rule. A permit statement causes any packet matching the criteria to be accepted. A deny statement causes any packet matching the criteria to be dropped. A packet that does not match the criteria of the first statement is subjected to the criteria of the second statement, and so on, until the end of the IP ACL is reached; at which point, the packet is dropped due to an implicit deny any any statement at the end of every IP ACL.

You can use the optional seq seq-num construct with any permit or deny command to establish a sequence number for the statement you are creating. If you do not use the seq seq-num construct, the system automatically assigns sequence numbers to the statements that you enter, in increments of 10.

The first statement that you enter is assigned the sequence number of 10, the second is assigned the number 20, and so on. This allows room to assign intermediate sequence numbers to statements that you might want to add later. The assigned sequence numbers for the various statements are displayed in the output of the show configuration acl and show ip access-list commands.

If manually assigned sequence numbers leave no room for insertion of additional entries in the IP ACL, you can use the resequence ip access-list command (in context configuration mode) to reassign the sequence numbers so that they are in increments of 10. The no seq seq-num construct removes an individual statement from the IP ACL.

1.1.3   IP ACL Packet Filtering

Based on the rules specified in the ACLs associated with the packet, the SmartEdge router decides whether the packet is forwarded or dropped. Statement criteria include all Internet protocols and can be specified by the protocol numbers established in RFC 1700, Assigned Numbers. A subset of these options can also be specified by keyword.

All packets that are permitted or dropped as a result of an IP ACL can be counted and logged (denied packets only) if you enable the count and log functions when you apply an IP ACL. By default, the counting and logging of packets is disabled because these functions have an impact on system performance. We recommend that you only enable logging or counting when required for diagnostic purposes.

The SmartEdge router uses IP ACLs to filter packets in the following order:

  1. ACLs applied to interfaces for inbound traffic on traffic card circuits and the Ethernet management port.
  2. ACLs applied to subscriber records and profiles for inbound traffic on subscriber circuits.
  3. ACLs applied to contexts for administrators (inbound only).
  4. ACLs applied to outbound traffic on traffic card circuits and the Ethernet management port.
  5. ACLs applied to subscriber records and profiles for outbound traffic on subscriber circuits.

1.1.4   Dynamic IP Filter ACL

Dynamic IP filter ACLs allow IP ACL packet filtering to be downloaded from a Remote Authentication Dial-In User Service (RADIUS) server. A dynamic IP filter ACL consists of a set of rules, each of which is contained in an RFC vendor-specific attribute (VSA) 242 instance.

For more information about VSA 242, see the Other Supported VSAssection in RADIUS Attributes.

1.2   Policy ACLs

A policy ACL is a list of packet filters (rules), each of which defines a class of packets. A policy ACL, unlike an IP ACL, does not define the action for each rule; instead, the action for each class is determined by the policy to which the policy ACL is applied. All policy ACLs are defined within a context.

1.2.1   Policy ACL Applications

You can apply a policy ACL to class-based forwarding, Network Address Translation (NAT), or quality of service (QoS) policies to filter packets. When applied to a class-based policy, a policy ACL allows different actions to be applied to different classes of packets.

For information about forward policies, see Configuring Forward Policies. For information about NAT policies, see Configuring NAT Policies. For information about QoS policing and metering policies, see Configuring Rate-Limiting and Class-Limiting.

1.2.2   Dynamic Policy ACLs

Dynamic policy ACLs allow a class-based policy to be governed by a policy ACL that is downloaded from a RADIUS server. A dynamic policy ACL consists of a set of classification rules, each of which is contained in a vendor-specific attribute (VSA) 164 instance. All rules in all dynamic policy ACLs are downloaded in a single RADIUS message. You do not apply a dynamic policy ACL to a class-based policy; instead, the SmartEdge OS applies the dynamic policy ACL from the VSA 164 instance. Class-based policies configured with dynamic ACLs are referred to as RADIUS-guided policies. Traditional policy ACLs and class-based policies are referred to as static policy ACLs and static policies, respectively.

1.2.3   Policy ACL Statements

A policy ACL uses permit statements to define how packets are assigned to classes. A packet that does not match the criteria of the first statement is subjected to the criteria of the second statement, and so on, until the end of the policy ACL is reached; at which point, the packet is assigned to the default class.

You can use the optional seq seq-num construct with any permit statement to establish a sequence number for the statement. If you do not use the seq seq-num construct, the system automatically assigns sequence numbers to the statements that you enter, in increments of 10. The first statement you enter is assigned the sequence number of 10, the second is assigned the number 20, and so on. This allows room to assign intermediate sequence numbers to statements that you might want to add later. The assigned sequence numbers for the various statements are displayed in the output of the show configuration acl, show configuration policy, and show policy access-list commands.

If manually assigned sequence numbers leave no room for insertion of additional entries in the policy ACL, you can use the resequence policy access-list command (in context configuration mode) to reassign the sequence numbers so they are in increments of 10. The no seq seq-num construct removes an individual statement from the policy ACL.

1.2.4   Policy ACL Packet Filtering

Statement criteria for filtering includes all Internet protocols, which can be specified by the protocol numbers established in RFC 1700, Assigned Numbers. A subset of these options can also be specified by keyword. Based on classification, a class-based policy defines the type of action to be performed on the packets in a particular class. All packets that match the criteria can be counted by the statement if you enable the count when you apply a policy ACL. By default, the counting of packets is disabled because this function has an impact on system performance. We recommend that you enable counting only when required for diagnostic purposes.

2   Configuration and Operations Tasks

Note:  
In this section, the command syntax in the task tables displays only the root command; for the complete command syntax, see Command List.

To configure ACLs, perform the tasks described in the following sections:

2.1   Configuration Guidelines

Guidelines for configuring IP and policy ACLs are described in the following sections:

2.1.1   Static IP and Policy ACL Guidelines

The following guidelines apply to the configuration of static IP and policy ACLs:

2.1.2   IP ACL Guidelines

The following filtering rules apply to IP ACLs:

2.1.3   Policy ACL Guidelines

The following rules apply to static and dynamic policy ACLs:

2.1.4   Guidelines for RADIUS-Guided Policies

Configuration guidelines for RADIUS-guided policies include:

2.1.5   VSA 164 Guidelines for Dynamic Policy ACLs

The following guidelines govern the use of vendor VSAs provided by Ericsson AB for dynamic policy ACLs:

Note:  
For more information about vendor VSAs provided by Ericsson AB, see theRedback VSAssection in RADIUS Attributes.

2.2   Configure an IP ACL

To configure an IP ACL, perform the tasks described in Table 1; enter all commands in access control list configuration mode, unless otherwise noted.

Table 1    Configure an IP ACL

Step

Task

Root Command

Notes

1.

Create or select an ACL and enter access control list configuration mode.

ip access-list

Enter this command in context configuration mode.

2.

Optional. Associate a description with an IP ACL.

description (ACL)

 

3.

Optional. Create ACL statements using either or both of the following tasks:

   

4.

Create an ACL statement using permit conditions.

permit

There is an implicit deny any any statement at the end of any permit statement.

5.

Create an ACL statement using deny conditions.

deny (ACL)

 

6.

Optional. Create an ACL condition using a unique ID and access ACL condition configuration mode.

condition

Enter the following commands in ACL condition configuration mode.

7.

Optional. Configure absolute time condition statements.

absolute

An absolute time ACL statement redefines an ACL rule’s action for only one specific time interval.

8.

Optional. Configure periodic time condition statements.

periodic

A periodic time ACL statement redefines the ACL rule action for a recurring time interval.

9.

Optional. Resequence statements in an IP ACL.

resequence ip access-list

Enter this command in context configuration mode.

2.3   Apply an IP ACL

To apply an IP ACL to packets associated with a context, an interface, or a subscriber record, named profile, or default profile, perform the appropriate task described in Table 2.

Table 2    Apply an IP ACL

Task

Root Command

Notes

Apply an IP ACL to an interface or to a subscriber record, named profile, or default profile.

ip access-group (interfaces and subs)

Enter this command in either interface or subscriber configuration mode.

Apply an IP ACL to a context.

admin-access-group

Enter this command in context configuration mode.

2.4   Enable ACL Counters or Logging for a Subscriber

To enable ACL counters or logging for a subscriber through the subscriber record, the default subscriber profile, or a named subscriber profile, perform the task described in Table 3.

Table 3    Enable ACL Counters or Logging for a Subscriber

Task

Root Command

Notes

Enable ACL counters or logging for a subscriber record, the default subscriber profile, or a named subscriber profile.

access-list

Enter this command in subscriber configuration mode.

2.5   Modify IP ACL Conditions in Real Time

To modify the action for an IP ACL condition, in real time, without requiring the reconfiguration of the ACL condition statements, perform the task described in Table 4.

Table 4    Modify IP ACL Condition Actions in Real Time

Task

Root Command

Notes

Modify the action for a condition referenced by an IP ACL.

modify ip access-list

Enter this command in exec mode.

2.6   Configure a Policy ACL

To configure a static policy ACL, perform the tasks described in Table 5; enter all commands in access control list configuration mode, unless otherwise noted.

Table 5    Configure a Policy ACL

Step

Task

Root Command

Notes

1.

Create or select a policy ACL and enter access control list configuration mode.

policy access-list

Enter this command in context configuration mode.

2.

Optional. Associate a description with a policy ACL.

description (ACL)

 

3.

Optional. Create policy ACL statements to allow packets that meet the specified criteria.

permit

Enter this command multiple times to specify multiple classes.

4.

Optional. Create a policy ACL condition using a unique ID and access ACL condition configuration mode.

condition

Enter the following commands in ACL condition configuration mode. You can create up to seven conditions in a policy ACL.

5.

Optional. Configure absolute time condition statements.

absolute

An absolute time ACL condition statement applies an ACL rule for only one specific time interval.

6.

Optional. Configure periodic time condition statements.

periodic

A periodic time ACL statement applies an ACL rule for a recurring time interval.

 

Optional. Resequence statements in a policy ACL.

resequence policy access-list

Enter this command in context configuration mode.

2.7   Apply a Policy ACL

To apply a policy ACL to packets associated with a forward policy, a NAT policy, or QoS metering or policing policy, and complete the configuration of the policy, perform the tasks described in Configuring Foward Policies, Configuring NAT Policies, and Configuring Rate-Limiting and Class-Limiting respectively.

2.8   Modify Policy ACL Conditions in Real Time

To modify the class name for a policy ACL condition, in real time, without requiring the reconfiguration of the ACL condition statements, perform the task described in Table 6.

Table 6    Modify Policy ACL Condition Actions in Real Time

Task

Root Command

Notes

Modify the action for a class name referenced by a policy ACL.

modify policy access-list

Enter this command in exec mode.

2.9   Operations Tasks

To monitor, troubleshoot, and administer IP and policy ACLs, perform the tasks described in Table 7. Enter the clear and debug commands in exec mode; enter the show commands in any mode.

Table 7    ACL Operations Tasks

Task

Root Command

Clear counters for administrative, IP, or policy ACLs.

clear access-group

Enable the generation of debug messages for IP classifier processes.

debug cls

Enable the generation of debug messages for IP ACL events.

debug ip access-list

Enable the generation of debug messages for policy ACLs.

debug policy access-list

Display information about all ACLs and the entities to which the ACLs are applied.

show access-group

Display the IP ACL configuration.

show configuration acl

Display the policy ACL configuration.

show configuration policy (ACL)

Display the status of configured IP ACLs.

show ip access-list

Display the status of configured policy ACLs.

show policy access-list

3   Configuration Examples

This section provides examples to configure, add and resequence ACL statements, configure absolute and periodic time condition statements, configure an IP ACL, and configure a policy ACL with a forward policy, NAT policy or QoS policing policy.

3.1   Configure an ACL Statement

The following example configures a policy ACL to prioritize web and voice-over-IP (VOIP) traffic:

[local]Redback(config-ctx)#policy access-list QoSACL-1

[local]Redback(config-access-list)#permit tcp any any eq 80 class Web

[local]Redback(config-access-list)#permit udp any any eq 1000 class VOIP

[local]Redback(config-access-list)#permit any any class default

The following example uses a policy ACL to define classes of traffic to be mirrored:

[local]Redback(config-ctx)#policy access-list PBR_ACL

[local]Redback(config-access-list)#seq 10 permit tcp any eq www any class WEB

[local]Redback(config-access-list)#seq 20 permit tcp any any eq www class WEB

[local]Redback(config-access-list)#seq 30 permit udp any class UDP

[local]Redback(config-access-list)#seq 40 permit ip any class IP

The following example specifies that all IP traffic to destination host 10.25.1.1 is to be denied, and all other traffic on subnet 10.25.1/24 is to be permitted:

[local]Redback(config-ctx)#ip access-list protect201

[local]Redback(config-access-list)#deny ip any host 10.25.1.1

[local]Redback(config-access-list)#permit ip any 10.25.1.0 0.0.0.255

3.2   Add an ACL Statement

The following example shows how to use the seq keyword to modify the existing tc1 ACL, adding a statement between the statements with sequence numbers 20 and 30:

[local]Redback#configure

[local]Redback(config)#context local

[local]Redback(config-ctx)#ip access-list tc1

[local]Redback(config-access-list)#seq 25 deny tcp 10.10.10.4 0.0.0.0 any eq 80

The output of the show configuration acl command now includes the new statement, with sequence number 25:

! 

  ip access-list tc1 

    description This is a sample access control list

    seq 10 deny ip host 10.10.10.2 host 10.10.20.2 

    seq 20 deny tcp host 10.10.10.3 any eq www 

    seq 25 deny tcp host 10.10.10.4 any eq www 

    seq 30 deny udp host 10.10.10.3 any 

    seq 40 deny ip host 10.10.10.4 any 

    seq 50 deny ip host 10.10.10.5 any 

    seq 60 permit ip any any 

3.3   Resequence ACL Statements

The following example displays the current sequencing of an IP ACL:

[local]Redback#show configuration acl



Building configuration...

! 

  ip access-list tc1 

    description This is a sample access control list

    seq 10 deny ip host 10.10.10.2 host 10.10.20.2 

    seq 20 deny tcp host 10.10.10.5 any eq telnet 

    seq 25 deny tcp host 10.10.10.4 any eq www 

    seq 30 deny udp host 10.10.10.3 any 

    seq 50 deny ip host 10.10.10.5 any

    seq 60 permit ip any any 

The following example resequences the statements in the IP ACL to increments of 10 and displays the new sequence of statements:

[local]Redback(config)#context local

[local]Redback(config-ctx)#resequence ip access-list tc1



[local]Redback#show configuration



Building configuration...

Current configuration:

context local

  ip access-list tc1 

    description This is a sample access control list

    seq 10 deny ip host 10.10.10.2 host 10.10.20.2 

    seq 20 deny tcp host 10.10.10.5 any eq telnet 

    seq 30 deny tcp host 10.10.10.4 any eq www 

    seq 40 deny udp host 10.10.10.3 any 

    seq 50 deny ip host 10.10.10.5 any 

    seq 60 permit ip any any 

3.4   Configure an Absolute Time Condition Statement

The following example creates an absolute time ACL condition statement for ACL condition 342, which is defined in the IP ACL, ip-acl-1. The absolute time ACL condition applies a deny action to all IP ACL statements that reference the ACL condition for the time interval beginning on December 15, 2003 at 9:00 p.m. (21:00) and ending on the same day at 11:00 p.m. (23:00):

[local]Redback(config-ctx)#ip access-list ip-acl-1

[local]Redback(config-access-list)#condition 342 time-range

[local]Redback(config-acl-condition)#absolute start 2003:12:15:21:00 end 2003:12:15:23:00 deny

3.5   Configure a Periodic Time Condition Statement

The following example creates an periodic ACL condition statement for the ACL condition 101, which is referenced by the IP ACL, ip-acl-2, such that all packets traveling between 9 a.m. and 5 p.m. (9:00 to 17:00 in 24-hour format) on weekdays are permitted:

[local]Redback(config-ctx)#ip access-list ip-acl-2

[local]Redback(config-access-list)#condition 101 time-range

[local]Redback(config-acl-condition)#periodic weekdays 9:00 to 17:00 permit

The following example creates a periodic ACL condition statement for the ACL condition 342, which is referenced by the policy ACL policy_acl_1, such that all packets traveling every weekday (Monday to Friday) from 9:00 p.m. to 11:00 p.m. (9:00 to 23:00 in 24-hour format) are permitted:

[local]Redback(config-ctx)#policy access-list policy_acl_1

[local]Redback(config-access-list)#condition 342 time-range

[local]Redback(config-acl-condition)#periodic weekdays 21:00 to 23:00 permit

3.6   Configure an IP ACL

The following example creates an IP ACL, tc1, and applies the list to an interface, oc1:

[local]Redback(config-ctx)#ip access-list tc1

[local]Redback(config-access-list)#description This is a sample access control list

[local]Redback(config-access-list)#deny ip 10.10.10.2 0.0.0.0 10.10.20.2 0.0.0.0 

[local]Redback(config-access-list)#deny tcp 10.10.10.3 0.0.0.0 any eq 80 

[local]Redback(config-access-list)#deny udp 10.10.10.3 0.0.0.0 any 

[local]Redback(config-access-list)#deny ip 10.10.10.4 0.0.0.0 any 

[local]Redback(config-access-list)#deny ip 10.10.10.5 0.0.0.0 any 

[local]Redback(config-access-list)#permit ip any any 

[local]Redback(config-access-list)#exit

[local]Redback(config-ctx)#interface oc1 

[local]Redback(config-if)#ip access-group tc1 in log

3.7   Configure a Policy ACL Associated with a Forward Policy

The policy ACL and forward policy configuration is as follows:

[local]Redback(config-ctx)#policy access-list PBR_Drop_ACL

[local]Redback(config-access-list)#seq 10 permit icmp host 51.1.1.2 class ICMP

[local]Redback(config-access-list)#seq 20 permit pim any class PIM

[local]Redback(config-access-list)#exit

[local]Redback(config-access-list)#exit

[local]Redback(config)#forward policy DropPolicy

[local]Redback(config-policy-frwd)#access-group PBR_Drop_ACL local

[local]Redback(config-policy-group)#class ICMP

[local]Redback(config-policy-group-class)#drop

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#class PIM

[local]Redback(config-policy-group-class)#drop

The following configuration applies the forward policy to the incoming_traffic interface:

[local]Redback(config)#port pos 9/1

[local]Redback(config-port)#no shutdown

[local]Redback(config-port)#bind interface incoming_traffic local

[local]Redback(config-port)#forward policy DropPolicy in

[local]Redback(config-port)#exit

3.8   Configure a Policy ACL Associated with a NAT Policy

The following example creates a policy ACL and applies it to a NAT policy with dynamic translations in which all packets except those classified as CLASS3 are ignored (that is, the NAT policy is not applied to them). All source IP addresses for incoming packets classified as CLASS3 are translated using IP addresses from the pool_dyn pool:

!Create the NAT pool

[local]Redback(config-ctx)#ip nat pool pool_dyn

[local]Redback(config-nat-pool)#address 11.11.11.0/24

[local]Redback(config-nat-pool)#exit

!Create the policy ACL

[local]Redback(config-ctx)#policy access-list NAT-ACL

[local]Redback(config-access-list)#seq 10 permit ip 10.10.10.0 0.0.0.255 class CLASS3

[local]Redback(config-access-list)#exit

!Create the NAT policy and apply the policy ACL

[local]Redback(config-ctx)#nat policy pol1

[local]Redback(config-nat-pool)#ignore

[local]Redback(config-nat-pool)#access-group NAT-ACL

[local]Redback(config-policy-group)#class CLASS3

[local]Redback(config-policy-group-class)#pool pool_dyn local

3.9   Configure a Policy ACL Associated with a QoS Policing Policy

The following example applies the conditions set by the ACL qos created for any circuit to which the QoS policing policy, class, is attached. Packets are classified into three classes: web, voice over IP (VOIP), and default:

[local]Redback(config-ctx)#policy access-list qos

[local]Redback(config-access-list)#permit tcp any any eq 80 class Web

[local]Redback(config-access-list)#permit udp any any eq 1000 class VOIP

[local]Redback(config-access-list)#permit any any class default

[local]Redback(config-access-list)#exit

[local]Redback(config-ctx)#exit

[local]Redback(config)#qos policy class policing

[local]Redback(config-policy-policing)#access-group qos local

[local]Redback(config-policy-group)#class web

[local]Redback(config-policy-group-class)#rate 5000 burst 1000

[local]Redback(config-policy-class-rate)#conform mark dscp AF11

[local]Redback(config-policy-class-rate)#exit

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#class voip

[local]Redback(config-policy-group-class)#mark dscp ef

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#class default

[local]Redback(config-policy-group-class)#mark dscp df

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#exit

[local]Redback(config-policy-policing)#exit

[local]Redback(config)#port ethernet 3/1

[local]Redback(config-port)#bind interface eth1 local

[local]Redback(config-port)#qos policy policing class


Web traffic that conforms to the traffic rate of 5000 kbps is marked with a Differentiated Services Code Point (DSCP) value of AF11. Web traffic exceeding that rate is dropped by default. Packets classified as VOIP are prioritized over both web and default traffic through the DSCP setting of ef, or expedited forwarding. Packets classified as default are set to the DSCP value of df, or default.