S Series Switches Feature Start-ACL V1.0 D

S Series Switches
Feature Start - ACL
Issue
01
Date
2013-09-30
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.

No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address:
Huawei Industrial Base

Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website:
http://enterprise.huawei.com
S Series Switches
Feature Start - ACL
About This Document
About This Document

Purpose
This document describes ACL features, including elementary knowledge, configuration guide,
troubleshooting, troubleshooting cases, and FAQs.
The procedures and methods for troubleshooting ACL faults are also provided in this
document.
Intended Audience
This document is intended for:
Technical support engineers
Maintenance engineers
Symbol Conventions
The symbols that may be found in this document are defined as follows.
Symbol
Description
Indicates a hazard with a high level or medium level of risk
which, if not avoided, could result in death or serious injury.
Indicates a hazard with a low level of risk which, if not
avoided, could result in minor or moderate injury.
Indicates a potentially hazardous situation that, if not avoided,
could result in equipment damage, data loss, performance
deterioration, or unanticipated results.
Provides a tip that may help you solve a problem or save time.
Provides additional information to emphasize or supplement
important points in the main text.
S Series Switches
Feature Start - ACL
About This Document
Change History
Changes between document issues are cumulative. The latest document issue contains all the
changes made in earlier issues.
Issue 01 (2013-09-30)
This is the initial official release.
Contents
Contents
About This Document.......................................................................ii

1 ACL Overview...............................................................................1
1.1 Introduction to ACL.......................................................................................................................................................1
1.1.1 ACL Rules...................................................................................................................................................................1
1.1.2 ACL Classification......................................................................................................................................................1
1.1.3 Matching Order of ACL Rules....................................................................................................................................2
1.1.4 Time Range of an ACL................................................................................................................................................3
1.2 Traffic Classifier.............................................................................................................................................................3
1.2.1 Simple Traffic Classification.......................................................................................................................................3
1.2.2 Complex Traffic Classification....................................................................................................................................4
1.2.3 Logical Relationship between Traffic Classifier Rules...............................................................................................5
1.3 Traffic Behavior..............................................................................................................................................................5
1.4 Traffic Policy..................................................................................................................................................................6
1.5 Simplified ACL..............................................................................................................................................................7
1.6 Reflective ACL...............................................................................................................................................................8
2 Configuration Guide......................................................................9
2.1 Scenario 1: Configuring Priority Mapping.....................................................................................................................9
2.1.1 Networking Description..............................................................................................................................................9
2.1.2 Configuration Roadmap............................................................................................................................................10
2.1.3 Configuration Example.............................................................................................................................................10
2.2 Scenario 2: Configuring Traffic Filtering.....................................................................................................................12
2.2.1 Networking Description............................................................................................................................................12
2.3 Scenario 3: Configuring Traffic Policing.....................................................................................................................15
Contents
2.4 Scenario 4: Configuring QinQ......................................................................................................................................19
2.5 Deployment Precautions...............................................................................................................................................22
2.5.1 Check that Traffic Policies Configured on Chassis Switches Are Applied Successfully..........................................22
2.5.2 ACLs Configured to Control FTP/Telnet/SSH Login Users Discard Packets that Do Not Match the ACLs...........22
3 Troubleshooting..........................................................................24
3.1 Troubleshooting Overview...........................................................................................................................................24
3.2 Traffic Filtering Does Not Take Effect.........................................................................................................................24
3.2.1 Fault Description.......................................................................................................................................................24
3.2.2 Troubleshooting Roadmap.........................................................................................................................................24
3.2.3 Troubleshooting Flowchart........................................................................................................................................25
3.2.4 Troubleshooting Procedure........................................................................................................................................26
3.3 Traffic Policy That Is Configured to Redirect Traffic to the Next Hop Does Not Take Effect....................................28
3.3.1 Fault Description.......................................................................................................................................................28
3.3.2 Troubleshooting Roadmap.........................................................................................................................................28
3.3.3 Troubleshooting Flowchart........................................................................................................................................29
3.3.4 Troubleshooting Procedure........................................................................................................................................29
3.4 Information Collection.................................................................................................................................................30
3.4.1 Network Topology.....................................................................................................................................................30
3.4.2 display Command List...............................................................................................................................................30
3.4.3 Switch Logs and Diagnosis Logs..............................................................................................................................31
4 Troubleshooting Cases.................................................................33
4.1 After Traffic Filtering Is Configured, Traffic Fails To Be Forwarded As Expected.....................................................33
4.1.1 Symptom and Networking.........................................................................................................................................33
4.1.2 Root Cause.................................................................................................................................................................34
4.1.3 Identification Method................................................................................................................................................34
4.1.4 Solution......................................................................................................................................................................34
4.1.5 Summary....................................................................................................................................................................35
4.2 After a Traffic Policy Is Configured to Redirect Traffic to the Next Hop, Services Are Interrupted...........................35
4.2.1 Symptom and Networking.........................................................................................................................................35
4.2.2 Root Cause.................................................................................................................................................................36
4.2.3 Identification Method................................................................................................................................................36
4.2.4 Solution......................................................................................................................................................................37
4.2.5 Summary....................................................................................................................................................................37
5 FAQ............................................................................................ 38
5.1 Does the S7700/S9700 Support Inter-Card Redirection? How Do I Configure This Function?.................................38
5.2 Why Is CAR Rate Limiting Inaccurate?.......................................................................................................................38
5.3 How Is PBR Implemented on S-series Switches?........................................................................................................39
5.4 The Traffic Behavior Is Not Set to deny, but Traffic is Discarded, Why?....................................................................39
Contents
5.5 How Do I Use a User-defined ACL?............................................................................................................................39
5.6 How Do I Know About ACL Resource Usage?...........................................................................................................40
A Acronyms and Abbreviations.......................................................41
S Series Switches
Feature Start - ACL
1 ACL Overview
ACL Overview
1.1 Introduction to ACL

1.1.1 ACL Rules
An Access Control List (ACL) is a set of ordered rules. The switch classifies data packets by
matching information in the data packets with ACL rules and allows or rejects the data
packets.
An ACL rule can filter packets based on the 5-tuple (protocol type, source IP address,
destination IP address, source port number, and destination port number).
1.1.2 ACL Classification

Table 1.1.2.1.1.1.1.1 ACL classification
Classification
Rule
Categor
y
Usage Scenario
Description
Support
for
IPv4 and IPv6
ACL4
IPv4
ACL4
and
ACL6
commands are different.
ACL6
IPv6
ACL4
and
ACL6
commands are different.
Numbered
ACL
A numbered ACL is identified

by a unique number, which
can be specified to reference
the ACL.
Named
ACL
A named ACL is identified by

a character string name, which
can be specified to reference
the ACL.
A named ACL can be

specified with an ACL
number. If no ACL
number is specified for a
named ACL, the system
allocates an ACL number
to the named ACL.
Naming mode
Compared with numbered

ACLs, named ACLs are easy
to identify and remember. The
switch supports flexible ACL
naming modes.
ACL4 and ACL6 names

are
unique
and
S Series Switches
Feature Start - ACL
1 ACL Overview
independent
other.
Function
of
each
Basic
ACL
A basic ACL filters packets

based on the source IP
address, fragment flag, and
time range.
Basic ACL numbers

range from 2000 to 2999.
Advanced
ACL
An advanced ACL filters

