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.
I. Applied to the hardware
directly
In the switch, an ACL can be directly applied
to the hardware for packet filtering and traffic classification. In this case, the
rules in an ACL are matched in the order determined by the hardware instead of
that defined in the ACL.
ACLs are directly applied to hardware when
they are used for:
l
Implementing QoS
l
Filtering the packets to be forwarded
II. Referenced by upper-level
modules
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 rules 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, 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 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.
An absolute time
range on an H3C S5600 switch can be within the range 1970/1/1 00:00 to
2100/12/31 24:00.
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
|
Note that:
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 multiple periodic time sections are defined
in a time range, the time range is active only when the system time is within
one of the periodic time sections.
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 multiple absolute
time sections are defined in a time range, the time range is active only when
the system time is within one of the absolute time sections.
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 earliest date available in the system and ends on
the specified end date. If the end date is not specified, the time section
starts from the specified start date to 2100/12/31 23:59.
# Define a periodic 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
# Define an absolute time range from 15:00
1/28/2000 to 15:00 1/28/2004.
<H3C> system-view
[H3C] time-range test from 15:00
1/28/2000 to 15:00 1/28/2004
[H3C] display time-range test
Current time is 13:30:32 4/16/2005
Saturday
Time-range : test ( Inactive )
From 15:00 Jan/28/2000 to 15:00
Jan/28/2004
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
|
When you define an ACL rule using the rule
command with the rule-id argument provided,
l
If the ACL is created with the config
keyword specified and the rule identified by the rule-id argument
exists, the settings specified in the rule command overwrite the
counterparts of the existing rule (other settings of the rule remain
unchanged). If the ACL is created with the auto keyword specified, the
rules of the ACL cannot be edited. In this case, the system prompts errors when
you execute the rule 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, ICMP protocol type, code, and so on.
An advanced ACL can be numbered from 3000
to 3999. Note that ACL 3998 and ACL 3999 cannot be
configured because they are reserved for the cluster management.
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
|
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 is applicable
only to the first SYN segment for establishing a TCP connection
|
TCP-specific argument
|
When using port name to specify TCP/UDP
ports, you can define the following information.
Table 1-9 TCP/UDP port values
|
Protocol type
|
Value
|
|
TCP
|
CHARgen
(19), bgp (179), cmd (514), daytime (13), discard
(9), domain (53), echo (7), exec (512), finger
(79), ftp (21), ftp-data (20), gopher (70), hostname
(101), irc (194), klogin (543), kshell (544), login
(513), lpd (515), nntp (119), pop2 (109), pop3
(110), smtp (25), sunrpc (111), tacacs (49), talk
(517), telnet (23), time (37), uucp (540), whois
(43), www (80)
|
|
UDP
|
biff (512),
bootpc (68), bootps (67), discard (9), dns (53), dnsix
(90), echo (7), mobilip-ag (434), mobilip-mn (435), nameserver
(42), netbios-dgm (138), netbios-ns (139), netbios-ssn (139),
ntp (123), rip (520), snmp (161), snmptrap (162),
sunrpc (111), syslog (514), tacacs-ds (65), talk
(517), tftp (69), time (37), who (513), xdmcp (177)
|
When advanced ACLs
are applied to ports of the H3C S5600 series Ethernet switches, only the rules configured
with the operator argument specified as eq are valid.
If the protocol
type is ICMP, you can also define the information listed in Table 1-10.
Table 1-10
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-11 lists some common ICMP messages.
Table 1-11
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
|
