comware acl configuration

i

Table of Contents

1 ACL Configuration·····································································································································1-1 ACL Overview ·········································································································································1-1

Introduction······································································································································1-1 Application of ACLs on the Switch ··································································································1-1 ACL Classification ···························································································································1-2 ACL Numbering and Naming ··········································································································1-2 Match Order·····································································································································1-2 ACL Rule Numbering Step ··············································································································1-3 Implementing Time-Based ACL Rules ····························································································1-4 Fragments Filtering with ACLs ········································································································1-4

ACL Configuration Task List ···················································································································1-4 Configuring an ACL·································································································································1-5

Creating a Time Range ···················································································································1-5 Configuring a Basic ACL ·················································································································1-5 Configuring an Advanced ACL ········································································································1-7 Configuring an Ethernet Frame Header ACL ··················································································1-8 Copying an ACL ······························································································································1-9 Applying an ACL for Packet Filtering·······························································································1-9

Displaying and Maintaining ACLs ·········································································································1-10 ACL Configuration Examples················································································································1-11

ACL Configuration Examples ········································································································1-11

1-1

1 ACL Configuration

This chapter includes these sections:

ACL Overview

ACL Configuration Task List

Configuring an ACL

Creating a Time Range

Configuring a Basic ACL

Configuring an Advanced ACL

Configuring an Ethernet Frame Header ACL

Copying an ACL

Applying an ACL for Packet Filtering

Displaying and Maintaining ACLs

ACL Configuration Examples

ACL Overview

Introduction

An access control list (ACL) is a set of rules (that is, a set of permit or deny statements) for identifying

traffic based on matching criteria such as source address, destination address, and port number. The

selected traffic will then be permitted or rejected by predefined security policies.

ACLs are widely used in technologies where traffic identification is desired, such as packet filtering and

QoS.

Application of ACLs on the Switch

The switch supports two ACL application modes:

Hardware-based application: An ACL is assigned to a piece of hardware. For example, an ACL is

applied to an Ethernet interface or VLAN interface for packet filtering or is referenced by a QoS

policy for traffic classification. Note that when an ACL is referenced to implement QoS, the actions

defined in the ACL rules, deny or permit, do not take effect; actions to be taken on packets

matching the ACL depend on the traffic behavior definition in QoS. For details about traffic

behavior, refer to the QoS Configuration.

1-2

Software-based application: An ACL is referenced by a piece of upper layer software. For example,

an ACL can be referenced to configure login user control behavior, thus controlling Telnet, SNMP

and Web users. Note that when an ACL is reference by the upper layer software, actions to be

taken on packets matching the ACL depend on those defined by the ACL rules. For details about

login user control, refer to the Login Configuration.

When an ACL is assigned to a piece of hardware and referenced by a QoS policy for traffic

classification, the switch does not take action according to the traffic behavior definition on a

packet that does not match the ACL.

When an ACL is referenced by a piece of software to control Telnet, SNMP, and Web login users,

the switch denies all packets that do not match the ACL.

For details of ACL application for packet filtering, refer to Applying an ACL for Packet Filtering.

ACL Classification

ACLs fall into three categories, as shown in Table 1-1.

Table 1-1 ACL categories

Category ACL number Match criteria

Basic ACLs 2000 to 2999 Source IPv4 address

Advanced ACLs 3000 to 3999 Source/destination IPv4 address, protocols over IPv4, and other Layer 3 and Layer 4 header fields

Ethernet frame header ACLs 4000 to 4999 Layer 2 header fields, such as source and destination MAC

addresses, 802.1p priority, and link layer protocol type

ACL Numbering and Naming

Each ACL category has a unique range of ACL numbers. When creating an ACL, you must assign it a

number for identification, and in addition, you can also assign the ACL a name for the ease of

identification. After creating an ACL with a name, you can neither rename it nor delete its name.

The ACL number and name must be globally unique.

Match Order

The rules in an ACL are sorted in a certain order. When a packet matches a rule, the device stops the

match process and performs the action defined in the rule. If an ACL contains overlapping or conflicting

rules, the matching result and action to take depend on the rule order.

Two ACL match orders are available:

config: Sorts ACL rules in ascending order of rule ID. A rule with a lower ID is matched before a

rule with a higher ID. If you use this approach, check the rules and their order carefully.

1-3

auto: Sorts ACL rules in depth-first order, as described in Table 1-2. The depth-first order varies

with ACL categories.

Table 1-2 Sorting ACL rules in depth-first order

ACL category Depth-first rule sorting procedures