packets based on the source IP
address,
destination
IP
address, IP precedence, Type
of Service (ToS), DiffServ
Code Point (DSCP) priority,
IP protocol type, ICMP type,
TCP source/destination port,
and UDP source/destination
port.
Advanced ACL numbers

Compared with basic ACLs,

advanced ACLs support more
accurate, diverse, and flexible
rules.
Layer
ACL
Userdefined
ACL
A Layer 2 ACL filters packets

based on the information in
Ethernet frame headers of
packets, such as the source
MAC address, destination
MAC address, and protocol
type in an Ethernet frame.
Layer 2 ACL numbers

A user-defined ACL matches

information in the packets
according to the offset position
and offset value.
User-defined
ACL
numbers range from 5000
to 5999.
1.1.3 Matching Order of ACL Rules

An ACL is composed of a list of rules. Each rule contains a deny or permit clause. These
rules may overlap or conflict. One rule can contain another rule, but the two rules must be
different. The matching order determines the priorities of ACL rules. The switch supports two
types of matching order: configuration order and automatic order.
Configuration order: ACL rules are matched in the order in which they were configured.
The rule that was configured first is matched first. By default, ACL rules are matched in
the configuration order.
Automatic order: The automatic order follows the depth first principle.
According to the depth first principle, a stricter matching condition represents a more accurate
ACL rule. An ACL rule can be configured based on the wildcard of IP addresses. A smaller
wildcard identifies a smaller network segment.
For example, 129.102.1.1 0.0.0.0 specifies a host with the IP address 129.102.1.1, and
129.102.1.1 0.0.0.255 specifies a network segment with addresses ranging from 129.102.1.1
S Series Switches
Feature Start - ACL
1 ACL Overview
to 129.102.1.255. The location defined by 129.102.1.1 0.0.0.0 is more specific than the
location specified by 129.102.1.1 0.0.0.255; therefore, the rule that contains 129.102.1.1
0.0.0.0 is matched first. The detailed standards are as follows:
Basic ACL rules

The rule that defines the smallest source IP address range is matched first.
Advanced IPv4 ACL rules

The rule that defines the smallest range is matched first. The system compares the
protocol range, source IP address, destination IP address, source port number, and
destination port number in an ACL in descending order. Among these items, only when
the former item ranges are the same, the latter item is compared. For example, only when
the protocol ranges of ACL rules are the same, the source IP addresses are compared. If
the preceding ranges are all the same, the rules are matched in the configuration order.
Layer 2 ACL rules

The rule that defines the smallest range is matched first. The system compares the
Ethernet type, source MAC address, destination MAC address, VLAN, 802.1p priorities
in VLAN packets, CVLAN, and 802.1p priorities in CVLAN packets in an ACL in
descending order. Among these items, only when the former item ranges are the same,
the latter item is compared. For example, the source MAC addresses are compared only
when the Ethernet types of ACL rules are the same. If the preceding ranges are all the
same, the rules are matched in the configuration order.
User-defined ACL rules

User-defined ACLs can only be matched in the configuration order.
1.1.4 Time Range of an ACL

Users may want certain ACL rules to be valid during a certain period but invalid out of the
period, that is, the ACL rules are used to filter packets based on the time range. For example,
if employees of a company are prohibited from browsing entertainment websites during
working hours but are allowed to visit these entertainment websites during after-hours using a
specified device, you can configure time ranges for ACL rules to take effect. To implement
this function, configure one or more time ranges, and run the rule command to reference the
time ranges so that packets are filtered based on the configured time ranges.
A time range of an ACL can be an absolute time range or a cycle time range. A cycle time
range is cyclic and takes effect every week. If a cycle time range is configured for an ACL,
the ACL is invalid in a specified period every week or in a certain day or days every week. An
absolute time range specifies a period of time starting from yyyy-mm-dd hh:mm to yyyy-mmdd hh:mm.
1.2 Traffic Classifier

1.2.1 Simple Traffic Classification
Simple traffic classification identifies packets with simple rules, for example, the DSCP field
of IP packets.
Simple traffic classification is implemented based on the following information:
DSCP priority in IP packets
802.1p priority in VLAN packets
S Series Switches
Feature Start - ACL
1 ACL Overview
IP precedence in IP packets
EXP priority in MPLS packets
1.2.2 Complex Traffic Classification

Complex traffic classification identifies packets according to Layer 2 and Layer 3 information
carried by packets or by matching ACL rules. The system then enforces corresponding QoS
policies to the classified packets. The ACL rules can be created based on IP 5-tuple (source IP
address, destination IP address, source port number, destination port number, and the packet
type) and TCP SYN information.
Complex traffic classification rules can be made based on Layer 2 or Layer 3 information.
A switch can perform complex traffic classification according to the following Layer 2 and
Layer 3 information.
Layer 2 information:
VLAN ID in the outer tag of VLAN packets
VLAN ID in the inner tag of VLAN packets
802.1p priority in the outer tag of VLAN packets
802.1p priority in the inner tag of VLAN packets
Double tags in VLAN packets
Source MAC address
Destination MAC address
Outbound interface
Inbound interface
Protocol field encapsulated based on Layer 2 information
Layer 3 information:
DSCP priority in IP packets
IP precedence in IP packets
EXP priority in MPLS packets
TCP SYN flag in TCP packets
IP protocol type (IPv4 or IPv6)
In addition to matching Layer 2 and Layer 3 information, a switch can also perform complex
traffic classification by matching the following information in ACLs:
IP precedence or DSCP priority
Prefix of a source IP address
Prefix of a destination IP address
Protocol number contained in an IP packet
Fragment flag
TCP SYN flag
TCP/UDP source port number or range
TCP/UDP destination port number or range
S Series Switches
Feature Start - ACL
1 ACL Overview
1.2.3 Logical Relationship between Traffic Classifier Rules

The logical relationship between traffic classifier rules can be OR or AND. The default
relationship is OR on chassis switches and AND on box switches.
AND:
Traffic classifier does not contain ACL rules.

All if-match clauses use the AND relationship. Packets match the traffic classifier
only when they match all the if-match clauses.
Traffic classifier contains ACL rules.

The logical relationship is AND among all if-match clauses but OR among all ACL
rules. Packets match the traffic classifier only when the packets match one ACL rule
and all the if-match clauses.
For example, if a traffic classifier specifies the relationship among the following rules
as AND:
if-match dmac 0-0-3
if-match smac 0-0-2
if-match acl 3000 (acl 3000 contains two rules: rule 5 permit ip source 1.1.1.1 0 and
rule 10 permit ip source 2.2.2.2 0)
Only packets that match the rules: dmac=0-0-3, smac=0-0-2, and sip=1.1.1.1 or
dmac=0-0-3, smac=0-0-2, and sip=2.2.2.2 can match the traffic classifier.
OR:
A packet matches a traffic classifier as long as it matches one rule in the traffic classifier.
For example, if a traffic classifier specifies the relationship among the following rules as
OR:
if-match dmac 0-0-3
if-match smac 0-0-2
if-match acl 3000 (acl 3000 contains two rules: rule 5 permit ip source 1.1.1.1 0 and rule
10 permit ip source 2.2.2.2 0)
Packets match the traffic classifier as long as they match any one of the preceding ifmatch clauses.
1.3 Traffic Behavior

