NE20E-S2 V800R011C10 Configuration Guide - IP Services 02

Rate and give feedback:

Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).

ACL Configuration

Access control lists (ACLs) help ensure network security and stability.

Overview of ACLs
Limitations for ACL
Configuring an Interface ACL
Configuring a Basic ACL
Configuring an Advanced ACL
Configuring a Layer 2 ACL
Configuring a User ACL
Configuring an MPLS-based ACL
Maintaining an ACL
- Clearing ACL Statistics
- Monitoring the ACL Operating Status
Configuration Examples for ACLs
- Example for Configuring a Basic ACL to Manage Device Access Rights
- Example for Configuring an Advanced ACL to Defend Against Attacks

Overview of ACLs

An ACL is a set of sequential packet filtering rules. After an ACL is configured on a router, the router permits or denies packets based on the matched rules defined in the ACL. ACLs can be applied to various services, such as routing policies, traffic management, and QoS.

Introduction

As the name indicates, an Access Control List (ACL) is a list. The list contains matching clauses, which are actually matching rules and used to tell the device to perform action on the packet or not.

ACLs are used to ensure reliable data transmission between devices on a network by performing the following:

Defend the network against various attacks, such as attacks by using IP, Transmission Control Protocol (TCP), or Internet Control Message Protocol (ICMP) packets.
Control network access. For example, ACLs can be used to control enterprise network user access to external networks, to specify the specific network resources accessible to users, and to define the time ranges in which users can access networks.
Limit network traffic and improve network performance. For example, ACLs can be used to limit the bandwidth for upstream and downstream traffic and to apply charging rules to user requested bandwidth, therefore achieving efficient utilization of network resources.

ACL rules are used to classify packets. After ACL rules are applied to a router, the router permits or denies packets based on them. The use of ACL rules therefore greatly improves network security.

An ACL is a set of rules. It identifies a type of packet but does not filter packets. Other ACL-associated functions are used to filter identified packets.

ACL Classification

The following table outlines ACL4 classification based on functions.

Table 3-1 ACL types

ACL Type	Function	ACL Number
Interface-based ACL	Defines rules based on packets' inbound interfaces.	1000 to 1999
Basic ACL	Defines rules based on packets' source addresses.	2000 to 2999
Advanced ACL	Rules in an advanced ACL are defined based on packets' source or destination addresses, source or destination port numbers, and protocol types.	3000 to 3999
Layer 2 ACL	Defines rules based on the Layer 2 information, such as the source MAC address, destination MAC address, or protocol type of Ethernet frames.	4000 to 4999
User ACL (UCL)	Defines rules based on the source/destination IP address, source/destination service group, source/destination user group, source/destination port number, and protocol type.	6000 to 9999
MPLS-based ACL	Defines rules based on MPLS packets' EXP values, labels, or TTL values.	10000 to 10999

Validity Period of ACL Rules

To control a type of traffic in a specified period of time, users can configure the validity period of an ACL rule to determine the time during which that traffic type is allowed to pass through. For example, to ensure reliable transmission of video services in prime time in the evening, restrict the traffic volume of common online users. The validity period can be an absolute or cyclic time range.

An absolute time range start from yyyy-mm-dd to yyyy-mm-dd. This time range is effective once and does not repeat.
A cyclic time range is cyclic, with a one week cycle. For example, an ACL rule takes effect from 8:00 to 12:00 every Sunday.

Matching Order of ACL Rules

First, the device checks whether the ACL exists.

Then, the device matches packets against rules in order according to the rule ID. When packets match one rule, the match operation is complete, and no more rules will be matched against.

A rule is identified by a rule ID, which is configured by a user or generated by the system according to the ACL increment. All rules in an ACL are arranged in ascending order of rule IDs.

If the rule ID is automatically allocated, there is a certain space between two rule IDs. The size of the space depends on the ACL increment. For example, if the ACL increment is set to 5, the difference between two rule IDs are 5, such as 5, 10, 15, and the rest may be deduced by analogy. If the ACL increment is 2, the rule IDs generated automatically by the system start from 2. In this manner, the user can add a rule before the first rule.

In configuration file, the rules are displayed in ascending order of rule IDs, not in the order of configuration.

Rule can be arranged in two modes: Configuration mode and Auto mode. The default mode is Configuration.

If the Configuration mode is used, users can set rule IDs or allow a device to automatically allocate rule IDs based on the increment.

If rule IDs are specified when rules are configured, the rules are inserted at places specified by the rule IDs. For example, three rules with IDs 5, 10, and 15 exist on a device. If a new rule with ID 3 is configured, the rules are displayed in ascending order, 3, 5, 10, and 15. This is the same as inserting a rule before ID 5. If users do not set rule IDs, the device automatically allocates rule IDs based on the increment. For example, if the ACL increment is set to 5, the difference or interval between two rule IDs is 5, such as 5, 10, 15, and the rest may be deduced by analogy.

If the ACL increment is set to 2, the device allocates rule IDs starting from 2. The increment allows users to insert new rules, facilitating rule maintenance. For example, the ACL increment is 5 by default. If a user does not configure a rule ID, the system automatically generates a rule ID 5 as the first rule. If the user intends to add a new rule before rule 5, the user only needs to input a rule ID smaller than 5. After the automatic realignment, the new rule becomes the first rule.

In the Configuration mode, the system matches rules in ascending order of rule IDs. As a result, a latter configured rule may be matched earlier.

If the auto mode is used, the system automatically allocates rule IDs, and places the most precise rule in the front of the ACL based on the depth-first principle. This can be implemented by comparing the address wildcard. The smaller the wildcard, the narrower the specified range.

For example, 172.16.1.1 0.0.0.0 specifies a host with the IP address 172.16.1.1, and 172.16.1.1 0.0.0.255 specifies a network segment with the network segment address ranging from 172.16.1.1 to 172.16.1.255. The former specifies a narrower host range and is placed before the latter.

The detailed operations are as follows:

For basic ACL rules, the source address wildcards are compared. If the source address wildcards are the same, the system matches packets against the ACL rules based on the configuration order.
For advanced ACL rules, the protocol ranges and then the source address wildcards are compared. If both the protocol ranges and the source wildcards are the same, the destination address wildcards are then compared. If the destination address wildcards are also the same, the ranges of source port numbers are compared with the smaller range being allocated a higher precedence. If the ranges of source port numbers are still the same, the ranges of destination port numbers are compared with the smaller range being allocated a higher precedence. If the ranges of destination port numbers are still the same, the system matches packets against ACL rules based on the configuration order of rules.

For example, a wide range of packets are specified for packet filtering. Later, it is required that packets matching a specific feature in the range be allowed to pass. If the auto mode is configured in this case, the administrator only needs to define a specific rule and does not need to re-order the rules because a narrower range is allocated a higher precedence in the auto mode.

Table 3-2 describes the depth-first principle for matching ACL rules.

Table 3-2 Depth-first principle for matching ACL rules

ACL Type	Matching Rules
Interface-based ACL	Rules with any set are matched last, and other rules are matched in the order they are configured.
Basic ACL	Rules with VPN instance information are matched before those without VPN instance information. If multiple rules contain the same VPN instance information, the rule with the smaller source IP addresses range (more 1s in the masks) is matched first. If multiple rules contain the same VPN instance information and the same source IP address range, they are matched in the order they are configured.
Advanced ACL	Rules with VPN instance information are matched before those without VPN instance information. If multiple rules contain the same VPN instance information, the rule that contains the protocol type is matched first. If multiple rules contain the same VPN instance information and the same protocol type, the rule with the smaller source IP address range (more 1s in the masks) is matched first. If multiple rules contain the same VPN instance information, protocol type, and source IP address range, the rule with the smaller destination IP address range (more 1s in the masks) is matched first. If multiple rules contain the same VPN instance information, protocol type, source IP address range, and destination IP address range, the rule with the smaller Layer 4 port number range (TCP/UDP port numbers) is matched first. If multiple rules contain the same VPN instance information, protocol type, source and destination IP address ranges, and port number range, they are matched in the order they are configured.
Layer 2 ACL	Rules with smaller wildcards of Layer 2 protocol types (more 1s in the masks) are matched first. If multiple rules contain the same Layer 2 protocol type wildcard, the rule with the smaller source MAC address range (more 1s in the masks) is matched first. If multiple rules contain the same Layer 2 protocol type wildcard and the same source MAC address range, the rule with the smaller destination MAC address range (more 1s in the masks) is matched first. If multiple rules contain the same Layer 2 protocol type wildcard, source and destination MAC address ranges, the rule with the smaller VLAN ID of the outer tag is matched first. If multiple rules contain the same Layer 2 protocol type wildcard, source and destination MAC address ranges, and VLAN ID of the outer tag, the rule with the higher 802.1p priority of the outer tag is matched first. If multiple rules contain the same Layer 2 protocol type wildcard, source and destination MAC address ranges, VLAN ID and 802.1p priority of the outer tag, the rule with the smaller VLAN ID of the inner tag is matched first. If multiple rules contain the same Layer 2 protocol type wildcard, source and destination MAC address ranges, VLAN ID and 802.1p priority of the outer tag, and VLAN ID of the inner tag, the rule with the higher 802.1p priority of the inner tag is matched first. If multiple rules contain the same Layer 2 protocol type wildcard, source and destination MAC address ranges, VLAN ID and 802.1p priority of the outer tag, VLAN ID and 802.1p priority of the inner tag, they are matched in the order they are configured.
MPLS-based ACL	Rules can only be arranged in Configuration mode.

ACL Step

An ACL increment is the difference between two adjacent ACL rule numbers that are automatically allocated. For example, if the ACL increment is set to 5, the rule numbers are multiples of 5, such as 5, 10, 15, and 20.

