23-QoS Configuration
Chapters Download (641.96 KB)
Table of Contents
Traditional Packet Forwarding Services
New Requirements from Emerging Applications
Congestion: Causes, Impacts, and Countermeasures
Major Traffic Management Technologies
QoS Functions for Uplink Traffic
QoS Functions for Downlink Traffic
Configuring QoS in an EPON System
QoS Configuration Task List in an EPON System
2 Traffic Classification, Traffic Policing and Line Rate Configuration
Traffic Classification Overview
Traffic Policing and Line Rate Overview
Traffic Evaluation and Token Bucket
Transmit Buffer for High Priority Downlink Traffic on an OLT Port
Traffic Policing and Line Rate Configuration
Configuring High Priority Packet Buffering for an ONU
Displaying and Maintaining Traffic Policing and Line Rate
QoS Policy Configuration Example
Applying the QoS Policy to an Interface
Applying the QoS Policy to a VLAN
Applying the QoS Policy Globally
Displaying and Maintaining QoS Policies
4 Congestion Management Configuration
Congestion Management Policies
Per-Queue Configuration Method
5 Priority Mapping Configuration
Configuring a Priority Mapping Table
Configuring the Priority Mapping on an OLT Device
Configuring the Priority Mapping on an ONU
Configuring the Priority for a Port
Configuring the Trusted Precedence Type for a Port
Displaying and Maintaining Priority Mapping
Priority Mapping Configuration Examples
Port Priority Mapping Configuration Example
Port Priority Configuration Example
UNI Priority Remarking Configuration Example
6 Traffic Mirroring Configuration
Mirroring Traffic to an Interface
Displaying and Maintaining Traffic Mirroring
Traffic Mirroring Configuration Example
Traffic Mirroring-to-Port Configuration Example
This chapter covers the following topics:
l Traditional Packet Forwarding Services
l New Requirements from Emerging Applications
l Congestion: Causes, Impacts, and Countermeasures
l Major Traffic Management Technologies
Quality of Service (QoS) is a concept concerning service demand and supply. It reflects the ability to meet customer needs. Generally, QoS focuses on improving services under certain conditions rather than grading services precisely.
In an internet, QoS evaluates the ability of the network to forward packets of different services. The evaluation can be based on different criteria because the network may provide various services. Generally, QoS refers to the ability to provide improved service by solving the core issues such as delay, jitter, and packet loss ratio in the packet forwarding process.
On traditional IP networks, devices treat all packets equally and handle them using the first in first out (FIFO) policy. All packets share the resources of the network and devices. How many resources the packets can obtain completely depends on the time they arrive. This service is called best-effort. It delivers packets to their destinations as possibly as it can, without any guarantee for delay, jitter, packet loss ratio, reliability and so on.
This service policy is only suitable for applications insensitive to bandwidth and delay, such as WWW, file transfer and e-mail.
The Internet has been growing along with the fast development of networking technologies. More and more people use the Internet to transmit data, share video and do a lot of other things.
Besides traditional applications such as WWW, e-mail and FTP, network users are experiencing new services, such as tele-education, telemedicine, video telephone, videoconference and Video-on-Demand (VoD). Enterprise users expect to connect their regional branches together with VPN technologies to carry out operational applications, for instance, to access the database of the company or to monitor remote devices through Telnet.
These new applications have one thing in common, that is, they all have special requirements for bandwidth, delay, and jitter. For example, videoconference and VoD require high bandwidth, low delay and jitter. As for mission-critical applications, such as transactions and Telnet, they may not require high bandwidth but do require low delay and preferential service during congestion.
The emerging applications demand higher service performance of IP networks. Better network services during packets forwarding are required, such as providing dedicated bandwidth, reducing packet loss ratio, managing and avoiding congestion, regulating network traffic, and setting the precedence of packets. To meet these requirements, networks must provide more improved services.
Network congestion is a major factor contributed to service quality degrading on a traditional network. Congestion is a situation where the forwarding rate decreases due to insufficient resources, resulting in extra delay.
Congestion easily occurs in complex packet switching circumstances in the Internet. The following figure shows two common cases:
Figure 1-1 Traffic congestion causes
l The traffic enters a device from a high speed link and is forwarded over a low speed link.
l The packet flows enter a device from several interfaces at the same rate and are forwarded out an interface at the same rate as well.
When traffic arrives at the line speed, a bottleneck is created at the outgoing interface causing congestion.
Besides bandwidth bottlenecks, congestion can be caused by resource shortage in various forms such as insufficient processor time, buffer, and memory, and by network resource exhaustion resulting from excessive arriving traffic in certain periods.
Congestion may bring these negative results:
l Increased delay and jitter during packet transmission
l Decreased network throughput and resource use efficiency
l Network resource (memory in particular) exhaustion and even system breakdown
It is obvious that congestion hinders resource assignment for traffic and thus degrades service performance. The chance of congestion is high in switched networks and multi-user application environments. To improve the service performance of your network, you must address the congestion issues.
A simple solution for congestion is to increase network bandwidth. However, it cannot solve all the problems that cause congestion.
A more effective solution is to provide differentiated services for different applications through traffic control and resource allocation. In this way, resources can be used more properly. During resources allocation and traffic control, the direct or indirect factors that might cause network congestion should be controlled to reduce the probability of congestion. Once congestion occurs, resource allocation should be performed according to the characteristics and demands of applications to minimize the effects of congestion on QoS.
Figure 1-2 End-to-end QoS model
As shown in Figure 1-2, traffic classification, traffic policing, traffic shaping (TS), congestion management, and congestion avoidance are the foundations for a network to provide differentiated services. Mainly they implement the following functions:
l Traffic classification uses certain match criteria to organize packets with different characteristics into different classes, and is the prerequisite for providing differentiated services. Traffic classification is usually applied in the inbound direction of a port.
l Traffic policing polices particular flows entering a device according to configured specifications and is usually applied in the inbound direction of a port. When a flow exceeds the specification, some restriction or punishment measures can be taken to prevent overconsumption of network resources and protect the commercial benefits of the carrier.
l Traffic shaping proactively adjusts the output rate of traffic to adapt traffic to the network resources of the downstream device and avoid unnecessary packet drop and congestion. Traffic shaping is usually applied in the outbound direction of a port.
l Congestion management provides measures for handling resource competition during network congestion and is usually applied in the outbound direction of a port. Generally, it stores packets in queues, and then uses a scheduling algorithm to arrange the forwarding sequence of the packets.
l Congestion avoidance monitors the usage status of network resources and is usually applied in the outbound direction of a port. As congestion becomes worse, it actively reduces the amount of traffic by dropping packets.
Among these traffic management technologies, traffic classification is the basis for providing differentiated services by classifying packets with certain match criteria. Traffic policing, traffic shaping, congestion management, and congestion avoidance manage network traffic and resources in different ways to realize differentiated services.
Normally, QoS provides the following functions:
l Traffic classification
l Access control
l Traffic policing and traffic shaping
l Congestion management
l Congestion avoidance
This section is focused on traffic classification, and the subsequent sections will introduce the other technologies in details.
Traffic classification organizes packets with different characteristics into different classes using match criteria. It is the basis for providing differentiated services.
You can define match criteria based on the IP precedence bits in the type of service (ToS) field of the IP packet header, or based on other header information such as IP addresses, MAC addresses, IP protocol field and port numbers. Contents other than the header information in packets are rarely used for traffic classification. You can define a class for packets with a common quintuple (source address, source port number, protocol number, destination address and destination port number), or for all packets to a certain network segment.
When packets are classified on the network boundary, the precedence bits in the ToS field of the IP packet header are generally re-set. In this way, IP precedence can be adopted as a classification criterion for the packets in the network. On the other hand, IP precedence can also be used in queuing to prioritize traffic. The downstream network can either adopt the classification results from its upstream network or classify the packets again according to its own criteria.
To provide differentiated services, traffic classes must be associated with certain traffic control actions or resource allocation actions. What traffic control actions to adopt depends on the current phase and the resources of the network. For example, CIR is adopted to police packets when they enter the network; GTS is performed on packets when they flow out of the node; queue scheduling is performed when congestion happens; congestion avoidance measures are taken when the congestion deteriorates.
You can configure QoS for an OLT and ONUs attached to the OLT. To achieve QoS in an EPON system, you must configure QoS at both the OLT side and the ONU side. The following part introduces QoS functions that can be configured for uplink traffic and those for the downlink traffic.
l Configuring the priority trust mode for an ONU.
l Configuring traffic classification for an ONU: the ONU classifies the uplink traffic of a UNI and marks 802.1p priority values for the matching traffic, so that traffic can be put into different queues.
l Configuring the UNI to tag the uplink 802.1q-untagged traffic with the default VLAN tag, and adding the UNI priority to the Priority field as the 802.1p priority.
l Configuring the ONU to perform traffic policing for uplink traffic of a UNI.
l Configuring the ONU to distribute the uplink traffic to different output queues based on the mapping between the 802.1p priority and local precedence.
l Configuring the ONU to perform congestion management for traffic from uplink ports, supporting SP and WFQ queue scheduling algorithms (available to only H3C ONUs).
l By default, an OLT port trusts the 802.1p priority of the packets. You can configure to trust the DSCP precedence of the packets through the command line. Thus, the OLT will obtain the 802.1p priority based on the mapping between the DSCP precedence and 802.1p priority before mapping the 802.1p priority to the corresponding output queue. This configuration applies to all uplink traffic of ONUs.
l Configuring congestion management for uplink ports (supporting SP, WRR, and SP+WRR queue scheduling algorithms).
l Configuring congestion avoidance on an OLT. When the port is congested, received packets are dropped selectively.
Figure 1-3 shows the QoS model for uplink traffic in an EPON system.
Figure 1-3 QoS model for uplink traffic in an EPON system
l Configuring the OLT to perform priority mapping for packets received from the uplink port according to the 802.1p-to-local priority mapping table and then assign packets to output queues of the OLT port.
l Configuring the OLT to perform congestion management for downlink traffic, supporting SP and WRR queue scheduling algorithms.
l Configuring the OLT to perform line rate and traffic shaping for downlink traffic.
l Configuring high-priority packet buffer for downlink traffic that the OLT sends to the specified ONU.
l Configuring the ONU to distribute the received downlink traffic to different output queues based on the mapping between the 802.1p priority and local precedence.
l Configuring the ONU to perform traffic policing for downlink traffic of a UNI.
Some ONUs support configuring queue scheduling for traffic from a UNI. To perform such configurations, you should log in to the ONU. For detailed configuration, refer to the ONU user manual.
Figure 1-4 shows the QoS model for downlink traffic in an EPON system.
Figure 1-4 QoS model for downlink traffic in an EPON system
Table 1-1 and Table 1-2 show how to configure QoS for downlink traffic and uplink traffic in an EPON system.
Table 1-1 Configure QOS at the OLT side of an EPON system
|
QoS at the OLT side |
Reference |
|
|
Configure QoS for uplink traffic |
Configure priority mapping on the OLT |
|
|
Configuring priority trust mode for the OLT port |
||
|
Configure traffic policing for uplink traffic of all ONUs (through QoS) |
||
|
Configure congestion management on the uplink Ethernet port |
||
|
Configure QoS for downlink traffic |
Configure the OLT to perform priority mapping for traffic received on an uplink port |
|
|
Configure congestion management (SP and WRR) on the downlink OLT port |
||
|
Configure the high-priority queue buffer for the specified ONU |
Transmit Buffer for High Priority Downlink Traffic on an OLT Port |
|
|
Configure line rate for downlink traffic |
||
Table 1-2 Configure QoS at the ONU side of an EPON system
|
QoS at the ONU side |
Reference |
|
|
Configure QoS for uplink traffic |
Configuring traffic classification and 802.1p priority marking for incoming packets on UNIs |
|
|
Configure priority trust mode for the ONU |
||
|
Configuring traffic policing for uplink traffic of a UNI |
||
|
Configure congestion management for the uplink port of an ONU |
||
|
Configure QoS for downlink traffic |
Configure the ONU to perform priority mapping for downlink traffic from the OLT according to the 802.1p-to-local priority mapping table |
|
|
Set the ONU port priority |
||
|
Configuring traffic policing for downlink traffic of a UNI |
||
l Traffic Classification Overview
l Traffic Policing and Line Rate Overview
l Traffic Evaluation and Token Bucket
l Traffic Policing and Line Rate Configuration
l Displaying and Maintaining Traffic Policing and Line Rate
Traffic classification organizes packets with different characteristics into different classes using match criteria. It is the basis for providing differentiated services.
You can define match criteria based on the IP precedence bits in the type of service (ToS) field of the IP packet header, or based on other header information such as IP addresses, MAC addresses, IP protocol field and port numbers. Contents other than the header information in packets are rarely used for traffic classification. You can define a class for packets with a common quintuple (source address, source port number, protocol number, destination address and destination port number), or for all packets to a certain network segment.
When packets are classified on the network boundary, the precedence bits in the ToS field of the IP packet header are generally re-set. In this way, IP precedence can be adopted as a classification criterion for the packets in the network. On the other hand, IP precedence can also be used in queuing to prioritize traffic. The downstream network can either adopt the classification results from its upstream network or classify the packets again according to its own criteria.
If user traffic is not limited, burst traffic will make the network more congested. Therefore it is necessary to limit user traffic in order to better utilize the network resources and provide better services for more users. For example, you can configure a flow to use only the resources committed to it in a time range, thus avoiding network congestion caused by burst traffic.
Traffic policing and generic traffic shaping (GTS) limit traffic rate and resource usage according to traffic specifications. The prerequisite for traffic policing or GTS is to know whether a traffic flow has exceeded the specification. If yes, proper traffic control policies are applied. Generally, token buckets are used to evaluate traffic specifications.
A token bucket can be considered as a container holding a certain number of tokens. The system puts tokens into the bucket at a set rate. When the token bucket is full, the extra tokens will overflow.
Figure 2-1 Evaluate traffic with the token bucket
The evaluation for the traffic specification is based on whether the number of tokens in the bucket can meet the need of packet forwarding. If the number of tokens in the bucket is enough to forward the packets (generally, one token is associated with a 1-bit forwarding authority), the traffic conforms to the specification, and the traffic is called conforming traffic; otherwise, the traffic does not conform to the specification, and the traffic is called excess traffic.
A token bucket has the following configurable parameters:
l Mean rate: At which tokens are put into the bucket, namely, the permitted average rate of traffic. It is usually set to the committed information rate (CIR).
l Burst size: the capacity of the token bucket, namely, the maximum traffic size that is permitted in each burst. It is usually set to the committed burst size (CBS). The set burst size must be greater than the maximum packet size.
One evaluation is performed on each arriving packet. In each evaluation, if the number of tokens in the bucket is enough, the traffic conforms to the specification and the corresponding tokens for forwarding the packet are taken away; if the number of tokens in the bucket is not enough, it means that too many tokens have been used and the traffic is excessive.
You can set two token buckets in order to evaluate more complicated conditions and implement more flexible regulation policies. For example, traffic policing uses four parameters:
l CIR
l CBS
l Peak information rate (PIR)
l Excess burst size (EBS)
The rates of putting tokens into the two buckets are CIR and PIR respectively, and their sizes are CBS and EBS respectively (the two buckets are called C bucket and E bucket respectively for short), representing different permitted burst levels. In each evaluation, different regulation policies can be implemented in different conditions, including “enough tokens in C bucket”, “insufficient tokens in C bucket but enough tokens in E bucket” and “insufficient tokens in both C bucket and E bucket”.
The typical application of traffic policing is to supervise the specification of certain traffic entering a network and limit it within a reasonable range, or to "discipline" the extra traffic. In this way, the network resources and the interests of the carrier are protected. For example, you can limit bandwidth consumption of HTTP packets to less than 50% of the total. If the traffic of a certain session exceeds the limit, traffic policing can drop the packets or reset the IP precedence of the packets.
Traffic policing is widely used in policing traffic entering the networks of internet service providers (ISPs). It can classify the policed traffic and perform pre-defined policing actions based on different evaluation results. These actions include:
l Forwarding the packets whose evaluation result is “conforming”.
l Dropping the packets whose evaluation result is “excess”.
l Modifying the IP precedence of the packets whose evaluation result is “conforming” and forwarding them.
In an EPON network, the S3600 series EPON OLT switches can allocate uplink/downlink bandwidth to ONUs based on different terminal service requirements to achieve efficient bandwidth utilization.
The line rate of a physical interface specifies the maximum rate for forwarding packets (including critical packets).
Line rate also uses token buckets for traffic control. With line rate configured on an interface, all packets to be sent through the interface are firstly handled by the token bucket at line rate. If there are enough tokens in the token bucket, packets can be forwarded; otherwise, packets are put into QoS queues for congestion management. In this way, the traffic passing the physical interface is controlled.
Figure 2-2 Line rate implementation
In the token bucket approach to traffic control, bursty traffic can be transmitted so long as enough tokens are available in the token bucket; if tokens are inadequate, packets cannot be transmitted until the required number of tokens are generated in the token bucket. Thus, traffic rate is restricted to the rate for generating tokens, thus limiting traffic rate and allowing bursty traffic.
Compared with traffic policing, line rate can only limit traffic rate on a physical interface. Since traffic policing operates at the IP layer, it can limit the rate of different flows on a port. However, traffic policing ignores packets not processed by the IP layer. To limit the rate of all the packets on interfaces, using line rate is easier.
Sometimes the size of traffic sent out an OLT port to an ONU may exceed the available bandwidth of the ONU port. To avoid loss of high priority packets sent to some important ONUs, you can enable high-priority traffic buffering on their ONU ports and allocate a transit buffer for each ONU port on the OLT port. The transmit buffers only apply to high priority traffic. A priority threshold is used to divide high priority traffic from low priority traffic. All traffic that carries an 802.1p priority that is equal to or higher than the priority threshold is considered high priority traffic.
On the S3600 series EPON OLT switches, you can use QoS policies to perform traffic policing for Ethernet ports and OLT ports. For details, refer to QoS Policy Configuration. This section covers only configuring traffic policing for the ONU devices, including:
l Allocating downlink bandwidth to an ONU
l Configuring traffic policing for downlink/uplink traffic of a UNI
You can allocate downlink bandwidth to an ONU depending on the service requirements of the terminals connected to the ONU.
Follow these steps to configure the ONU bandwidth allocation and related parameters:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter ONU port view |
interface interface-type interface-number |
— |
|
Enable the ONU downlink bandwidth allocation policy |
bandwidth downstream policy enable |
Required By default, the downlink bandwidth allocation policy is disabled. |
|
Configure the ONU downlink bandwidth limit |
bandwidth downstream { max-bandwidth value | max-burstsize value } * |
Optional By default, the maximum bandwidth is 999994 kbps, and the maximum burst buffer is 8388480 bytes. |
l The configuration of high-priority packet buffering (as shown in Configuring High Priority Packet Buffering for an ONU) and that of the downlink bandwidth limit take effect only when the downlink bandwidth allocation policy is enabled.
l The configured downlink bandwidth limitation takes effect only on known unicasts, but not on unknown unicasts, multicasts, or broadcasts.
l The sum of the minimum uplink bandwidths configured for all the existing ONU ports under an OLT port cannot exceed 921600 Kbps, namely, 900 Mbps.
Follow these steps to configure traffic policing for downlink/uplink traffic of a UNI:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter ONU port view |
interface interface-type interface-number |
— |
|
Configure traffic policing for uplink/downlink traffic |
uni uni-number port-policy { { inbound { cir cir-value | bucket-depth bucket-depth-value | extra-burst-size ebs-value }* } | outbound cir cir-value [ pir pir-value ] } |
Optional The CIR should be a multiple of 64. By default, traffic policing is not configured for a UNI. Note that: only H3C ONUs support the outbound keyword. |
The line rate of a physical interface specifies the maximum rate of incoming packets or outgoing packets.
Follow these steps to configure the line rate:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter Ethernet port view or OLT port view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure the line rate for the interface/port group |
qos lr outbound cir committed-information-rate [ cbs committed-burst-size ] |
Required |
|
|
Display line rate information on the interface |
display qos lr interface [ interface-type interface-number ] |
Available in any view |
|
Limit the outbound line rate of OLT 1/0/1 to 512 kbps.
# Enter system view.
<Sysname> system-view
# Enter interface view.
[Sysname] interface Olt 1/0/1
# Limit the outbound line rate of OLT 1/0/1 to 512 kbps.
[Sysname-Olt1/0/1] qos lr outbound cir 512
To avoid loss of high priority packets sent to some important ONUs, you can enable high-priority traffic buffering on their ONU ports and allocate a transit buffer for each ONU port on the OLT port. The transmit buffers only apply to high priority traffic. A priority threshold is used to divide high priority traffic from low priority traffic. All traffic that carries an 802.1p priority that is equal to or higher than the priority threshold is considered high priority traffic.
Follow these steps to configure high-priority packet buffering for the downlink traffic to an ONU:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter OLT port view |
interface interface-type interface-number |
— |
|
Set the transmit buffer to be assigned for each ONU port enabled with high-priority traffic buffering |
bandwidth downstream priority-queue priority high-priority-reserved value |
Required The value argument is in bytes. By default, no buffer is reserved for high-priority packets. |
|
Return to system view |
quit |
— |
|
Enter ONU port view |
interface interface-type interface-number |
— |
|
Enable high-priority traffic buffering for downlink traffic on the ONU port |
bandwidth downstream high-priority enable |
Optional Disabled by default. |
To use high-priority packet buffering for downlink traffic on an OLT port, ensure that the downlink bandwidth allocation policy is enabled (see Configuring Traffic Policing).
|
To do… |
Use the command… |
Remarks |
|
Display interface line rate configuration information |
display qos lr interface [ interface-type interface-number ] |
Available in any view |
When configuring a QoS policy, go to these sections for information you are interested in:
l Displaying and Maintaining QoS Policies
A QoS policy involves three components: class, traffic behavior, and policy. You can associate a class with a traffic behavior using a QoS policy.
Classes are used to identify traffic.
A class is identified by a class name and contains some match criteria.
You can define a set of match criteria to classify packets, and the relationship between criteria can be and or or.
l and: The device considers a packet belongs to a class only when the packet matches all the criteria in the class.
l or: The device considers a packet belongs to a class as long as the packet matches one of the criteria in the class.
A traffic behavior defines a set of QoS actions for packets.
A policy associates a class with a traffic behavior.
You can configure multiple class-to-traffic behavior associations in a policy.
Follow these steps to configure a QoS policy:
1) Create a class and define a set of match criteria in class view.
2) Create a traffic behavior and define a set of QoS actions in traffic behavior view.
3) Create a policy and associate the traffic behavior with the class in policy view.
You need to decide on:
l The class name and match criteria.
l The traffic behavior name and actions in the traffic behavior.
l The policy name.
To define a class, you need to specify a name for it and then configure match criteria in class view.
Follow these steps to define a class:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Create a class and enter class view |
traffic classifier tcl-name [ operator { and | or } ] |
Required By default, the relation between match criteria is logic and. |
|
Define a match criterion |
if-match match-criteria |
Required |
|
Display class information |
display traffic classifier user-defined [ tcl-name ] |
Optional Available in any view |
match-criteria: Matching rules to be defined for a class. Table 3-1 describes the available forms of this argument.
Table 3-1 The form of the match-criteria argument
|
Form |
Description |
|
acl { access-list-number | name acl-name } |
Specifies to match an IPv4 ACL specified by its number or name. The access-list-number argument specifies an ACL by its number, which ranges from 2000 to 4999; the name acl-name keyword-argument combination specifies an ACL by its name. In a class configured with the operator and, the logical relationship between rules defined in the referenced IPv4 ACL is or. |
|
acl ipv6 { access-list-number | name acl-name } |
Specifies to match an IPv6 ACL specified by its number or name. The access-list-number argument specifies an ACL by its number, which ranges from 2000 to 3999; the name acl-name keyword-argument combination specifies an ACL by its name. In a class configured with the operator and, the logical relationship between rules defined in the referenced IPv6 ACL is or. |
|
any |
Specifies to match all packets. |
|
customer-dot1p 8021p-list |
Specifies to match packets by 802.1p priority of the customer network. The 8021p-list argument is a list of 802.1p priority values. You can provide up to eight space-separated 802.1p priority values for this argument. 802.1p priority is in the range 0 to 7. |
|
customer-vlan-id vlan-id-list |
Specifies to match the packets of specified VLANs of user networks. The vlan-id-list argument specifies a list of VLAN IDs, in the form of vlan-id to vlan-id or multiple discontinuous VLAN IDs (separated by space). You can specify up to eight VLAN IDs for this argument at a time. VLAN ID is in the range 1 to 4094. In a class configured with the operator and, the logical relationship between the customer VLAN IDs specified for the customer-vlan-id keyword is or. |
|
destination-mac mac-address |
Specifies to match the packets with a specified destination MAC address. |
|
dscp dscp-list |
Specifies to match packets by DSCP precedence. The dscp-list argument is a list of DSCP values. You can provide up to eight space-separated DSCP values for this argument. DSCP is in the range of 0 to 63. |
|
ip-precedence ip-precedence-list |
Specifies to match packets by IP precedence. The ip-precedence-list argument is a list of IP precedence values. You can provide up to eight space-separated IP precedence values for this argument. IP precedence is in the range 0 to 7. |
|
protocol protocol-name |
Specifies to match the packets of a specified protocol. The protocol-name argument can be IP or IPv6. |
|
service-dot1p 8021p-list |
Specifies to match packets by 802.1p priority of the service provider network. The 8021p-list argument is a list of 802.1p priority values. You can provide up to eight space-separated 802.1p priority values for this argument. 802.1p priority is in the range 0 to 7. |
|
service-vlan-id vlan-id-list |
Specifies to match the packets of the VLANs of the operator’s network. The vlan-id-list argument is a list of VLAN IDs, in the form of vlan-id to vlan-id or multiple discontinuous VLAN IDs (separated by space). You can specify up to eight VLAN IDs for this argument at a time. VLAN ID is in the range of 1 to 4094. In a class configured with the operator and, the logical relationship between the service VLAN IDs specified for the service-vlan-id keyword is or. |
|
source-mac mac-address |
Specifies to match the packets with a specified source MAC address. |
To define a traffic behavior, you should first create a traffic behavior name and then configure attributes in traffic behavior view.
Follow these steps to define a traffic behavior:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Create a traffic behavior and enter traffic behavior view |
traffic behavior behavior-name |
Required |
|
Enable traffic accounting |
accounting |
Required You can configure the corresponding traffic behavior as required. |
|
Configure a CAR policy |
car cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ pir peak-information-rate ] [ green action ] [ red action ] [ yellow action ] |
|
|
Drop or send packets |
filter { deny | permit } |
|
|
Mirror packets to the CPU or an interface |
mirror-to { cpu | interface interface-type interface-number } |
|
|
Redirect traffic to a specified target |
redirect { cpu | interface interface-type interface-number | next-hop { ipv4-add [ ipv4-add ] | ipv6-add [ interface-type interface-number ] [ ipv6-add [ interface-type interface-number ] ] } } |
|
|
Set the DSCP value for packets |
remark dscp dscp-value |
|
|
Set the 802.1p priority for packets |
remark dot1p 8021p |
|
|
Set the drop precedence for packets |
remark drop-precedence drop-precedence-value |
|
|
Set the IP precedence for packets |
remark ip-precedence ip-precedence-value |
|
|
Set the local precedence for packets |
remark local-precedence local-precedence |
|
|
Set the customer network VLAN ID for packets |
remark customer-vlan-id vlan-id-value |
|
|
Set the provider network VLAN ID for packets |
remark service-vlan-id vlan-id-value |
|
|
Display traffic behavior configuration information |
display traffic behavior user-defined [ behavior-name ] |
Optional Available in any view |
A policy defines the mapping between a class and a traffic behavior (a set of QoS actions).
In a policy, multiple class-to-traffic-behavior mappings can be configured, and these mappings are executed according to the order configured.
Follow these steps to define a policy:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Create a policy and enter policy view |
qos policy policy-name |
Required |
|
Specify the traffic behavior for a class in the policy |
classifier tcl-name behavior behavior-name |
Required |
|
Display the specified class and its associated traffic behavior in the QoS policy |
display qos policy user-defined [ policy-name [ classifier tcl-name ] ] |
Optional Available in any view |
Configure a QoS policy test_policy to limit the rate of packets with IP precedence 6 to 10 Mbps.
# Create a class test_class to match the packets with IP precedence 6.
<Sysname> system-view
[Sysname] traffic classifier test_class
[Sysname-classifier-test_class] if-match ip-precedence 6
[Sysname-classifier-test_class] quit
# Create a traffic behavior test_behavior and configure the action of limiting the traffic rate to 100 kbps for it.
[Sysname] traffic behavior test_behavior
[Sysname-behavior-test_behavior] car cir 10240
[Sysname-behavior-test_behavior] quit
# Create a QoS policy test_policy and associate the traffic behavior with the class.
[Sysname] qos policy test_policy
[Sysname-qospolicy-test_policy] classifier test_class behavior test_behavior
You can apply the QoS policy in different views as follows:
l In interface view, the policy applies to the inbound or outbound direction of an interface;
l In VLAN view, the policy applies to the inbound or outbound direction of a VLAN;
l In system view, the policy applies to the inbound or outbound direction of all ports globally.
You can modify the classification rules, traffic behaviors, and classifier-behavior associations of a QoS policy already applied.
A policy can be applied to multiple interfaces. Only one policy can be applied in inbound direction of an interface.
Follow these steps to apply the QoS policy to an interface or PVC:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view, port group view, or PVC view |
Enter Ethernet port view, OLT port view or ONU port view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Apply the policy to the interface/port group/PVC |
qos apply policy policy-name inbound |
Required |
|
Whether a QoS policy can be applied to an ONU port depends on the support of the ONU for actions in the QoS policy. For details, refer to the user manual of the ONU.
# Apply QoS policy test_policy to the inbound direction of OLT 1/0/1.
<Sysname> system-view
[Sysname] interface Olt 1/0/1
[Sysname-Olt1/0/1] qos apply policy test_policy inbound
Follow these steps to apply the QoS policy to a VLAN:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Apply the QoS policy to the specified VLAN(s) |
qos vlan-policy policy-name vlan vlan-id-list inbound |
Required |
QoS policies cannot be applied to dynamic VLANs, for example, VLANs created by GVRP.
# Apply QoS policy test_policy to the inbound direction of VLAN 200, VLAN 300, VLAN 400, and VLAN 500.
<Sysname> system-view
[Sysname] qos vlan-policy test_policy vlan 200 300 400 500 inbound
You can apply the QoS policy globally to the inbound direction of all ports.
Follow these steps to apply a QoS policy globally:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Apply a QoS policy globally |
qos apply policy policy-name global inbound |
Required |
# Apply QoS policy test_policy to the inbound direction globally.
<Sysname> system-view
[sysname] qos apply policy test_policy global inbound
|
To do… |
Use the command… |
Remarks |
|
Display traffic class information |
display traffic classifier user-defined [ tcl-name ] |
Available in any view |
|
Display traffic behavior configuration information |
display traffic behavior user-defined [ behavior-name ] |
Available in any view |
|
Display the configuration of one or all classes in one or all QoS policies and the associated behavior(s) of the class(es) |
display qos policy user-defined [ policy-name [ classifier tcl-name ] ] |
Available in any view |
|
Display QoS policy configuration on the specified or all interfaces |
display qos policy interface [ interface-type interface-number ] [ inbound | outbound ] |
Available in any view |
|
Display VLAN QoS policy information |
display qos vlan-policy { name policy-name | vlan vlan-id } [ inbound ] |
Available in any view |
|
Display information about a global QoS policy |
display qos policy global [ inbound ] |
Available in any view |
|
Clear VLAN QoS policy statistics |
reset qos vlan-policy [ vlan vlan-id ] [ inbound ] |
Available in user view |
|
Clear statistics of a global QoS policy |
reset qos policy global [ inbound ] |
Available in user view |
When configuring congestion management, go to these sections for information you are interested in:
l Overview
l Congestion Management Policies
l Per-Queue Configuration Method
Congestion occurs on the interface or PVC where the arrival rate of packets is faster than the sending rate. If there is no enough buffer capacity to store these packets, a part of them will be lost, which may cause the sending device to retransmit these packets because of timeout, deteriorating the congestion.
In general, congestion management adopts queuing technology. The system uses a certain queuing algorithm for traffic classification, and then uses a certain precedence algorithm to send the traffic. Each queuing algorithm deals with a particular network traffic problem and has significant impacts on bandwidth resource assignment, delay, and jitter.
The S3600 series EPON OLT switches support the following three queue scheduling algorithms:
l SP: SP applicable to all queues
l WRR: WRR applicable to all queues
l SP+WRR: SP applicable to some queues and WRR to some others
The S3600 series EPON OLT switches also support configuring WFQ on ONUs.
This section describes Strict Priority (SP) queuing, Weighted Round Robin (WRR) queuing, Weighted Fair Queuing (WFQ), and SP+WRR queuing.
1) SP queuing
SP queuing is specially designed for mission-critical applications, which require preferential service to reduce response delay when congestion occurs.
Figure 4-1 Schematic diagram for SP queuing
As shown in Figure 4-1, SP queuing classifies eight queues on a port into eight classes, numbered 7 to 0 in descending priority order.
SP queuing schedules the eight queues strictly according to the descending order of priority. It sends packets in the queue with the highest priority first. When the queue with the highest priority is empty, it sends packets in the queue with the second highest priority, and so on. Thus, you can assign mission-critical packets to the high priority queue to ensure that they are always served first and common service packets to the low priority queues and transmitted when the high priority queues are empty.
The disadvantage of SP queuing is that packets in the lower priority queues cannot be transmitted if there are packets in the higher priority queues. This may cause lower priority traffic to starve to death.
2) WRR queuing
WRR queuing schedules all the queues in turn to ensure that every queue can be served for a certain time, as shown in Figure 4-2.
Figure 4-2 Schematic diagram for WRR queuing
Assume there are eight output queues on a port. WRR assigns each queue a weight value (represented by w7, w6, w5, w4, w3, w2, w1, or w0) to decide the proportion of resources assigned to the queue. On a 100 Mbps port, you can configure the weight values of WRR queuing to 5, 5, 3, 3, 1, 1, 1, and 1 (corresponding to w7, w6, w5, w4, w3, w2, w1, and w0 respectively). In this way, the queue with the lowest priority is assured of 5 Mbps of bandwidth at least, thus avoiding the disadvantage of SP queuing that packets in low-priority queues may fail to be served for a long time.
Another advantage of WRR queuing is that while the queues are scheduled in turn, the service time for each queue is not fixed, that is, if a queue is empty, the next queue will be scheduled immediately. This improves bandwidth resource use efficiency.
3) SP+WRR queue scheduling algorithm
You can implement SP+WRR queue scheduling on a port by assigning some queues on the port to the SP scheduling group and the others to the WRR scheduling group (that is, group 1). Packets in the SP scheduling group are scheduled preferentially. When the SP scheduling group is empty, packets in the WRR scheduling group are scheduled. Queues in the SP scheduling group are scheduled by SP. Queues in the WRR scheduling group are scheduled by WRR.
4) WFQ queuing
Figure 4-3 Schematic diagram for WFQ queuing
WFQ is derived from fair queuing (FQ), which is designed for fairly sharing network resources, reducing the delay and jitter of all traffic. FQ fully consider the interests of all queues to ensure that:
l Different queues have fair dispatching opportunities, preventing a single queue from being delayed for too long.
l Short packets and long packets are fairly scheduled: if there are both long packets and short packets in queues, statistically the short packets should be scheduled preferentially to reduce the jitter between packets as a whole.
Compared with FQ, WFQ takes weights into account when determining the queue scheduling order. Statistically, WFQ gives high priority traffic more scheduling opportunities than low priority traffic. WFQ can automatically classify traffic according to the “session” information of traffic (protocol type, TCP or UDP source/destination port numbers, source/destination IP addresses, IP precedence bits in the ToS field, and so on), and try to provide as many queues as possible so that each traffic flow can be put into these queues to balance the delay of every traffic flow as a whole. When dequeuing packets, WFQ assigns outgoing interface bandwidth to each traffic flow by precedence. The higher precedence value a traffic flow has, the more bandwidth it gets.
Additionally, WFQ can work with the minimum guaranteed bandwidth mechanism. You can configure a minimum guaranteed bandwidth for each WFQ queue to guarantee that each WFQ queue is guaranteed of the bandwidth when congestion occurs. The assignable bandwidth (assignable bandwidth = total bandwidth – the sum of the minimum guaranteed bandwidth for each queue) is allocated to queues based on queue priority.
For example, assume that the total bandwidth of a port is 10 Mbps, and there are five flows on the port currently, with the precedence being 0, 1, 2, 3, and 4 and the minimum guaranteed bandwidth being 128 kbps, 128 kbps, 128 kbps, 64 kbps, and 64 kbps respectively.
l The assignable bandwidth = 10 Mbps – (128 kbps + 128 kbps + 128 kbps + 64 kbps + and 64 kbps) = 9.5 Mbps
l The total assignable bandwidth quota is the sum of all the (precedence value + 1)s, that is, 1 + 2 + 3 + 4 + 5 = 15.
l The bandwidth percentage assigned to each flow is (precedence value of the flow + 1)/total assignable bandwidth quota. The bandwidth percentages for the flows are 1/15, 2/15, 3/15, 4/15, and 5/15 respectively.
l The bandwidth finally assigned to a queue = the minimum guaranteed bandwidth + the bandwidth allocated to the queue from the assignable bandwidth
Because WFQ can balance delay and jitter across flows when congestion occurs, it is very useful on some special occasions. For example, WFQ is adopted for the assured forwarding (AF) services of the Resource Reservation Protocol (RSVP). In Generic Traffic Shaping (GTS), WFQ is used to schedule buffered packets.
Follow these steps to configure SP queuing:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter Ethernet port view, OLT port view or ONU port view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure SP queuing |
qos sp |
Required The default queuing algorithm on an interface is SP queuing. |
|
|
Display SP queuing configuration |
display qos sp interface [ interface-type interface-number ] |
Optional Available in any view |
|
1) Network requirements
Configure OLT 1/0/1 to adopt SP queuing.
2) Configuration procedure
# Enter system view
<Sysname> system-view
# Configure OLT 1/0/1 to adopt SP queuing.
[Sysname] interface Olt 1/0/1
[Sysname-Olt1/0/1] qos sp
Follow these steps to configure basic WRR queuing:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter Ethernet port view or OLT port view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Enable WRR queuing |
qos wrr |
Required The default queuing algorithm on an interface is SP queuing. |
|
|
Configure a basic WRR queue |
qos wrr queue-id group group-id weight schedule-value |
Required By default, on a WRR-enabled port, the weight values are 1, 2, 3, 4, 5, 9, 13, and 15 for queue 0 to queue 7. |
|
1) Network requirements
Configure OLT 1/0/1 to use WRR and assign the weight values 1, 2, 4, 6, 8, 10, 12, and 14 to queue 0 to queue 7.
2) Configuration procedure
# Enter system view.
<Sysname> system-view
# Configure WRR queuing on OLT 1/0/1.
[Sysname] interface Olt 1/0/1
[Sysname-Olt1/0/1] qos wrr
[Sysname-Olt1/0/1] qos wrr 0 group 1 weight 1
[Sysname-Olt1/0/1] qos wrr 1 group 1 weight 2
[Sysname-Olt1/0/1] qos wrr 2 group 1 weight 4
[Sysname-Olt1/0/1] qos wrr 3 group 1 weight 6
[Sysname-Olt1/0/1] qos wrr 4 group 1 weight 8
[Sysname-Olt1/0/1] qos wrr 5 group 1 weight 10
[Sysname-Olt1/0/1] qos wrr 6 group 1 weight 12
[Sysname-Olt1/0/1] qos wrr 7 group 1 weight 14
Follow these steps to configure SP + WRR queuing:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter port view or port group view |
Enter Ethernet port view or OLT port view |
interface interface-type interface-number |
Perform either of the two operations. The configuration performed in Ethernet interface view applies to the current port only. The configuration performed in port group view applies to all the ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Enable WRR queuing |
qos wrr |
Required The default queuing algorithm on an interface is SP queuing. |
|
|
Configure SP queue scheduling |
qos wrr queue-id group sp |
Required |
|
|
Configure WRR queue scheduling |
qos wrr queue-id group group-id weight schedule-value |
Required |
|
When you use the SP+WRR queue scheduling algorithm, make sure that queues in the same scheduling group are consecutive.
1) Network requirements
Configure OLT 1/0/1 to use the SP+WRR queue scheduling algorithm as follows.
l Assign queues 4, 5, 6, and 7 of OLT 1/0/1 to the SP scheduling group.
l Assign queues 0, 1, 2, and 3 to the WRR scheduling group, with the weight of 2, 4, 6, and 8 respectively.
2) Configuration procedure
# Enter system view.
<Sysname> system-view
# Enable the SP+WRR queue scheduling algorithm on GigabitEthernet1/0/1.
[Sysname] interface Olt 1/0/1
[Sysname-Olt1/0/1] qos wrr
[Sysname-Olt1/0/1] qos wrr 0 group 1 weight 2
[Sysname-Olt1/0/1] qos wrr 1 group 1 weight 4
[Sysname-Olt1/0/1] qos wrr 2 group 1 weight 6
[Sysname-Olt1/0/1] qos wrr 3 group 1 weight 8
[Sysname-Olt1/0/1] qos wrr 4 group sp
[Sysname-Olt1/0/1] qos wrr 5 group sp
[Sysname-Olt1/0/1] qos wrr 6 group sp
[Sysname-Olt1/0/1] qos wrr 7 group sp
On the S3600 series EPON OLT switches, WFQ can be configured only on ONU ports.
Follow these steps to configure an HWFQ queue:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter ONU port view |
interface interface-type interface-number |
— |
|
Enable WFQ queuing |
qos wfq |
Optional SP by default on an ONU port |
|
Set a weight for the specified WFQ queue |
qos wfq queue-id weight schedule-value |
Required |
|
Display HWFQ queuing configuration |
display qos wfq interface [ interface-type interface-number ] |
Optional Available in any view |
Whether you can configure WFQ on an ONU port depends on whether the ONU attached to the ONU port supports WFQ.
When configuring priority mapping, go to these sections for information you are interested in:
l Configuring a Priority Mapping Table
l Configuring the Priority for a Port
l Configuring the Trusted Precedence Type for a Port
l Displaying and Maintaining Priority Mapping
l Priority Mapping Configuration Examples
This section introduces IP precedence, ToS precedence, differentiated services codepoint (DSCP) values, and 802.1p priority.
1) IP precedence, ToS precedence, and DSCP values
Figure 5-1 DS field and ToS bytes
As shown in Figure 5-1, the ToS field of the IP header contains eight bits: the first three bits (0 to 2) represent IP precedence from 0 to 7; the subsequent four bits (3 to 6) represent a ToS value from 0 to 15. According to RFC 2474, the ToS field of the IP header is redefined as the differentiated services (DS) field, where a DSCP value is represented by the first six bits (0 to 5) and is in the range 0 to 63. The remaining two bits (6 and 7) are reserved.
Table 5-1 Description on IP Precedence
|
IP Precedence (decimal) |
IP Precedence (binary) |
Description |
|
0 |
000 |
Routine |
|
1 |
001 |
priority |
|
2 |
010 |
immediate |
|
3 |
011 |
flash |
|
4 |
100 |
flash-override |
|
5 |
101 |
critical |
|
6 |
110 |
internet |
|
7 |
111 |
network |
In a network in the Diff-Serve model, traffic is grouped into the following four classes, and packets are processed according to their DSCP values.
l Expedited Forwarding (EF) class: In this class, packets are forwarded regardless of link share of other traffic. The class is suitable for preferential services requiring low delay, low packet loss, low jitter, and high bandwidth.
l Assured forwarding (AF) class: This class is divided into four subclasses (AF 1 to AF 4), each containing three drop priorities for more granular classification. The QoS level of the AF class is lower than that of the EF class.
l Class selector (CS) class: This class is derived from the IP ToS field and includes eight subclasses;
Table 5-2 Description on DSCP values
|
DSCP value (decimal) |
DSCP value (binary) |
Description |
|
46 |
101110 |
ef |
|
10 |
001010 |
af11 |
|
12 |
001100 |
af12 |
|
14 |
001110 |
af13 |
|
18 |
010010 |
af21 |
|
20 |
010100 |
af22 |
|
22 |
010110 |
af23 |
|
26 |
011010 |
af31 |
|
28 |
011100 |
af32 |
|
30 |
011110 |
af33 |
|
34 |
100010 |
af41 |
|
36 |
100100 |
af42 |
|
38 |
100110 |
af43 |
|
8 |
001000 |
cs1 |
|
16 |
010000 |
cs2 |
|
24 |
011000 |
cs3 |
|
32 |
100000 |
cs4 |
|
40 |
101000 |
cs5 |
|
48 |
110000 |
cs6 |
|
56 |
111000 |
cs7 |
|
0 |
000000 |
be (default) |
802.1p priority lies in Layer 2 packet headers and is applicable to occasions where Layer 3 header analysis is not needed and QoS must be assured at Layer 2.
Figure 5-2 An Ethernet frame with an 802.1Q tag header
As shown in Figure 5-2, the 4-byte 802.1Q tag header consists of the tag protocol identifier (TPID, two bytes in length), whose value is 0x8100, and the tag control information (TCI, two bytes in length). Figure 5-3 presents the format of the 802.1Q tag header.
The priority in the 802.1Q tag header is called 802.1p priority, because its use is defined in IEEE 802.1p. Table 5-3 presents the values for 802.1p priority.
Table 5-3 Description on 802.1p priority
|
802.1p priority (decimal) |
802.1p priority (binary) |
Description |
|
0 |
000 |
best-effort |
|
1 |
001 |
background |
|
2 |
010 |
spare |
|
3 |
011 |
excellent-effort |
|
4 |
100 |
controlled-load |
|
5 |
101 |
video |
|
6 |
110 |
voice |
|
7 |
111 |
network-management |
When a packet enters a device, the device assigns to the packet a series of predefined parameters (including 802.1p priority, DSCP precedence, local precedence, and drop precedence).
The local precedence and drop precedence are defined as follows:
l Local precedence is a locally significant precedence that the device assigns to a packet. A local precedence value corresponds to an output queue. Packets with the highest local precedence are processed preferentially. The specific process method varies with device models.
l Drop precedence is a parameter used for packet drop. The value 2 corresponds to red packets, the value 1 corresponds to yellow packets, and the value 0 corresponds to green packets. Packets with the highest drop precedence are dropped preferentially. The specific process method varies with device models.
An S3600 series EPON OLT switch can trust one of the following two priority types:
l Trusting the DSCP precedence of received packets. In this mode, the switch searches the DSCP-to-802.1p/drop/DSCP mapping table based on the DSCP precedence of the received packet for the 802.1p priority/drop precedence/DSCP precedence to be used to mark the packet. Then the switch searches the DSCP-to-local mapping table based on the marked DSCP precedence for the corresponding local precedence and marks the received packet with the local precedence.
l Trusting the 802.1p priority of received packets. When an 802.1q tagged packet reaches a port in this mode, the switch uses the 802.1p priority carried in the packet rather than the port priority to search the 802.1p-to-local/drop priority mapping table for the local and drop precedence to be assigned to the packet. If the arriving packet is not 802.1q tagged, however, the port priority is used to do the search.
The device provides various types of priority mapping table, as listed below.
l dot1p-dp: 802.1p-to-drop priority mapping table.
l dot1p-lp: 802.1p-to-local priority mapping table.
l dscp-dot1p: DSCP-to-802.1p priority mapping table, which is applicable to only IP packets.
l dscp-dp: DSCP-to-drop priority mapping table, which is applicable to only IP packets.
l dscp-dscp: DSCP-to-DSCP priority mapping table, which is applicable to only IP packets.
The default dot1p-dp and dot1p-lp priority mapping tables on Ethernet ports are different from those on OLT ports. For details, refer to Table 5-4 and Table 5-5.
Table 5-4 The default dot1p-lp and dot1p-dp priority mapping tables on Ethernet ports
|
Input priority value |
dot1p-lp mapping |
dot1p-dp mapping |
|
802.1p |
Local precedence (lp) |
Drop precedence (dp) |
|
0 |
2 |
0 |
|
1 |
0 |
0 |
|
2 |
1 |
0 |
|
3 |
3 |
0 |
|
4 |
4 |
0 |
|
5 |
5 |
0 |
|
6 |
6 |
0 |
|
7 |
7 |
0 |
Table 5-5 The default dot1p-lp and dot1p-dp priority mapping tables on OLT ports
|
Input priority value |
dot1p-lp mapping |
dot1p-dp mapping |
|
802.1p |
Local precedence (lp) |
Drop precedence (dp) |
|
0 |
0 |
0 |
|
1 |
1 |
0 |
|
2 |
2 |
0 |
|
3 |
3 |
0 |
|
4 |
4 |
0 |
|
5 |
5 |
0 |
|
6 |
6 |
0 |
|
7 |
7 |
0 |
Table 5-6 The default dscp-dp and dscp-dot1p priority mapping tables
|
Input priority value |
dscp-dp mapping |
dscp-dot1p mapping |
|
dscp |
Drop precedence (dp) |
802.1p priority (dot1p) |
|
0 to 7 |
0 |
0 |
|
8 to 15 |
0 |
1 |
|
16 to 23 |
0 |
2 |
|
24 to 31 |
0 |
3 |
|
32 to 39 |
0 |
4 |
|
40 to 47 |
0 |
5 |
|
48 to 55 |
0 |
6 |
|
56 to 63 |
0 |
7 |
For the default dscp-dscp mappings, an input value yields a target value that is equal to it.
When an ONU receives packets from an ONU port, it assigns local precedence to the packets according to the 802.1p-to-local priority mapping table. Table 5-7 shows the default 802.1p-to-local priority mapping table.
Table 5-7 The default 802.1p-tolocal priority mapping table
|
802.1p priority |
Local precedence |
|
0 |
0 |
|
1 |
0 |
|
2 |
1 |
|
3 |
1 |
|
4 |
2 |
|
5 |
2 |
|
6 |
3 |
|
7 |
3 |
You can classify the traffic received on a UNI based on information in the traffic, such as MAC address and IP address, and then configure different mapping policies for each class of packets. When the ONU receives packets on a UNI, it determines the actions to perform for packets based on the match criteria, VLAN operation mode of the port, and VLAN tagging status of the received packets. For details, refer to Table 5-8.
Table 5-8 Relationship between VLAN operation modes and priority remarking
|
VLAN operation mode |
With or without VLAN tag |
Packet processing |
|
Transparent mode |
With VLAN tag |
l In the case of traffic classification based on the source MAC address/destination MAC address, Ethernet priority, VLAN ID, or physical port, if the packet matches the configured traffic classification rule, the packet is priority-remarked with the value specified in the rule and is then forwarded; otherwise, the packet is directly forwarded. l In the case of traffic classification based on Ethernet type, DSCP, IP protocol type, source IP address/destination IP address, or source L4 port, the packet is forwarded without any change. |
|
Without VLAN tag |
The packet is forwarded without any change. |
|
|
Tag mode |
With VLAN tag |
The packet is dropped. |
|
Without VLAN tag |
l The packet is tagged with the VLAN tag corresponding to the default PVID of the port, and then: l If the packet matches the configured traffic classification rule, the packet is priority-remarked with the value specified in the rule and is then forwarded; l Otherwise, the packet is remarked with the port priority and is then forwarded. |
|
|
Translation mode |
With VLAN tag |
Case 1: The VLAN ID in the VLAN tag matches a VLAN translation entry on the port. The VLAN ID is replaced with the VLAN ID corresponding to the entry, and then: l If the packet matches the configured traffic classification rule, the packet is priority-remarked with the value specified in the rule and is then forwarded; l Otherwise, the packet is directly forwarded. Case 2: The VLAN ID in the tag is the default VLAN ID of the port: l If the packet matches the configured traffic classification rule, the packet is priority-remarked with the value specified in the rule and is then forwarded; l Otherwise, the packet is directly forwarded. Case 3: The VLAN ID in the tag does not match any VLAN translation entry on the port. The packet is dropped. |
|
Without VLAN tag |
The packet is tagged with the VLAN tag corresponding to the default PVID of the port, and then: l If the packet matches the configured traffic classification rule, the packet is priority-remarked with the value specified in the rule and is then forwarded; l Otherwise, the packet is remarked with the port priority and is then forwarded. |
You can modify the priority mapping tables of an OLT device or ONU device as needed.
You need to decide on the new mapping values.
Follow these steps to configure a priority mapping table:
|
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
Enter priority mapping table view |
qos map-table { dot1p-dp | dot1p-lp | dscp-dot1p | dscp-dp | dscp-dscp } |
Required You can enter the corresponding priority mapping table view as required. |
|
Configure the priority mapping table |
import import-value-list export export-value |
Required Newly configured mappings overwrite the previous ones. |
|
Display the configuration of the priority mapping table |
display qos map-table [ dot1p-dp | dot1p-lp | dscp-dot1p | dscp-dp | dscp-dscp ] |
Optional Available in any view |
Follow these steps to modify the 802.1p-local priority mapping table of an OLT port:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter OLT port view |
interface interface-type interface-number |
— |
|
Modify the 802.1p-to-local priority mapping table on the OLT port for downlink or uplink traffic |
priority-queue-mapping { downstream | upstream } { value } &<1-8> |
Optional For the default mapping, see Table 5-5. |
Follow these steps to configure the 802.1p-to-local priority mapping table:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter ONU port view |
interface interface-type interface-number |
— |
|
Configure the 802.1p-to-local priority mapping table |
qos cos-local-precedence-map cos0-map-local-prec cos1-map-local-prec cos2-map-local-prec cos3-map-local-prec cos4-map-local-prec cos5-map-local-prec cos6-map-local-prec cos7-map-local-prec |
Required The default 802.1p-to-local priority mapping table is shown in Table 5-7. |
Follow these steps to configure uplink traffic classification and priority remarking for a UNI:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter ONU port view |
interface interface-type interface-number |
— |
|
Configure uplink traffic priority remarking for a UNI |
uni uni-number classification-marking index index queue qid priority priority { selector operator matched-value } &<1-4> |
Required |
Currently, up to eight rules can be configured for each UNI port on an H3C ONU.
Table 5-9 Restrictions about the configuration
|
Item |
Restrictions |
|
Priority remarking based on the source MAC address or destination Mac address |
l If a source MAC address–based traffic classification rule and a destination MAC address–based traffic classification rule are configured for a UNI port of an ONU, and if the uplink traffic satisfies both rules, only the destination MAC address–based traffic classification rule applies even if the other one has a higher priority. l The configuration of destination MAC address–based priority remarking takes effect globally. Namely, a destination MAC address–based traffic classification rule configured for a UNI port of an ONU applies to incoming traffic from all the other UNI ports of the ONU. l In the case of source MAC address–based priority remarking for a UNI port, the ONU adds the source MAC address and the corresponding UNI port statically into its MAC address table; In the case of destination MAC address–based priority remarking for a UNI port, the ONU adds the destination MAC address and the PON port of the ONU statically into its MAC address table. l It does not support priority remarking based on the source MAC addresses/destination MAC addresses that are multicast MAC addresses, all-0 MAC addresses, broadcast MAC addresses, or the MAC address of the ONU. |
|
Priority remarking based on Ethernet priority |
When the VLAN operation mode is set to tag mode for a UNI and the 802.1p priority value in the traffic classification rule is the same as the priority of the UNI, the traffic classification rule will not take effect. |
|
Priority remarking based on VLAN ID |
The configuration of VLAN ID–based priority remarking takes effect globally. Namely, a VLAN ID–based traffic classification rule configured for a UNI port of an ONU applies to incoming traffic from all the other UNI ports of the ONU. |
|
Priority remarking based on Ethernet type, DSCP, IP protocol type, source IP address/destination IP address, or source L4 port |
l The configuration of priority remarking based on Ethernet type, DSCP, IP protocol type, source IP address/destination IP address, or source L4 port takes effect globally. Namely, such a traffic classification rule configured for a UNI port of an ONU applies to incoming traffic from all the other UNI ports of the ONU. l If multiple rules are matched on the same UNI of an ONU, the match sequence is L3 à L4 à L2; if the rules are for the same layer, the rule with the smallest index has the highest precedence. l The device does not support priority remarking for different UNIs of an ONU based on the same Ethernet type, DSCP, IP protocol type, source IP address/destination IP address, or source L4 port. l The device does not support priority remarking based on destination L4 ports. |
For the VLAN operation mode and configuration on an UNI, refer to VLAN Configuration.
Modify the dot1p-lp mapping table of an OLT port as shown in Table 5-10.
Table 5-10 The dot1p-lp mapping table
|
802.1p priority |
Local precedence |
|
0 |
0 |
|
1 |
0 |
|
2 |
1 |
|
3 |
1 |
|
4 |
2 |
|
5 |
2 |
|
6 |
3 |
|
7 |
3 |
l Configure the dot1p-lp priority mapping table of an Ethernet port
# Enter system view.
<Sysname> system-view
# Enter the dot1p-lp priority mapping table view.
[Sysname] qos map-table dot1p-lp
# Modify dot1p-lp priority mapping parameters.
[Sysname-maptbl-dot1p-lp] import 0 1 export 0
[Sysname-maptbl-dot1p-lp] import 2 3 export 1
[Sysname-maptbl-dot1p-lp] import 4 5 export 2
[Sysname-maptbl-dot1p-lp] import 6 7 export 3
l Configure the dot1p-lp priority mapping table of OLT 1/0/1
# Enter system view.
<Sysname> system-view
# Enter port view of OLT 1/0/1.
[Sysname] interface Olt 1/0/1
# Modify dot1p-lp priority mapping parameters.
[Sysname-Olt1/0/1] priority-queue-mapping upstream 0 0 1 1 2 2 3 3
Port priority is in the range of 0 to 7. You can set the port priority as needed.
You need to decide on a priority for the port.
Follow these steps to configure port priority:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter Ethernet port view, OLT port view or ONU port view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure a priority for the port |
qos priority priority-value |
Required The default port priority is 0. |
|
Set the priority of the port to 7.
# Enter system view.
<Sysname> system-view
# Set the priority of OLT 1/0/1 to 7.
[Sysname] interface Olt 1/0/1
[Sysname-Olt1/0/1] qos priority 7
You can configure whether to trust the priority of packets. On a device supporting port trusted precedence type, the priority mapping process for packets is shown in Priority Mapping Overview.
You can configure one of the following trusted precedence types for a port:
l dot1p: Trusts the 802.1p priority of the received packets and uses the 802.1p priority for mapping.
l dscp: Trusts the DSCP precedence of the received IP packets and uses the DSCP precedence for mapping.
l The trusted precedence type for the port is determined.
l The priority mapping table corresponding to the trusted precedence type is configured. For the detailed configuration procedure, refer to Configuring a Priority Mapping Table.
Follow these steps to configure the trusted precedence type:
|
To do… |
Use the command… |
Remarks |
|
|
Enter system view |
system-view |
— |
|
|
Enter interface view or port group view |
Enter Ethernet port view, OLT port view or ONU port view |
interface interface-type interface-number |
Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.. |
|
Enter port group view |
port-group manual port-group-name |
||
|
Configure to trust the DSCP precedence of the received packets |
qos trust dscp |
Use either command By default, the 802.1p priority of the received packets is trusted |
|
|
Configure to trust the 802.1p priority of the received packets |
undo qos trust |
||
|
Display the trusted precedence type configuration |
display qos trust interface [ interface-type interface-number ] |
Optional Available in any view |
|
Configure the port OLT 1/0/1 to trust the DSCP precedence.
# Enter system view.
<Sysname> system-view
# Enter port view.
[Sysname] interface Olt 1/0/1
# Configure the port to trust the DSCP precedence.
[Sysname-Olt1/0/1] qos trust dscp
|
To do… |
Use the command… |
Remarks |
|
Display priority mapping table configuration information |
display qos map-table [ dot1p-dp | dot1p-lp | dscp-dot1p | dscp-dp | dscp-dscp ] |
Available in any view |
|
Display the trusted precedence type on the port |
display qos trust interface [ interface-type interface-number ] |
Available in any view |
As shown in Figure 5-4, an S3600 EPON OLT switch connects to multiple networks through Ethernet ports and OLT ports.
Configure the S3600 switch to enqueue packets based on the 802.1p priority of packets. The priority mapping tables are user-defined.
Figure 5-4 Network diagram for priority mapping configuration
# Enter system view.
<Switch> system-view
# Enter inbound dot1p-lp priority mapping table view and modify the priority mapping table parameters.
[Switch] qos map-table inbound dot1p-lp
[Switch-maptbl-in-dot1p-lp] import 0 1 export 0
[Switch-maptbl-in-dot1p-lp] import 2 3 export 1
[Switch-maptbl-in-dot1p-lp] import 4 5 export 2
[Switch-maptbl-in-dot1p-lp] import 6 7 export 3
[Switch-maptbl-in-dot1p-lp] quit
# Configure GigabitEthernet 1/1/1 to trust the 802.1p priority of packets.
[Switch] interface gigabitethernet 1/1/1
[Switch-GigabitEthernet1/1/1] qos trust dot1p
[Switch-GigabitEthernet1/1/1] quit
# Configure GigabitEthernet 1/1/3 to trust the 802.1p priority of packets.
[Switch] interface gigabitethernet 1/1/3
[Switch-GigabitEthernet1/1/3] qos trust dot1p
[Switch-GigabitEthernet1/1/3] quit
# Configure the 802.1p-to-local priority mapping table for upstream and downstream packets of OLT 1/0/1 respectively.
[Switch] interface Olt 1/0/1
[Switch-Olt1/0/1] priority-queue-mapping downstream 0 0 1 1 2 2 3 3
[Switch-Olt1/0/1] priority-queue-mapping upstream 0 0 1 1 2 2 3 3
[Switch-Olt1/0/1] quit
# Configure the 802.1p-to-local priority mapping table for upstream and downstream packets of OLT 1/0/2 respectively.
[Switch] interface Olt 1/0/2
[Switch-Olt1/0/2] priority-queue-mapping downstream 0 0 1 1 2 2 3 3
[Switch-Olt1/0/2] priority-queue-mapping upstream 0 0 1 1 2 2 3 3
As shown in Figure 5-5, a switch connects to multiple networks through Ethernet ports and OLT ports.
Configure the switch to assign local precedence to received packets based on the port priority of receiving ports. The default priority mapping tables are adopted.
Figure 5-5 Network diagram for port priority configuration
# Enter system view.
<Switch> system-view
# Configure the priority of GigabitEthernet 1/1/1.
[Switch] interface gigabitethernet 1/1/1
[Switch-GigabitEthernet1/1/1] qos priority 1
[Switch-GigabitEthernet1/1/1] quit
# Configure the priority of GigabitEthernet 1/1/3.
[Switch] interface gigabitethernet 1/1/3
[Switch-GigabitEthernet1/1/3] qos priority 3
[Switch-GigabitEthernet1/1/3] quit
# Configure the priority of OLT 1/0/1.
[Switch] interface Olt 1/0/1
[Switch-Olt1/0/1] qos priority 5
[Switch-Olt1/0/1] quit
# Configure the priority of OLT 1/0/2.
[Switch] interface Olt 1/0/2
[Switch-Olt1/0/2] qos priority 7
As shown in Figure 5-6:
l Set the uplink bandwidth of the ONU to 50 Mbps.
l Configure the VLAN operation mode as transparent for both UNI 1 and UNI 2.
l Configure priority remarking for UNI 1: Remark tagged packets sourced from the MAC address of 000A-EB7F-AAAB with 802.1p priority 3.
l Configure priority remarking for UNI 2: Remark tagged packets sourced from the MAC address of 001B-EB7F-21AC with 802.1p priority 1.
Figure 5-6 Network diagram for UNI priority remarking configuration
# Create ONU 3/0/1:1, and bind it to an ONU.
<Sysname> system-view
[Sysname] interface olt 3/0/1
[Sysname-Olt3/0/1] using onu 1
[Sysname-Olt3/0/1] quit
[Sysname] interface onu 3/0/1:1
[Sysname-Onu3/0/1:1] bind onuid 000f-e200-0104
# Set the uplink bandwidth of the ONU port to 50 Mbps (64 Kbps × 800).
[Sysname-Onu3/0/1:1] upstream-sla minimum-bandwidth 800 maximum-bandwidth 800
# Configure the VLAN operation mode as transparent for UNI 1 and UNI 2.
[Sysname-Onu3/0/1:1] uni 1 vlan-mode transparent
[Sysname-Onu3/0/1:1] uni 2 vlan-mode transparent
For detailed information about ONU uplink bandwidth and VLAN operation mode of a UNI, refer to EPON-OLT Configuration.
# Configure priority remarking for UNI 1 and UNI 2.
[Sysname-Onu3/0/1:1] uni 1 classification-marking index 1 queue 3 priority 3 src-mac equal 000A-EB7F-AAAB
[Sysname-Onu3/0/1:1] uni 2 classification-marking index 1 queue 1 priority 1 src-mac equal 001B-EB7F-21AC
Suppose congestion occurs on the ONU port when two 50-Mbps streams sent by the UNIs respectively towards the OLT arrive after the above configuration is complete. The ONU port will then drop the packets sourced from the MAC address of 001B-EB7F-21AC, because their queue precedence is lower than that of the packets sourced from the MAC address of 000A-EB7F-AAAB.
When configuring traffic mirroring, go to these sections for information you are interested in:
l Configuring Traffic Mirroring
l Displaying and Maintaining Traffic Mirroring
l Traffic Mirroring Configuration Example
Traffic mirroring refers to the process of copying the specified packets to the specified destination for packet analysis and monitoring.
You can configure mirroring traffic to an interface, or to the CPU.
l Mirroring traffic to an interface: copies the matching packets on an interface to a destination interface.
l Mirroring traffic to the CPU: copies the matching packets on an interface to a CPU (the CPU of the board where the traffic mirroring-enabled interface resides).
To configure traffic mirroring, you must enter the view of an existing traffic behavior.
In a traffic behavior, the action of mirroring traffic to an interface, and the action of mirroring traffic to a CPU is mutually exclusive.
Follow these steps to mirror traffic to an interface:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter traffic behavior view |
traffic behavior behavior-name |
— |
|
Specify the destination interface for traffic mirroring |
mirror-to interface interface-type interface-number |
Required |
Follow these steps to mirror traffic to the CPU:
|
To do… |
Use the command… |
Remarks |
|
Enter system view |
system-view |
— |
|
Enter traffic behavior view |
traffic behavior behavior-name |
— |
|
Mirror traffic to the CPU |
mirror-to cpu |
Required |
|
To do… |
Use the command… |
Remarks |
|
Display traffic behavior configuration information |
display traffic behavior user-defined [ behavior-name ] |
Available in any view |
|
Display QoS policy configuration information |
display qos policy user-defined [ policy-name [ classifier tcl-name ] ] |
Available in any view |
On the custom network shown in Figure 6-1,
l The hosts are connected to Device through OLT 1/0/1. The MAC address of Host A is 0014-222c-aa6.
l Server is connected to GigabitEthernet 1/1/2 of Device.
Configure the mirror-to-port action on Switch to mirror all the packets sent by Host A to Server for analysis.
Figure 6-1 Network diagram for mirroring traffic to a port
Configuration on Device:
# Enter system view.
<Device> system-view
# Configure ACL 2000 to permit all packets.
[Device] acl number 2000
[Device-acl-basic-2000] rule 1 permit
[Device-acl-basic-2000] quit
# Create class 1 and reference ACL 2000 for traffic classification in class 1.
[Device] traffic classifier 1
[Device-classifier-1] if-match acl 2000
[Device-classifier-1] quit
# Create behavior 1 and configure the action of mirroring traffic to GigabitEthernet 1/1/2 for the behavior.
[Device] traffic behavior 1
[Device-behavior-1] mirror-to interface gigabitethernet 1/1/2
[Device-behavior-1] quit
# Create QoS policy 1 and associate traffic behavior 1 with class 1 in the QoS policy.
[Device] qos policy 1
[Device-qospolicy-1] classifier 1 behavior 1
[Device-qospolicy-1] quit
# Apply QoS policy 1 in the inbound direction of OLT 1/0/1.
[Device] interface Olt 1/0/1
[Device-Olt1/0/1] qos apply policy 1 inbound
After the configurations above are completed, you can analyze and monitor all the packets that Host A sends on Server.