A traffic classifier must be associated with a traffic control action or a resource allocation
action such as permit, deny, traffic policing, and re-marking so that the switch can provide
differentiated services. These actions constitute a traffic behavior. A switch provides the
following traffic behaviors based on complex traffic classification:
Permit/Deny
Re-marking
Redirection
Traffic policing
Flow mirroring
Security and traffic statistics
All traffic behaviors except for deny can be used together.
S Series Switches
Feature Start - ACL
1 ACL Overview
Permit/Deny
The permit/deny action is the simplest traffic control action, which allows the switch to
control network traffic by forwarding or discarding packets.
Re-marking
This action sets the precedence field in a packet. Packets carry different priority fields on
various networks. For example, packets carry the 802.1p field in a VLAN, the ToS field
on an IP network, and the EXP field on an MPLS network. Therefore, a switch is
required to mark priority fields of packets based on the network type. Generally, a switch
at the network border re-marks priority fields of incoming packets. Switches within the
network provide QoS services based on the re-marked priority fields, or re-mark the
priority fields based on their own configurations.
Redirection
This action redirects packets to the CPU of a specified interface card, specified interface,
next hop address, or Label Switched Path (LSP) but does not forward packets based on
the original destination IP address. A switch supports multiple next hops. Policy-based
routing (PBR) is implemented based on redirection. A PBR route is a static route. When
the redirect-to next hop is unavailable, the switch forwards packets based on the original
forwarding path.
Traffic policing
This traffic control action limits the traffic rate and the resources used by traffic. By
using traffic policing, the switch can discard excess packets, re-mark the color or
precedence, or take other QoS measures to control the traffic rate.
Traffic mirroring
This action copies the specified data packets to a specified destination to detect and
troubleshoot faults on a network.
Traffic statistics
This action collects statistics on data packets of specified service flows, including the
number of forwarded and discarded packets and bytes that match specified traffic
classification rules. The traffic statistics action is not a QoS control measure but can be
used with other actions to improve security of networks and packets.
1.4 Traffic Policy

Packets can be classified according to Layer 2 information, Layer 3 information, or ACLs. To
provide differentiated services for service flows, you must bind a traffic classifier and a traffic
behavior to a traffic policy and apply the traffic policy. After a traffic classifier and traffic
behavior are created, they must be bound to a traffic policy and applied to a specific interface
or VLAN, or applied globally to take effect.
After a traffic policy is applied, the system delivers ACLs to the chip. The delivering
sequence or grouping of ACLs determines the order in which traffic policy rules are matched.
You can run the traffic policy policy-name [ match-order { auto | config } ]command on a
switch to specify the matching order. If the matching order is set to auto, rules are matched
based on priorities of traffic classifiers predefined on the system. The priority order is: Layer
2 and Layer 3 information > Layer 2 information > Layer 3 information. If the matching order
is set to config, rules are matched in the order in which traffic classifiers were configured.
Switches that do not support the config mode use the auto matching order by default.
S Series Switches
Feature Start - ACL
1 ACL Overview
1.5 Simplified ACL

To make a traffic policy effective, you need to configure ACLs, traffic classifiers, and traffic
behaviors, bind the traffic classifiers and traffic behaviors to the traffic policy, and apply it
globally to interfaces or VLANs. Box switches support simplified ACLs, which enables a
simple configuration process. You only need to configure an ACL and bind the ACL to
simplified ACL commands such as traffic-filter to make it effective. Simplified ACL
commands include traffic-filter, traffic-limit, traffic-mirror, traffic-redirect, trafficremark, and traffic-statistics. The traffic-redirect command redirects packets to the
specified interface, CPU, or next hop. The traffic-remark command re-marks the information
including the 802.1p priority, DMAC, DSCP, IP precedence, local precedence, and VLANs.
Table 1 describes simplified ACL commands supported on different models.
Table 1.5.1.1.1.1.1.1 Support for simplified ACL commands
Simplified
ACL
Command
2700- EI
2752 -EI
3700-SI
3700-EI
3700-HI
5700- SI
traffic-filter
Supported
Supported
Supported
Supported
Supported
Supported
traffic-limit
Supported
Supported
Supported
Supported
Supported
Supported
traffic-mirror
Supported
Supported
Supported
Supported
Supported
Supported
traffic-redirect
Not Supported
Supported
Supported
Supported
Supported
Does not
support
redirection to
the next hop.
traffic-remark
Does not support

re-marking of
DMAC/CVLAN/I
P precedence.
Does not
support remarking of
CVLAN.
Does not
CVLAN.
Does not
CVLAN.
Supported
Does not
DMAC/CVLA
N.
traffic-statistics
Supported
Supported
Supported
Supported
Supported
Supported
Simplified
ACL
Command
5700S-LI
5700-LI
5710-EI
5710-HI
6700-EI
5700- HI
5700- EI
traffic-filter
Supported
Supported
Supported
Supported
Supported
Supported
Supported
traffic-limit
Supported
Supported
Supported
Supported
Supported
Supported
Supported
traffic-mirror
Supported
Supported
Supported
Supported
Supported
Supported
Supported
traffic-redirect
Does not
support
redirection
to the next
hop.
Does not
support
redirection
to the next
hop.
Supported
Supported
Supported
Supported
Supported
traffic-remark
Does not
Does not
Supported
Supported
Supported
Supported
Supported
S Series Switches
Feature Start - ACL
trafficstatistics
1 ACL Overview
DMAC/CV
LAN.
DMAC/C
VLAN.
Supported
Supported
Supported
Supported
Supported
Supported
Supported
1.6 Reflective ACL

Users from a public network are denied access to a private network but sometimes are
required to send data back to the private network after a user on the private network accesses
the public network.
After a reflective ACL is configured, request packets initiated by an external network user
cannot enter the internal network. When a user on the internal network sends a request packet
to a user on the external network, a reflective ACL entry is generated on the interface
according to the source IP address, destination IP address, and port number in the packet.
Then the user on the external network can access the user on the internal network.
As shown in Figure 1.6.1.1.1.1.1, PC b on the external network cannot initially access PC a
on the internal network. After PC a sends a packet with the source IP address IPa, source
interface Porta, destination IP address IPb, and destination interface Portb to PC b, the switch
with reflective ACL configured generates a reflective ACL rule that permits packets with the
source IP address IPb, source interface Portb, destination IP address IPa, and destination
interface Porta to pass through.
Figure 1.6.1.1.1.1.1 Reflective ACL
Configuration Guide
2.1 Scenario 1: Configuring Priority Mapping

2.1.1 Networking Description
As shown in Figure 2.1.1.1.1.1.1, the switch connects to a router through GE2/0/1. Enterprise
branches 1 and 2 access the network through the switch and router. Enterprise branch 1
belongs to VLAN 100 and enterprise branch 2 belongs to VLAN 200. Enterprise branch 1
requires better QoS guarantee. Priorities of packets from enterprise branches 1 and 2 are
mapped to 4 and 2 respectively so that differentiated services are provided.
Figure 2.1.1.1.1.1.1 Networking diagram of priority mapping based on simple traffic classification
2.1.2 Configuration Roadmap

The configuration roadmap is as follows:
1.
Create VLANs and configure interfaces so that enterprise branches 1 and 2 can connect to the network
through the switch.
2.
Create traffic classifiers to classify service flows from different VLANs and configure priority mapping as
the traffic behavior.
3.
Bind traffic policies to GE1/0/1 and GE1/0/2 on the switch respectively.
2.1.3 Configuration Example