If an ACL increment is changed, rules in the ACL are automatically renumbered. For example, if the ACL increment is changed from 5 to 2, the original rule numbers 5, 10, 15, and 20 will be renumbered as 2, 4, and 6.
If the default increment 5 is restored for an ACL, the system immediately renumbers the rules in the ACL based on the default increment. For example, if the increment of ACL 3001 is 2, rules in ACL 3001 are numbered 0, 2, 4, and 6. If the default increment 5 is restored, the rules will be renumbered as 5, 10, 15, and 20.

Limitations for ACL

Limitations for ACL on NE20E-S2E

Restrictions	Guidelines	Impact
By default, interface-based ACLs do not take effect for Layer 3 multicast protocol packets.	Run the traffic-policy match-protocol-type mc-reserved command to configure ACL rules on interfaces.	ACL rules do not take effect for reserved multicast packets.

Limitations for ACL on NE20E-S2F

Restrictions	Guidelines	Impact
By default, interface-based ACLs do not take effect for Layer 3 multicast protocol packets.	Run the traffic-policy match-protocol-type mc-reserved command to configure ACL rules on interfaces.	ACL rules do not take effect for reserved multicast packets.

Configuring an Interface ACL

An interface ACL defines rules to filter packets.

Usage Scenario

Figure 3-1 Configuring an interface ACL

Interfaces 1 through 2 in this example are GE 0/1/0, GE 0/2/0, respectively.

As shown in Figure 3-1, an ACL based on GE 0/1/0 is created on Device A to allow Device A to permit all packets sent from Network A to the Internet and deny all packets sent from Network B to the Internet.

(Optional) Creating a Validity Period for an ACL Rule

You can create a validity period for an ACL rule to control network traffic in a specified period.

Context

To control certain types of traffic in a specified period, you can configure the validity period of an ACL rule to determine the time traffic passes through. For example, to ensure reliable transmission of video traffic at prime time at night, limit the volume of traffic for common online users.

After this configuration task is performed, a time range is created. Then you can specify the time range as the validity period when creating an ACL rule.

The validity period of an ACL rule can be either of the following types:

Absolute time range: The validity period is fixed.
Relative time range: The validity period is a periodic period, for example, each Monday.

Procedure

Run system-view
The system view is displayed.
Run time-range time-name { start-time to end-time days &<1-7> | from time1 date1 [ to time2 date2 ] }
A validity period is created.
- You can configure up to 256 time ranges.
- Up to 32 relative time ranges (periodic time ranges) and 12 absolute time ranges can share one time range name.
Run commit
The configuration is committed.

Creating an Interface ACL

You can create an interface ACL and configure parameters for the ACL.

Procedure

Run system-view
The system view is displayed.
Run acl { name interface-based-acl-name { interface | [ interface ] number interface-based-acl-number } | [ number ] interface-based-acl-number } [ match-order { config | auto } ]
An interface ACL is created.

The interface ACL number ranges from 1000 to 1999.
(Optional) Run step step
An ACL increment is set.

You can use an ACL increment to maintain ACL rules and add new ACL rules conveniently.

Assume that a user has created four rules numbered from 1 to 4 in an ACL. The user can reconfigure the ACL increment, for example, to 2 by running the step 2 command in the ACL view. The original rule numbers 1, 2, 3, and 4 are renumbered as 2, 4, 6, and 8, respectively. After that, the user can run the rule 3 command to add a rule numbered 3 between the renumbered rules 2 and 4.
(Optional) Run description text
The ACL description is configured.

The description command configures a description for an ACL in any of the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
- Names of named ACLs cannot fully explain the ACLs' functions.
Run commit
The configuration is committed.

Configuring an Interface-based ACL Rule

Interface-based ACL rules are defined based on packets' inbound interfaces to filter packets.

Procedure

Run system-view
The system view is displayed.
Run acl { name interface-acl-name { interface | [ interface ] number interface-based-acl-number } | [ number ] interface-based-acl-number }
The interface ACL view is displayed.
Run rule [ rule-id ] [ name rule-name ] { permit | deny } interface { interface-type interface-number | any } [ time-range time-name ] ^*
A rule is configured for the interface ACL.
- Adding new rules to an ACL will not affect the existing rules.
- When an existing rule is edited and the edited contents conflict with the original contents, the edited contents take effect.
When you configure an interface ACL:
- If an interface is specified by configuring interface, the system filters only packets received by this specified interface.
- If all interfaces are specified by configuring any, the system does not check packets' inbound interfaces, and considers that all packets have matched the rule and directly takes an action (deny or permit) on the packets.
- If a validity period is specified by configuring time-range, the time range name specified by time-name must already exist. Otherwise, the rule configuration fails.
(Optional) Run rule description text
The description for an ACL rule is configured.
The description of an ACL rule can contain the functions of the ACL rule. Configuring a description for an ACL rule is recommended to prevent misuse of the rule in the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
Run commit
The configuration is committed.

Verifying the Configuration of an Interface ACL

After configuring an interface ACL, verify the configuration.

Prerequisites

An interface ACL has been configured.

Procedure

Run the display acl { acl-number | name acl-name | all } command to check interface ACL configurations.
Run the display time-range { time-name | all } command to check the configuration of a specified or all validity periods.

Configuring a Basic ACL

A basic ACL defines rules to filter packets.

Usage Scenario

Figure 3-2 Configuring a basic ACL

Interfaces 1 through 2 in this example are GE 0/1/0, GE 0/2/0, respectively.

As shown in Figure 3-2, a basic ACL is created on Device A to allow Device A to permit all packets sent from Network A to the Internet and deny all packets sent from Network B and Network C to the Internet.

(Optional) Creating a Validity Period for an ACL Rule

You can create a validity period for an ACL rule to control network traffic in a specified period.

Context

After this configuration task is performed, a time range is created. Then you can specify the time range as the validity period when creating an ACL rule.

The validity period of an ACL rule can be either of the following types:

Absolute time range: The validity period is fixed.
Relative time range: The validity period is a periodic period, for example, each Monday.

Procedure

Run system-view
The system view is displayed.
Run time-range time-name { start-time to end-time days &<1-7> | from time1 date1 [ to time2 date2 ] }
A validity period is created.
- You can configure up to 256 time ranges.
- Up to 32 relative time ranges (periodic time ranges) and 12 absolute time ranges can share one time range name.
Run commit
The configuration is committed.

Creating a Basic ACL

You can create a basic ACL and configure parameters for the ACL.

Procedure

Run system-view
The system view is displayed.
Run acl { name basic-acl-name { basic | [ basic ] number basic-acl-number } | [ number ] basic-acl-number } [ match-order { config | auto } ]
A basic ACL is created.

The basic ACL number ranges from 2000 to 2999.
(Optional) Run step step
An ACL increment is set.

You can use an ACL increment to maintain ACL rules and add new ACL rules conveniently.

Assume that a user has created four rules numbered from 1 to 4 in an ACL. The user can reconfigure the ACL increment, for example, to 2 by running the step 2 command in the ACL view. The original rule numbers 1, 2, 3, and 4 are renumbered as 2, 4, 6, and 8, respectively. After that, the user can run the rule 3 command to add a rule numbered 3 between the renumbered rules 2 and 4.
(Optional) Run description text
The ACL description is configured.

The description command configures a description for an ACL in any of the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
- Names of named ACLs cannot fully explain the ACLs' functions.
Run commit
The configuration is committed.

Configuring a Basic ACL Rule

Basic ACL rules are defined based on whether the packets are the first fragments, packets' source IP addresses, and VPN instances to filter packets.

Procedure

Run system-view
The system view is displayed.
Run acl { name basic-acl-name { basic | [ basic ] number basic-acl-number } | [ number ] basic-acl-number } [ match-order { config | auto } ]
The basic ACL view is displayed.
Run rule [ rule-id ] [ name rule-name ] { deny | permit } [ fragment-type { fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-first } | source { source-ip-address { source-wildcard | 0 | src-netmask } | any } | time-range time-name | [ vpn-instance vpn-instance-name | vpn-instance-any ] ] ^*
A rule is configured for the basic ACL.
- Adding new rules to an ACL will not affect the existing rules.
- When an existing rule is edited and the edited contents conflict with the original contents, the edited contents take effect.
When you configure a basic ACL:
- If a source IP address is specified by configuring source, the system filters only packets with this specified source IP address.
- If all source IP addresses are specified by configuring any, the system does not check packets' source IP addresses and considers that all packets have matched the rule and directly takes an action (deny or permit) on the packets.
- If a validity period is specified by configuring time-range, the time range name specified by time-name must already exist. Otherwise, the rule configuration fails.
(Optional) Run rule description text
The description for an ACL rule is configured.
The description of an ACL rule can contain the functions of the ACL rule. Configuring a description for an ACL rule is recommended to prevent misuse of the rule in the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
Run commit
The configuration is committed.

Applying a Basic ACL

Basic ACLs can be used in device management, routing policies, multicast packet filtering, and QoS services.

Context

Table 3-3 describes the typical applications of basic ACLs.

Table 3-3 Typical applications of basic ACLs

Typical Application	Usage Scenario	Operation
Device management	When a device functions as an FTP or TFTP server, configure a basic ACL on the device to allow only the clients that match specific ACL rules to access the server.	For details on how to configure rights to access an FTP or TFTP server, see Configuring FTP Access Control Configuring TFTP Access Authority
	Configure a basic ACL to restrict the incoming or outgoing calls on VTY user interfaces.	For details on how to configure the restriction on incoming and outgoing calls on VTY user interfaces, see Setting Restrictions for Incoming and Outgoing Calls on VTY User Interfaces.
	Specify an NMS and manageable MIB objects for SNMP-based communication between the NMS and managed device to improve communication security.	For details on how to configure the NMS's right to access devices, see Controlling the NM Station's Access to the Device (SNMPv1) Controlling the NM Station's Access to the Device (SNMPv2) Controlling the NM Station's Access to the Device (SNMPv3)
