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

Configuring ACLs

© Ericsson AB 2010. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

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.2IPv4 Filtering ACLs
2.3IPv6 Filtering ACLs
2.4Enable ACL Counters or Logging for a Subscriber
2.5Modify IP ACL Conditions in Real Time
2.6Policy ACLs
2.7Operations 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 to Filter IPv4 Traffic
3.7Configure an IP ACL to Filter IPv6 Traffic
3.8Apply IPv4 and IPv6 ACLs to the Same Interface
3.9Configure a Policy ACL Associated with a Forward Policy
3.10Configure a Policy ACL Associated with a NAT Policy
3.11Configure a Policy ACL Associated with a QoS Policing Policy
3.12Configure an ACL to Enable SNMP Traps


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.

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.

1.1.1   IP ACL Applications

You can create IP ACLs to filter IPv4 and IPv6 control and administration traffic on the following:

IPv4 and IPv6 ACLs can coexist on contexts or interfaces.

Note:  
IPv6 ACLs are not supported with PPA1 traffic cards.

Use the following guidelines for creating filtering ACLs:

1.1.2   IP ACL Statements

In IP ACLs 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.

Implicit statements can block valid access to a context. For example, in the local context, it could block administrator access to the Ethernet management port. To allow administrator access, add a statement to explicitly allow access from authorized sources.

Note:  
In IPv6 ACLs, a maximum of 100 rules is allowed.

You can use the seq seq-num permit or deny constructs to establish a sequence order for the statements you are creating. If you use the permit or deny commands, which do not explicitly set the sequence, 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. Use the no seq seq-num construct to remove 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 IPv4 packets that are dropped as a result of an IP ACL are counted and logged (denied packets only) if you enable the count and log functions when you apply an IP ACL. However, IPv6 packets can be counted, but not logged.

By default, these functions are disabled because they have an impact on system performance. We recommend that you only enable them when they are 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 administration (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 VSAs section 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.

Note:  
QoS metering, policing, and forwarding policies do not currently support policy ACLs for classification of IPv6 traffic. When IPv6 traffic is subject to a metering, policing, or forwarding policy, that was configured using an IPv4 policy ACL, IPv6 packets do not match any of the classes, but are subject to the configured policy-level action.

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 the Vendor VSAs Provided by Ericsson AB section in RADIUS Attributes.

2.2   IPv4 Filtering ACLs

2.2.1   Configure an IPv4 ACL

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

Table 1    Configure an IPv4 ACL

Step

Task

Root Command

Notes

1.

Create or select an ACL and enter access control list configuration mode to add options and rules.

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


or seq

To explicitly set its order in the list, use the seq permit construct for each statement.

5.

Create an ACL statement using deny conditions.

deny


or seq

To explicitly set its order in the list, use the seq deny construct for each statement.

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.2.2   Apply an IP ACL for IPv4 Traffic

To apply an IPv4 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 IPv4 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 subscribers)

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.3   IPv6 Filtering ACLs

2.3.1   Configure an IPv6 ACL

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

Table 3    Configure an IPv6 ACL

Step

Task

Root Command

Notes

1.

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

ipv6 access-list

Enter this command in context configuration mode.


For IPv6, a maximum of 100 rules can be added to each ACL.

2.

Optional. Associate a description with an IP ACL.

description (ACL)

 

4.

Optional. Create an ACL statement using permit conditions.

permit


or seq

To explicitly set its order in the list, use the seq permit construct for each statement.

5.

Optional. Create an ACL statement using deny conditions.

deny


or seq

To explicitly set its order in the list, use the seq deny construct for each statement.

6.

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

condition

After entering this command, you can enter the absolute, periodic, or resequence ip access-list optional commands in ACL condition configuration mode.


The condition command is not supported on IPv6 ACLs applied on the Ethernet Management port; conditions are ignored.

7.

Optional. Configure absolute time condition statements.

absolute

An absolute time ACL statement redefines an ACL rule 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.2   Apply an IP ACL for IPv6 Traffic

To apply an IPv6 ACL to packets associated with a context or an interface, perform the appropriate task described in Table 2.

Table 4    Apply an IPv6 ACL

Task

Root Command

Notes

Apply an IPv6 ACL to an interface.

ipv6 access-group

Enter this command in interface mode.

To filter control and administrative traffic, apply an administrative IPv6 ACL to a context.

ipv6 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 5.

Table 5    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 6.

Table 6    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   Policy ACLs

