- Table of Contents
- Related Documents
-
Title | Size | Download |
---|---|---|
02-ACL Configuration | 204.75 KB |
Table of Contents
1.1.4 Effective Period of an IPv4 ACL
1.1.5 IP Fragments Filtering with IPv4 ACL
1.2.4 Effective Period of an IPv4 ACL
Chapter 2 IPv4 ACL Configuration
2.2 Configuring a Basic IPv4 ACL
2.2.1 Configuration Prerequisites
2.3 Configuring an Advanced IPv4 ACL
2.3.1 Configuration Prerequisites
2.4 Configuring an Ethernet Frame Header ACL
2.4.1 Configuration Prerequisites
2.5 Configuring a User-Defined ACL
2.5.1 Configuration Prerequisites
2.6 Displaying and Maintaining IPv4 ACLs
2.7 IPv4 ACL Configuration Examples
2.7.1 IPv4 ACL Configuration Examples
Chapter 3 IPv6 ACL Configuration
3.2 Configuring a Basic IPv6 ACL
3.2.1 Configuration Prerequisites
3.3 Configuring an Advanced IPv6 ACL
3.3.1 Configuration Prerequisites
3.4 Displaying and Maintaining IPv6 ACLs
3.5 IPv6 ACL Configuration Examples
3.5.1 IPv6 Configuration Examples
Chapter 4 Flow Template Configuration
4.1 Configuring a Flow Template
4.2 Displaying and Maintaining Flow Templates
4.3 Flow Template Configuration Examples
Chapter 1 ACL Overview
& Note:
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. One way to implement packet switching is to use access control lists (ACLs).
An ACL is a set of rules (or a set of permit or deny statements) for determining which packets can pass and which should be rejected based on matching criteria such as source address, destination address, and port number. ACLs are widely used in technologies where traffic identification is desired, such as QoS.
This chapter covers these topics:
l IPv4 ACL
l IPv6 ACL
1.1 IPv4 ACL
This section covers these topics:
l Effective Period of an IPv4 ACL
l IP Fragments Filtering with IPv4 ACL
1.1.1 IPv4 ACL Classification
IPv4 ACLs, identified by ACL numbers, fall into the following four categories:
l Basic IPv4 ACL, based on source IP address. Basic ACLs are numbered 2000 through 2999.
l Advanced IPv4 ACL, based on source IP address, destination IP address, protocol carried on IP, and other Layer 3 or Layer 4 protocol header information. Advanced ACLs are numbered 3000 through 3999.
l Ethernet frame header ACL, based on Layer 2 protocol header fields such as source MAC address, destination MAC address, 802.1p priority, and data link layer protocol type. Ethernet frame header ACLs are numbered 4000 through 4999.
l User-defined ACL, based on customized information of protocol headers such as IP and MPLS. User-defined ACLs are numbered 5000 through 5999.
1.1.2 IPv4 ACL Match Order
Each ACL is a sequential collection of rules defined with different matching criteria. The rules may be repeated or contradictory. The ACL match order determines how a packet is matched against the rules.
At present, the following two match orders are available:
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.
I. Depth-first match for a basic IPv4 ACL
The following shows how your device performs depth-first match in a basic IPv4 ACL:
1) Sort rules by VPN instance first and compare packets against the rule configured with a VPN instance.
2) In case of a tie, 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.
3) 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.
II. Depth-first match for an advanced IPv4 ACL
The following shows how your device performs depth-first match in an advanced IPv4 ACL:
1) Sort rules by VPN instance first and compare packets against the rule configured with a VPN instance prior to other rules.
2) If two rules are present with VPN instances, look at the protocol range in addition. Then compare packets against the rule with the protocol carried on IP specified prior to the other.
3) 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.
4) If two rules are present with the same number of zeros in their source IP address wildcards, look up the destination IP address wildcards in the rules. Then, compare packets against the rule configured with more zeros in the destination IP address wildcard prior to the other.
5) If the numbers of zeros in the destination IP address wildcards are the same, compare packets against the rule configured with a lower Layer 4 port number prior to the other.
6) If the Layer 4 port numbers are the same, compare packets against the rule configured first prior to the other.
III. Depth-first match for an Ethernet frame header IPv4 ACL
The following shows how your device 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 up 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, compare packets against the rule configured first prior to the other.
& Note:
The match order for a user-defined ACL can only be config.
The comparison of a packet against an ACL stops once a match is found. The packet is then processed as per the rule.
1.1.3 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 5, 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 5, you can insert a rule numbered 1.
1.1.4 Effective Period of an IPv4 ACL
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.
1.1.5 IP Fragments Filtering with IPv4 ACL
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.
To address the risk, the following packet filtering functions are delivered:
l IP-based filtering on all fragments.
l Standard match and exact match for ACLs containing advanced information such as TCP/UDP port number and ICMP type. The default approach is standard match.
& Note:
l Standard match considers only Layer 3 information.
l Exact match considers all header information defined in ACL rules.
1.2 IPv6 ACL
This section covers these topics:
l Effective Period of an IPv4 ACL
1.2.1 IPv6 ACL Classification
IPv6 ACLs, identified by ACL numbers, fall into the following three categories:
l Basic IPv6 ACL, based on source IPv6 address. Basic IPv6 ACLs are numbered 2000 through 2999.
l Advanced IPv6 ACL, based on source IPv6 address, destination IPv6 address, protocol carried on IPv6, and other Layer 3 or Layer 4 protocol header fields. Advanced ACLs are numbered 3000 through 3999.
1.2.2 IPv6 ACL Match Order
Similar to IPv4 ACLs, each IPv6 ACL is a sequential collection of rules defined with different matching criteria, and the rules may be repeated or contradictory. The ACL match order determines how a packet is matched against the rules.
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 device 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 device 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 the source IPv6 address wildcards 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.2.3 IPv6 ACL Step
Refer to IPv4 ACL Step.
1.2.4 Effective Period of an IPv4 ACL
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 Configuring a Basic IPv4 ACL
l Configuring an Advanced IPv4 ACL
l Configuring an Ethernet Frame Header ACL
l Configuring a User-Defined ACL
l Displaying and Maintaining IPv4 ACLs
l IPv4 ACL Configuration Examples
2.1 Creating a Time Range
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 |
Display the configuration and state of a specified or all time ranges |
display time-range { all | time-name } |
Optional Available in any view |
A time range can be one of the following:
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.
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.
2.1.2 Configuration Example
# Create a 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 13:27:32 4/16/2005 Saturday
Time-range : test ( Inactive )
08:00 to 18:00 working-day
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.
2.2.1 Configuration Prerequisites
If you want to reference a time range to a rule, define it with the time-range command first.
2.2.2 Configuration Procedure
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 [ match-order { auto | config } ] |
Required The default match order is config. |
Create or modify a rule |
rule [ rule-id ] { deny | permit } [ fragment | logging | source { sour-addr sour-wildcard | any } | time-range time-name | vpn-instance vpn-instance-name ] * |
Required To create multiple rules, repeat this step. |
Set a rule numbering step |
step step-value |
Optional The default step is 5. |
Create an IPv4 ACL description |
description text |
Optional A basic IPv4 ACL has no description by default. |
Create a rule description |
rule rule-id comment text |
Optional A rule has no description by default. |
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 order rather than by rule number.
Caution:
l You can modify the match order of an ACL with the acl number acl-number 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.
l For common LPUs, matching packets against an ACL rule with the vpn-instance keyword or the logging keyword specified is not supported.
2.2.3 Configuration Example
# 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, 1 rule,
ACL's step is 5
rule 0 deny source 1.1.1.1 0 (5 times matched)
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, TCP flag, 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.
2.3.1 Configuration Prerequisites
If you want to reference a time range to a rule, define it with the time-range command first.
2.3.2 Configuration Procedure
Follow these steps to configure an advanced IPv4 ACL:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
–– |
Create and enter advanced IPv4 ACL view |
acl number acl-number [ match-order { auto | config } ] |
Required The default match order is config. |
Create or modify a rule |
rule [ rule-id ] { deny | permit } protocol [ destination { dest-addr dest-wildcard | any } | destination-port operator port1 [ port2 ] | dscp dscp | established | 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-name | tos tos | vpn-instance vpn-instance-name ] * |
Required To create multiple rules, repeat this step. |
Set a rule numbering step |
step step-value |
Optional The default step is 5. |
Create an IPv4 ACL description |
description text |
Optional An advanced IPv4 ACL has no description by default. |
Create a rule description |
rule rule-id comment text |
Optional A rule has no description by default. |
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 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.
l For common LPUs, matching packets against an ACL rule with the vpn-instance, logging, or reflective keyword specified is not supported.
2.3.3 Configuration Example
# Create IPv4 ACL 3000, permitting TCP packets with port number 80 sent from 129.9.0.0 to 202.38.160.0 to pass.
<Sysname> system-view
[Sysname] acl number 3000
[Sysname-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
# Verify the configuration.
[Sysname-acl-adv-3000] display acl 3000
Advanced ACL 3000, 1 rule,
ACL's step is 5
rule 0 permit tcp source 129.9.0.0 0.0.255.255 destination 202.38.160.0 0.0.2.255 destination-port eq www (5 times matched)
2.4 Configuring an Ethernet Frame Header ACL
Ethernet frame header ACLs filter packets based on Layer 2 protocol header fields such as source MAC address, destination MAC address, 802.1p priority, and link layer protocol type. They are numbered in the range 4000 to 4999.
2.4.1 Configuration Prerequisites
If you want to reference a time range to a rule, define it with the time-range command first.
2.4.2 Configuration Procedure
Follow these steps to configure an Ethernet frame header ACL:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
–– |
Create and enter Ethernet frame header ACL view |
acl number acl-number [ match-order { auto | config } ] |
Required The default match order is config. |
Create or modify a rule |
rule [ rule-id ] { deny | permit } [ cos vlan-pri | dest-mac dest-addr dest-mask | lsap lsap-code lsap-wildcard | source-mac sour-addr source-mask | time-range time-name | type type-code type-wildcard ] * |
Required To create multiple rules, repeat this step. |
Set a rule numbering step |
step step-value |
Optional The default step is 5. |
Create an ACL description |
description text |
Optional An Ethernet frame header ACL has no description by default. |
Create a rule description |
rule rule-id comment text |
Optional A rule has no description by default. |
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 order rather than by rule number.
Caution:
l You can modify the match order of an ACL with the acl number acl-number 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.
l When you create an Ethernet frame header ACL, do not specify the LSAP keyword or set the type-code argument to 0x0800, 0x86DD, 0x8847, 0x8848, or 0x8100.
l For the default flow template to be used, the destination mask corresponding to the type keyword must be 0xFFFF.
2.4.3 Configuration Example
# Create IPv4 ACL 4000 to deny frames with the 802.1p priority of 3.
<Sysname> system-view
[Sysname] acl number 4000
[Sysname-acl-ethernetframe-4000] rule deny cos 3
# Verify the configuration.
[Sysname-acl-ethernetframe-4000] display acl 4000
Ethernet frame ACL 4000, 1 rule,
ACL's step is 5
rule 0 deny cos excellent-effort(5 times matched)
2.5 Configuring a User-Defined ACL
User-defined ACLs allow you to customize rules based on information of protocol headers such as IP. When defining a user-defined ACL rule, you need to specify an offset in bytes on which a match operation should start from the beginning of a packet header and in addition, specify a mask. When comparing a packet against the rule, the system ANDs the mask with the corresponding bytes in the packet and compare the result with the rule.
User-defined ACLs are numbered in the range 5000 to 5999.
2.5.1 Configuration Prerequisites
If you want to reference a time range to a rule, define it with the time-range command first.
2.5.2 Configuration Procedure
Follow these steps to configure a user-defined IPv4 ACL:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
–– |
Create and enter user-defined IPv4 ACL view |
acl number acl-number |
Required |
Create or modify a rule |
rule [ rule-id ] { deny | permit } [ { ipv4 | ipv6 | l2 | l4 | l5 ] rule-string rule-mask offset }&<1-8> ] [ time-range time-name ] |
Required To create multiple rules, repeat this step. |
Create an ACL description |
description text |
Optional A user-defined IPv4 ACL has no description by default. |
Create a rule description |
rule rule-id comment text |
Optional A rule has no description by default. |
Note that:
l You will fail to create a user-defined ACL rule if its permit/deny statement is exactly the same as another rule. Unlike other types of ACLs, however, you can modify a user-defined ACL rule.
l For a user-defined ACL, the match order can only be config.
l For D-type boards, matching packets against a user-defined ACL that the offset is set from the beginning of the Layer 5 header is not supported.
The rule specified in the rule comment command must have existed.
2.5.3 Configuration Example
# Configure user-defined ACL 5500, permitting any packet whose 13th and 14th bytes starting from the Layer 2 header are 0x0806 (that is, ARP packets) in time range t1.
<Sysname> system-view
[Sysname] acl number 5500
[Sysname-acl-user-5500] rule 0 permit l2 0806 ffff 12 time-range t1
# Verify the configuration.
[Sysname-acl-user-5500] display acl 5500
User defined ACL 5500, 1 rule,
ACL's step is 5
rule 0 permit l2 0806 ffff 12 time-range t1 (Active)
2.6 Displaying and Maintaining IPv4 ACLs
To do... |
Use the command… |
Remarks |
Display information about a specified or all IPv4 ACLs |
display acl { acl-number | all | name acl-name } |
Available in any view |
Display the configuration and state of a specified or all time ranges |
display time-range { time-name | all } |
Available in any view |
Clear the statistics about the specified or all IPv4 ACLs except for user-defined IPv4 ACLs |
reset acl counter { acl-number | all} |
Available in user view |
2.7 IPv4 ACL Configuration Examples
2.7.1 IPv4 ACL Configuration Examples
I. Network Requirements
A company interconnects its departments through the Device. The President’s Office uses IP address 129.111.1.2; the salary server of the Finance Department uses IP address 129.110.1.2.
II. Network Diagram
Figure 2-1 Network diagram for ACL configuration
III. Configuration Procedure
1) Create a time range for office hours
# Create a periodic time range spanning 8:00 to 18:00 in working days.
<Sysname> system-view
[Sysname] time-range trname 8:00 to 18:00 working-day
2) Define an ACL to control accesses to the salary server
# Create and enter the view of ACL 3000.
[Sysname] acl number 3000
# Create a rule to control access of the President’s Office to the salary server.
[Sysname-acl-adv-3000] rule 1 permit ip source 129.111.1.2 0.0.0.0
[Sysname-acl-adv-3000] quit
# Create a rule to control accesses of other departments to the salary server.
[Sysname] acl number 3001
[Sysname-acl-adv-3001] rule 1 deny ip source any destination 129.110.1.2 0.0.0.0 time-range trname
[Sysname-acl-adv-3001] quit
3) Define and apply a QoS policy on interfaces
# Configure traffic classification rules and traffic behaviors.
[Sysname] traffic classifier test_permit
[Sysname-classifier-test_permit] if-match acl 3000
[Sysname-classifier-test_permit] quit
[Sysname] traffic behavior test_permit
[Sysname-behavior-test_permit] filter permit
[Sysname-behavior-test_permit] quit
[Sysname] traffic classifier test_deny
[Sysname-classifier-test_deny] if-match acl 3001
[Sysname-classifier-test_deny] quit
[Sysname] traffic behavior test_deny
[Sysname-behavior-test_deny] filter deny
[Sysname-behavior-test_deny] quit
# Configure a QoS policy.
[Sysname] qos policy test
[Sysname-qospolicy-test] classifier test_permit behavior test_permit
[Sysname-qospolicy-test] classifier test_deny behavior test_deny
[Sysname-qospolicy-test] quit
# Apply the QoS policy at the inbound direction of Ethernet 3/1/1, Ethernet 3/1/2 and Ethernet 3/1/3.
[Sysname] interface Ethernet 3/1/1
[Sysname-Ethernet3/1/1] qos apply policy test inbound
[Sysname-Ethernet3/1/1] quit
[Sysname] interface Ethernet 3/1/2
[Sysname-Ethernet3/1/2] qos apply policy test inbound
[Sysname-Ethernet3/1/2] quit
[Sysname] interface Ethernet 3/1/3
[Sysname-Ethernet3/1/3] qos apply policy test inbound
[Sysname-Ethernet3/1/3] quit
Chapter 3 IPv6 ACL Configuration
When configuring IPv6 ACLs, go to these sections for information you are interested in:
l Configuring a Basic IPv6 ACL
l Configuring an Advanced IPv6 ACL
l Displaying and Maintaining IPv6 ACLs
l IPv6 ACL Configuration Examples
3.1 Creating a Time Range
Refer to section Creating a Time Range
3.2 Configuring a Basic IPv6 ACL
Basic IPv6 ACLs filter packets based on source IPv6 address. They are numbered in the range 2000 to 2999.
3.2.1 Configuration Prerequisites
If you want to reference a time range to a rule, define it with the time-range command first.
3.2.2 Configuration Procedure
Follow these steps to configure an IPv6 ACL:
To do… |
Use the command… |
|
Enter system view |
system-view |
–– |
Create and enter basic IPv6 ACL view |
acl ipv6 number acl6-number [ match-order { auto | config } ] |
Required The default match order is config. |
Create or modify a rule |
rule [ rule-id ] { deny | permit } [ fragment | logging | source { ipv6-address prefix-length | ipv6-address/prefix-length | any } | time-range time-name ] * |
Required To create multiple rules, repeat this step. |
Set a rule numbering step |
step step-value |
Optional The default step is 5. |
Create an IPv6 ACL description |
description text |
Optional A basic IPv6 ACL has no description by default. |
Create a rule description |
rule rule-id comment text |
Optional A rule has no description by default. |
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 ipv6 command to verify rules configured in an ACL. If the match order for this IPv6 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 IPv6 ACL with the acl ipv6 number acl6-number 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.
3.2.3 Configuration Example
# Create IPv6 ACL 2000 to deny IPv6 packets with source address FE80:5060::8050/96.
<Sysname> system-view
[Sysname] acl ipv6 number 2000
[Sysname-acl6-basic-2000] rule deny source fe80:5060::8050/96
# Verify the configuration.
[Sysname-acl6-basic-2000] display acl ipv6 2000
Basic IPv6 ACL 2000, 1 rules,
ACL’s step is 5
rule 0 deny source FE80:5060::8050/96 (5 times matched)
3.3 Configuring an Advanced IPv6 ACL
Advanced ACLs filter packets based on the source IPv6 address, destination IPv6 address, protocol carried on IPv6, and other protocol header fields such as the TCP/UDP source port, TCP/UDP destination port, ICMP message type, and ICMP message code.
Advanced IPv6 ACLs are numbered in the range 3000 to 3999. Compared with basic IPv6 ACLs, they allow of more flexible and accurate filtering.
3.3.1 Configuration Prerequisites
If you want to reference a time range to a rule, define it with the time-range command first.
3.3.2 Configuration Procedure
Follow these steps to configure an advanced IPv6 ACL:
To do… |
Use the command… |
Remarks |
Enter system view |
system-view |
–– |
Create and enter advanced IPv6 ACL view |
acl ipv6 number acl6-number [ match-order { auto | config } ] |
Required The default match order is config. |
Create or modify a rule |
rule [ rule-id ] { deny | permit } protocol [ destination { dest dest-prefix | dest/dest-prefix | any } | destination-port operator port1 [ port2 ] | dscp dscp | fragment | icmpv6-type { icmpv6-type icmpv6-code | icmpv6-message } | logging | source { source source-prefix | source/source-prefix | any } | source-port operator port1 [ port2 ] | time-range time-name ] * |
Required To create multiple rules, repeat this step. |
Set a rule numbering step |
step step-value |
Optional The default step is 5. |
Create an ACL description |
description text |
Optional An advanced IPv6 ACL has no description by default. |
Create a rule description |
rule rule-id comment text |
Optional A rule has no description by default. |
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 ipv6 command to verify rules configured in an IPv6 ACL. If the match order for this IPv6 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 IPv6 ACL with the acl ipv6 number acl6-number 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.
l When creating an IPv6 ACL rule, you cannot specify the fragment keyword and the protocol argument at the same time.
3.3.3 Configuration Example
# Create IPv6 ACL 3000 to permit the TCP packets with the source address 2030:5060::9050/64 to pass.
<Sysname> system-view
[Sysname] acl ipv6 number 3000
[Sysname-acl6-adv-3000] rule permit tcp source 2030:5060::9050/64
# Verify the configuration.
[Sysname-acl6-adv-3000] display acl ipv6 3000
Advanced IPv6 ACL 3000, 1 rule,
ACL's step is 5
rule 0 permit tcp source 2030:5060::9050/64 (5 times matched)
3.4 Displaying and Maintaining IPv6 ACLs
To do… |
Use the command… |
Remarks |
Display information about a specified or all IPv6 ACLs |
display acl ipv6 { acl6-number | all | name acl6-name } |
Available in any view |
Display the configuration and status about the specified or all time ranges |
display time-range { time-name | all } |
Available in any view |
Clear the statistics about a specified or all IPv6 ACLs |
reset acl ipv6 counter { acl6-number | all } |
Available in user view |
3.5 IPv6 ACL Configuration Examples
3.5.1 IPv6 Configuration Examples
I. Network Requirements
II. Configuration Procedure
# Enter system view.
<Sysname> system-view
# Create an ACL rule, permitting the packets with the source IP addresses in the range 4050::9000 to 4050::90FF.
[Sysname] acl ipv6 number 2000
[Sysname-acl6-basic-2000] rule permit source 4050::9000/120
# Create an ACL rule, denying the packets with any source IP addresses.
[Sysname] acl ipv6 number 2001
[Sysname-acl6-basic-2001] rule deny source any
# Configure a traffic classification rule and a traffic behavior, permitting the packets with the source IP addresses in the range 4050::9000 to 4050::90FF.
[Sysname] traffic classifier c_permit
[Sysname-classifier-c_permit] if-match acl ipv6 2000
[Sysname-classifier-c_permit] quit
[Sysname] traffic behavior b_permit
[Sysname-behavior-b_permit] filter permit
[Sysname-behavior-b_permit] quit
# Configure a traffic classification rule and a traffic behavior, denying the packets with any source IP addresses.
[Sysname] traffic classifier c_deny
[Sysname-classifier-c_deny] if-match acl ipv6 2001
[Sysname-classifier-c_deny] quit
[Sysname] traffic behavior b_deny
[Sysname-behavior-b_deny] filter deny
[Sysname-behavior-b_deny] quit
# Configure the QoS policy.
[Sysname] qos policy test
[Sysname-qospolicy-test] classifier c_permit behavior b_permit
[Sysname-qospolicy-test] classifier c_deny behavior b_deny
[Sysname-qospolicy-test] quit
# Apply the policy in the inbound direction of Ethernet 1/1/1.
[Sysname] interface ethernet1/1/1
[Sysname- Ethernet1/1/1] qos apply policy test inbound
[Sysname- Ethernet1/1/1] quit
Chapter 4 Flow Template Configuration
This chapter covers these topics:
l Displaying and Maintaining Flow Templates
l Flow Template Configuration Example
4.1 Configuring a Flow Template
Follow these steps to create a flow template and apply it to an interface:
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
–– |
|
Create a flow template |
Create a basic flow template |
flow-template flow-template-name basic { customer-vlan-id | dip | dipv6 | dmac | dport | dscp | ethernet-protocol | fragments | icmp-code | icmp-type | icmpv6-code | icmpv6-type | ip-precdence | ip-protocol | ip-ttl | ipv6-dscp | ipv6-fragment | ipv6-protocol | mpls-exp | service-cos | service-vlan-id | sip | sipv6 | smac | sport | tcp-flag | tos } * |
Optional Use either command. |
Create an extended flow template |
flow-template flow-template-name extend { ipv4 offset-max-value length-max-value | ipv6 offset-max-value length-max-value | l2 offset-max-value length-max-value | l4 offset-max-value length-max-value | l5 offset-max-value length-max-value } * |
||
Enter interface view or port group view |
Enter interface view |
interface interface-type interface-number |
Required |
Enter port group view |
port-group { aggregation agg-id | manual port-group-name } |
||
Apply the flow template to the interface or port group |
flow-template flow-template-name |
Optional The default one applies by default. |
Caution:
When one of the following situations occurs, you cannot configure user-defined flow templates on interfaces:
l B-type and C-type boards have IPv6 unicast and mix-insertion enabled on the virtual interfaces of VLANs.
l A Loopback interface for tunneling is configured on the ports of D-type boards.
l B-type and C-type boards have MLD, MLD Snooping and IPv6 PIM enabled on the virtual interfaces of VLANs.
l B-type, C-type and D-type boards have the RSVP protocol enabled on the virtual interfaces of VLANs.
l B-type, C-type and D-type boards are configured with VPLS redirection to the VPLS service boards.
Once a user-defined flow template is configured on an interface, only after the corresponding functions are removed can the user-defined flow template be deleted.
& Note:
l By default, the default flow template is referenced on interfaces.
l On an interface you can reference only one user-defined flow template and this flow template must be one already created.
l The default flow template for a non-D class board includes these fields: sip, dip, ip-protocol, sport, dport, tcp-flag, icmp-type, icmp-code, service-vlan-id, and ethernet-protocol. In addition to the above mentioned fields, the default flow template for a D class board also includes these fields: sipv6, dipv6, ipv6-protocol, and ipv6-fragment.
l Referencing a user-defined flow template on an interface may cause VLAN ACLs not function at the inbound direction of the interface.
l Configuring user-defined flow templates is prohibited on the even numbered interfaces of XP4C and XP4B boards. However, user-defined flow templates configured on the odd numbered ports will function at the outbound direction of all ports.
l A flow template with the mpls-exp keyword specified can be applied on only ports of boards suffixed with C, CA or CB.
l User-defined flow templates are not available for the POS interface.
The total size of all fields (in bytes) in a flow template should be less than 16 bytes. Table 4-1 shows the size of every field.
Table 4-1 Description on the size of every field
Field |
Length in bytes |
Remarks |
customer-vlan-id |
4 or 8 |
Usually 8 bytes (4 bytes when the ethernet-protocol field is configured) |
dip |
4 |
— |
dipv6 |
10 |
10 bytes in a flow template In fact, the field is 16-byte long. |
dmac |
6 |
— |
dscp |
1 |
1 byte, no matter these three fields are configured respectively or together |
ip-precedence |
1 |
|
tos |
1 |
|
ethernet-protocol |
6 |
— |
fragments |
0 or 2 |
0 bytes for B-type or C-type boards; 2 bytes for D-type boards |
icmp-type |
2 |
2 bytes, no matter they are configured respectively or together; Total 2 bytes when they are configured with the sport field; Total 2 bytes (for B-type or C-type boards) or 4 bytes (for D-type boards) when they are configured with the dport field. |
icmp-code |
2 |
|
icmpv6-type |
2 |
2 bytes, no matter they are configured respectively or together; Total 2 bytes when they are configured with the sport field. |
icmpv6-code |
2 |
|
sport |
2 |
— |
dport |
2 |
— |
ip-protocol |
1 |
— |
ip-ttl |
1 |
— |
ipv6-dscp |
0 |
— |
ipv6-fragment |
1 |
1 byte, no matter they are configured respectively or together |
ipv6-protocol |
1 |
|
mpls-exp |
0 |
0 bytes in a flow template |
service-cos |
0, 2 or 4 |
0 bytes when the customer-vlan-id field is configured; 2 bytes when the ethernet-protocol field is configured; or 4 bytes |
service-vlan-id |
0 or 2 |
2 bytes for B-type or C-type boards; 0 bytes for D-type boards |
sip |
4 |
— |
sipv6 |
0 |
0 bytes in a flow template In fact, the field is 16-byte long. |
smac |
6 |
— |
tcp-flag |
1 |
— |
4.2 Displaying and Maintaining Flow Templates
To do… |
Use the command… |
Remarks |
Display the configuration information of a specified or all user-defined flow templates |
display flow-template user-defined [ flow-template-name ] |
Available in any view |
Display information about the flow templates referenced to interfaces. |
display flow-template interface [ interface-type interface-number ] |
Available in any view |
4.3 Flow Template Configuration Examples
I. Network requirements
Create flow templates and apply them to Ethernet interfaces.
II. Configuration procedure
# Create basic user-defined flow template aaa and extended user-defined flow template bbb.
<Sysname> system-view
[Sysname] flow-template aaa basic customer-vlan-id
[Sysname] flow-template bbb extend 14 2 4 15 10 7
# Reference flow template aaa on interface Ethernet 4/1/1 and flow template bbb on interface Ethernet 3/1/1.
[Sysname] interface ethernet 4/1/1
[Sysname-Ethernet4/1/1] flow-template aaa
[Sysname-Ethernet4/1/1] quit
[Sysname] interface ethernet 3/1/1
[Sysname-Ethernet3/1/1] flow-template bbb
[Sysname-Ethernet3/1/1] quit
# Display information about flow template aaa.
[Sysname] display flow-template user-defined aaa
user-defined flow template: basic
name:aaa, index:1, total reference counts:1
fields: customer-vlan-id
# Display information about all user-defined flow templates.
[Sysname] display flow-template user-defined
user-defined flow template: basic
name:aaa, index:1, total reference counts:1
fields: customer-vlan-id
user-defined flow template: extend
name:bbb, index:2, total reference counts:1
fields: 14 2 4 15 10 7
# Display information about the user-defined flow templates referenced to interfaces.
[Sysname] display flow-template interface
Interface: Ethernet4/1/1
user-defined flow template: basic
name:aaa, index:1, total reference counts:1
fields: customer-vlan-id
Interface: Ethernet3/1/1
user-defined flow template: extend
name:bbb, index:2, total reference counts:1
fields: 14 2 4 15 10 7
# Delete flow template aaa. As it is being referenced by interface Ethernet 4/1/1, remove it from the interface first.
[Sysname] interface ethernet 4/1/1
[Sysname-Ethernet4/1/1] undo flow-template
[Sysname-Ethernet4/1/1] quit
[Sysname] undo flow-template name aaa