Multicast packet filtering	To filter multicast packets, configure a basic ACL to receive or forward only the multicast packets that match the ACL rules.	For details on how to filter multicast packets, see Setting a Multicast Source Address Range Setting a Legal C-RP Address Range Setting a Legal BSR Address Range Setting an SSM Group Address Range
Routing policies	To control the reception and advertisement of routing information on a device, configure a basic ACL on the device to allow the device to receive or advertise only the routes that match the ACL rules.	For details on how to control the reception and advertisement of routing information on a device, see Applying Filters to the Received Routes Controlling BGP to Receive Routes Applying Filters to the Advertised Routes Controlling BGP to Advertise Routes
QoS services	To process different types of traffic, configure a basic ACL to perform traffic policing, traffic shaping, or traffic classification on traffic that matches the ACL rules.	For details on how to process different types of traffic, see Configuring the Traffic Policing Policy, Configuring Traffic Shaping, and Configuring Traffic Behaviors.

Typical Cases of Applying a Basic ACL

Cases of applying a basic ACL in device management
For example, a user configures a device as follows:
- Configuring a basic ACL for FTP login
```
acl number 2001 
 rule 5 deny source 192.168.2.100 0 
 rule 10 permit
ftp acl 2001
```
  Matching result: Users with the IP address 192.168.2.100 are prohibited from logging in to the device using FTP.
- Configuring a basic ACL for Telnet login
```
acl number 2001 
 rule 5 permit source 192.168.2.100 0 
 rule 10 deny 
user-interface vty 0 4 
 acl 2001 inbound
```
  Matching result: Only users with the IP address 192.168.2.100 are allowed to log in to the device using Telnet.
- Configuring a basic ACL for SNMP login
```
acl number 2001 
 rule 5 deny source 192.168.2.100 0 
 rule 10 permit
snmp-agent community read cipher public acl 2001
```
  Matching result: Users with the IP address 192.168.2.100 are prohibited from logging in to the device using SNMP.
Case of applying a basic ACL in multicast packet filtering
For example, a user configures a device as follows:
```
acl number 2001
 rule 5 permit source 10.10.1.2 0
 rule 10 deny source 10.10.1.1 0
pim
 source-policy 2001
```
Matching result: The device permits multicast packets containing the source address 10.10.1.2 whereas discarding those containing the source address 10.10.1.1.
Cases of applying a basic ACL in routing policies
For example, a user configures a device as follows:
- A routing policy of a routing protocol is used to filter routes.
```
ip route-static 1.1.1.0 255.255.255.0 NULL0
ip route-static 192.168.2.0 255.255.255.0 NULL0
ip route-static 192.168.2.100 255.255.255.255 NULL0
bgp 1
 peer 10.1.1.1 as-number 1
 ipv4-family unicast
  undo synchronization
  import-route static route-policy test
peer 10.1.1.1 enable
```
```
route-policy test permit node 0
 if-match acl 2001
acl number 2001
 rule 5 permit source 192.168.2.100 0
 rule 10 deny source 1.1.1.0 0.0.0.255
```
  Matching result: Routes from the network segments 1.1.1.0 and 192.168.2.0 are filtered out, whereas the route 192.168.2.100 is permitted.
  Routes from the network segments 1.1.1.0 are filtered out, because the action defined in the ACL rule that the routes match is deny.
  
  Routes from the network segment 192.168.2.0 do not match any specified ACL rules. By default, the device matches the routes with the last ACL rule. The action defined in the last ACL rule is deny, and therefore the routes are filtered out.
  
  The route 192.168.2.100 is permitted, because the action defined in the ACL rule that the route matches is permit and the action defined in the routing policy is also permit.
```
route-policy test permit node 0 
 if-match acl 2001 
 apply cost 100 
route-policy test permit node 1 
 apply cost 200
acl number 2001 
 rule 5 permit source 192.168.2.100 0 
```
  Matching result: The cost of the route 192.168.2.100 is changed to 100, whereas the costs of other routes are changed to 200.
  
  In the preceding route-policy, permit is specified for node 0, the route 192.168.2.100/32 passes the check by the if-match clause, and the device takes the action (apply cost 100) specified in the apply clause. As a result, the cost of the route is changed to 100. The other routes do not pass the check by the if-match clause, and the device takes the action (apply cost 200) specified in node 1 in the route-policy. As a result, the costs of these routes are changed to 200.
```
route-policy test deny node 0 
 if-match acl 2001 
 apply cost 100 
route-policy test permit node 1 
 apply cost 200
acl number 2001 
 rule 5 permit source 192.168.2.100 0 
```
  Matching result: The cost of the route 192.168.2.100/32 is not changed to 100.
  
  In the preceding route-policy, deny is specified for node 0, the route 192.168.2.100/32 passes the check by the if-match clause, and the device does not take the action (apply cost 100) specified in the apply clause. As a result, the cost of the route is not changed to 100. The other routes do not pass the check by the if-match clause, and the device takes the action (apply cost 200) specified in node 1 in the route-policy. As a result, the costs of these routes are changed to 200.
- A filtering policy of a routing protocol is used to filter routes.
```
ip route-static 1.1.1.0 255.255.255.0 NULL0
ip route-static 192.168.2.0 255.255.255.0 NULL0  
ip route-static 192.168.2.100 255.255.255.255 NULL0 
bgp 1
 peer 10.1.1.2 as-number 1 
 ipv4-family unicast 
  undo synchronization 
  filter-policy 2001 export 
  import-route static  
peer 10.1.1.2 enable 
acl number 2001
 rule 5 permit source 192.168.2.100 0 
 rule 10 deny source 1.1.1.0 0.0.0.255 
```
  Matching result: Routes from the network segments 1.1.1.0 and 192.168.2.0 are filtered out, whereas the route 192.168.2.100 is permitted.
  Routes from the network segments 1.1.1.0 are filtered out, because the action defined in the ACL rule that the routes match is deny.
  
  Routes from the network segment 192.168.2.0 do not match any specified ACL rules. By default, the device matches the routes with the last ACL rule. The action defined in the last ACL rule is deny, and therefore the routes are filtered out.
  
  The route 192.168.2.100 is permitted, because the action defined in the ACL rule that the route matches is permit and the action defined in the filtering policy is export.
Cases of applying a basic ACL in QoS services
For example, a user configures a device as follows:
- Configuring a basic ACL in firewall traffic behavior (packet filtering)
```
acl number 2001
 rule 5 permit source 5.0.0.0 0.255.255.255
 rule 10 deny source 6.0.0.0 0.255.255.255
traffic classifier acl 
 if-match acl 2001
traffic behavior test
 deny
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/1/1
 traffic-policy test inbound
```
  GE 0/1/1 receives the following packets:
  - Packet 1 with the source IP address 5.0.0.1/24
  - Packet 2 with the source IP address 6.0.0.1/24
  - Packet 3 with the source IP address 7.0.0.1/24
  Matching result: Packets 1 and 2 are discarded but packet 3 is permitted.
- Configuring a basic ACL in common traffic behavior
```
acl number 2001
 rule 5 permit source 5.0.0.0 0.255.255.255
 rule 10 deny source 6.0.0.0 0.255.255.255
traffic classifier acl 
 if-match acl 2001
traffic behavior test
 remark ip-precedence 7
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/1/1
 traffic-policy test inbound
```
  GE 0/1/1 receives the following packets:
  - Packet 1 with the source IP address 5.0.0.1/24 and IP precedence 0
  - Packet 2 with the source IP address 6.0.0.1/24 and IP precedence 0
  - Packet 3 with the source IP address 7.0.0.1/24 and IP precedence 0
  Matching result: Packet 1 is permitted, and its IP precedence is re-marked 7; packet 3 is permitted, and its IP precedence remains 0; packet 2 is discarded.

Verifying the Configuration of a Basic ACL

After configuring a basic ACL, verify the configuration.

Prerequisites

A basic ACL has been configured.

Procedure

Run the display acl { acl-number | name acl-name | all } command to check basic ACL configurations.
Run the display time-range { time-name | all } command to check the configuration of a specified or all validity periods.

Configuring an Advanced ACL

An advanced ACL defines rules to filter packets.

Usage Scenario

Figure 3-3 Configuring an advanced ACL

As shown in Figure 3-3, an advanced ACL is created on Device D to allow Device D to permit all ICMP packets sent from Network B to Network C and deny all ICMP packets sent from Network A to the Network C.

(Optional) Creating a Validity Period for an ACL Rule

You can create a validity period for an ACL rule to control network traffic in a specified period.

Context

After this configuration task is performed, a time range is created. Then you can specify the time range as the validity period when creating an ACL rule.

The validity period of an ACL rule can be either of the following types:

Absolute time range: The validity period is fixed.
Relative time range: The validity period is a periodic period, for example, each Monday.

Procedure

Run system-view
The system view is displayed.
Run time-range time-name { start-time to end-time days &<1-7> | from time1 date1 [ to time2 date2 ] }
A validity period is created.
- You can configure up to 256 time ranges.
- Up to 32 relative time ranges (periodic time ranges) and 12 absolute time ranges can share one time range name.
Run commit
The configuration is committed.

Creating an Advanced ACL

You can create an advanced ACL and configure parameters for the ACL.

Procedure

Run system-view
The system view is displayed.
Run acl { name advance-acl-name { advance | [ advance ] number advance-acl-number } | [ number ] advance-acl-number } [ match-order { config | auto } ]
An advanced ACL is created.

