An access control list (ACL) is used
primarily to identify traffic flows. In order to filter data packets, a series
of match rules must be configured on the network device to identify the packets
to be filtered. After the specific packets are identified, and based on the
predefined policy, the network device can permit/prohibit the corresponding
packets to pass.
ACLs classify packets based on a series of
match conditions, which can be the source addresses, destination addresses and
port numbers carried in the packets.
The packet match rules defined by ACLs can
be referenced by other functions that need to differentiate traffic flows, such
as the definition of traffic classification rules in QoS.
According to the
application purpose, ACLs fall into the following four types:
l
Basic ACL: rules are made based on the L3 source
IP addresses only.
l
Advanced ACL: rules are made based on the L3 and
L4 information such as the source and destination IP addresses of the data
packets, the type of protocol over IP, protocol-specific features, and so on.
l
Layer 2 ACL: rules are made based on the Layer 2
information such as the source and destination MAC address information, VLAN
priority, Layer 2 protocol, and so on.
l
User-defined ACL: such rules specify a byte in
the packet, by its offset from the packet header, as the starting point to
perform logical AND operations, and compare the extracted string with the
user-defined string to find the matching packets for processing.
I. ACLs activated
directly on the hardware
In the switch, an ACL can be directly
activated on the switch hardware for packet filtering and traffic
classification in the data forwarding process. In this case, the match order of
multiple rules in an ACL is determined by the hardware of the switch, and any
user-defined match order, even if it is configured when the ACL is defined,
will not work.
ACLs are directly activated on the switch
hardware in the following situations: the switch references ACLs to implement
the QoS functions, and the forwards data through ACLs.
II. ACL referenced by
the upper-level modules
The switch also uses ACLs to filter packets
processed by software and implements traffic classification. In this case,
there are two types of match orders for the rules in an ACL: config
(user-defined match order) and auto (the system performs automatic
ordering, namely according “depth-first” order). In this scenario,
you can specify the match order for multiple rules in an ACL. You cannot modify
the match order for an ACL once you have specified it. You can specify a new
the match order only after all the rules are deleted from the ACL.
ACLs can also be referenced by route
policies or be used to control login users.
An ACL may contain a number of rules, which
specify different packet ranges. This brings about the issue of match order
when these rules are used to match packets.
An ACL supports the following two types of
match orders:
l
Configured order: ACL rules are matched
according to the configured order.
l
Automatic ordering: ACL rules are matched
according to the “depth-first” order.
I. IP ACL depth-first
order
With the depth-first rule adopted, the
rules of an IP ACL (basic and advanced ACL) are matched in the following order:
1)
Protocol range of ACL rules. The range for IP
protocol is 1 to 255 and those of other protocols over IP are the same as the
corresponding protocol numbers. The smaller the protocol range, the higher the
priority.
2)
Range of source IP address. The smaller the
source IP address range (that is, the longer the mask), the higher the
priority.
3)
Range of destination IP address. The smaller the
destination IP address range (that is, the longer the mask), the higher the
priority.
4)
Range of Layer 4 port number, that is, of
TCP/UDP port number. The smaller the range, the higher the priority.
If rule A and rule B are the same in all
the four ACEs (access control elements) above, and also in their numbers of
other ACEs to be considered in deciding their priority order, weighting
principles will be used in deciding their priority order.
The weighting principles work as follows:
l
Each ACE is given a fixed weighting value. This
weighting value and the value of the ACE itself will jointly decide the final
matching order.
l
The weighting values of ACEs rank in the
following descending order: DSCP, ToS, ICMP, established, VPN-instance,
precedence, fragment.
l
A fixed weighting value is deducted from the
weighting value of each ACE of the rule. The smaller the weighting value left,
the higher the priority.
l
If the number and type of ACEs are the same for
multiple rules, then the sum of ACE values of a rule determines its priority.
The smaller the sum, the higher the priority.
II. Layer 2 ACL
depth-first order
With the depth-first rule adopted, the
rules of a Layer 2 ACL are matched in the order of the mask length of the
source MAC address and destination MAC address. The longer of the mask is, the
higher the match priority is. If two mask lengths are the same, the priority of
the match rule configured earlier is higher. For example, the priority of the
match rule with source MAC address mask FFFF-FFFF-0000 is higher then the
priority of the match rule with source MAC address mask FFFF-0000-0000.
A time range-based ACL enables you to
implement ACL control over packets by differentiating the time ranges.
A time range can be specified in each rule
in an ACL. If the time range specified in a rule is not configured, the system
will give a prompt message and allow such a rule to be successfully created.
However, the rule does not take effect immediately. It takes effect only when
the specified time range is configured and the system time is within the time
range. If you remove the time range of an ACL rule, the ACL rule becomes
invalid the next time the ACL rule timer refreshes.
1.1.4
Types of ACLs Supported by the Ethernet Switch
The following types of ACLs are supported
by the Ethernet switch:
l
Basic ACL
l
Advanced ACL
l
Layer 2 ACL
l
User-defined ACL
A switch can only choose one ACL mode for
traffic flows, Layer 2 ACL mode or Layer 3 ACL mode. In Layer 2 ACL mode, only
Layer 2 ACL can be activated or imported by other applications, and Layer 3 ACL
is similar.
Table 1-1
Choose ACL mode for traffic flows
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Choose ACL mode
for traffic flows
|
acl
mode { ip-based |
link-based }
|
Required
By default, a
switch chooses ip-based ACL mode for traffic flows, that is, ACL
classifies the traffic flows based on Layer 3 information.
|
|
Display the ACL
mode for traffic flows
|
display
acl mode
|
Optional
The display command
can be executed in any view
|
This configuration is only effective on A type cards.
# Configure the ACL mode for traffic flows
as link-based.
<H3C>
system-view
[H3C] acl mode link-based
[H3C] display acl mode
The current acl mode: link-based.
The acl match-order { config | auto } command is used to set the matching
order of ACL rules when they are configured (before they are sent to a port).
While the acl order command is used to set the matching order of ACL
rules after they are configured (after they are sent to a port).The S7500
Switches support three matching orders of ACL rules sent to a port: depth-first,
first-config-first-match, and last-config-first match. You can
specify one of the three orders.
Table 1-2
Set the matching order of ACL rules sent to a port
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Set the matching order
of the configured ACL rules sent to a port
|
acl order {
auto | first-config-first-match | last-config-first-match
}
|
Required
By default, the
configured ACL rules sent to a port match in the depth-first order, that is, the auto mode.
|
|
Display the
traffic flows ACL mode
|
display acl order
|
Optional
The display command
can be executed in any view
|
# Specify the matching order of ACL rules
sent to a port as first-config-first-match.
<H3C>
system-view
[H3C] acl order
first-config-first-match
[H3C] display acl order
the current order is
first-config-first-match
A number of time sections can be configured
under the same time range name, and there is an “OR” relationship
among these sections.
The time range configuration tasks include
configuring periodic time sections and configuring absolute time sections. A
periodic time section appears as a period of time in a day of the week, while
an absolute time section appears in the form of “the start time to the
end time”.
Table 1-3 Configure a time range
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Create a time range
|
time-range time-name { start-time to end-time
days-of-the-week [ from start-time start-date ] [ to
end-time end-date ] | from start-time start-date [ to
end-time end-date ] | to end-time end-date }
|
Required
|
|
Display a time range or all the time
ranges
|
display time-range
{ all | time-name }
|
Optional
This command can be executed in
any view.
|
If only a periodic time section is defined
in a time range, the time range is active only within the defined periodic time
section.
If only an absolute time section is defined
in a time, the time range is active only within the defined absolute time
section.
If both a periodic
time section and an absolute time section are defined in a time range, the time
range is active only when the periodic time range and the absolute time range
are both matched. Assume that a time range defines an absolute time section
from 00:00 January 1, 2004 to 23:59 December 31, 2004, and a periodic time
section from 12:00 to 14:00 every Wednesday. This time range is active only
from 12:00 to 14:00 every Wednesday in 2004.
If the start time is specified, the time
range starts on the current date and ends on the end date.
If the end date is note specified, the time
range is from the date of configuration till the largest date available in the
system.
# Define a time range “test”
that will be active from 8:00 to 18:00 Monday through Friday.
<H3C> system-view
[H3C] time-range test 8:00 to 18:00
working-day
[H3C] display time-range test
Current time is
11:14:19 4-27-2006 Thursday
Time-range : test
( Active )
08:00 to 18:00 working-day
A basic ACL defines
rules only based on the L3 source IP addresses to analyze and process data
packets.
The value range for basic ACL numbers is
2,000 to 2,999.
Before configuring an ACL rule containing
time range arguments, you need to define the corresponding time ranges. For the
configuration of time ranges, refer to section 1.4 "Configuring Time Ranges”
The value of the
source IP address information in the rule has been defined.
Table 1-4 Define a basic ACL rule
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Create or enter basic ACL view
|
acl {
number acl-number | name acl-name [ advanced |
basic | link | user ] } [ match-order { config
| auto } ]
|
Required
By the default, the match order is config.
|
|
Define an rule
|
rule [ rule-id
] { permit | deny } [ source { source-addr
wildcard | any } | fragment | time-range time-name
]*
|
Required
|
|
Display ACL information
|
display acl config { all | acl-number | acl-name }
|
Optional
This command can be executed in
any view.
|
In the case that you specify the rule ID
when defining a rule:
l
If the rule corresponding to the specified rule
ID already exists, you will edit the rule, and the modified part in the rule
will replace the original content, while other parts remain unchanged.
l
If the rule corresponding to the specified rule
ID does not exists, you will create and define a new rule.
l
The content of a modified or created rule must
not be identical with the content of any existing rule; otherwise the rule
modification or creation will fail, and the system will prompt that the rule
already exists.
If you do not specify a rule ID, you will
create and define a new rule, and the system will assign an ID for the rule
automatically.
# Configure ACL 2000 to deny packets whose
source IP address is 1.1.1.1.
<H3C> system-view
[H3C] acl number 2000
[H3C-acl-basic-2000] rule deny source
1.1.1.1 0
[H3C-acl-basic-2000] display acl
config 2000
Basic ACL 2000, 1 rule
rule 0 deny source 1.1.1.1 0 (0 times
matched)
Advanced ACLs define classification rules
according to the source and destination IP addresses of packets, the type of
protocol over IP, and protocol-specific features such as TCP/UDP source and destination
ports, TCP flag bit, ICMP protocol type, code, and so on.
The value range for advanced ACL numbers is
3,000 to 3,999.
Advanced ACLs
support analysis and processing of three packet priority levels: type of
service (ToS) priority, IP priority and differentiated services codepoint
Priority (DSCP).
Using advanced ACLs, you can define
classification rules that are more accurate, more abundant, and more flexible
than those defined with basic ACLs.
Before configuring
an ACL rule containing time range arguments, you need to configure define the
corresponding time ranges. For the configuration of time ranges, refer to
section 1.4 "Configuring
Time Ranges”.
The values of source and destination IP
addresses, the type of the protocols carried by IP, and protocol-specific
features in the rule have been defined.
Table 1-5 Define an advanced ACL rule
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Create or enter advanced ACL view
|
acl {
number acl-number | name acl-name [ advanced |
basic | link | user ] } [ match-order { config
| auto } ]
|
Required
By the default, the match order is config.
|
|
Define an rule
|
rule [ rule-id
] { permit | deny } rule-string
|
Required
|
|
Display ACL information
|
display acl config { all | acl-number | acl-name }
|
Optional
This command can be executed in
any view.
|
rule-string:
rule information, which can be combination of the parameters described in Table 1-6. You must configure the protocol
argument in the rule information before you can configure other arguments.
Table 1-6 Rule
information
|
Parameter
|
Type
|
Function
|
Description
|
|
protocol
|
Protocol type
|
Type of protocol over IP
|
When expressed in numerals, the value
range is 1 to 255.
When expressed with a name, the value can
be GRE, ICMP, IGMP, IP, IPinIP, OSPF, TCP, and UDP.
|
|
source { sour-addr
sour-wildcard | any }
|
Source address information
|
Specifies the source address information
in the rule
|
sour-addr sour-wildcard is used to specify the source address of the packet, expressed in
dotted decimal notation.
any represents
all source addresses.
|
|
destination { dest-addr dest-wildcard | any }
|
Destination address information
|
Specifies the destination address
information in the rule
|
dest-addr dest-wildcard is used to specify the destination address of the packet,
expressed in dotted decimal notation.
any
represents all destination address.
|
|
precedence
precedence
|
Packet precedence
|
Packet priority
|
Value range: 0 to 7
|
|
tos tos
|
Packet precedence
|
ToS priority
|
Value range: 0 to 15
|
|
dscp dscp
|
Packet precedence
|
DSCP priority
|
Value range: 0 to 63
|
|
fragment
|
Fragment information
|
Specifies that the ACL rule is effective
for non-initial fragment packets
|
—
|
|
time-range
time-name
|
Time range information
|
Specifies the time range in which the ACL
rule is active
|
—
|
sour-wildcard and dest-wildcard represent the wildcards of the destination subnet
masks, provided in dotted decimal. For example, if you want to specify the
subnet mask as 255.255.0.0, you need to input 0.0.255.255. The wildcard can be
0, representing the host address.
To define DSCP priority, you can directly
input a value ranging from 0 to 63, or input a keyword listed in Table 1-7.
Table 1-7 Description
of DSCP values
|
Keyword
|
DSCP value in decimal
|
DSCP value in binary
|
|
ef
|
46
|
101110
|
|
af11
|
10
|
001010
|
|
af12
|
12
|
001100
|
|
af13
|
14
|
001110
|
|
af21
|
18
|
010010
|
|
af22
|
20
|
010100
|
|
af23
|
22
|
010110
|
|
af31
|
26
|
011010
|
|
af32
|
28
|
011100
|
|
af33
|
30
|
011110
|
|
af41
|
34
|
100010
|
|
af42
|
36
|
100100
|
|
af43
|
38
|
100110
|
|
cs1
|
8
|
001000
|
|
cs2
|
16
|
010000
|
|
cs3
|
24
|
011000
|
|
cs4
|
32
|
100000
|
|
cs5
|
40
|
101000
|
|
cs6
|
48
|
110000
|
|
cs7
|
56
|
111000
|
|
be (default)
|
0
|
000000
|
To define the IP precedence, you can directly input a value ranging
from 0 to 7, or input a keyword listed in the following table.
Table 1-8
Description of IP precedence value
|
Keyword
|
IP Precedence value in decimal
|
IP Precedence value in binary
|
|
|
routine
|
0
|
000
|
|
priority
|
1
|
001
|
|
immediate
|
2
|
010
|
|
flash
|
3
|
011
|
|
flash-override
|
4
|
100
|
|
critical
|
5
|
101
|
|
internet
|
6
|
110
|
|
network
|
7
|
111
|
|
|
|
|
|
|
To define the ToS
value, you can directly input a value ranging from 0 to 15, or input a keyword
listed in the following table.
Table 1-9
Description of ToS value
|
Keyword
|
ToS value in decimal
|
ToS value in binary
|
|
normal
|
0
|
0000
|
|
min-monetary-cost
|
1
|
0001
|
|
max-reliability
|
2
|
0010
|
|
max-throughput
|
4
|
0100
|
|
min-delay
|
8
|
1000
|
If the protocol type is TCP or UDP, you can
also define the following information:
Table 1-10 TCP/UDP-specific rule
information
|
Parameter
|
Type
|
Function
|
Description
|
|
source-port operator port1 [ port2 ]
|
Source
port(s)
|
Defines
the source port information of UDP/TCP packets
|
The value
of operator can be lt (less than), gt (greater than), eq (equal to),
neq (not equal to) or range (within the range of) Only the
“range” operator requires two port numbers as the operands, and
other operators require only one port number as the operand
port1 and port2: TCP/UDP port number(s), expressed with name(s)
or numerals; when expressed with numerals, the value range is 0 to 65,535
|
|
destination-port operator port1 [ port2 ]
|
Destination
port(s)
|
Defines
the destination port information of UDP/TCP packets
|
|
established
|
“TCP
connection established” flag
|
Specifies
that the rule is applicable only to the first SYN segment for establishing a
TCP connection
|
TCP-specific
argument
|
If the protocol type is ICMP, you can also
define the following information:
Table 1-11 ICMP-specific rule
information
|
Parameter
|
Type
|
Function
|
Description
|
|
icmp-type icmp-type
icmp-code
|
Type and message code information of ICMP
packets
|
Specifies the type and message code
information of ICMP packets in the ACL rule
|
icmp-type:
ICMP message type, ranging 0 to 255
icmp-code:
ICM |