2.6.1   Configure a Policy ACL

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

Table 7    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.

7.

Optional. Resequence statements in a policy ACL.

resequence policy access-list

Enter this command in context configuration mode.

2.6.2   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.6.3   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 8.

Table 8    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.7   Operations Tasks

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

Table 9    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 (IPv4).

debug ip access-list

Enable the generation of debug messages for IP ACL events (IPv6).

debug ipv6 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 IPv4 ACLs.

show ip access-list

Display the status of configured IPv6 ACLs.

show ipv6 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.

In this example, the order of the condition statements is assigned automatically by the SmartEdge OS. To determine the list order, use the seq permit construct for each one.

[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 to Filter IPv4 Traffic

The following example creates an IPv4 ACL, tc4 with deny and permit statements. In this case, the SmartEdge OS orders the list sequence. If you wanted to determine the order of the statements, use the seq deny and seq permit commands.

[local]Redback(config-ctx)#ip access-list tc4
[local]Redback(config-access-list)#description This is a sample IP 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 

3.7   Configure an IP ACL to Filter IPv6 Traffic

The following example creates an IPv6 ACL, tc6.

[local]Redback(config-ctx)#ipv6 access-list tc6
[local]Redback(config-ipv6-access-list)#description This is a sample IPv6 access control list
[local]Redback(config-ipv6-access-list)#seq 12 deny tcp 22:1:1::2/128 any traffic-class eq df
[local]Redback(config-ipv6-access-list)#seq 20 deny udp any any range 80 81
[local]Redback(config-ipv6-access-list)#seq 20 deny tcp any 5:6:7:8:9::/120 eq ftp established
[local]Redback(config-ipv6-access-list)#seq 900 permit ipv6 any any

3.8   Apply IPv4 and IPv6 ACLs to the Same Interface

The following example shows the two IPv4 and IPv6 ACLs in Section 3.6and Section 3.7 applied to the same interface in a context:

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

[local]Redback(config-if)#ip access-group tc4 in count log
[local]Redback(config-if)#ipv6 access-group tc6 in count

3.9   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.10   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.11   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.

3.12   Configure an ACL to Enable SNMP Traps

Filter ACLs contain a set of rules, executed in specific order. Each rule defines certain criteria, such as, checking for IP packets, protocol, source/destination IP addresses, and ports. Each rule also contains an action, either permit or deny. If the packet matches the criteria declared in the given rule, the action is executed; that is, the packet is either permitted or denied, and the processing is stopped without executing the rules that follow. If the packet does not match the criteria declared in the given rule, the processing continues on to the next rule. Table 10 describes the key concepts in the IP ACL statements:

Table 10    ACL Fields and Values

ACL Fields

Description

Sequence Number

An appropriate sequence number that positions the rule in the proper processing order in the list of rules.

Action

Permit or deny

Protocol

UDP

Source IP

— Source IP Address: 0.0.0.0


— Wildcard: 255.255.255.255


Specifies that the source can be any IP address

Destination Port

snmptrap

Condition

eq

To configure an ACL that allows you to block all incoming UDP traffic and continue to forward SNMP traps, enter the command in context configuration mode. In the following example, for every statement with sequence numbers, 10, 20, and 30, a different ACL action is initiated. Sequence 10 permits UDP traffic with destination address 127.0.0.1 and the snmptrap destination port. In other words, it allows the packets matching these criteria, to be processed by the system. Sequence 20 denies UDP traffic data collection, thereby drops UDP packets that do not meet the criteria declared in the previous rule. Sequence 30 permits collection of any IP packets that do not match the previous rules. The any any construct at the end of every IP ACL refers to any source or any destination IP address:

 
[local]Redback(config-ctx)#ip access-list block-all-udp-except-internal-traps

[local]Redback(config-access-list)#seq 10 permit udp any host 127.0.0.1 eq snmptrap

[local]Redback(config-access-list)#seq 20 deny udp any any

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

Administrative ACLs are used to protect the SmartEdge OS from Denial of Service (DoS) and other attacks. As opposed to ACLs that are applied to IP traffic sent or received on an interface, administrative ACLs are applied to IP traffic that is received locally and processed within a SmartEdge context. For example, an administrative ACL may be used to restrict access to a limited set of applications originating from a single source subnet. To configure an administrative ACL, issue the following command:

 
[local]Redback(config-ctx)#admin-access-group block-all-udp-except-internal-traps in