The advanced ACL number ranges from 3000 to 3999.
(Optional) Run step step
An ACL increment is set.

You can use an ACL increment to maintain ACL rules and add new ACL rules conveniently.

Assume that a user has created four rules numbered from 1 to 4 in an ACL. The user can reconfigure the ACL increment, for example, to 2 by running the step 2 command in the ACL view. The original rule numbers 1, 2, 3, and 4 are renumbered as 2, 4, 6, and 8, respectively. After that, the user can run the rule 3 command to add a rule numbered 3 between the renumbered rules 2 and 4.
(Optional) Run description text
The ACL description is configured.

The description command configures a description for an ACL in any of the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
- Names of named ACLs cannot fully explain the ACLs' functions.
Run commit
The configuration is committed.

(Optional) Configuring an ACL IP Address Pool

An ACL IP address pool is applicable to the scenario in which multiple IP addresses need to be matched and reduces the configuration workload.

Context

In typical ACL usage scenarios, for example, in the policy-based routing scenario, both the source and destination IP addresses need to be matched. To implement policy-based routing using ACL rules to match both source and destination IP addresses carried in packets, specify all possible combinations of source IP addresses and destination IP addresses when configuring ACL rules. However, these combinations are over 10 thousands on a large-scale network. It is unreasonable to configure manually all ACL rules that match both source and destination IP addresses carried in packets.

To reduce the configuration workload, configure an ACL IP address pool. After an ACL IP address pool is configured, you only need to configure an ACL rule with a specified IP address pool name (pool-name) to match multiple IP addresses carried in packets.

In scenarios in which ACL rules are used to match both source and destination IP addresses carried in packets, run the acl ip-pool command to create an ACL source IP address pool (which includes all needed IP addresses) and an ACL destination IP address pool (which includes all needed destination IP addresses), respectively.

If you need to filter packets based on the source IP addresses of BGP peers, run the apply bgp-peer command to associate the IP addresses of BGP peers with the ACL/ACL IPv6 address pools to which these addresses belong. Then, reference ACL/ACL6 address pool in QoS or device security service to filter packets based on the source IP addresses of BGP peers.

Procedure

Run system-view
The system view is displayed.
Run acl ip-pool pool-name
An ACL IP address pool is created and the IP address pool view is displayed.
The address association of BGP peers and manual IP address configuration are mutually exclusive. Run one of the following command:
- Run the ip address ip-address { mask | mask-length } command to add IP addresses to the ACL IP address pool.
  
  If the ip address command is run more than once, all configurations take effect.
- Run the apply bgp-peer [ public-vpn | all-private-vpn | vpn-instance vpn-instance-name ] command to associate IP addresses of BGP peers with the ACL IP address pool.
  
  This command is applicable only to QoS or device security services.
Run commit
The configuration is committed.

(Optional) Configuring an ACL Port Pool

When multiple port numbers need to be matched to ACL rules, you can configure an ACL port pool to reduce the configuration workload.

Context

In typical ACL usage scenarios, such as QoS traffic policy, a user may need to match multiple port numbers. To implement policy-based routing using advanced ACL rules to match multiple source and destination port numbers, the user needs to specify all possible combinations of source and destination port numbers when configuring ACL rules. On large-scale networks, tens of millions of ACL rules may need to be manually configured to matches the port numbers, which is not viable.

To reduce the configuration workload, configure an ACL port pool. After an ACL port pool is configured, you only need to configure an ACL rule with a specified port pool name (pool-name) to match multiple port numbers.

When an ACL rule needs to match multiple source and destination port numbers, you need to run this command twice to create an ACL source port pool and an ACL destination port pool separately.

Procedure

Run system-view
The system view is displayed.
Run acl port-pool pool-name
An ACL port pool is created, and the ACL port pool view is displayed.
Run eq begin-port-number,neq begin-port-number,gt begin-port-number, lt end-port-number, or range begin-port-number end-port-number
Port numbers are added to the ACL port pool.
Run commit
The configuration is committed.

Configuring an Advanced ACL Rule

Advanced ACL rules are defined based on packets' source IP address, destination IP address, protocol type carried over IP, source port, and destination port to filter packets.

Procedure

Run system-view
The system view is displayed.
Run acl { name advance-acl-name { advance | [ advance ] number advance-acl-number } | [ number ] advance-acl-number } [ match-order { config | auto } ]
The advanced ACL view is displayed.
Run any of the following commands to create an ACL rule:
- Create an advanced ACL rule when protocol is UDP.
  
  rule [ rule-id ] [ name rule-name ] { deny | permit } { protocol | udp } [ [ dscp dscp | [ precedence precedence | tos tos ] ^* ] | { destination { destination-ip-address { destination-wildcard | 0 | des-netmask } | any } | destination-pool destination-pool-name } | { destination-port operator port-number | destination-port-pool destination-port-pool-name } | fragment-type { fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-first } | { source { source-ip-address { source-wildcard | 0 | src-netmask } | any } | source-pool source-pool-name } | { source-port operator port-number | source-port-pool source-port-pool-name } | time-range time-name | [ vpn-instance vpn-instance-name | vpn-instance-any ] | ttl ttl-operation ttl-value | packet-length length-operation length-value ] ^*
- Create an advanced ACL rule when protocol is TCP.
  
  rule [ rule-id ] [ name rule-name ] { deny | permit } { protocol | tcp } [ [ dscp dscp | [ precedence precedence | tos tos ] ^* ] | { destination { destination-ip-address { destination-wildcard | 0 | des-netmask } | any } | destination-pool destination-pool-name } | { destination-port operator port-number | destination-port-pool destination-port-pool-name } | fragment-type { fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-first } | { source { source-ip-address { source-wildcard | 0 | src-netmask } | any } | source-pool source-pool-name } | { source-port operator port-number | source-port-pool source-port-pool-name } | { tcp-flag | syn-flag } { tcp-flag [ mask mask-value ] | established | { ack [ fin | psh | rst | syn | urg ] ^* } | { fin [ ack | psh | rst | syn | urg ] ^* } | { psh [ fin | ack | rst | syn | urg ] ^* } | { rst [ fin | psh | ack | syn | urg ] ^* } | { syn [ fin | psh | rst | syn | urg ] ^* } | { urg [ fin | psh | rst | syn | urg ] ^* } } | time-range time-name | [ vpn-instance vpn-instance-name | vpn-instance-any ] | ttl ttl-operation ttl-value | packet-length length-operation length-value ] ^*
- Create an advanced ACL rule when protocol is ICMP.
  
  rule [ rule-id ] [ name rule-name ] { deny | permit } { protocol | icmp } [ [ dscp dscp | [ precedence precedence | tos tos ] ^* ] | { destination { destination-ip-address { destination-wildcard | 0 | des-netmask } | any } | destination-pool destination-pool-name } | fragment-type { fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-first } | icmp-type { icmp-name | icmp-type [ to icmp-type-end ] [ icmp-code ] } | { source { source-ip-address { source-wildcard | 0 | src-netmask } | any } | source-pool source-pool-name } | time-range time-name | [ vpn-instance vpn-instance-name | vpn-instance-any ] | ttl ttl-operation ttl-value | packet-length length-operation length-value ] ^*
- Create an advanced ACL rule when protocol is any protocol except TCP, UDP, and ICMP.
  
  rule [ rule-id ] [ name rule-name ] { deny | permit } { protocol | gre | ip | ipinip | igmp | ospf } [ [ dscp dscp | [ precedence precedence | tos tos ] ^* ] | { destination { destination-ip-address { destination-wildcard | 0 | des-netmask } | any } | destination-pool destination-pool-name } | fragment-type { fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-first } | { source { source-ip-address { source-wildcard | 0 | src-netmask } | any } | source-pool source-pool-name } | time-range time-name | [ vpn-instance vpn-instance-name | vpn-instance-any ] | ttl ttl-operation ttl-value | packet-length length-operation length-value ] ^*
Adding new rules to an ACL will not affect the existing rules.

When an existing rule is edited and the edited contents conflict with the original contents, the edited contents take effect.
When you configure an advanced ACL:
- If no VPN instance is specified, (that is, vpn-instance is not configured in Step 3), the traffic belongs to the public network.
- If a destination IP address is specified by configuring destination, a destination port number is specified by configuring destination-port, a source IP address is specified by configuring source, and a source port number is specified by configuring source-port, the system filters only packets with the specified destination IP address, destination port number, source IP address, and source port number.
- If all destination IP addresses, destination port numbers, source IP addresses, and source port numbers are specified by configuring any, the system does not check packets' destination IP addresses, destination port numbers, source IP addresses, and source port numbers, and considers that all packets have matched the rule and directly takes an action (deny or permit) on the packets.
- If a validity period is specified by configuring time-range, the time range name specified by time-name must already exist. Otherwise, the rule configuration fails.
(Optional) Run rule description text
The description for an ACL rule is configured.
The description of an ACL rule can contain the functions of the ACL rule. Configuring a description for an ACL rule is recommended to prevent misuse of the rule in the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
Run commit
The configuration is committed.

Applying an Advanced ACL

Advanced ACLs can be used in routing policies, multicast packet filtering, and QoS services.

Context

Table 3-4 describes the typical applications of advanced ACLs.

Table 3-4 Typical applications of advanced ACLs

Typical Application	Usage Scenario	Operation
Device management	Configure an advanced ACL to restrict the incoming or outgoing calls on VTY user interfaces.	For details on how to configure the restriction on incoming and outgoing calls on VTY user interfaces, see Setting Restrictions for Incoming and Outgoing Calls on VTY User Interfaces.
Multicast packet filtering	To filter multicast packets, configure an advanced ACL to receive or forward only the multicast packets that match the ACL rules.	For details on how to filter multicast packets, see Setting a Multicast Source Address Range Setting a Legal C-RP Address Range Setting a Legal BSR Address Range Setting an SSM Group Address Range
QoS services	To process different types of traffic, configure an advanced ACL to perform traffic policing, traffic shaping, or traffic classification on traffic that matches the ACL rules.	For details on how to process different types of traffic, see Configuring the Traffic Policing Policy, Configuring Traffic Shaping, and Configuring Traffic Behaviors.