Step 1 Create VLANs and configure interfaces.
# Create VLANs 100, 200, and 300.
< Switch > system-view
[Switch] vlan batch 100 200 300
# Configure GE1/0/1, GE1/0/2, and GE2/0/1 as trunk interfaces, add GE1/0/1 and GE1/0/2 to
VLAN 100 and VLAN 200, and add GE2/0/1 to VLAN 100, VLAN 200, and VLAN 300.
[Switch] interface gigabitethernet1/0/1
[Switch-GigabitEthernet1/0/1] port link-type trunk
[Switch-GigabitEthernet1/0/1] port trunk allow-pass vlan 100
[Switch-GigabitEthernet1/0/1] quit
[Switch-GigabitEthernet1/0/2] port trunk allow-pass vlan 200
[Switch-GigabitEthernet2/0/1] port trunk allow-pass vlan 100 200 300
Step 2 Configure traffic classifiers.

# Configure traffic classifiers c1, c2, and c3 on the switch to classify different service flows
from the enterprise based on VLAN ID.
[Switch] traffic classifier c1
[Switch-classifier-c1] if-match vlan-id 100
[Switch-classifier-c1] quit

Step 3 Configure traffic behaviors.

# Configure traffic behaviors b1 and b2 on the switch to map priorities of different service
flows.
[Switch] traffic behavior b1
[Switch-behavior-b1] remark 8021p 4
[Switch-behavior-b1] quit
[Switch-behavior-b2] remark 8021p 2
Step 4 Configure traffic policies.

# Configure traffic policies on the switch, bind the traffic behaviors and traffic classifiers to
the traffic policies, and apply the traffic policies to GE1/0/1 and GE1/0/2.
[Switch] traffic policy p1
[Switch-trafficpolicy-p1] classifier c1 behavior b1
[Switch- trafficpolicy-p1] quit
[Switch- trafficpolicy-p2] classifier c2 behavior b2
[Switch] interface gigabitethernet 1/0/1
[Switch-GigabitEthernet1/0/1] traffic-policy p1 inbound
Step 5 Verify the configuration.

# Check information about the applied traffic policies. The traffic policy p1 is used as an
example.
[Switch]display traffic classifier user-defined c1
User Defined Classifier Information:
Classifier: c1
Precedence: 10
Operator: OR
Rule(s) : if-match vlan-id 100
[Switch]display traffic behavior user-defined b1
User Defined Behavior Information:
Behavior: b1
Remark:
Remark 8021p 4
[Switch]display traffic policy user-defined p1
User Defined Traffic Policy Information:
Policy: p1
Classifier: c1
Operator: OR
Behavior: b1
Remark:
Remark 8021p 4
[Switch]display traffic-policy applied-record p1
------------------------------------------------Policy Name:
p1
Policy Index:
Classifier:c1
Behavior:b1
------------------------------------------------*interface GigabitEthernet1/0/1
traffic-policy p1 inbound
slot 1
success
------------------------------------------------Policy total applied times: 1.

[Switch]
----End
Configuration Files
Configuration file of the switch
#
sysname Switch
#
vlan batch 100 200 300
#
traffic classifier c1 operator or precedence 10
if-match vlan-id 100
#
traffic behavior b1
remark 8021p 4
traffic behavior b2
remark 8021p 2
traffic behavior test
#
traffic policy p1
classifier c1 behavior b1
traffic policy p2
#
interface GigabitEthernet1/0/1
port link-type trunk
port trunk allow-pass vlan 100
#

port trunk allow-pass vlan 200
#
port trunk allow-pass vlan 100 200 300
#
return
2.2 Scenario 2: Configuring Traffic Filtering

In Figure 2.2.1.1.1.1.1, the switch connects to users through GE1/0/1 and connects to a server
through GE2/0/1. It is required that users connected to the switch do not communicate with
each other and only communicate with the server.
Figure 2.2.1.1.1.1.1 Networking diagram of traffic filtering based on complex traffic classification

1.
Configure an ACL rule to match packets with the source IP address 192.168.0.1/24 and
destination IP address 192.168.2.100.
2.
Configure a traffic classifier to match the ACL.
3.
Configure a traffic policy, bind the traffic classifier and traffic behavior to the traffic
policy, and apply the traffic policy to the inbound direction of GE1/0/1.

Step 1 Configure an ACL.
# Configure advanced ACL 3000 on the switch to permit only packets with the source IP
address 192.168.1.0/24 and destination IP address 192.168.2.100 and deny other IP packets.
[Switch] acl 3000
[Switch-acl-adv-3000] rule 1 permit ip source 19.168.1.0 0.0.0.255 destination
192.168.2.100 0
[Switch-acl-adv-3000] rule 2 deny ip
[Switch-acl-adv-3000] quit
Step 2 Configure a traffic classifier.

Create a traffic classifier c1 on the switch to match ACL 3000.
[Switch-classifier-c1] if-match acl 3000
Step 3 Configure a traffic behavior.

# Create a traffic behavior b1 on the switch and configure no action.
Step 4 Configure a traffic policy and apply the traffic policy to the interface.
# Create a traffic policy p1 on the switch and bind the traffic classifier and traffic behavior to
the traffic policy.
[Switch-trafficpolicy-p1] quit
# Apply the traffic policy p1 to GE1/0/1.

[Switch] quit

# Check the traffic policy configuration.
<Switch> display acl 3000
Advanced ACL 3000, 2 rules
Acl's step is 5
rule 1 permit ip source 19.168.1.0 0.0.0.255 destination 192.168.2.100 0
rule 2 deny ip
<Switch> display traffic classifier user-defined
Classifier: c1
Precedence: 10
Operator: OR
Rule(s) : if-match acl 3000Total classifier number is 1
<Switch> display traffic policy user-defined p1
Policy: p1
Classifier: c1
Operator: OR
Behavior: b1
-None<Switch>display traffic-policy applied-record
#
------------------------------------------------Policy Name:
p1
Policy Index:
Classifier:c1
Behavior:b1
slot 1
success

#
----End
Configuration Files
#
sysname Switch
#
vlan batch 20
#
acl number 3000
rule 1 permit ip source 19.168.1.0 0.0.0.255 destination 192.168.2.100 0
rule 2 deny ip
#
if-match acl 3000
#
traffic behavior b1
#
traffic policy p1
#
#
return
2.3 Scenario 3: Configuring Traffic Policing

After classifying traffic into different types, the switch limits the rate of traffic matching
traffic classifier rules. Traffic policing discards excess traffic to limit traffic within a proper
range and to protect network resources and carriers' interests.

As shown in Figure 2.3.1.1.1.1.1, the switch connects to the router through GE2/0/1;
enterprise users can access the network through the switch and router. Enterprise voice
services, video services, and data services belong to VLAN 120, VLAN 110, and VLAN 100
respectively. On the switch, traffic policing needs to be performed on packets of different

services to limit traffic within a proper range and provide bandwidth guarantee for services.
Figure 2.3.1.1.1.1.1 Networking diagram of traffic policing based on complex traffic classification

1.
Create VLANs and configure interfaces on the switch so that enterprise users can access
the network.
2.
Configure traffic classifiers on the switch to classify packets based on their VLAN IDs.
3.
Create a traffic policy on the switch, bind traffic behaviors and traffic classifiers to the
traffic policy, and apply the traffic policy to the interface connecting enterprise users to
the switch.