Basic ACL 1) A rule with more 0s in the source IP address wildcard mask takes precedence.

More 0s means a narrower IP address range. 2) A rule with a smaller ID takes precedence.

Advanced ACL

1) A rule configured with a specific protocol is prior to a rule with the protocol type set to IP. IP represents any protocol over IP.

2) A rule with more 0s in the source IP address wildcard mask takes precedence. More 0s means a narrower IP address range.

3) A rule with more 0s in the destination IP address wildcard mask takes precedence.4) A rule with a narrower TCP/UDP service port number range takes precedence. 5) A rule with a smaller ID takes precedence.

Ethernet frame header ACL

1) A rule with more 1s in the source MAC address mask takes precedence. More 1s means a smaller MAC address.

2) A rule with more 1s in the destination MAC address mask takes precedence. 3) A rule with a smaller ID takes precedence.

A wildcard mask, also called an inverse mask, is a 32-bit binary and represented in dotted decimal

notation. In contrast to a network mask, the 0 bits in a wildcard mask represent ‘do care’ bits, while the

1 bits represent 'don’t care bits'. If the 'do care' bits in an IP address identical to the 'do care' bits in an

IP address criterion, the IP address matches the criterion. All 'don’t care' bits are ignored. The 0s and

1s in a wildcard mask can be noncontiguous. For example, 0.255.0.255 is a valid wildcard mask. With

wildcard masks, you can create more granular match criteria than network masks.

ACL Rule Numbering Step

What is the ACL rule numbering step

If you do not assign an ID for the rule you are creating, the system automatically assigns it a rule ID.

The rule numbering step sets the increment by which the system numbers rules automatically. For

example, the default ACL rule numbering step is 5. If you do assign IDs to rules you are creating, they

are numbered 0, 5, 10, 15, and so on. The wider the numbering step, the more rules you can insert

between two rules.

By introducing a gap between rules rather than contiguously numbering rules, you have the flexibility of

inserting rules in an ACL. This feature is important for a config order ACL, where ACL rules are

matched in ascending order of rule ID.

Automatic rule numbering and re-numbering

The ID automatically assigned to an ACL rule takes the nearest higher multiple of the numbering step to

the current highest rule ID, starting with 0.

1-4

For example, if the numbering step is 5 (the default), and there are five ACL rules numbered 0, 5, 9, 10,

and 12, the newly defined rule will be numbered 15. If the ACL does not contain any rule, the first rule

will be numbered 0.

Whenever the step changes, the rules are renumbered, starting from 0. For example, if there are five

rules numbered 5, 10, 13, 15, and 20, changing the step from 5 to 2 causes the rules to be renumbered

0, 2, 4, 6 and 8.

Likewise, after you restore the default step, ACL rules are renumbered in the default step. Assume that

there are four ACL rules numbered 0, 2, 4, and 6 in steps of 2. When the default step is restored, the

rules are renumbered 0, 5, 15, and 15.

Implementing Time-Based ACL Rules

You can implement ACL rules based on the time of day by applying a time range to them. A time-based

ACL rule takes effect only in any time periods specified by the time range.

Two basic types of time range are available:

Periodic time range, which recurs periodically on a day or days of the week.

Absolute time range, which represents only a period of time and does not recur.

You may apply a time range to ACL rules before or after you create it. However, the rules using the time

range can take effect only after you define the time range.

Fragments Filtering with ACLs

Traditional packet filtering matched only first fragments of IPv4 packets, and allowed all subsequent

non-first fragments to pass through. This mechanism resulted in security risks, because attackers may

fabricate non-first fragments to attack networks.

As for the configuration of a rule of an ACL, the fragment keyword specifies that the rule applies to

non-first fragment packets only, and does not apply to non-fragment packets or the first fragment

packets. ACL rules that do not contain this keyword is applicable to both non-fragment packets and

fragment packets.

ACL Configuration Task List

Complete the following tasks to configure an ACL:

Task Remarks

Creating a Time Range Optional




Required Configure at least one task

Copying an ACL Optional

Applying an ACL for Packet Filtering Optional

1-5

Configuring an ACL

Creating a Time Range

Follow these steps to create a time range:

To do… Use the command… Remarks

Enter system view system-view ––

Create a time range

time-range time-range-name { start-time to end-time days [ from time1 date1 ] [ to time2 date2 ] | from time1 date1 [ to time2 date2 ] | to time2 date2 }

Required By default, no time range exists.

You may create a maximum of 256 time ranges.

A time range can be one of the following:

Periodic time range created using the time-range time-range-name start-time to end-time days

command. A time range thus created recurs periodically on the day or days of the week. A periodic

time range is active only when the system time falls within it.

Absolute time range created using the time-range time-range-name { from time1 date1 [ to time2

date2 ] | to time2 date2 } command. Unlike a periodic time range, a time range thus created does

not recur. For example, to create an absolute time range that is active between January 1, 2010

00:00 and December 31, 2010 23:59, you may use the time-range test from 00:00 01/01/2010 to 23:59 12/31/2010 command.

Compound time range created using the time-range time-range-name start-time to end-time days

{ from time1 date1 [ to time2 date2 ] | to time2 date2 } command. A time range thus created recurs

on the day or days of the week only within the specified period. For example, to create a time range

that is active from 12:00 to 14:00 on Wednesdays between January 1, 2010 00:00 and December

31, 2010 23:59, you may use the time-range test 12:00 to 14:00 wednesday from 00:00 01/01/2010 to 23:59 12/31/2010 command.

You may create individual time ranges identified with the same name. They are regarded as one time

range whose active period is the result of ORing periodic ones, ORing absolute ones, and ANDing

periodic and absolute ones.

If you do not specify the start time and date, the time range starts from the earliest time that the system

supports, namely 00:00 01/01/1970. If you do not specify the end time and date, the time range ends at

the latest time that the system supports, namely 24:00 12/31/2100.


Basic ACLs match packets based on only source IP address.

Follow these steps to configure a basic ACL:



1-6


Create a basic ACL and enter its view

acl number acl-number [ name acl-name ] [ match-order { auto | config } ]

Required By default, no ACL exists. Basic ACLs are numbered in the range 2000 to 2999. You can use the acl name acl-name command to enter the view of an existing named ACL.

Configure a description for the basic ACL description text

Optional By default, a basic ACL has no ACL description.

Set the rule numbering step step step-value Optional 5 by default.

Create or edit a rule

rule [ rule-id ] { deny | permit } [ fragment | logging | source { sour-addr sour-wildcard | any } | time-range time-range-name ] *

Required By default, an Basic ACL does not contain any rule. To create or edit multiple rules, repeat this step. For a basic ACL rule to be referenced by a QoS policy for traffic classification, the logging keyword is not supported.

Configure or edit a rule description rule rule-id comment text Optional By default, an ACL rule has no rule description.

Note that:

You can only modify the existing rules of an ACL that uses the match order of config. When

modifying a rule of such an ACL, you may choose to change just some of the settings, in which

case the other settings remain the same.

You cannot create a rule with, or modify a rule to have, the same permit/deny statement as an

existing rule in the ACL.

When the ACL match order is auto, a newly created rule will be inserted among the existing rules

in the depth-first match order. Note that the IDs of the rules still remain the same.

You can modify the match order of an ACL with the acl number acl-number [ name acl-name ]

match-order { auto | config } command, but only when the ACL does not contain any rules.

The rule specified in the rule comment command must already exist.

1-7


Advanced ACLs match packets based on source and destination IP addresses, protocols over IP, and

other protocol header information, such as TCP/UDP source and destination port numbers, TCP flags,

ICMP message types, and ICMP message codes.

Advanced ACLs also allow you to filter packets based on three priority criteria: type of service (ToS), IP

precedence, and differentiated services codepoint (DSCP) priority.

Compared with basic ACLs, advanced ACLs allow of more flexible and accurate filtering.

Follow these steps to configure an advanced ACL:



Create an advanced ACL and enter its view


Required By default, no ACL exists. Advanced ACLs are numbered in the range 3000 to 3999. You can use the acl name acl-name command to enter the view of an existing named ACL.

Configure a description for the advanced ACL description text

Optional By default, an Advanced ACL has no ACL description.



rule [ rule-id ] { deny | permit } protocol [ { established | { ack ack-value | fin fin-value | psh psh-value | rst rst-value | syn syn-value | urg urg-value } * } | destination { dest-addr dest-wildcard | any } | destination-port operator port1 [ port2 ] | dscp dscp | fragment | icmp-type { icmp-type icmp-code | icmp-message } | logging | precedence precedence | reflective | source { sour-addr sour-wildcard | any } | source-port operator port1 [ port2 ] | time-range time-range-name | tos tos ] *

Required By default, an advanced ACL does not contain any rule. To create or edit multiple rules, repeat this step. For an advanced ACL rule to be referenced by a QoS policy for traffic classification, the logging keyword is not supported.