Typical Cases of Applying an Advanced ACL

Cases of applying an advanced ACL in device management
For example, a user configures a device as follows:
```
acl number 3001 
 rule 5 permit ip source 192.168.2.100 0 
 rule 10 deny ip source any
user-interface vty 0 4 
 acl 3001 inbound
```
Matching result: Only users with the IP address 192.168.2.100 are allowed to log in to the device using Telnet.
Case of applying an advanced ACL in multicast packet filtering
For example, a user configures a device as follows:
```
acl number 3001
 rule 5 permit ip source 10.10.1.2 0
 rule 10 deny ip source 10.10.1.1 0
pim
 source-policy 3001
```
Matching result: The device permits multicast packets containing the source address 10.10.1.2 whereas discarding those containing the source address 10.10.1.1.

Cases of applying an advanced ACL in QoS services

For example, a user configures a device as follows:

Configuring an advanced ACL in firewall traffic behavior (packet filtering)

acl number 3000 
 rule 5 permit tcp destination-port eq domain 
 rule 10 permit udp destination-port eq dns 
 rule 15 permit icmp icmp-type echo 
 rule 20 permit icmp icmp-type echo-reply
traffic classifier acl 
 if-match acl 3000
traffic behavior test
 permit
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/1/1
 traffic-policy test inbound

Matching result: DNS Echo, DNS Echo Reply, ICMP Echo, and ICMP Echo Reply packets are permitted.

acl number 3000 
 rule 5 permit ip source 10.108.0.0 0.0.0.255
 rule 10 deny ip source 10.108.0.0 0.0.255.255
traffic classifier acl 
 if-match acl 3000
traffic behavior test
 permit
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/1/1
 traffic-policy test inbound

Matching result: IP packets from the network segment 10.108.0.0/24 are permitted, whereas those from the network segment 10.108.0.0/16 are denied.

acl number 3000 
 rule permit tcp source 10.9.0.0 0.0.255.255 destination 10.8.160.0 0.0.0.255 destination-port eq www
traffic classifier acl 
 if-match acl 3000
traffic behavior test
 permit
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/1/1
 traffic-policy test inbound

Matching result: Hosts in the 10.9.0.0 network segment are permitted to send WWW packets to hosts in the 10.8.160.0 network segment.

time-range no-http 08:00 to 16:00 working-day 
acl number 3000 
 rule 5 deny tcp source-port eq www time-range no-http 
 rule 10 deny tcp destination-port eq www time-range no-http
traffic classifier acl 
 if-match acl 3000
traffic behavior test
 permit
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/1/1
 traffic-policy test inbound

Matching result: HTTP packets are denied from 8:00 am to 6:00 pm Monday through Friday.

acl number 3000 
 rule 5 permit tcp
traffic classifier acl 
 if-match acl 3000
traffic behavior test
 permit
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/1/1
 traffic-policy test inbound

Matching result: TCP packets are permitted.

Configuring an advanced ACL in common traffic behavior
```
acl number 3001
 rule 5 permit ip source 5.0.0.0 0.255.255.255
 rule 10 deny ip source 6.0.0.0 0.255.255.255
traffic classifier acl 
 if-match acl 3001
traffic behavior test
 remark ip-precedence 7
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/1/1
 traffic-policy test inbound
```
GE 0/1/1 receives the following packets:
- Packet 1 with the source IP address 5.0.0.1/24 and IP precedence 0
- Packet 2 with the source IP address 6.0.0.1/24 and IP precedence 0
- Packet 3 with the source IP address 7.0.0.1/24 and IP precedence 0
Matching result: Packet 1 is permitted, and its IP precedence is re-marked 7; packet 3 is permitted, and its IP precedence remains 0; packet 2 is discarded.

Verifying the Configuration of an Advanced ACL

After configuring an advanced ACL, verify the configuration.

Prerequisites

An advanced ACL has been configured.

Procedure

Run the display acl { acl-number | name acl-name | all } command to check advanced ACL configurations.
Run the display time-range { time-name | all } command to check the configuration of a specified or all validity periods.

Configuring a Layer 2 ACL

A Layer 2 ACL defines rules to filter packets.

Usage Scenario

Layer 2 ACLs can be used in QoS and routing policies to filter packets.

Figure 3-4 Configuring a Layer 2 ACL

As shown in Figure 3-4, a Layer 2 ACL is created on Device D to deny all packets sent from a host (MAC address 1-1-1) connected to Device A to Device C and to permit all packets sent from a host (MAC address 2-1-1) connected to Device B to Device C.

(Optional) Creating a Validity Period in Which an ACL Rule Takes Effect

You can create a validity period in which an ACL rule takes effect to control network traffic in a specified period.

Context

After this configuration task is performed, a time range is created. Then you can specify the time range as the validity period when creating an ACL rule.

The validity period of an ACL rule can be either of the following types:

Absolute time range: The validity period is fixed.
Relative time range: The validity period is a periodic period, for example, each Monday.

Procedure

Run system-view
The system view is displayed.
Run time-range time-name { start-time to end-time days &<1-7> | from time1 date1 [ to time2 date2 ] }
The validity period of an ACL rule is created.
- You can configure up to 256 time ranges.
- Up to 32 relative time ranges (periodic time ranges) and 12 absolute time ranges can share one time range name.
Run commit
The configuration is committed.

Creating a Layer 2 ACL

This section describes how to create a Layer 2 ACL and how to configure the related parameters.

Procedure

Run system-view
The system view is displayed.
Run acl { name link-acl-name { link | [ link ] number link-acl-number } | [ number ] link-acl-number } [ match-order { config | auto } ]
A Layer 2 ACL is created.

The number of a Layer 2 ACL ranges from 4000 to 4999.
(Optional) Run step step
An ACL increment is set.

You can use an ACL increment to maintain ACL rules and add new ACL rules conveniently.

Assume that a user has created four rules numbered from 1 to 4 in an ACL. The user can reconfigure the ACL increment, for example, to 2 by running the step 2 command in the ACL view. The original rule numbers 1, 2, 3, and 4 are renumbered as 2, 4, 6, and 8, respectively. After that, the user can run the rule 3 command to add a rule numbered 3 between the renumbered rules 2 and 4.
(Optional) Run description text
The ACL description is configured.

The description command configures a description for an ACL in any of the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
- Names of named ACLs cannot fully explain the ACLs' functions.
Run commit
The configuration is committed.

Configuring Rules for a Layer 2 ACL

This section describes how to configure rules for a Layer 2 ACL.

Procedure

Run system-view
The system view is displayed.
Run acl { name link-acl-name { link | [ link ] number link-acl-number } | [ number ] link-acl-number } [ match-order { config | auto } ]
The Layer 2 ACL view is displayed.
Run rule [ rule-id ] [ name rule-name ] { deny | permit } [ type type [ type-mask ] | source-mac source-mac [ source-mac-mask ] | destination-mac dest-mac [ dest-mac-mask ] | 8021p 8021p | cvlan-8021p cvlan-8021p | time-range time-name ]
The rules for the Layer 2 ACL are configured.
- Adding new rules to an ACL will not affect the existing rules.
- When an existing rule is modified and the modified contents conflict with the original contents, the modified contents take precedence.
During the configuration of rules for the Layer 2 ACL:
- If time-range is specified, the specified time range name must exist. If the specified time range name does not exist, the ACL rules will not take effect.
(Optional) Run rule description text
The description for an ACL rule is configured.
The description of an ACL rule can contain the functions of the ACL rule. Configuring a description for an ACL rule is recommended to prevent misuse of the rule in the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
Run commit
The configuration is committed.

Applying a Layer 2 ACL

Layer 2 ACLs can be used in QoS services.

Context

Table 3-5 describes the typical applications of Layer 2 ACLs.

Table 3-5 Typical applications of Layer 2 ACLs

Typical Application	Usage Scenario	Operation
QoS	To process different types of traffic, users can configure a Layer 2 ACL to perform traffic policing, traffic shaping, or traffic classification on traffic that matches the ACL rules.	To find out more about the procedures for processing different types of traffic, see how to configure traffic policing, traffic shaping, and traffic behaviors.

Typical Cases of Applying a Layer 2 ACL

Cases of applying a Layer 2 ACL in QoS services

For example, a user configures a device as follows:

Configuring an Ethernet frame header-based ACL in firewall traffic behavior (packet filtering)

acl number 4001
 rule permit 8021p 3 source-mac 1-1-1 ffff-ffff-ffff
 rule 10 deny 
traffic classifier acl 
 if-match acl 4001
traffic behavior test
 permit
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/2/0
 traffic-policy test inbound

Matching result: Only VLAN packets with the 802.1p priority 3 in the outer VLAN tag, source MAC address 1-1-1, and source MAC address mask ffff-ffff-ffff are permitted.

Configuring an Ethernet frame header-based ACL in common traffic behavior
```
acl number 4001
 rule permit 8021p 3 source-mac 1-1-1 ffff-ffff-ffff
 rule 10 deny 
traffic classifier acl 
 if-match acl 4001
traffic behavior test
 remark 8021p 7
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/2/0
 traffic-policy test inbound
```
Matching result: Only VLAN packets with the 802.1p priority 3 in the outer VLAN tag, source MAC address 1-1-1, and source MAC address mask ffff-ffff-ffff are permitted, and the packets' 802.1p priority is re-marked 7.