# Create VLANs 100, 110, and 120 on the switch.
<Quidway> system-view
[Quidway] sysname Switch
[Switch] vlan batch 100 110 120
# Configure GE1/0/1 and GE2/0/1 as trunk interfaces and add them to VLAN 100, VLAN
110, and VLAN 120.

Step 2 Configure traffic classifiers.

# Configure traffic classifiers c1, c2, and c3 on the switch to classify different service flows
from the enterprise based on VLAN IDs.
Step 3 Configure traffic policing.

# Configure traffic behaviors b1, b2, and b3 on the switch to perform traffic policing on
different service flows.
[Switch-behavior-b1] car cir 2000 pir 10000
Step 4 Configure a traffic policy and apply the traffic policy to an interface.
# Create a traffic policy p1 on the switch, bind the traffic behaviors and traffic classifiers to
the traffic policy, and apply the traffic policy to the inbound direction of GE1/0/1 to perform
traffic policing and re-mark priorities on packets from the enterprise.

[Switch-trafficpolicy-p1] quit

# Check information about the traffic policy.
[Switch] display traffic classifier user-defined
Classifier: c2
Precedence: 15
Operator: OR
Classifier: c3
Precedence: 20
Operator: OR
Classifier: c1
Precedence: 10
Operator: OR
Total classifier number is 3
[Switch] display
traffic behavior user-defined

Behavior: b2
Committed Access Rate:
CIR 4000 (Kbps), PIR 10000 (Kbps), CBS 500000 (byte), PBS 1250000 (byte)
Color Mode: color Blind

Conform Action: pass
Yellow
Action: pass
Exceed
Action: discard
Behavior: b3
Yellow
Action: pass
Exceed
Action: discard
Behavior: b1
Yellow
Action: pass
Exceed
Action: discard
Total behavior number is 3

[Switch] display traffic policy user-defined p1
Policy: p1
Classifier: c1
Operator: OR
Behavior: b1
Yellow
Action: pass
Exceed
Action: discard
Classifier: c2
Operator: OR
Behavior: b2
Yellow
Action: pass
Exceed
Action: discard
Classifier: c3
Operator: OR
Behavior: b3
Yellow
Action: pass
Exceed
Action: discard
----End
Configuration Files
#
sysname Switch
#
vlan batch 100 110 120
#

#
traffic behavior b1
car cir 2000 pir 10000 cbs 250000 pbs 1250000 mode color-blind green pass yello
w pass red discard
traffic behavior b2
w pass red discard
traffic behavior b3
w pass red discard
#
traffic policy p1
#
#
#
return
2.4 Scenario 4: Configuring QinQ

As shown in Figure 2.4.1.1.1.1.1, enterprise A has two offices and uses VLAN 10. The
enterprise expects that some internal users in two offices can communicate through the carrier
network.
Figure 2.4.1.1.1.1.1 Networking diagram of QinQ based on traffic classifiers

The configuration roadmap for configuring QinQ on SWITCH 1 is as follows:
1.
Create VLANs and configure interfaces so that enterprise users can access the network
through the switch.
2.
Configure a traffic classifier on the switch to classify packets based on their IP addresses
and configure a traffic behavior to add a VLAN tag.
3.
Bind the traffic behavior and traffic classifier to a traffic policy and apply the traffic
policy to the inbound direction of interfaces.

# Create VLAN 10 and VLAN 20.
< Switch > system-view
[Switch] vlan batch 10 20
# Configure GE1/0/1 and GE1/0/2 as hybrid interfaces and add GE1/0/1 to VLAN 10 and
VLAN 2 to VLAN 20.
[Switch-GigabitEthernet1/0/1] port hybrid tagged vlan 10
[Switch-GigabitEthernet1/0/1] port hybrid untagged vlan 20
[Switch-GigabitEthernet1/0/2] port hybrid tagged vlan 20
Step 2 Configure a traffic classifier.

# Configure a traffic classifier c1 on the switch to add a VLAN tag to packets from
10.10.10.1/24.
[Switch]acl 3000
[Switch -acl-adv-3000]rule 1 permit ip source 10.10.10.1 0.0.0.255
[Switch -acl-adv-3000]quit
[Switch-classifier-c1] if-match acl 3000
Step 3 Configure a traffic behavior.

# Create a traffic behavior b1 on the switch to add a tag to packets.
[Switch-behavior-b1] nest top-most vlan-id 20
Step 4 Configure a traffic policy.

# Configure a traffic policy on the switch, bind the traffic behavior and traffic classifier to the
traffic policy, and apply the traffic policy to GE1/0/1 and GE1/0/2.

# Check information about the traffic policy.
[Switch] display traffic classifier user-defined

Classifier: c1
Precedence: 60
Operator: OR
Rule(s) : if-match acl 3000
Total classifier number is 1
[Switch] display
traffic behavior user-defined

Behavior: b1
Nest:
Nest top-most vlanid 20
Total behavior number is 1
[Switch] display traffic policy user-defined p1
Policy: p1
Classifier: c1
Operator: OR
Behavior: b1
Nest:
Nest top-most vlanid 20
[Switch]display traffic-policy applied-record p1
------------------------------------------------Policy Name:
p1
Policy Index:
Classifier:c1
Behavior:b1
slot 1
success
----End
Configuration Files
#
sysname Switch
#
vlan batch 10 20
#
acl number 3000
rule 1 permit ip source 10.10.10.0 0.0.0.255
#
if-match acl 3000
#
traffic behavior b1
nest top-most vlan-id 20
#
traffic policy p1
#
port hybrid tagged vlan 10
port hybrid untagged vlan 20
#
port hybrid tagged vlan 20
#
return
2.5 Deployment Precautions

2.5.1 Check that Traffic Policies Configured on Chassis
Switches Are Applied Successfully
Description: Chassis switches V100R002 generate configurations for traffic policies that fail
to be delivered. No info message is displayed to indicate that traffic policies fail to be
delivered. Users may mistakenly consider that these traffic policies are successfully applied.
Root cause: Chassis switches V100R002 can dynamically update traffic policy information
and generate configurations even if traffic policies fail to be applied. The system only records
application failure information in logs but displays no info message.
Identification method: Run the display traffic-policy xxx applied-record command.
Solution: Run the display traffic-policy xxx applied-record command to check that
application status of the traffic policy is displayed as success.
Versions involved: V100R002
2.5.2 ACLs Configured to Control FTP/Telnet/SSH Login

Users Discard Packets that Do Not Match the ACLs
Description: When ACLs are referenced by upper layer software to control FTP/Telnet/SSH
login users, packets that do not match the ACLs are discarded.
Root cause: There are hardware ACLs and software ACLs. Hardware ACLs are implemented
through the chip and delivered to the chip through the traffic policies. Hardware ACLs do not
process packets that do not match the ACLs. When software ACLs are referenced by upper
layer software to control FTP/Telnet/SSH login users, packets that do not match the ACLs are
discarded. Hardware and software ACLs are implemented differently. Ensure that you
configure correct ACLs.
Identification method: Run the display acl xxx command.
Solution: Run the display acl xxx command to check ACL configurations and ensure that
correct ACLs are bound to FTP/Telnet/SSH.
Versions involved: All versions
Troubleshooting
3.1 Troubleshooting Overview

