Chapter 1 ACL
Overview
In order to filter traffic, network devices
use sets of rules, called access control lists (ACLs), to identify and handle
packets.
When configuring ACLs, go to these chapters
for information you are interested in:
l
ACL Overview
l
IPv4 ACL Configuration
l
IPv6 ACL Configuration
Unless otherwise
stated, ACLs refer to both IPv4 ACLs and IPv6 ACLs throughout this document.
As network scale and network traffic are
increasingly growing, network security and bandwidth allocation become more and
more critical to network management. Packet filtering can be used to
efficiently prevent illegal users from accessing networks and to control
network traffic and save network resources. Access control lists (ACL) are
often used to filter packets with configured matching rules.
ACLs are sets of rules (or sets of permit
or deny statements) that decide what packets can pass and what should be
rejected based on matching criteria such as source MAC address, destination MAC
address, source IP address, destination IP address, and port number.
1.1.2 Application
of ACLs on the Switch
The switch supports two ACL application
modes:
l
Hardware-based application: An ACL is assigned
to a piece of hardware. For example, an ACL can be referenced by QoS 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 part in
this manual.
l
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 part about login
configuration in this manual.
l
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.
l
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.
1.2 Introduction to IPv4 ACL
This section covers these topics:
l
IPv4
ACL Classification
l
IPv4
ACL Naming
l
IPv4
ACL Match Order
l
IPv4 ACL Step
l
Effective
Period of an IPv4 ACL
l
IP
Fragments Filtering with IPv4 ACL
1.2.1 IPv4 ACL Classification
IPv4 ACLs, identified by ACL numbers, fall
into four categories, as shown in Table 1-1.
Table 1-1 IPv4 ACL categories
|
Category
|
ACL number
|
Matching criteria
|
|
Basic IPv4 ACL
|
2000 to 2999
|
Source IP address
|
|
Advanced IPv4 ACL
|
3000 to 3999
|
Source IP address, destination IP
address, protocol carried on IP, and other Layer 3 or Layer 4 protocol header
information
|
|
Ethernet frame header ACL
|
4000 to 4999
|
Layer 2 protocol header fields such as
source MAC address, destination MAC address, 802.1p priority, and link layer
protocol type
|
1.2.2 IPv4 ACL Naming
When creating an IPv4 ACL, you can specify a
unique name for it. Afterwards, you can identify the ACL by its name.
An IPv4 ACL can have only one name. Whether
to specify a name for an ACL is up to you. After creating an ACL, you cannot
specify a name for it, nor can you change or remove the name of the ACL.
The name of an IPv4
ACL must be unique among IPv4 ACLs. However, an IPv4 ACL and an IPv6 ACL can
share the same name.
An ACL consists of multiple rules, each of which
specifies different matching criteria. These criteria may have overlapping or
conflicting parts. This is where the order in which a packet is matched against
the rules comes to rescue.
Two match orders are available for IPv4
ACLs:
l
config: where packets
are compared against ACL rules in the order in which they are configured.
l
auto: where
depth-first match is performed. The term depth-first match has different
meanings for different types of ACLs.
The following shows how your switch
performs depth-first match in a basic IPv4 ACL:
1)
Sort rules by source IP address wildcard first
and compare packets against the rule configured with more zeros in the source
IP address wildcard prior to other rules.
2)
If two rules are present with the same number of
zeros in their source IP address wildcards, compare packets against the rule
configured first prior to the other.
The following shows how your switch
performs depth-first match in an advanced IPv4 ACL:
1)
Sort rules by protocol range and compare packets
against the rule with the protocol carried on IP specified prior to the other.
2)
If the protocol ranges are the same, look at
source IP address wildcard. Then, compare packets against the rule configured
with more zeros in the source IP address wildcard prior to the other.
3)
If the numbers of zeros in the source IP address
wildcards are the same, look at the destination IP address wildcards. Then,
compare packets against the rule configured with more zeros in the destination
IP address wildcard prior to the other.
4)
If the numbers of zeros in the destination IP
address wildcards are the same, look at the Layer 4 port number (TCP/UDP port
number). Then compare packets against the rule configured with the lower port
number prior to the other.
5)
If the port numbers are the same, compare
packets against the rule configured first prior to the other.
The following shows how your switch
performs depth-first match in an Ethernet frame header ACL:
1)
Sort rules by source MAC address mask first and
compare packets against the rule configured with more ones in the source MAC
address mask prior to other rules.
2)
If two rules are present with the same number of
ones in their source MAC address masks, look at the destination MAC address
masks. Then, compare packets against the rule configured with more ones in the
destination MAC address mask prior to the other.
3)
If the numbers of ones in the destination MAC
address masks are the same, the one configured first is compared prior to the
other.
The comparison of a packet against an ACL
stops once a match is found. The packet is then processed as per the rule.
1.2.4 IPv4 ACL Step
I. Meaning of the step
When defining rules in an IPv4 ACL, you do
not necessarily assign them numbers; the system can do this automatically, and
the step defines the increment between two neighboring numbers. For example,
with a step of 5, rules are automatically numbered 0, 5, 10, 15, and so on. By
default, the step is 5.
Whenever the step changes, the rules are
renumbered, starting from 0. For example, if four rules are numbered 5, 10, 15,
and 20 respectively, changing the step from 5 to 2 will cause the rules to be
renumbered 0, 2, 4, and 6.
II. Benefits of using the step
With the step and rule
numbering/renumbering mechanism, you do not need to assign rules numbers when
defining them. The system will assign a newly defined rule a number that is the
smallest multiple of the step bigger than the currently biggest number. For
example, with a step of five, if the biggest number is currently 28, the newly
defined rule will get a number of 30. If the ACL has no rule defined already,
the first defined rule will get a number of 0.
Another benefit of using the step is that
it allows you to insert new rules between existing ones as needed. For example,
after creating four rules numbered 0, 5, 10, and 15 in an ACL with a step of
five, you can insert a rule numbered 1.
You can control when a rule can take effect
by referencing a time range in the rule.
A referenced time range can be one that has
not been created yet. The rule, however, can take effect only after the time
range is defined and comes active.
Traditional packet filtering performs match
operation on, rather than all IP fragments, the first ones only. All subsequent
non-first fragments are handled in the way the first fragments are handled.
This causes security risk as attackers may fabricate non-first fragments to
attack your network.
As for the configuration of a rule of an
IPv4 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.
1.3 Introduction to IPv6 ACL
This section covers these topics:
l
IPv6
ACL Classification
l
IPv6
ACL Naming
l
IPv6
ACL Match Order
l
IPv6
ACL Step
l
Effective
Period of an IPv6 ACL
1.3.1 IPv6 ACL Classification
IPv6 ACLs, identified by ACL numbers, fall
into three categories, as show in Table 1-2.
Table 1-2 IPv6 ACL categories
|
Category
|
ACL number
|
Matching criteria
|
|
Basic IPv6 ACL
|
2000 to 2999
|
Source IPv6 address
|
|
Advanced IPv6 ACL
|
3000 to 3999
|
Source IPv6 address, destination IPv6
address, protocol carried on IPv6, and other Layer 3 or Layer 4 protocol
header fields
|
1.3.2
IPv6 ACL Naming
When creating an IPv6 ACL, you can specify
a unique name for it. Afterwards, you can identify the IPv6 ACL by its name.
An IPv6 ACL can have only one name. Whether
to specify a name for an ACL is up to you. After creating an ACL, you cannot
specify a name for it, nor can you change or remove the name of the ACL.
The name of an IPv6
ACL must be unique among IPv6 ACLs. However, an IPv6 ACL and an IPv4 ACL can
share the same name.
Similar to IPv4 ACLs, IPv6 ACLs are
sequential collections of rules defined with different matching parameters. The
order in which a packet is matched against the rules in an IPv6 ACL may affect
how the packet is handled.
Like in IPv4 ACLs, the following two match
orders are available in IPv6 ACLs:
l
config: where
rules are compared against in the order in which they are configured.
l
auto: where
depth-first match is performed.
I. Depth-first match for a basic
IPv6 ACL
The following shows how your switch
performs depth-first match in a basic IPv6 ACL:
1)
Sort rules by source IPv6 address wildcard first
and compare packets against the rule configured with a longer prefix in the
source IPv6 address wildcard prior to other rules.
2)
If two rules are present with the same prefix
length in their source IPv6 address wildcards, compare packets against the rule
configured first prior to the other.
II. Depth-first match for an
advanced IPv6 ACL
The following shows how your switch
performs depth-first match in an advanced IPv6 ACL:
1)
Sort rules by protocol range first, and compare
packets against the rule with the protocol carried on IPv6 specified prior to
other rules.
2)
If two rules are present with the same protocol
range, look at source IPv6 address wildcard in addition. Then, compare packets
against the rule configured with a larger prefix length in the source IPv6
address wildcard prior to the other.
3)
If the prefix lengths in the source IPv6 address
wildcards are the same, look at the destination IPv6 address wildcards. Then,
compare packets against the rule configured with a larger prefix length in the
destination IPv6 address wildcard prior to the other.
4)
If the prefix lengths in the destination IPv6
address wildcards are the same, look at the Layer 4 port number (TCP/UDP port
number). Then compare packets against the rule configured with the lower port
number prior to the other.
5)
If the port numbers are the same, compare
packets against the rule configured first prior to the other.
The comparison of a packet against an ACL
stops once a match is found. The packet is then processed as per the rule.
1.3.4 IPv6 ACL Step
Refer to IPv4 ACL Step.
Refer to Effective Period of an IPv4 ACL.
Chapter 2 IPv4 ACL Configuration
When configuring an IPv4 ACL, go to these
sections for information you are interested in:
l
Creating a Time Range
l
Configuring a Basic
IPv4 ACL
l
Configuring an Advanced
IPv4 ACL
l
Configuring an Ethernet
Frame Header ACL
l
Copying an IPv4 ACL
l
Displaying and
Maintaining IPv4 ACLs
l
IPv4 ACL Configuration
Example
2.1 Creating a Time Range
You can specify a time range for each rule
in an ACL. A time range-based ACL takes effect only in specified time ranges.
Only after a time range is configured and the system time is within the time
range, can an ACL rule take effect.
Two types of time ranges are available:
l
Periodic time range, which recurs periodically
on the day or days of the week.
l
Absolute time range, which takes effect only in
a period of time and does not recur.
2.1.1 Configuration Procedure
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-name { start-time to end-time days [ from
time1 date1 ] [ to time2 date2 ] | from time1
date1 [ to time2 date2 ] | to time2 date2 }
|
Required
|
Note that:
l
Periodic time range created using the time-range
time-name start-time to end-time days
command. A time range thus created recurs periodically on the day or days of
the week.
l
Absolute time range created using the time-range
time-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, 2004 00:00 and December 31, 2004 23:59,
you may use the time-range test from 00:00 01/01/2004 to 23:59 12/31/2004
command.
l
Compound time range created using the time-range
time-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, 2004 00:00 and December
31, 2004 23:59, you may use the time-range test 12:00 to 14:00 wednesday
from 00:00 01/01/2004 to 23:59 12/31/2004 command.
l
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.
l
With no start time specified, the time range is
from the earliest time that the system can express (that is, 00:00 01/01/1970)
to the end time. With no end time specified, the time range is from the time
the configuration takes effect to the latest time that the system can express
(that is, 24:00 12/31/2100).
l
Up to 256 time ranges can be defined.
# Create a periodic time range that is
active from 8:00 to 18:00 every working day.
<Sysname> system-view
[Sysname] time-range test 8:00 to
18:00 working-day
[Sysname] display time-range test
Current time is 22:17:42 1/5/2006
Thursday
Time-range : test ( Inactive )
08:00 to 18:00 working-day
# Create an absolute time range from 15:00,
Jan 28, 2006 to 15:00, Jan 28, 2008.
<Sysname> system-view
[Sysname] time-range test from 15:00
1/28/2006 to 15:00 1/28/2008
[Sysname] display time-range test
Current time is 22:20:18 1/5/2006
Thursday
Time-range : test ( Inactive )
from 15:00 1/28/2006 to 15:00
1/28/2008
2.2 Configuring a Basic IPv4 ACL
Basic IPv4 ACLs filter packets based on
source IP address. They are numbered in the range 2000 to 2999.
If you want to reference a time range to a
rule, define it with the time-range command first.
Follow these steps to configure a basic
IPv4 ACL:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
––
|
|
Create and enter basic IPv4 ACL view
|
acl number
acl-number [ name acl-name ] [ match-order { auto
| config } ]
|
Required
The default match order is config.
If you specify a name for an IPv4 ACL
when creating the ACL, you can use the acl name acl-name
command to enter the view of the ACL later.
|
|
Create or modify a rule
|
rule [ rule-id
] { deny | permit } [ fragment | logging |
source { sour-addr sour-wildcard | any } |
time-range time-name ] *
|
Required
To create multiple rules, repeat this
step.
Note that the logging keyword is
not supported if the ACL is to be referenced by a QoS policy for traffic
classification.
|
|
Set a rule numbering step
|
step step-value
|
Optional
The default step is 5.
|
|
Create an IPv4 ACL description
|
description text
|
Optional
By default, no IPv4 ACL description is
present.
|
|
Create a rule description
|
rule rule-id
comment text
|
Optional
By default, no rule description is
present.
|
Note that:
l
You will fail to create or modify a rule if its
permit/deny statement is exactly the same as another rule. In addition, if the
ACL match order is set to auto rather than config, you cannot
modify ACL rules.
l
You may use the display acl command to
verify rules configured in an ACL. If the match order for this ACL is auto,
rules are displayed in the depth-first match order rather than by rule number.
Caution:
l
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 it does not contain any
rules.
l
The rule specified in the rule comment
command must have existed.
# Create IPv4 ACL 2000 to deny the packets
with source address 1.1.1.1 to pass.
<Sysname> system-view
[Sysname] acl number 2000
[Sysname-acl-basic-2000] rule deny
source 1.1.1.1 0
# Verify the configuration.
[Sysname-acl-basic-2000] display acl
2000
Basic ACL 2000, named -none-, 1
rule,
ACL's step is 5
rule 0 deny source 1.1.1.1 0
2.3 Configuring an Advanced IPv4 ACL
Advanced IPv4 ACLs filter packets based on
source IP address, destination IP address, protocol carried on IP, and other
protocol header fields, such as the TCP/UDP source port, TCP/UDP destination
port, ICMP message type, and ICMP message code.
In addition, advanced IPv4 ACLs allow you
to filter packets based on three priority criteria: type of service (ToS), IP
precedence, and differentiated services codepoint (DSCP) priority.
Advanced IPv4 ACLs are numbered in the
range 3000 to 3999. Compared with basic IPv4 ACLs, they allow of more flexible
and accurate filtering.
If you want to reference a time range to a
rule, define it with the time-range command first.
Follow these steps to configure an advanced
IPv4 ACL:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