Verifying the Configuration of a Layer 2 ACL

After configuring a Layer 2 ACL, verify the configuration.

Prerequisites

A Layer 2 ACL has been configured.

Procedure

Run the display acl { acl-number | name acl-name | all } command to check the configuration of a Layer 2 ACL.
Run the display time-range { time-name | all } command to check the configuration of a specified time range or all time ranges.

Configuring a User ACL

A User ACL defines rules to filter packets.

Usage Scenario

To process different types of traffic, users can configure a User ACL to perform traffic policing, traffic shaping, or traffic classification on traffic that matches the ACL rules.

(Optional) Creating a Validity Period for an ACL Rule

You can create a validity period for an ACL rule to control network traffic in a specified period.

Context

After this configuration task is performed, a time range is created. Then you can specify the time range as the validity period when creating an ACL rule.

The validity period of an ACL rule can be either of the following types:

Relative time range: The validity period is a periodic period, for example, each Monday.
Absolute time range: The validity period is fixed.

Procedure

Run system-view
The system view is displayed.
Run time-range time-name { start-time to end-time days &<1-7> | from time1 date1 [ to time2 date2 ] }
A validity period is created.
- You can configure up to 256 time ranges.
- Up to 32 relative time ranges (periodic time ranges) and 12 absolute time ranges can share one time range name.
Run commit
The configuration is committed.

Creating a User ACL

You can create a user ACL and configure parameters for the ACL.

Procedure

Run system-view
The system view is displayed.
Run acl { name ucl-acl-name [ ucl | [ ucl ] number ucl-acl-number ] | [ number ] ucl-acl-number } [ match-order { auto | config } ]
A user ACL is created.

The user ACL number ranges from 6000 to 9999.
(Optional) Run step step
An ACL increment is set.

You can use an ACL increment to maintain ACL rules and add new ACL rules conveniently.

Assume that a user has created four rules numbered from 1 to 4 in an ACL. The user can reconfigure the ACL increment, for example, to 2 by running the step 2 command in the ACL view. The original rule numbers 1, 2, 3, and 4 are renumbered as 2, 4, 6, and 8, respectively. After that, the user can run the rule 3 command to add a rule numbered 3 between the renumbered rules 2 and 4.
(Optional) Run description text
The ACL description is configured.

The description command configures a description for an ACL in any of the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
- Names of named ACLs cannot fully explain the ACLs' functions.
Run commit
The configuration is committed.

Configuring a User ACL Rule

Packets can be matched based on the source/destination IP address, source/destination service group, source/destination user group, source/destination port number, and protocol type.

Procedure

Run system-view
The system view is displayed.
Run acl { name ucl-acl-name [ ucl | [ ucl ] number ucl-acl-number ] | [ number ] ucl-acl-number } [ match-order { auto | config } ]
The user ACL view is displayed.
Run any of the following commands to create an ACL rule:
- Create a user ACL rule when protocol is UDP.
  
  rule [ rule-id ] [ name rule-name ] { deny | permit } { protocol | udp } [ [ dscp dscp | [ precedence precedence | tos tos ] ^* ] | source { { ip-address { source-ip-address { source-ip-address-mask | 0 } | any } | source-pool source-pool-name } | any | [ service-group { service-group-name | any } | user-group { user-group-name | any } ] } | destination { { ip-address { destination-ip-address { destination-ip-address-mask | 0 } | any } | destination-pool destination-pool-name } | any | [ service-group { service-group-name | any } | user-group { user-group-name | any } ] } | source-port operator port-number | destination-port operator port-number | fragment-type { fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-first } | time-range time-name | [ logging ] | vlan vlan-id | inner-vlan cvlan-id ] ^*
- Create a user ACL rule when protocol is TCP.
  
  rule [ rule-id ] [ name rule-name ] { deny | permit } { protocol | tcp } [ [ dscp dscp | [ precedence precedence | tos tos ] ^* ] | source { { ip-address { source-ip-address { source-ip-address-mask | 0 } | any } | source-pool source-pool-name } | any | [ service-group { service-group-name | any } | user-group { user-group-name | any } ] } | destination { { ip-address { destination-ip-address { destination-ip-address-mask | 0 } | any } | destination-pool destination-pool-name } | any | [ service-group { service-group-name | any } | user-group { user-group-name | any } ] } | source-port operator port-number | destination-port operator port-number | syn-flag { syn-flag [ mask mask-value ] | { bit-match { established | fin | syn | rst | psh | ack | urg | ece | crw | ns } } } | fragment-type { fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-first } | time-range time-name | [ logging ] | vlan vlan-id | inner-vlan cvlan-id ] ^*
- Create a user ACL rule when protocol is ICMP.
  
  rule [ rule-id ] [ name rule-name ] { deny | permit } { protocol | icmp } [ [ dscp dscp | [ precedence precedence | tos tos ] ^* ] | source { { ip-address { source-ip-address { source-ip-address-mask | 0 } | any } | source-pool source-pool-name } | any | [ service-group { service-group-name | any } | user-group { user-group-name | any } ] } | destination { { ip-address { destination-ip-address { destination-ip-address-mask | 0 } | any } | destination-pool destination-pool-name } | any | [ service-group { service-group-name | any } | user-group { user-group-name | any } ] } | icmp-type { icmp-name | icmp-type icmp-code } | fragment-type { fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-first } | time-range time-name | [ logging ] | vlan vlan-id | inner-vlan cvlan-id ] ^*
- Create a user ACL rule when protocol is any protocol except TCP, UDP, and ICMP.
  
  rule [ rule-id ] [ name rule-name ] { deny | permit } { protocol | gre | ip | ipinip | igmp | ospf } [ [ dscp dscp | [ precedence precedence | tos tos ] ^* ] | source { { ip-address { source-ip-address { source-ip-address-mask | 0 } | any } | source-pool source-pool-name } | any | [ service-group { service-group-name | any } | user-group { user-group-name | any } ] } | destination { { ip-address { destination-ip-address { destination-ip-address-mask | 0 } | any } | destination-pool destination-pool-name } | any | [ service-group { service-group-name | any } | user-group { user-group-name | any } ] } | fragment-type { fragment | non-fragment | non-subseq | fragment-subseq | fragment-spe-first } | time-range time-name | [ logging ] | vlan vlan-id | inner-vlan cvlan-id ] ^*
Adding new rules to an ACL will not affect the existing rules.

When an existing rule is edited and the edited contents conflict with the original contents, the edited contents take effect.
(Optional) Run rule description text
The description for an ACL rule is configured.
The description of an ACL rule can contain the functions of the ACL rule. Configuring a description for an ACL rule is recommended to prevent misuse of the rule in the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
Run commit
The configuration is committed.

Applying a User ACL

User ACLs can be used in QoS services.

Context

Table 3-6 describes the typical applications of User ACLs.

Table 3-6 Typical applications of User ACLs

Typical Application	Usage Scenario	Operation
QoS	To process different types of traffic, users can configure a User ACL to perform traffic policing, traffic shaping, or traffic classification on traffic that matches the ACL rules.	To find out more about the procedures for processing different types of traffic, see how to configure traffic policing, traffic shaping, and traffic behavior.

Verifying the Configuration of a User ACL

After configuring a user ACL, verify the configuration.

Prerequisites

All configurations of the user ACL are configured.

Procedure

Run the display acl { acl-number | name acl-name | all } command to view user ACL configurations.
Run the display time-range { time-name | all } command view the configuration and status within a specified time range or all time ranges.

Configuring an MPLS-based ACL

An MPLS-based ACL defines rules to filter packets.

Usage Scenario

Figure 3-5 Configuring an MPLS-based ACL

As shown in Figure 3-5, an MPLS-based ACL is created for QoS services on Device D to allow Device D to allocate 54000 bit/s bandwidth to the MPLS packets with an EXP value smaller than 3 sent from Network A and to allocate 8000 bit/s bandwidth to the MPLS packets with an EXP value greater than 3 sent from Network B.

Creating an MPLS-based ACL

You can create an MPLS-based ACL and configure parameters for the ACL.

Procedure

Run system-view
The system view is displayed.
Run acl { name mpls-acl-name { mpls | [ mpls ] number mpls-acl-number } | [ number ] mpls-acl-number }
An MPLS-based ACL is created.

The MPLS-based ACL number ranges from 10000 to 10999.
(Optional) Run step step
An ACL increment is set.

You can use an ACL increment to maintain ACL rules and add new ACL rules conveniently.

Assume that a user has created four rules numbered from 1 to 4 in an ACL. The user can reconfigure the ACL increment, for example, to 2 by running the step 2 command in the ACL view. The original rule numbers 1, 2, 3, and 4 are renumbered as 2, 4, 6, and 8, respectively. After that, the user can run the rule 3 command to add a rule numbered 3 between the renumbered rules 2 and 4.
(Optional) Run description text
The ACL description is configured.

The description command configures a description for an ACL in any of the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
- Names of named ACLs cannot fully explain the ACLs' functions.
Run commit
The configuration is committed.

Configuring an MPLS-based ACL Rule

MPLS-based ACL rules are defined based on MPLS packets' EXP, label, or TTL values to filter packets.

Procedure