ACL is a most commonly deployed feature. Common ACL faults include:
Traffic filtering does not take effect.
The traffic policy that is configured to redirect traffic to the next hop does not take effect.
This chapter describes methods to troubleshoot these ACL faults.
3.2 Traffic Filtering Does Not Take Effect

3.2.1 Fault Description
Traffic filtering is configured to control packet forwarding on the existing network. Only
specified traffic is allowed to pass through and other traffic is denied. However, traffic is not
forwarded as required in actual scenarios.
3.2.2 Troubleshooting Roadmap

The troubleshooting roadmap is as follows:
1.
Check whether traffic filtering configurations such as the subnet mask are correct on the
interface and whether traffic policies are successfully applied.
2.
Check whether traffic forwarding fails because of other configurations.
3.
Configure the traffic statistics function and traffic classifiers to check whether packets
are received on the inbound interface.
4.
Configure the traffic statistics function and traffic classifiers to check whether packets
are received on the outbound interface.
3.2.3 Troubleshooting Flowchart

Figure 3.2.3.1.1.1.1 Troubleshooting flowchart
3.2.4 Troubleshooting Procedure

Step 1 Check traffic policy configurations.
If the traffic classifier contains ACL rules, check whether ACL rules are correctly configured
and whether logical relationship of the traffic classifier is correct. If the traffic classifier
contains Layer 2 and Layer 3 information, check whether traffic polices based on Layer 2 and
Layer 3 information are correctly configured and applied successfully.
<Switch> display acl
<Switch> display traffic classifier user-defined
<Switch> display traffic behavior user-defined
<Switch> display traffic policy user-defined
Step 2 Configure the traffic statistics function to check whether the switch receives packets.
Configure a traffic classifier to match corresponding packets and configure a traffic behavior
to collect traffic statistics. The following example collects traffic statistics on packets with the
source IP address 192.168.0.1.
#
acl number 3000
rule 1 permit ip source 192.168.0.1 0
#
traffic classifier test operator and
if-match acl 3000
#
statistic enable
#
traffic policy test
classifier test behavior test
#
traffic-policy test inbound
#
Check whether statistics on corresponding packets can be collected. If so, packets with the
source IP address 192.168.0.1 are received by the local device. If not, the packets do not reach
the local device.
display traffic policy statistics interface GigabitEthernet 0/0/1 inbound
Interface: GigabitEthernet0/0/1
Traffic policy inbound: test
Rule number: 1
Current status: OK!
Board : 0
Item
Packets
Bytes
--------------------------------------------------------------------Matched
+--Passed
+--Dropped
+--Filter
+--URPF
+--CAR
Step 3 Configure the traffic statistics function to check whether packets are received by the outbound
interface.
The method to configure the traffic statistics function is the same as that in step 2. After the
traffic policy is configured, apply it to the outbound direction of the outbound interface.
#
acl number 3000
#
if-match acl 3000
#
#
if-match 8021p 3
#
statistic enable
#
traffic policy test
classifier test behavior test

#
traffic-policy test outbound
#
Check whether statistics on corresponding packets are collected. If so, packets have been sent
from the outbound interface. If not, packets are discarded by the device.
display traffic policy statistics interface GigabitEthernet 0/0/2 outbound
Interface: GigabitEthernet0/0/2
Traffic policy outbound: test
Rule number: 1
Current status: OK!
Board : 0
Item
Packets
Bytes
--------------------------------------------------------------------Matched
+--Passed
+--Dropped
+--Filter
+--URPF
+--CAR
Step 4 Check whether other configurations affect traffic forwarding.

Check configurations that match the information in the traffic classifier and whether these
configurations on VLAN interfaces affect packet forwarding.
----End
3.3 Traffic Policy That Is Configured to Redirect

Traffic to the Next Hop Does Not Take Effect
3.3.1 Fault Description
A traffic policy is configured to redirect traffic to the next hop so that traffic is forwarded
along the specified path. However, the configuration does not take effect.
3.3.2 Troubleshooting Roadmap

The troubleshooting roadmap is as follows:
1.
Check whether the traffic policy is configured correctly.
2.
Check that the redirect-to-next hop exists.
3.
Configure the traffic statistics function to check that packets are sent to the next hop.
3.3.3 Troubleshooting Flowchart

Figure 3.3.3.1.1.1.1 Troubleshooting flowchart
3.3.4 Troubleshooting Procedure

Step 1 Check whether the traffic policy is configured correctly.
Run the following command:

display traffic-policy test applied-record
------------------------------------------------Policy Name:
test
Policy Index:
Classifier:test
Behavior:test
traffic-policy test inbound
slot 0
success
Step 2 Check whether the redirect-to-next hop exists.

Check whether the redirect-to-next hop exists based on the outbound interface. If not, traffic
redirection cannot take effect. If so, find out the reasons why the upstream device does not
send an ARP packet.
display arp interface GigabitEthernet 0/0/10
IP ADDRESS
MAC ADDRESS
EXPIRE(M) TYPE INTERFACE
VPN-INSTANCE
VLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------Total:0
Dynamic:0
Static:0
Interface:0
Step 3 Configure the traffic statistics function to check whether packets are received by the next hop
device.
Configure a traffic behavior to collect traffic statistics in the traffic policy and check whether
packet statistics can be collected. If so, packets are received by the next hop device. If not, the
next hop device does not receive any packet.
----End
3.4 Information Collection

If the fault cannot be located, collect the following information. If non-Huawei devices are
involved, collect information according to the command reference.
3.4.1 Network Topology

Collect network topology information including device names, system MAC addresses, and
names of connected interfaces.
3.4.2 display Command List

Command
Description
display version
Displays version information.
display device
Displays device status.
display patch-information
Displays patch information.
display cpu-usage (slot slot-id)
Displays CPU usage.
display memory-usage (slot slot-id)
Displays memory usage.
display current-configuration
Displays the device configuration.
display interface
Displays traffic on all ports every 5 minutes or

twice.
display traffic policy statistics interface

GigabitEthernet 0/0/x inbound/outbound
Displays traffic statistics.
display arp interface GigabitEthernet

0/0/x
Display ARP information on the interface.
3.4.3 Switch Logs and Diagnosis Logs
Chassis switches
Command for collecting diagnosis information:

display diagnostic-information
Log files and diagnosis logs

Step 1: Run the save logfile command in the common view to save the configuration
file.
Step 2: Run the save diag-logfile command in the hidden view (diagnosis view in
V200R001 and a later version) to save the diagnosis log file.
Step 3: Start the FTP server on the PC and download the primary log files and
diagnosis log files to the PC.
Log files of the active MPUs on an S9700 or S7700 series are stored in Cfcard:/logfile, and those of
the standby MPUs are stored in slave#cfcard:/logfile.
The following table lists log file names.
Version
Log File Name
Diagnosis File Name
V100R002
log.txt
diag.txt
V100R003
log.log
log.dblg
V100R006
log.log
log.dblg
V200R001
log.log
log.dblg
Log files and diagnosis log files of the active MPUs are mandatory. If a fault triggers a switchover or
the standby MPUs fail, you must collect log files and diagnosis log files of the standby MPUs. If a
CSS is torn down, collect log files and diagnosis log files on the four MPUs.
When the size of a log file exceeds the threshold, the switch automatically archives the log file and
saves it as a .zip file. For example, 2012-11-27.05-00-25.log.zip and 2012-11-15.05-22-32.diag.zip
are respectively an archived log file and a diagnosis log file. The file name indicates the archiving
time. Therefore, collect the log file and diagnosis log file generated when the fault occurs.
If the FTP server is unavailable, run the more command, such as more log.log. To collect diagnosis
log files of V100R003 or later, run the display diag-logfile command in the hidden view
(V100R003/V100R006) or diagnosis view (V200R001 or later), for example, display diag-logfile
cfcard:/logfile/log.dblg. It takes a long time to collect a large log file. FTP is recommended for
downloading log files.
Box switches
Command for collecting diagnosis information:

display diagnostic-information
Logs
In V100R003 and V100R005:
Step 1: Run the display logbuffer command to collect information in the log buffer.
Step 2: Run the display trapbuffer command to collect information in the trap
buffer.
Box switches support log file recording from V100R006; therefore, perform the
following operations to collect log files:
Step 1: Run the save logfile command in the common view to save the configuration
file.
Step 2: Start the FTP server on the PC and download the primary log files and
diagnosis log files to the PC.
Log files of box switches are saved in flash:/syslogfile and flash:/resetinfo.
If a CSS is torn down or fails to be reset, collect log files of all devices in the CSS.
Box switches have only a small number of log files. Send all files in directories syslogfile and
resetinfo to R&D for analysis.
Directories syslogfile or resetinfo may not exist on some models due to hardware restrictions, so
you do not need to collect log files.
Troubleshooting Cases
4.1 After Traffic Filtering Is Configured, Traffic Fails To

Be Forwarded As Expected
4.1.1 Symptom and Networking
As shown in Figure 4.1.1.1.1.1.1, the clients connect to the switch through interfaces in
different VLANs. All the clients are on the same network segment 192.167.0.1/16. ACLs are
configured to prohibit Layer 3 communications among the clients. However, packets from a
client can still be forwarded by the switch to another client.
Figure 4.1.1.1.1.1.1 Networking diagram
Related configurations:
acl number 3999
rule 0 permit ip destination 192.167.0.0 0.0.255.255
#
traffic classifier denyacl operator or precedence 65535
if-match acl 3999

#
Traffic behavior deny
Deny
#
Traffic policy miwangacl
Classifier denyacl behavior deny
#
user-bind mac-address 286e-d488-cf71 interface gigabitethernet 1/0/1
description connect N001
port link-type access
port default vlan 1150
traffic-policy miwangacl inbound
port-mirroring to observe-port 1 inbound
port-mirroring to observe-port 1 outbound
#
ip source check user-bind enable
#

4.1.2 Root Cause

The system delivers ACL rules for static binding entries. On the S7700, such ACL rules
delivered for service features take precedence over user-defined ACL rules. If traffic matches
both a user-defined ACL and a static binding entry with conflicting actions, the action
specified by the static binding entry takes effect. In this example, the static binding entry takes
effect for the traffic and therefore traffic is still forwarded after a traffic filtering policy is
configured.
4.1.3 Identification Method

1.
Check whether the traffic policy is applied successfully.
2.
Check whether there are configurations that affect traffic forwarding.
4.1.4 Solution
Upgrade the device to V2R1 or a later version. If the traffic behavior is set to deny, the
system performs the action drop for the traffic matching the user-defined ACL. In a version
earlier than V2R1, the system performs the dropcancel action for the traffic that matches a
static binding entry. The two actions conflict with each other. On the S7700, the ACL rules of
service features take precedence over the user-defined ACL rules. Therefore, the action
specified by the static binding entry takes effect and traffic is still forwarded. In V2R1 and a
later version, the S7700 delivers ACL rules of static binding entries only to match
IP/VLAN/MAC information but no longer to deliver actions, which prevents action conflict
between the user-defined ACLs and binding entries. Actions configured in user-defined ACLs
are then executed and traffic is discarded.
4.1.5 Summary
If traffic filtering does not take effect, check whether configurations of other features affect
traffic forwarding.
4.2 After a Traffic Policy Is Configured to Redirect

Traffic to the Next Hop, Services Are Interrupted
4.2.1 Symptom and Networking
A traffic policy is configured on the S7706 to redirect packets with the source IP address
100.25.8.10 to the next hop address 192.168.15.20. However, no packet is received by the
next hop device.
Figure 4.2.1.1.1.1.1 Networking diagram
Related configurations:
acl number 3100
traffic classifier tcCorpApnRadiusUp precedence 100

if-match acl 3100
traffic classifier tcCorpApnSvr1101 precedence 1101

traffic behavior bCorpApnRadius1101

redirect vpn-instance CorpApn1101 ip-nexthop 192.168.15.20
traffic behavior bCorpApnSvr1101

redirect vpn-instance CorpApn1101 ip-nexthop 192.168.15.10
traffic policy tpCorpApn1101

classifier tcCorpApnRadiusUp behavior bCorpApnRadius1101
classifier tcCorpApnSvr1101 behavior bCorpApnSvr1101
vlan 1101
traffic-policy tpCorpApn1101 inbound
4.2.2 Root Cause

The specified next-hop address does not exist or the traffic policy is set to auto, causing
incorrect ACL rule matching.
4.2.3 Identification Method

Step 1 Check whether the traffic policy with redirect-to-next-hop behavior is correctly configured.
display traffic-policy applied-record tpCorpApn1101
-------------------------------------------------Policy Name:
tpCorpApn1101
Policy Index:
10
Classifier:tcCorpApnRadiusUp
Classifier:tcCorpApnSvr1101
Behavior:bCorpApnRadius1101
Behavior:bCorpApnSvr1101
------------------------------------------------*vlan 1101
traffic-policy tpCorpApn1101 inbound
slot 1
success
slot 3
success
slot 4
success
Step 2 Check whether the redirect-to-next hop exists. If the following information is displayed, the
next hop does not exist.
display arp interface Vlanif 1501
IP ADDRESS
MAC ADDRESS
EXPIRE(M) TYPE
INTERFACE
VPN-INSTANCE
VLAN/CEVLAN
-----------------------------------------------------------------------------192.168.15.1
101b-5498-000f
I -
Vlanif1501
-----------------------------------------------------------------------------Total:1
Dynamic:0
Static:0
Interface:1
Step 3 Check whether the downstream device correctly sends the ARP packet that carries the nexthop address. If not, the local device cannot learn the ARP entry. In this case, modify
configurations on the downstream device. If the local device learns the next-hop address in
the ARP entry but packets are forwarded to the interface 192.168.15.10 rather than the
interface 192.168.15.20, the packets incorrectly match classifier tcCorpApnRadiusUp
behavior bCorpApnRadius1101. This is because packets carry VLAN 1101 and the
matching order of traffic policy rules is auto by default. In auto mode, a Layer 2 ACL has a
higher priority than a Layer 3 ACL on chassis devices; therefore, the packets preferentially
match a Layer 2 ACL.
----End
4.2.4 Solution
Modify configurations on the downstream device so that the downstream device can
correctly send ARP packets.
Set the matching order of traffic policy rules to config.
4.2.5 Summary
Note that priorities of traffic classifiers are not the order in which packets were matched.
If traffic is not received on the redirect-to-next-hop device, check whether the device
learns the ARP entry of the next-hop address.
Set the matching order of traffic policy rules to config so that rules are matched in the
order in which they were configured.
FAQ
5.1 Does the S7700/S9700 Support Inter-Card

