An access control list (ACL) is mainly used
for traffic classification. To filter data packets, a network device needs to
be configured with a series of ACLs to identify the packets to be filtered. A
network device can permit/deny specific packets in a predefined way only after
the traffic is classified.
ACLs classify packets using a series of
conditions known as rules. The conditions can be based on source addresses,
destination addresses and port numbers carried in the packets.
The rules of an ACL can be referenced by
other functions that need traffic classification, such as QoS.
According to their
application purposes, ACLs fall into the following four types.
l
Basic ACL. Rules are created based on Layer 3
source IP addresses only.
l
Advanced ACL. Rules are created based on the Layer
3 and Layer 4 information such as the source and destination IP addresses, the
type of the protocols carried by IP, protocol-specific features, and so on.
l
Layer 2 ACL. Rules are created based on the
Layer 2 information such as source and destination MAC addresses, VLAN priorities,
Layer 2 protocols, and so on.
l
User-defined ACL. An ACL of this type matches
packets by comparing specific strings retrieved from the packets with specified
strings.
ACL can also be used to filter and classify
the packets to be processed by software. In this case, the rules in an ACL can
be matched in one of the following two ways:
l
config, where rules in an ACL are matched in the order defined by the user.
l
auto, where the
rules in an ACL are matched in the order determined by the system, namely the “depth-first” order.
When applying ACLs in this way, you can
specify the order in which the rules in the ACL are matched. The matching order
cannot be modified once it is determined unless you delete all the rules in the
ACL.
An ACL is referenced by an upper-layer
module when it is
l
Referenced by route policies
l
Used to control login users
An ACL can contain multiple rules, each of which
matches specific type of packets. So the order in which the rules of an ACL are
matched needs to be determined.
The order in which the rules of an ACL are
matched can be:
l
The order the rules are created.
l
The order determined by the system. In this
case, the rues are matched according to the “depth-first” rule.
With the depth-first rule adopted, the
rules of an ACL are matched according to:
1)
Protocol range. The range for IP is 1 to 255 and
those of other protocols are their 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, the weighting
principles will be used in deciding their priority order, as listed below.
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.
A time range-based ACL takes effect only in
specified time ranges.
You can specify a time range for each rule
in an ACL. An ACL rule cannot take effect if you do not configure the time
range for it. It takes effect only when the 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 after 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 time range can contain multiple time sections
in a time range. The time sections in an ACL are of the logical OR relationship.
A time section can be periodic or absolute.
A periodic time section is defined by specifying days of a week, while an
absolute time section is defined by specifying the start time and the end time.
Table 1-1 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 when the system time within the
defined periodic time section.
If only an absolute time section is defined
in a time range, the time range is active only when the system time 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 contains an absolute time section ranging
from 00:00 January 1, 2004 to 23:59 December 31, 2004, and a periodic time
section ranging from 12:00 to 14:00 on every Wednesday. This time range is
active only when the system time within the range from 12:00 to 14:00 on every
Wednesday in 2004.
If the start time is not specified, the
time section starts on the current date and ends on the end date.
If the end date is not specified, the time section
ends on the most forward time the system can hold.
# Define a time range that will be active
from 8:00 to 18:00 on 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 13:27:32 4/16/2005
Saturday
Time-range : test ( Inactive )
08:00 to 18:00 working-day
A basic ACL filters
packets based on their Layer 3 source IP addresses.
A basic ACL can be numbered from 2000 to
2999.
To configure a time range-based basic ACL
rule, you need to create the corresponding time range first. For information
about time range configuration, refer to section 1.2 “Time Range Configuration”.
The source IP
addresses based on which the ACL filters packets are determined.
Table 1-2 Define a basic ACL rule
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Create an ACL or enter basic ACL view
|
acl number
acl-number [ match-order { config | auto } ]
|
By the default, the matching order is config.
|
|
Define an ACL rule
|
rule [ rule-id
] { permit | deny } [ fragment | source {
sour-addr sour-wildcard | any } | time-range time-name ]*
|
Required
|
|
Assign a description string to the ACL
|
description text
|
Optional
|
|
Display the information about an ACL or
all the ACLs
|
display acl
{ all | acl-number }
|
Optional
This command can be executed in
any view.
|
When you define an ACL rule using the rule
command with the rule-id argument provided,
l
If the ACL rule identified by the rule-id
argument already exists, the settings specified in the rule command
overwrite the corresponding settings of the existing rule. And the existing
settings remain unchanged if the corresponding settings are not specified in
the command.
l
If the ACL rule identified by the rule-id
argument does not exist, you will create a new rule.
l
The content of a modified or created rule cannot
be identical with the content of any existing rules; otherwise the rule
modification or creation will fail, and the system prompts that the rule
already exists.
If you do not specify the rule-id
argument when creating an ACL rule, the rule will be numbered automatically.
# Configure ACL 2000 to deny packets whose
source IP addresses are 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 2000
Basic ACL 2000, 1 rule
Acl's step is 1
rule 0 deny source 1.1.1.1 0
An advanced ACL can filter packets by their
source and destination IP addresses, the protocols carried by IP. The rules in
an advanced ACL rule can based on protocol-specific features such as TCP/UDP
source and destination ports, TCP flag bit, ICMP protocol type, code, and so
on.
An advanced ACL can be numbered from 3000
to 3999.
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 for basic ACLs.
To configure an time
range-based advanced ACL rule, you need to create the corresponding time ranges
first. For information about of time range configuration, refer to section 1.2 “Time Range Configuration”.
The settings to be specified in the rule,
such as source and destination IP addresses, the protocols carried by IP, and
protocol-specific features, are determined.
Table 1-3 Define an advanced ACL rule
|
Operation
|
Command
|
Description
|
|
Enter system view
|
system-view
|
—
|
|
Create an advanced VLAN or enter advanced
ACL view
|
acl number
acl-number [ match-order { config | auto } ]
|
By the default, the match order is config.
|
|
Define an ACL rule
|
rule [ rule-id
] { permit | deny } rule-string
|
Required
|
|
Assign a description string to the ACL
rule
|
rule rule-id
comment text
|
Optional
|
|
Assign a description string to the ACL
|
description text
|
Optional
|
|
Display the information about an ACL or
all the ACLs
|
display acl
{ all | acl-number }
|
Optional
This command can be executed in
any view.
|
The rule-string argument of the rule
command listed in Table 1-3 can be a combination of the argument/keywords described in Table 1-4. Note that the rule-string argument must begin with the protocol argument.
Table 1-4 Description
on the argument/keywords used in the rule-string argument
|
Arguments/Keywords
|
Type
|
Function
|
Description
|
|
protocol
|
Protocol type
|
Type of the protocols carried by IP
|
When expressed in numerals, this argument
ranges from 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
|
Specifies the source address information for
the ACL rule
|
The sour-addr sour-wildcard arguments specify the source address of the packets, expressed in
dotted decimal notation. You can specify the IP address of a host as the
source address by providing 0 for the sour-wildcard argument.
any
represents any source address.
|
|
destination { dest-addr dest-wildcard | any }
|
Destination address
|
Specifies the destination address
information for the ACL rule
|
The dest-addr dest-wildcard arguments specify the destination address of the packets,
expressed in dotted decimal notation. You can specify the IP address of a host
as the destination address by providing 0 for the dest-wildcard
argument.
any
represents any destination address.
|
|
precedence
precedence
|
Packet priority
|
IP precedence
|
The precedence argument ranges
from 0 to 7.
|
|
tos tos
|
Packet priority
|
ToS
|
The tos argument ranges from 0 to
15.
|
|
dscp dscp
|
Packet priority
|
DSCP
|
The dscp argument ranges from 0 to
63.
|
|
fragment
|
Fragment information
|
Specifies that the rule is effective for the
packets that are not the first fragments.
|
—
|
|
time-range
time-name
|
Time range information
|
Specifies the time range in which the
rule is active.
|
—
|
If you specify the dscp keyword, you
can directly input a value ranging from 0 to 63 or input one of the keywords
listed in Table 1-5 as the DSCP.
Table 1-5 DSCP
values and the corresponding keywords
|
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
|
If you specify the precedence
keyword, you can directly input a value ranging from 0 to 7 or input one of the
keywords listed in Table
1-6 as the IP precedence.
Table 1-6 IP precedence values and the
corresponding keywords
|
Keyword
|
IP Precedence in decimal
|
IP Precedence 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
|
If you specify the tos keyword, you
can directly input a value ranging from 0 to 15 or input one of the keywords
listed in Table 1-7 as the ToS value.
Table 1-7 ToS value and the
corresponding keywords
|
Keyword
|
ToS in decimal
|
ToS 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 information listed in Table 1-8.
Table 1-8 TCP/UDP-specific
ACL rule information
|
Parameter
|
Type
|
Function
|
Description
|
|
source-port operator port1 [ port2 ]
|
Source
port
|
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. Other
operators require only one port number as the operand.
port1 and port2: TCP/UDP port numbers, expressed as port names
or port numbers. When expressed as numbers, the value range is 0 to 65535.
|
|
destination-port operator port1 [ port2 ]
|
Destination port
|
Defines the destination port information
of UDP/TCP packets
|
|
established
|
TCP connection flag
|
Specifies that the rule applies to TCP
packets with the ack or rst flag (Packets of this type are TCP
connection packets.)
|
TCP-specific argument
|
If the protocol
type is ICMP, you can also define the information listed in Table 1-9.
Table 1-9 ICMP-specific
ACL 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 rule
|
icmp-type:
ICMP message type, ranging from 0 to 255
icmp-code:
ICMP message code, ranging from 0 to 255
|
If the protocol
type is ICMP, you can also just input the ICMP message name after the icmp-type
keyword. Table 1-10 lists some common ICMP messages.
Table 1-10 ICMP messages
|
Name
|
ICMP type
|
ICMP code
|
|
echo
|
Type=8
|
Code=0
|
|
echo-reply
|
Type=0
|
Code=0
|
|
fragmentneed-DFset
|
Type=3
|
Code=4
|
|
host-redirect
|
Type=5
|
Code=1
|
|
host-tos-redirect
|
Type=5
|
Code=3
|
|
host-unreachable
|
Type=3
|
Code=1
|
|
information-reply
|
Type=16
|
Code=0
|
|
information-request
|
Type=15
|
Code=0
|
|
net-redirect
|
Type=5
|
Code=0
|
|
net-tos-redirect
|
Type=5
|
Code=2
|
|
net-unreachable
|
Type=3
|
Code=0
|
|
parameter-problem
|
Type=12
|
Code=0
|
|
port-unreachable
|
Type=3
|
Code=3
|
|
protocol-unreachable
|
Type=3
|
Code=2
|
|
reassembly-timeout
|
Type=11
|
Code=1
|
|
source-quench
|
Type=4
|
Code=0
|
|
source-route-failed
|
Type=3
|
Code=5
|
|
timestamp-reply
|
Type=14
|
Code=0
|
|
timestamp-request
|
Type=13
|
Code=0
|
|
ttl-exceeded
|
Type=11
|
Code=0
|
When you define an ACL rule using the rule
command with the rule-id argument provided,
l
If the ACL rule identified by the rule-id
argument already exists, the settings specified in the rule command
overwrite the corresponding settings of the existing rule. And the existing
settings remain unchanged if the corresponding settings are not specified in
the command.
l
If the ACL rule identified by the rule-id
argument does not exist, you will create a new rule.
l
The content of a modified or created rule cannot
be identical with the content of any existing rules; otherwise the rule
modification or creation will fail, and the system prompts that the rule
already exists.
If you do not specify the rule-id
argument when creating an ACL rule, the rule will be numbered automatically.
# Configure ACL 3000 to permit the packets sourced
from the network 129.9.0.0 and destined for the network 202.38.160.0 and with
the destination port number being 80.
<H3C>system-view
[H3C] acl number 3000
[H3C-acl-adv-3000] rule permit tcp
source 129.9.0.0 0.0.255.255 destination 202.38.160.0 0.0.0.255
destination-port eq 80
[H3C-acl-adv-3000] display acl 3000
Advanced ACL 3000, 1 rule
Acl's step is 1
rule 0 permit tcp source 129.9.0.0
0.0.255.255 destination 202.38.160.0 0.0.0.255 destination-port eq www
Layer 2 ACLs filter
packets according to their Layer 2 information, such as the source and
destination MAC addresses, VLAN priority, and Layer 2 protocol types.
A Layer 2 ACL can be numbered from 4000 to
4999.
To configure a time range-based Layer 2 ACL
rule, you need to create the corresponding time ranges first. For information
about time range configuration, refer to section 1.2 “Time Range Configuration”.
The settings to be
specified in the rule, such as source and destination MAC addresses, VLAN
priorities, and Layer 2 protocol types, are determined.
Table 1-11 Define a Layer 2 ACL rule