Run system-view
The system view is displayed.
Run acl { name mpls-acl-name { mpls | [ mpls ] number mpls-acl-number } | [ number ] mpls-acl-number }
The MPLS-based ACL view is displayed.
Run rule [ rule-id ] [ name rule-name ] { deny | permit } [ exp { exp-value | any } &<1-4> | label { label-value | any } &<1-4> | ttl { { lt | eq | gt } ttl-value | range ttl-value1 ttl-value2 | any } &<1-3> ] ^*
Rules for the MPLS-based ACL are configured.
- Adding new rules to an ACL will not affect the existing rules.
- When an existing rule is edited and the edited contents conflict with the original contents, the edited contents take effect.
When you configure an MPLS-based ACL:
- If an EXP value is specified by configuring exp, a label value is specified by configuring label, and a TTL value is specified by configuring ttl, the system filters only the packets with the specified EXP, label, and TTL values.
- If all EXP, label, and TTL values are specified by configuring any, the system does not check MPLS packets' EXP, label, and TTL values, and considers that all packets have matched the rule and directly takes an action (deny or permit) on the packets.
(Optional) Run rule description text
The description for an ACL rule is configured.
The description of an ACL rule can contain the functions of the ACL rule. Configuring a description for an ACL rule is recommended to prevent misuse of the rule in the following situations:
- A large number of ACLs are configured, and their functions are difficult to identify.
- An ACL is used at a long interval, and its function may be left forgotten.
Run commit
The configuration is committed.

Applying an MPLS-based ACL

MPLS-based ACLs can be used in QoS services.

Context

Table 3-7 describes the typical applications of MPLS-based ACLs.

Table 3-7 Typical applications of MPLS-based ACLs

Typical Application	Usage Scenario	Operation
QoS services	To process different types of traffic, configure an MPLS-based ACL to perform traffic policing, traffic shaping, or traffic classification on traffic that matches the ACL rules.	For details on how to process different types of traffic, see Configuring the Traffic Policing Policy, Configuring Traffic Shaping, and Configuring Traffic Behaviors.

Typical Cases of Applying an MPLS-based ACL

Cases of applying an MPLS-based ACL in QoS services

For example, a user configures a device as follows:

Configuring an MPLS-based ACL in firewall traffic behavior (packet filtering)

acl number 10001
 rule 5 permit exp 3 label 2048 ttl eq 23
 rule 10 deny 
traffic classifier acl 
 if-match acl 10001
traffic behavior test
 permit
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/2/0
 traffic-policy test inbound

Matching result: Only MPLS packets with the EXP value 3, label value 2048, and TTL value 23 are permitted.

Configuring an MPLS-based ACL in common traffic behavior

acl number 10001
 rule 5 permit exp 3 label 2048 ttl eq 23
 rule 10 deny 
traffic classifier acl 
 if-match acl 10001
traffic behavior test
 remark mpls-exp 7
traffic policy test
 classifier acl behavior test
interface GigabitEthernet0/2/0
 traffic-policy test inbound

Matching result: Only MPLS packets with the EXP value 3, label value 2048, and TTL value 23 are permitted, and the packet EXP value is re-marked 7.

Verifying the Configuration of an MPLS-based ACL

After configuring an MPLS-based ACL, verify the configuration.

Prerequisites

An MPLS-based ACL has been configured.

Procedure

Run the display acl { acl-number | name acl-name | all } command to check MPLS-based ACL configurations.
Run the display time-range { time-name | all } command to check the configuration of a specified or all validity periods.

Maintaining an ACL

This section describes how to clear ACL statistics and monitor the ACL operating status.

Clearing ACL Statistics

This section describes how to clear ACL statistics.

Context

ACL statistics cannot be restored after they are cleared. Exercise caution when running a reset command.

Procedure

Run the reset acl counter { acl-number | name acl-name | all } command in the user view to clear ACL statistics.

Monitoring the ACL Operating Status

This section describes how to monitor the ACL operating status.

Context

Run the following commands in any view to check the ACL operating status in routine maintenance.

Procedure

Run the display acl { acl-number | name acl-name | all } command to check the ACL operating status.
Run the display time-range { time-name | all } command to check the configuration of a specified or all validity periods.

Configuration Examples for ACLs

This section provides ACL configuration examples.

Example for Configuring a Basic ACL to Manage Device Access Rights

This section provides an example for configuring a basic ACL to manage device access rights.

Networking Requirements

On the network shown in Figure 3-6, the PE is a device in the HR department and two VPN instances VPN-A and VPN-B are created on the PE. CE1 is a device in Department A and belongs to VPN-A that uses 111:1 as the VPN-target. CE2 is a device in Department B and belongs to VPN-B that uses 222:2 as the VPN-target. To allow the user (CE1) in VPN-A to log in to the PE by Telnet and prevent the user (CE2) in VPN-B from logging in to the PE, configure a basic ACL on the PE so that devices in Department A are allowed to access the devices in the HR department, whereas devices in Department B are not allowed to access the devices in the HR department, and devices in Department A and Department B cannot access each other.

Figure 3-6 Configuring a basic ACL to manage device access rights

Interfaces 1 through 2 in this example are GE 0/1/0, GE 0/2/0, respectively.

Configuration Roadmap

The configuration roadmap is as follows:

Configure VPN instances on different devices.
Define ACL rules to configure rights for different VPN users to access the PE.
Apply the ACL to allow different VPN users to have different rights to access the PE.

Data Preparation

To complete the configuration, you need the following data:

ACL number
VPN instance names

Procedure

Configure VPN instances on the PE.

# Configure VPN-A.

<HUAWEI> system-view

[~HUAWEI] sysname PE

[*HUAWEI] commit

[~PE] ip vpn-instance vpna

[*PE-vpn-instance-vpna] ipv4-family

[*PE-vpn-instance-vpna-af-ipv4] route-distinguisher 100:1

[*PE-vpn-instance-vpna-af-ipv4] vpn-target 111:1 both

[*PE-vpn-instance-vpna-af-ipv4] commit

[~PE-vpn-instance-vpna-af-ipv4] quit

[~PE-vpn-instance-vpna] quit

[~PE] interface gigabitethernet 0/1/0

[~PE-GigabitEthernet0/1/0] ip binding vpn-instance vpna

[*PE-GigabitEthernet0/1/0] ip address 10.1.1.1 24

[*PE-GigabitEthernet0/1/0] commit

[~PE-GigabitEthernet0/1/0] quit

# Configure VPN-B.

[~PE] ip vpn-instance vpnb

[*PE-vpn-instance-vpnb] ipv4-family

[*PE-vpn-instance-vpnb-af-ipv4] route-distinguisher 100:2

[*PE-vpn-instance-vpnb-af-ipv4] vpn-target 222:2 both

[*PE-vpn-instance-vpnb-af-ipv4] commit

[~PE-vpn-instance-vpnb-af-ipv4] quit

[~PE-vpn-instance-vpnb] quit

[~PE] interface gigabitethernet 0/2/0

[~PE-GigabitEthernet0/2/0] ip binding vpn-instance vpnb

[*PE-GigabitEthernet0/2/0] ip address 10.2.1.1 24

[*PE-GigabitEthernet0/2/0] commit

[~PE-GigabitEthernet0/2/0] quit

Create a basic ACL and configure ACL rules on the PE to allow the user (CE1) in VPN-A to log in to PE by Telnet and prevent the user (CE2) in VPN-B from logging in to the PE.

[~PE] acl number 2001

[*PE-acl4-basic-2001] rule permit vpn-instance vpna

[*PE-acl4-basic-2001] rule deny vpn-instance vpnb

[*PE-acl4-basic-2001] commit

[~PE-acl4-basic-2001] quit

Apply the ACL in Telnet services on the PE.

[~PE] user-interface vty 0 4

[~PE-ui-vty0-4] authentication-mode password

[*PE-ui-vty0-4] set authentication password

Please configure the login password (8-16)
Enter Password:
Confirm Password:

[*PE-ui-vty0-4] acl 2001 inbound

[*PE-ui-vty0-4] commit

Configure IP addresses for CE1 and CE2 as shown in Figure 3-6. For configuration details, see Configuration Files in this section.

Verify the configuration.

# Log in to the PE from CE1 by Telnet. The command output shows that CE1 can log in to the PE by Telnet.

<CE1> telnet vpn-instance vpna 10.1.1.1

Trying 10.1.1.1 ...                                                             
Press CTRL+K to abort                                                           
Connected to 10.1.1.1 ...                                                       
Info: The max number of VTY users is 10, and the number                         
      of current VTY users on line is 1.  
<PE>

# Log in to the PE from CE2 by Telnet. The command output shows that CE2 cannot log in to the PE by Telnet.

<CE2> telnet vpn-instance vpnb 10.2.1.1

Trying 10.2.1.1 ...
Press CTRL+K to abort
Error: Failed to connect to the remote host.Press CTRL+K to abort

# Log in to CE2 from CE1 by Telnet. The command output shows that CE1 cannot log in to CE2 by Telnet.

<CE1> telnet vpn-instance vpnb 10.2.1.2

Trying 10.2.1.2 ...
Press CTRL+K to abort
Error: Failed to connect to the remote host.Press CTRL+K to abort

Configuration Files

PE configuration file

#
 sysname PE
#
ip vpn-instance vpna
 route-distinguisher 100:1
 vpn-target 111:1 export-extcommunity
 vpn-target 111:1 import-extcommunity
ip vpn-instance vpnb
 route-distinguisher 100:2
 vpn-target 222:2 export-extcommunity
 vpn-target 222:2 import-extcommunity
#
acl number 2001
 rule 5 permit vpn-instance vpna
 rule 10 deny vpn-instance vpnb
#
interface GigabitEthernet0/1/0
 undo shutdown
 ip binding vpn-instance vpna
 ip address 10.1.1.1 255.255.255.0
#
interface GigabitEthernet0/2/0
 undo shutdown
 ip binding vpn-instance vpnb
 ip address 10.2.1.1 255.255.255.0