Redirection? How Do I Configure This Function?
The S7700 and S9700 support inter-card redirection for incoming traffic and can redirect the
packets that match certain rules to the CPU, an interface, or an IP address. Do as follows to
configure the redirection function:
Configure an ACL.
[Quidway] acl number 3000
[S7700-acl-adv-3000] rule 0 permit ip source 192.168.1.1 0
Configure a traffic classifier.

[Quidway] traffic classifier 3000
[QUIDWAY-classifier-3000] if-match acl 3000
Configure a traffic behavior.

[Quidway] traffic behavior 3000
[Quidway-behavior-3000] redirect interface GigabitEthernet 4/0/0
Configure a traffic policy.

[Quidway] traffic policy 3000
[Quidway-trafficpolicy-3000] classifier 3000 behavior 3000
Apply the traffic policy to an interface.

[Quidway-GigabitEthernet3/0/0] traffic-policy 3000 inbound
5.2 Why Is CAR Rate Limiting Inaccurate?

The switch counts lengths of the inter-frame gaps and VLAN tags when calculating the CAR,
which causes inaccurate rate limiting. It is recommended that you use packets of over 1000
bytes in CAR tests to minimize the impact of inter-frame gaps and VLAN tags.
For example, a 64-byte packet usually has an inter-frame gap of 20 bytes and a VLAN tag of
4 bytes. Therefore, the total packet length is 88 bytes (64 bytes + 20 bytes + 4 bytes = 88
bytes). During CAR rate limiting, the switch calculates the traffic rate based on the 88-byte
packet length, so the rate limiting result is inaccurate. If the switch uses large packets, the
lengths of inter-frame gap and the VLAN tag account for a small proportion of the total
packet length and cause a little impact on the packet rate. Therefore, the rate limiting result is
more accurate.
5.3 How Is PBR Implemented on S-series Switches?

S-series switches support weak PBR. Packets are still forwarded even if the specified nexthop address does not exist.
Starting from V1R6, the switches support multiple next hops for redirection. The next hops
work in active/standby mode. A maximum of four next-hop IP addresses can be configured in
a traffic behavior. A switch determines the primary path and backup paths according to the
sequence in which next-hop IP addresses were configured. The next-hop IP address that was
configured first has the highest priority and this next hop is used as the primary path. Other
next hops are used as backup paths. When the primary patch is Down, one of the backup paths
is selected as the new primary path.
5.4 The Traffic Behavior Is Not Set to deny, but

Traffic is Discarded, Why?
The traffic policy may reference an ACL with a deny action. If traffic matches this ACL, the
traffic is denied even when permit action is configured in the traffic behavior. When an ACL
is referenced by a traffic policy, the permit/deny actions in the ACL are used with the
permit/deny actions in the traffic behavior. If a deny action is defined either in the ACL or
the traffic behavior, the deny action is performed.
5.5 How Do I Use a User-defined ACL?

In V100R005 and a later version, a switch provides user-defined ACLs. A user-defined ACL
can match any part of a packet. A user-defined ACL can start matching from the following
fields based on the following information in a packet:
l2-head
ipv4-head and ipv6-head
l4-head
A user-defined ACL matches the four-byte character string after a specified offset in any of
the preceding fields. The matched character string must be four bytes and the offset bytes are
set through a command.
For example, to match packets with the IPv4 TTL of 1, run the following commands:
[Quidway] acl 5000
[Quidway-acl-user-5000] rule permit ipv4-head 0x01000000 0xff000000 8
The value 8 is the number of offset bytes before the TTL field in the IPv4 packet header. The
TTL field occupies one byte and the value 0x01000000 corresponds to TTL value 1 after the
offset from the IPv4 packet header.
5.6 How Do I Know About ACL Resource Usage?

You can run the display acl resource [ slot slot-id ] command on the switch to check the ACL
resource usage.
Example: Run the display acl resource slot 3 command to check the ACL resource usage in
slot 3.
< Switch >display acl resource slot
Slot
3
Vlan-ACL
Inbound-ACL
Outbound-ACL
---------------------------------------------------------------------------Rule Used
10
329
Rule Free
2038
7863
1021
Rule Total
2048
8192
1024
Meter Used
58
Meter Free
8134
1024
Meter Total
8192
1024
Counter Used
59
Counter Free
8133
1023
Counter Total
8192
1024
----------------------------------------------------------------------------
The following table describes each field in the command output.

Item
Description
Slot
Slot ID.
Vlan-ACL
ACL processor in a VLAN.
Inbound-ACL
Upstream ACL processor.
Outbound-ACL
Downstream ACL processor.
Rule Used
Number of used ACL rules.
Rule Free
Number of idle ACL rules.
Rule Total
Total number of ACL rules.
Meter Used
Number of used meters.
Meter Free
Number of idle meters.
Meter Total
Total number of meters.
Counter Used
Number of used counters.
Counter Free
Number of idle counters.
Counter Total
Total number of counters.
S Series Switches
Feature Start - ACL
A Acronyms and Abbreviations
Acronyms and Abbreviations
ACL
Access Control List
CAR
Committed Access Rate

S Series Switches Feature Start-ACL V1.0 D

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

S Series Switches Feature Start-ACL V1.0 D

Uploaded by

Copyright:

Available Formats

S Series Switches

Feature Start - ACL

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Industrial Base

About This Document

About This Document

Technical support engineers

About This Document

About This Document.......................................................................ii

A Acronyms and Abbreviations.......................................................41

1.1 Introduction to ACL

1.1.2 ACL Classification

A numbered ACL is identified

A named ACL is identified by

A named ACL can be

Compared with numbered

ACL4 and ACL6 names

A basic ACL filters packets

Basic ACL numbers

An advanced ACL filters

Advanced ACL numbers

Compared with basic ACLs,

A Layer 2 ACL filters packets

Layer 2 ACL numbers

A user-defined ACL matches

1.1.3 Matching Order of ACL Rules

Basic ACL rules

Advanced IPv4 ACL rules

Layer 2 ACL rules

User-defined ACL rules

1.1.4 Time Range of an ACL

1.2 Traffic Classifier

DSCP priority in IP packets

802.1p priority in VLAN packets

EXP priority in MPLS packets

1.2.2 Complex Traffic Classification

VLAN ID in the outer tag of VLAN packets

VLAN ID in the inner tag of VLAN packets

802.1p priority in the outer tag of VLAN packets

802.1p priority in the inner tag of VLAN packets

Double tags in VLAN packets

Source MAC address

Destination MAC address

Protocol field encapsulated based on Layer 2 information

DSCP priority in IP packets

EXP priority in MPLS packets

TCP SYN flag in TCP packets

IP protocol type (IPv4 or IPv6)

IP precedence or DSCP priority

Prefix of a source IP address

Prefix of a destination IP address

Protocol number contained in an IP packet

TCP SYN flag

TCP/UDP source port number or range

TCP/UDP destination port number or range

1.2.3 Logical Relationship between Traffic Classifier Rules

Traffic classifier does not contain ACL rules.

Traffic classifier contains ACL rules.

1.3 Traffic Behavior

Security and traffic statistics

All traffic behaviors except for deny can be used together.