Configure or edit a rule description rule rule-id comment text Optional By default, an ACL rule has no rule description.

Note that:






1-8







Ethernet frame header ACLs, also called Layer 2 ACLs, match packets based on Layer 2 protocol

header fields such as source MAC address, destination MAC address, 802.1p priority (VLAN priority),

and link layer protocol type.

Follow these steps to configure an Ethernet frame header ACL:



Create an Ethernet frame header ACL and enter its view


Required By default, no ACL exists. Ethernet frame header ACLs are numbered in the range 4000 to 4999.. You can use the acl name acl-name command to enter the view of an existing named Ethernet frame header ACL.

Configure a description for the Ethernet frame header ACL description text

Optional By default, an Ethernet frame header ACL has no ACL description.



rule [ rule-id ] { deny | permit } [ cos vlan-pri | dest-mac dest-addr dest-mask | { lsap lsap-type lsap-type-mask | type protocol-type protocol-type-mask } | source-mac sour-addr source-mask | time-range time-range-name ] *

Required

By default, an Ethernet frame header ACL does not contain any rule. To create or edit multiple rules, repeat this step.

Configure or edit a rule description rule rule-id comment text

Optional By default, an Ethernet frame header ACL rule has no rule description.

Note that:

1-9











Copying an ACL

You can create an ACL by copying an existing ACL. The new ACL has the same properties and content

as the source ACL except the ACL number and name.

To copy an ACL successfully, ensure that:

The destination ACL number is from the same category as the source ACL number.

The source ACL already exist but the destination ACL does not.

Copying an ACL

Follow these steps to copy an ACL:


Enter system view system-view —

Copy an existing ACL to create a new ACL

acl copy { source-acl-number | name source-acl-name } to { dest-acl-number | name dest-acl-name }

Required

Applying an ACL for Packet Filtering

You can apply an ACL to the inbound direction of an ethernet interface or VLAN interface to filter

received packets such as Ethernet frames and IPv4 packets.

ACLs on VLAN interfaces filter only packets forwarded at Layer 3.

1-10

Filtering Ethernet Frames

Follow these steps to apply an Ethernet frame header ACL to an interface to filter Ethernet frames:



Enter Ethernet interface view

interface interface-type interface-number Enter

interface view Enter VLAN interface view interface vlan-interface vlan-id

Use either command

Apply an Ethernet frame header ACL to the interface to filter Ethernet frames

packet-filter { acl-number | name acl-name } inbound

Required By default, an interface does not filter Ethernet frames.

Filtering IPv4 Packets

Follow these steps to apply an ACL to an interface to filter IPv4 packets:



Enter Ethernet interface view

interface interface-type interface-number Enter

interface view Enter VLAN interface view interface vlan-interface vlan-id

Use either command

Apply a basic or advanced ACL to the interface to filter IPv4 packets

packet-filter { acl-number | name acl-name } inbound

Required By default, an interface does not filter IPv4 packets.

Displaying and Maintaining ACLs

To do... Use the command… Remarks

Display configuration and match statistics for one or all ACLs

display acl { acl-number | all | name acl-name } Available in any view

Display the usage of ACL resources display acl resource Available in any view

Display the configuration and status of one or all time ranges

display time-range { time-range-name | all } Available in any view

Clear statistics on one or all ACLs reset acl counter { acl-number | all | name acl-name } Available in user view

1-11



Network requirements

As shown in Figure 1-1, apply an ACL to the inbound direction of interface GigabitEthernet 1/0/1 on

Device A so that the interface denies IPv4 packets sourced from Host A from 8:00 to 18:00 everyday.

Figure 1-1 Network diagram for applying an ACL to an interface for filtering

IP networkGE1/0/1Host A

192.168.1.2/24

Device A

Host B192.168.1.3/24

Configuration procedure

# Create a time range named study, setting it to become active from 08:00 to 18:00 everyday.

<DeviceA> system-view

[DeviceA] time-range study 8:00 to 18:00 daily

# Create basic ACL 2009. [DeviceA] acl number 2009

# Create a basic ACL rule to deny packets sourced from 192.168.1.2/32 during time range study. [DeviceA-acl-basic-2009] rule deny source 192.168.1.2 0 time-range study

[DeviceA-acl-basic-2009] quit

# Apply ACL 2009 to the inbound direction of interface GigabitEthernet 1/0/1. [DeviceA] interface gigabitethernet 1/0/1

[DeviceA-GigabitEthernet1/0/1] packet-filter 2009 inbound

comware acl configuration

Documents