#    
user-interface con 0
user-interface vty 0 4
 acl 2001 inbound
 authentication-mode password
 user privilege level 15
 set authentication password cipher $1c$`g=H/qo%;7$b6Za%2'[D!0blsOXF=.3QCNC-f)co,[aeE.`e`-<$
user-interface vty 16 20
#
return

CE1 configuration file

#
 sysname CE1
#
ip vpn-instance vpna
 route-distinguisher 100:1
 vpn-target 111:1 export-extcommunity
 vpn-target 111:1 import-extcommunity
#
interface GigabitEthernet0/1/0
 undo shutdown
 ip binding vpn-instance vpna
 ip address 10.1.1.2 255.255.255.0
#
user-interface con 0
user-interface vty 0 4
user-interface vty 16 20
#
return

CE2 configuration file

#
 sysname CE2
#
ip vpn-instance vpnb
 route-distinguisher 100:2
 vpn-target 222:2 export-extcommunity
 vpn-target 222:2 import-extcommunity
#
interface GigabitEthernet0/1/0
 undo shutdown
 ip binding vpn-instance vpnb
 ip address 10.2.1.2 255.255.255.0
#
user-interface con 0
user-interface vty 0 4
user-interface vty 16 20
#
return

Example for Configuring an Advanced ACL to Defend Against Attacks

This section provides an example for configuring an advanced ACL to defend against attacks.

Networking Requirements

As shown in Figure 3-7, Device A, Device B, and Device C are access devices whereas Device D, Device E, and Device F are core devices. The access devices connect to the core devices through 10 Gbit/s interfaces. Voice and 3G services run on the network. To control user access and ensure network and device security, security policies need to be configured on the access routers to prevent ICMP packet attacks. To achieve this purpose, configure an advanced ACL on Device A.

If the attacker (PC) attacks the network, Device A can use the configured advanced ACL to prevent the ICMP packet attacks.

Figure 3-7 Configuring an advanced ACL to defend against attacks

Interfaces 1 through 2 in this example are GE 0/1/0, GE 0/2/0, respectively.

Configuration Roadmap

The configuration roadmap is as follows:

Set passwords for users that log in to a device using the NMS and CLI to improve login security.
Record all information about unsuccessful logins in a log file and output log information to the console interface for network administrators to check the login information.
Configure an advanced ACL on Device A and apply the advanced ACL to QoS services to defend against ICMP packet attacks.

Data Preparation

To complete the configuration, you need the following data:

IP address of each interface
Password for users that log in to a device using the NMS and CLI
Number of the advanced ACL

Procedure

Assign an IP address to each interface. For configuration details, see Configuration Files in this section.

Set a password for users that log in to a device using the NMS and CLI.

<HUAWEI> system-view

[~HUAWEI] sysname DeviceA

[*HUAWEI] commit

[~DeviceA] user-interface console 0
[*DeviceA-ui-con0] shell
[*DeviceA-ui-con0] authentication-mode password
[*DeviceA-ui-con0] set authentication password cipher Huawei-123
[*DeviceA-ui-con0] idle-timeout 30 0
[*DeviceA-ui-con0] commit
[~DeviceA-ui-con0] quit
[~DeviceA] user-interface maximum-vty 15
[*DeviceA] user-interface vty 5 14
[*DeviceA-ui-vty5-14] shell
[*DeviceA-ui-vty5-14] authentication-mode password
[*DeviceA-ui-vty5-14] set authentication password cipher Huawei-123
[*DeviceA-ui-vty5-14] idle-timeout 30 0
[*DeviceA-ui-vty5-14] commit
[~DeviceA-ui-vty5-14] quit

The configurations of the other access devices are similar to the configuration of router A.

Record all information about unsuccessful logins in a log file and output log information to the console interface.

[~DeviceA] info-center enable
[*DeviceA] info-center source default channel 9 log level warnings
[*DeviceA] info-center logfile channel channel9
[*DeviceA] commit
[~DeviceA] quit
<DeviceA> terminal logging

Configure an advanced ACL on Device A and apply the advanced ACL to QoS services to defend against ICMP packet attacks.

<DeviceA> system-view

[~DeviceA] acl number 3001

[*DeviceA-acl4-advance-3001] description anti-virus

[*DeviceA-acl4-advance-3001] rule 5 deny icmp

[*DeviceA-acl4-advance-3001] commit

[~DeviceA-acl4-advance-3001] quit

[~DeviceA] traffic classifier anti-virus

[*DeviceA-classifier-anti-virus] if-match acl 3001

[*DeviceA-classifier-anti-virus] commit

[~DeviceA-classifier-anti-virus] quit

[~DeviceA] traffic behavior anti-virus

[*DeviceA-behavior-anti-virus] commit

[~DeviceA-behavior-anti-virus] quit

[~DeviceA] traffic policy anti-virus

[*DeviceA-trafficpolicy-anti-virus] classifier anti-virus behavior anti-virus

[*DeviceA-trafficpolicy-anti-virus] commit

[~DeviceA-trafficpolicy-anti-virus] quit

[~DeviceA] interface gigabitethernet 0/2/0

[*DeviceA-GigabitEthernet0/2/0] traffic-policy anti-virus inbound

[*DeviceA-GigabitEthernet0/2/0] commit

[~DeviceA-GigabitEthernet0/2/0] traffic-policy anti-virus outbound

[*DeviceA-GigabitEthernet0/2/0] commit

Verify the configuration.

# Ping Device A from the PC. The command output shows that the ping operation fails.

c:\>ping 172.16.1.1

Pinging 172.16.1.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 172.16.1.1:
    Pacets: Sent = 4, Received = 0, Lost = 4 <100% loss>,

# Delete the advanced ACL on Device A. Then the command output shows that ping operation is successful.

c:\>ping 172.16.1.1

Pinging 172.16.1.1 with 32 bytes of data:
Reply from 172.16.1.1: bytes=32 time<1ms TTL=128
Reply from 172.16.1.1: bytes=32 time<1ms TTL=128
Reply from 172.16.1.1: bytes=32 time<1ms TTL=128
Reply from 172.16.1.1: bytes=32 time<1ms TTL=128

Ping statistics for 172.16.1.1:
    Pacets: Sent = 4, Received = 4, Lost = 0 <0% loss>,
Approximate round trip times in mill-seconds:
    Minimum = 0ms, Maximum = 0 ms, Average = 0ms

Configuration Files

Only the configuration file of Device A is provided.

Device A configuration file

#
 sysname DeviceA
#
 info-center source default channel 9 log level warning
#
acl number 3001
 description anti-virus
 rule 5 deny icmp
#
traffic classifier anti-virus
 if-match acl 3001
#
traffic behavior anti-virus
#
traffic policy anti-virus
 classifier anti-virus behavior anti-virus
#
interface GigabitEthernet0/2/0
 undo shutdown
 traffic-policy anti-virus inbound
 traffic-policy anti-virus outbound
#
user-interface maximum-vty 15
user-interface con 0
 authentication-mode password
 set authentication password cipher $1c$+ml_E.a0;2${3#YMMJkS;|55pT,![V6_S;%Ch53r1+)m;UL('kC$
 idle-timeout 30 0
user-interface vty 0 4
user-interface vty 5 14
 set authentication password cipher $1c$]%!4MA^MCZ$#Mh<#-{x^)j)~&Mu-fK*)<+7,pC2|,F.b80W`V`H$
 idle-timeout 30 0
user-interface vty 16 20
#
return

Overview of ACLs
Limitations for ACL
Configuring an Interface ACL
Configuring a Basic ACL
Configuring an Advanced ACL
Configuring a Layer 2 ACL
Configuring a User ACL
Configuring an MPLS-based ACL
Maintaining an ACL
- Clearing ACL Statistics
- Monitoring the ACL Operating Status
Configuration Examples for ACLs
- Example for Configuring a Basic ACL to Manage Device Access Rights
- Example for Configuring an Advanced ACL to Defend Against Attacks

Translation

简体中文

Download

Updated: 2020-02-07

Document ID: EDOC1100125470

Downloads: 4

Average rating:

This Document Applies to these Products

Reminder

Enterprise

Corporate

Consumer

Carrier

Africa

Latin America

Middle East

Asia Pacific

North America

Europe

ACL Configuration

Overview of ACLs

Introduction

ACL Classification

Validity Period of ACL Rules

Matching Order of ACL Rules

ACL Step

Limitations for ACL

Limitations for ACL on NE20E-S2E

Limitations for ACL on NE20E-S2F

Configuring an Interface ACL

Usage Scenario

(Optional) Creating a Validity Period for an ACL Rule

Context

Procedure

Creating an Interface ACL

Procedure

Configuring an Interface-based ACL Rule

Procedure

Verifying the Configuration of an Interface ACL

Prerequisites

Procedure

Configuring a Basic ACL

Usage Scenario

(Optional) Creating a Validity Period for an ACL Rule

Context

Procedure

Creating a Basic ACL

Procedure

Configuring a Basic ACL Rule

Procedure

Applying a Basic ACL

Context

Typical Cases of Applying a Basic ACL

Verifying the Configuration of a Basic ACL

Prerequisites

Procedure

Configuring an Advanced ACL

Usage Scenario

(Optional) Creating a Validity Period for an ACL Rule

Context

Procedure

Creating an Advanced ACL

Procedure

(Optional) Configuring an ACL IP Address Pool

Context

Procedure

(Optional) Configuring an ACL Port Pool

Context

Procedure

Configuring an Advanced ACL Rule

Procedure

Applying an Advanced ACL

Context

Typical Cases of Applying an Advanced ACL

Verifying the Configuration of an Advanced ACL

Prerequisites

Procedure

Configuring a Layer 2 ACL

Usage Scenario

(Optional) Creating a Validity Period in Which an ACL Rule Takes Effect

Context

Procedure

Creating a Layer 2 ACL

Procedure

Configuring Rules for a Layer 2 ACL

Procedure

Applying a Layer 2 ACL

Context