ZXR10 ZSR V2. Configuration Guide (QoS) Intelligent Integrated Multi-Service Router. Version:

Transcription

1 ZXR10 ZSR V2 Intelligent Integrated Multi-Service Router Configuration Guide (QoS) Version: ZTE CORPORATION No. 55, Hi-tech Road South, ShenZhen, P.R.China Postcode: Tel: Fax: URL:

2 LEGAL INFORMATION Copyright 2014 ZTE CORPORATION. The contents of this document are protected by copyright laws and international treaties. Any reproduction or distribution of this document or any portion of this document, in any form by any means, without the prior written consent of ZTE CORPORATION is prohibited. Additionally, the contents of this document are protected by contractual confidentiality obligations. All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE CORPORATION or of their respective owners. This document is provided as is, and all express, implied, or statutory warranties, representations or conditions are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose, title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the use of or reliance on the information contained herein. ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications covering the subject matter of this document. Except as expressly provided in any written license between ZTE CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter herein. ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice. Users may visit the ZTE technical support website to inquire for related information. The ultimate right to interpret this product resides in ZTE CORPORATION. Revision History Revision No. Revision Date Revision Reason R First edition Serial Number: SJ Publishing Date: (R1.0)

3 Contents About This Manual... I Chapter 1 QoS Overview Chapter 2 CAR Configuration CAR Overview TrTCM Overview Configuring CAR CAR Configuration Instance Chapter 3 Flow Classification Configuration Flow Classification Overview Configuring Flow Classification Flow Classification Configuration Instances Configuring Null-Rule Flow Classification Configuring EXP-Based Flow Classification Configuring MAC Address-Based Flow Classification Configuring IPv4 ACL-Based Flow Classification Classifying Flows in the Match-Any Mode Chapter 4 Flow Action Configuration Flow Action Overview Configuring Flow Actions Flow Action Configuration Instances Configuring Packet Marking Configuring Traffic Supervision Configuring PQ Configuring WFQ Configuring CBWFQ Configuring WRED Chapter 5 H-QoS Configuration H-QoS Overview Configuring H-QoS H-QoS Configuration Instance Chapter 6 Priority Inheritance Configuration Priority Inheritance Overview I

4 6.2 Configuring Priority Inheritance Priority Inheritance Configuration Instances P Inheritance Configuration Instance Pipe Mode Configuration Instance Figures... I Glossary... III II

5 About This Manual Purpose This manual describes the principle, configuration commands and configuration instances about QoS function of the ZXR10 ZSR V2. Intended Audience This manual is intended for: Network planning engineers Commissioning engineers Maintaining engineers What Is in This Manual This manual contains the following chapters: Chapter Summary 1, QoS Overview Provides an overview of QoS, differences between integrated service and differentiated service, principle of QoS tool, queue policy and drop policy. 2, CAR Configuration Describes the CAR principle, configuration commands and configuration instances. 3, Flow Classification Configuration Describes the Flow Classification principle, configuration commands and configuration instances. 4, Flow Action Configuration Describes the Flow Action principle, configuration commands and configuration instances. 5, H-QoS Configuration Describes the H-QoS principle, configuration commands and configuration instances. 6, Priority Inheritance Configuration Describes the Priority Inheritance principle, configuration commands and configuration instances. Conventions This manual uses the following typographical conventions: Typeface Italics Bold Meaning Variables in commands. It may also refers to other related manuals and documents. Menus, menu options, function names, input fields, option button names, check boxes, drop-down lists, dialog box names, window names, parameters and commands. I

6 Typeface Constant width Meaning Text that you type, program codes, filenames, directory names, function names. [ ] Optional parameters. { } Mandatory parameters. Separates individual parameter in series of parameters. Danger: indicates an imminently hazardous situation. Failure to comply can result in death or serious injury, equipment damage, or site breakdown. Warning: indicates a potentially hazardous situation. Failure to comply can result in serious injury, equipment damage, or interruption of major services. Caution: indicates a potentially hazardous situation. Failure to comply can result in moderate injury, equipment damage, or interruption of minor services. Note: provides additional information about a certain topic. II

7 Chapter 1 QoS Overview Introduction to QoS In traditional Internet Protocol (IP) networks, all packets are treated in the same way. Routers use the First In First Out (FIFO) policy to process these packets. Routers transmit packets to destinations with the best-effort principle. However, routers cannot guarantee the performance such as transmission reliability and delay. With the development of new applications in IP networks, there are new requirements for Quality of Service (QoS). The best-effort principle in traditional IP networks cannot meet the requirements of applications. For VoIP services for example, long delays in packets transmission are not tolerated. A feasible method to solve this problem is to provide the Quality of Service (QoS) ability for the Internet. QoS is used to provide different service qualities (such as providing special bandwidth, reducing the packet loss rate, and reducing delay and delay jitter) in accordance with different requirements of applications. To achieve this purpose, QoS provides the following functions: Packet classification Packet marking Traffic supervision and shaping Congestion avoidance Congestion management Integrated Service and Differentiated Service To implement QoS in IP networks, it is necessary to provide better and more predictable network services through the configurations of characteristics, such as allocating bandwidth, reducing packet loss rate, avoiding and managing congestion, measuring network traffic, and setting the priority for cross-network service flows. QoS provides a series of measures for service guarantee at the best-effort IP layer. There are two QoS models: Integrated Service (IntServ) Differentiated Service (DiffServ) The IntServ model can meet different QoS requirements. This model requests specific resources before packets are sent. The request is sent through a signal. An application advertises its traffic parameters and specific service quality request (including bandwidth, and delay) to the network. The application sends packets after receiving the confirmation message, that is, confirming that the network has reserved resources for this application. At the same time, the packets sent by the application are controlled within the description range of traffic parameters. 1-1

8 ZXR10 ZSR V2 Configuration Guide (QoS) This model can meet the QoS requirement. However, because the network needs to maintain a QoS record for each flow, the network extension may be affected, and this model is not widely used in practical applications. Different from the IntServ model, the DiffServ model does not need a signal. That is, before packets are sent, an application program does not need to notify network. The network does not need to maintain the QoS record for each flow. This module provides specific services in accordance with the QoS designated in each packet. Users can use different methods to designate the QoS of each packet, such as in the IP precedence, source address, and destination address. The network implements packet classification, traffic shaping, traffic supervision, and congestion management in accordance with the information. The DiffServ model can be considered as a compromise of IntServ model and best-effort mode. The service granularity of the DiffServ model is larger than that of the IntServ model. Compared with best-effort, the DiffServ model supports the traffic priority. The DiffServ model contains the following two complementary parts: Traffic classification: Including classification in accordance with Access Control List (ACL), traffic amount, Type Of Service (ToS) and Network Based Application Recognition (NBAR). Classification management policy: Including the queuing policy, dropping policy, and shaping policy. QoS Tools In general, the QoS tools in router devices include the classification and marking tool, traffic supervision and shaping tool, congestion avoidance tool, and congestion management tool. Packet classification: The packet classification tool can classify network service flows into several priorities or service classes. For example, in accordance with the Differentiated Services Code Point (DSCP) field in IP packet headers, packets can be classified into 64 service classes at most. After the packet classification, different QoS policies, such as congestion management, traffic supervision and shaping, packet marking and re-marking, can be applied to different service classes. Common packet classification basis include physical interface, sub-interface, PVC, Medium Access Control (MAC) address, 802.1Q/p CoS, Multi Protocol Label Switching (MPLS) EXP, DSCP, IP precedence (IPP), IP quintuple group, packet header, and Uniform Resource Locator (URL) in payload. Packet marking: The marking tool is normally used to create the trust boundary relied on by other QoS tools. Users can make different marks for different service classes in accordance with user policies. A mark of a packet can be the criteria for the next classification, and the mark also can be carried to other devices by the packet. In 1-2

9 Chapter 1 QoS Overview addition, the routers can re-mark packets in accordance with traffic supervision results, such as packet degradation. Traffic supervision and shaping: The traffic supervision is used to check traffic rate in real time and take corresponding actions when the traffic exceeds the committed rate. Traffic supervision can fix whether the traffic rate exceeds the committed rate. It will re-mark or drop the traffic that exceeds the committed rate. The traffic shaping is a traffic smoothing tool that operates together with the queuing mechanism. The traffic shaping function is used to ensure that the traffic is smoothly sent at a specified rate. If the outcoming traffic exceeds the designated rate temporarily, the traffic that exceeds the committed rate will be stored in a buffer and transmitted with delay. Congestion avoidance tool: The congestion avoidance tool is a supplement to the congestion management tool. The congestion management tool manages the head of a queue, while the congestion avoidance tool manages the tail of a queue. Common congestion avoidance tools include Random Early Detection (RED), Weighted Random Early Detection (WRED) and Explicit Congestion Notification (ECN). Congestion management tool: Among all QoS tools, the congestion management tool has the most obvious effect on the service quality of application programs. The congestion management tool is also considered as a queuing tool. When the congestion occurs in a network, the congestion management determines the de-queuing policies of different service flows. Common congestion management tools include Priority Queuing (PQ), Weighted Fair Queuing (WFQ), and Class Based Weighted Fair Queuing (CBWFQ). Queuing Policy The queuing policies consists of the following three types: First In First Out (FIFO) Queuing The FIFO queuing is the simplest queuing and it is the default queuing mode in a router. All packets to be sent on the interface go to the FIFO queue tail of an interface in accordance with the sequence they arrive. When a router sends packets, it begins from the FIFO queue head. During packet transmission, packets are treated in the same way. There is no guarantee for the packet transmission quality. Priority Queuing (PQ) PQ classifies traffic into four queues, including the high priority queue, the medium priority queue, the normal priority queue, and the low priority queue. The queues are handled in accordance with their respective priorities strictly. Packets in the high priority queue are first sent by using the PQ policy. The packets in the medium priority queue leave the queue after all the packets in the high priority queue are sent. Similarly, the packets in the normal priority queue leave the queue after all the packets in the medium priority queue are sent. At last, the packets in the low priority queue are sent. 1-3

10 ZXR10 ZSR V2 Configuration Guide (QoS) In this way, the packets in the higher priority queues are sent in preference to other packets. When congestion occurs in the network, the packets with lower priorities will be delayed by the packets with higher priorities. As a result, the packets for important services will always be processed first, and packets for unimportant services will be processed when the network is idle. In this way, the important services are handled quickly and network resources are used fully. Weighted Fair Queuing (WFQ) WFQ is a flow-based fair queuing. It is a queuing mode developed to adjust the advantages of flows with larger packets over the flows with smaller packets. Through the scheduling policy based on virtual sending clock, WFQ can allocate relatively fair bandwidths for flows with different sizes of packets. Dropping Policy A dropping policy is to determine the dropping mode to drop packets when a queue occurs congestion. Common dropping policies include tail drop, RED, and WRED. Figure 1-1Common QoS Flow in Router Devices shows the common QoS flow in router devices. Figure 1-1 Common QoS Flow in Router Devices 1-4

11 Chapter 2 CAR Configuration Table of Contents CAR Overview TrTCM Overview Configuring CAR CAR Configuration Instance CAR Overview Introduction to CAR The typical function of traffic supervision is to limit the traffic entering a link of a network and limit burst on a link. When packets meet specific conditions, if the packet traffic on a link is too large, the traffic supervision can take different actions on the packets, such as dropping packets, and resetting packet priorities. A common method is to use Committed Access Rate (CAR) to limit the packet traffic of a specific type, for example, limiting the bandwidth used by HTTP packets within 50%. For Internet Service Providers (ISPs), it is necessary to control the traffic that enters the network. For enterprise networks, controlling the traffic for some applications is a helpful tool to control network operations. Network administrators can use the CAR to control traffic. CAR is a type of basic traffic supervision technology. It is composed of traffic classification and rate limit. The CAR classification can be made on the basis of 802.1P, IP priority, DSCP, and MPLS-EXP. Token Bucket CAR uses Token Bucket (TB) to control traffic, see Figure 2-1Traffic Control Through CAR. 2-1

12 ZXR10 ZSR V2 Configuration Guide (QoS) Figure 2-1 Traffic Control Through CAR 1. A device classifies packets in accordance with the predefined matching rules. For the packets with defined traffic characteristics, the device will send them directly without the processing of the token bucket. For the packets with no defined traffic characteristics, they will be sent to the token bucket for processing. 2. If there are enough tokens to send the packets, the packets are allowed to pass and then be sent. If there are not enough tokens in the token bucket to send the packets, the packets will be dropped. In this way, packet traffic of a specific class can be controlled. 3. Tokens can be put to the bucket in accordance with the rate set by users. Users also can set the capacity of the token bucket. When the amount of tokens is equal to the capacity, the amount will not increase. 4. When a packet is handled by the token bucket, if there are enough tokens in the bucket, the packet will be allowed to pass and the appropriate amount of tokens in the bucket will be removed in accordance with the length of the packet. When there are not enough tokens, the packet will be dropped. The token bucket is a good tool to control the data flow. When the bucket is full of tokens, all the packets represented by tokens can be transmitted. This allows the burst transmission of data. When there is no token in the bucket, packets will not be sent until enough tokens are generated in the bucket. Therefore, the rate of packet traffic should not be larger than the rate to generate tokens, which achieves traffic limit. In practical applications, CAR not only can be used to control traffic, but also can be used to mark or re-mark packets. That is, CAR can be used to set or modify the priorities of IP packets, which achieves marking packets. For example, when packets meet the traffic characteristics, set the priorities of the packets to 5. When the packets do not meet the traffic characteristics, drop the packets, or set the priorities to 1 and then send them. In this way, the device ensures not to drop packets 2-2

13 Chapter 2 CAR Configuration with priority 5 in the following processing if possible. When there is no congestion on the network, the packets with priority 1 are also sent. When congestion occurs, the packets with priority 1 are dropped first, and then the packets with priority 5 may be dropped. 2.2 TrTCM Overview Introduction to TrTCM Two-rate Three Color Marker (TrTCM) classifies IP packet flows based on the Peak Information Rate (PIR), Committed Information Rate (CIR), and their related burst sizes. TrTCM marks these packets in green, yellow, or red. If the rate of a packet exceeds the PIR, it is marked in red. Otherwise, the packet is marked in yellow or green in accordance with the fact that whether the packet exceeds the CIR. TrTCM Configuration The configuration of the TrTCM is implemented by setting its mode and assigning values for the four traffic parameters. The parameters are: Peak Information Rate (PIR) Peak Burst Size (PBS) Committed Information Rate (CIR) Committed Burst Size (CBS) The unit of PIR and CIR is Kbit/s, and the unit of PBS and CBS is bytes. The PIR and CIR are measured in bytes of IP packets per second. The value of PIR must not be less than the value of CIR. The PBS and CBS are measured in bytes of IP packets. Their values must be more than 0 and must not be less than the maximum bytes of IP packets that may pass every second. TrTCM Classification Two buckets are needed to complete the classification: Bucket P and bucket C. The filling rate of bucket P is PIR, and the filling rate of bucket C is CIR. The two rates are independent of each other. The largest size of bucket P is PBS, and the largest size of bucket C is CBS. In initialization, the two buckets are full of tokens, Tp (0) = PBS, and Tc (0) = CBS. Then the number of the tokens in bucket P (that is, Tp) increases by PIR every second, and the upper limit is PBS. The number of the tokens in bucket C (that is, Tc) increases by CIR every second, and the upper limit is CBS. TrTCM Mark TrTCM marks reflect the results of classification. It is implemented by setting the DS fields in packets. 2-3

14 ZXR10 ZSR V2 Configuration Guide (QoS) 2.3 Configuring CAR This procedure describes how to configure CAR on the ZXR10 ZSR V2 to achieve the supervision and control of traffic in the network. Steps 1. Configure CAR. Step Command Function 1 ZXR10(config)#qos Enters QoS configuration mode. 2 ZXR10(config-qos)#interface <interface-name> Enters QoS interface configuration mode. 3 ZXR10(config-qos-if-interface-name)#rate-limit {input output}{unicast broadcast unknown ipv4-access-list <acl-name> ipv6-access-list <acl-name> localport dscp <dscp-value> mpls-exp <mpls-exp-value> precedence <prec-value> inner-8021p <in8021p-value>[outer-8021p <out8021p-value>] outer-8021p <out8021p-value> inner-vlan <invlan-value>[outer-vlan <outvlan-value>] outer-vlan <outvlan-value>} cir <cir-value> cbs <cbs-value> pir <pir-value> pbs <pbs-value> conform-action <action> exceed-action <action> violate-action <action> ZXR10(config-qos-if)#rate-limit {input output}{ipv4 ipv6}{dscp <dscp-value> precedence <prec-value>} cir <cir-value> cbs <cbs-value> pir <pir-value> pbs <pbs-value> conform-action <action> exceed-action <action> violate-action <action> Applies CAR on an interface and sets traffic supervision on input interface or output interface. Applies CAR on an interface and sets traffic supervision on input interface or output interface. broadcast: L2 VPN broadcast traffic. unicast: L2 VPN unicast traffic. unknown: L2 VPN unknown traffic. cir<cir-value>: CIR value, in the range of cbs<cbs-value>: CBS value, in the range of pir<pir-value>: PIR value, in the range of pbs<pbs-value>: PBS value, in the range of dscp <dscp-value>: DSCP value, in the range of mpls-exp <mpls-exp-value>: MPLS-EXP value, in the range of 0-7. precedence <prec-value>: IP priority, in the range of

15 Chapter 2 CAR Configuration outer-8021p<outer-8021p-value>: Outer-8021p value, in the range of 0-7. inner-8021p<inner-8021p-value>: Inner-8021p value, in the range of 0-7. outer-vlan<outer-vlan-value>: Outer-vlan value, in the range of inner-vlan<inner-vlan-value>: Inner-vlan value, in the range of statistical-share: Flow division mark. <action>: Use one of the following keyword to take action on packets matching the designated rate. drop: dropping packets transmit: transmitting packets set-dscp-transmit: setting DSCP value (0-63) and transmitting packets set-prec-transmit: setting IP priority (0-7) and transmitting packets set-exp-transmit: setting MPLS priority value (0-7) and transmitting packets set-8021p-transmit: setting 8021p priority (0-7) and transmitting packets 2. Verify the configuration. Command ZXR10#show running-config carset Function Displays CAR SET configuration on interfaces End of Steps 2.4 CAR Configuration Instance Configuration Description In Figure 2-2CAR Configuration Instance, user1 connects to the network through gei-1/1, and user2 connects to the network through gei-1/2. The precedence of user1 is 1, and the precedence of user2 is 2. Packets of user1 and user2 leave the device through gei-1/3. It is required that the precedence of packets that leave the device through gei-1/3 is 7, the guaranteed bandwidth is 100M, and the maximum bandwidth is 150 M. 2-5

16 ZXR10 ZSR V2 Configuration Guide (QoS) Figure 2-2 CAR Configuration Instance Configuration Flow Configure two CAR commands on gei-1/3. One matches precedence 1 and the other matches precedence 2. Set the precedence of traffic that passes the device to 7. Configuration Commands 1. Enter CAR configuration mode. ZXR10(config)#qos ZXR10(config-qos)# 2. Enter interface configuration mode. ZXR10(config-qos)#interface gei-1/3 ZXR10(config-qos-if-gei-1/3)# 3. Configure CARs. ZXR10(config-qos-if-gei-1/3)#rate-limit output precedence 1 cir cbs pir pbs conform-action set-prec-transmit 7 exceed-action set-prec-transmit 7 violate-action drop ZXR10(config-qos-if-gei-1/3)#rate-limit output precedence 2 cir cbs pir pbs conform-action set-prec-transmit 7 exceed-action set-prec-transmit 7 violate-action drop Configuration Verification Run the show running-config carset command to query CAR SET configuration on interfaces as follows. ZXR10(config)#show running-config carset!<carset> qos interface gei-1/3 rate-limit output precedence 1 cir cbs pir pbs conform-action set-prec-transmit 7 exceed-action set-prec-transmit 7 violate-action drop 2-6

17 Chapter 2 CAR Configuration rate-limit output precedence 2 cir cbs pir pbs conform-action set-prec-transmit 7 exceed-action set-prec-transmit 7 violate-action drop $ $!</carset> 2-7

18 ZXR10 ZSR V2 Configuration Guide (QoS) This page intentionally left blank. 2-8

19 Chapter 3 Flow Classification Configuration Table of Contents Flow Classification Overview Configuring Flow Classification Flow Classification Configuration Instances Flow Classification Overview Services are packet flows on networks. Before end-to-end QoS of services are provided, it is necessary to classify and mark (or color) the packet flows entering the network, thus ensuring that special packets can be treated and processed differently. Flow classification is implemented in accordance with the values in specified fields. Internet Engineering Task Force (IETF) defines the IPv4 ToS field and IPv6 traffic class, see Figure 3-1ToS Field and IPv6 Traffic Class. Figure 3-1 ToS Field and IPv6 Traffic Class The class of packets is marked by the DSCP field in IP packet headers, see Figure 3-2Class of Packets by Using DSCP. Figure 3-2 Class of Packets by Using DSCP Packet classification is used to classify packets into several service classes. The DSCP field of an IP header consists of 6 bits, so at most 64 service classes are supported in theory. After packets are classified, QoS can be used to customize proper policies to handle the flows, for example, accomplishing congestion management, bandwidth allocation, and delay limit for flows of a specified level. 3-1

20 ZXR10 ZSR V2 Configuration Guide (QoS) An MPLS packet uses the Exp field in an MPLS shim, see Figure 3-3Exp Field in an MPLS Shim. Figure 3-3 Exp Field in an MPLS Shim The Exp field consists of 3 bits, so 8 different QoS priorities are supported. A Label Edge Router (LER) in the MPLS domain sets the value of the Exp field in a packet after flow classification. The packet is then treated differently in accordance with the value when Label Switch Routers (LSRs) in the MPLS domain forwards labels. Packet classification in accordance with classification policies should be implemented on the basis of network structures and service requirements. The classification policies at the network edge are flexible. The packets can be classified in accordance with layer-3 features of packets. A packet flow may be determined by a quintuple (source address, source port number, protocol number, destination address, and destination port number). A packet flow may also consist of all packets in a specified network segment. After classification, it is necessary to set the value of the DSCP field in the IP header or the value of the Exp field in the MPLS shim. This type of setting is called re-mark. For details, refer to Chapter 4 in this document. After the re-mark operation, the value of the DSCP field or the Exp field is used as the basis of classification in the next processing. The next processing (or forwarding) node can accept the classification result of the previous hop processing (or forwarding) node, or classify and mark the packets again in accordance with its own classification policies. 3.2 Configuring Flow Classification This procedure describes how to configure flow classification that is used to classify data packets entering the network. The classified data packets can be controlled and processed by using the QoS technology. Steps 1. Configure flow classification. Step Command Function 1 ZXR10(config)#class-map<class-map-name>match-all[i pv4 ipv6] Creates a class-map and enters class mapping configuration mode. 3-2

21 Chapter 3 Flow Classification Configuration Step Command Function 2 ZXR10(config-cmap)#match dscp <dscp-value>[,<dscp-m in> <dscp-max>] ZXR10(config-cmap)#match precedence <precedence>[,<precedence-min> <precedence-max>] ZXR10(config-cmap)#match mpls-exp <mpls-exp-value >[,<mpls-exp-min> <mpls-exp -max>] ZXR10(config-cmap)#match in-vlan <invlan-value>[,<i nvlan-min> <invlan-max>] ZXR10(config-cmap)#match out-vlan <exvlan-value>[,<e xvlan-min> <exvlan-max>] ZXR10(config-cmap)#match in-8021p<in8021p-value >[,<in8021p-min> <in8021p-max>] ZXR10(config-cmap)#match out-8021p<ex8021p-value >[,<ex8021p-min> <ex8021p-max>] ZXR10(config-cmap)#match vrf-name<vrf-name> ZXR10(config-cmap)#match uni-cast ZXR10(config-cmap)#match multi-cast ZXR10(config-cmap)#match mac-address<mac-address> ZXR10(config-cmap)#match ipv4-access-list<acl4-name> Defines the data flow of a class-map according to an IP DSCP value, range: 0-63 Defines the data flow of a class-map according to an IP precedence, range: 0-7 Defines the data flow of a class-map according to the EXP field in MPLS label packets, range: 0-7 Defines the data flow of a class-map according to an inner VLAN-ID, range: Defines the data flow of a class-map according to an outer layer VLAN-ID, range: Defines the data flow of a class-map according to an inner 802.1p, range: 0-7 Defines the data flow of a class-map according to an outer 802.1p, range: 0-7 Defines the data flow of a class-map according to a VRF name. Defines the data flow of a class-map according to a unicast rule. Defines the data flow of a class-map according to a multicast rule. Defines the data flow of a class-map according to a MAC address. Defines the data flow of a class-map according to an IPv4 access list. 3-3

22 ZXR10 ZSR V2 Configuration Guide (QoS) Step Command Function ZXR10(config-cmap)#match ipv6-access-list <acl6-name> ZXR10(config-cmap)#match child Defines the data flow of a class-map according to an IPv6 access list. Configures a class-map for the data flow of which the matching item is null. Note: On "match all" mode, "Match dscp" collides with "match precedence". "Match child" collides with any other matching rule. "Match uni-cast" collides with "match multi-cast". Before the creation of a class-map, the matching mode must be specified. The relationship of several "match" entries in the same class-map is "match all". The relationship of the "match" values in the same "match" entry is "match any". 2. Verify the configurations. Command ZXR10#show class-map [<class-map-name>] Function Displays all class-maps and configuration of matching rules. End of Steps 3.3 Flow Classification Configuration Instances Configuring Null-Rule Flow Classification Configuration Description 1. In class-map configuration, the match child rule collides with any other matching rule. If the matching rule is match child, no other matching rule can be configured. If other matching rules are configured, the match child rule cannot be configured. 2. On the ZXR10 ZSR V2, a class-map is used in a policy-map (policy-map based on a flow class), that is, the object for which a policy takes effect is a flow of a specified class. The flow is defined by the class-map. Nested policy-maps can be used, so the class-maps defined by the match child rule have the following differences. If a class-map that classifies packets according to the match child rule is used in a single-hierarchy policy-map, the matching rule of the object (that is, a class-map) for which the policies in the policy-map take effect is null. All packets are classified into this class. 3-4

23 Chapter 3 Flow Classification Configuration If a class-map that classifies packets according to the match child rule is used in a policy-map in several nested policy-maps, and if the policy-map is not the home hierarchy, traffic that can enter this hierarchy can be classified into this class. The matching traffic at the subordinate hierarchies is not differentiated at the current hierarchy and the traffic is aggregated to a class-map at this hierarchy. Generally, the match child rule is not used on the home hierarchy in a multi-hierarchy policy-map. Configuration Flow 1. Create a class-map. Set the name to ipv4-all, set the matching mode to match all, and set the protocol stack to IPv4. 2. Configure a match rule for this class-map. Configure the match interface <interface _name> command as the classification rule (in the same class-map, the match child rule collides with any other matching rules). Configuration Commands The configuration of ZXR10 ZSR V2: ZXR10(config)#class-map ipv4-all match-all ipv4 ZXR10(config-cmap)#match child ZXR10(config-cmap)#exit Configuration Verification View all class-maps on the device as follows. ZXR10(config)#show class-map class-map ipv4-all match-all ipv4 match child ZXR10(config)# View a specified class-map (the class-map named ipv4-all) as follows. ZXR10(config)#show class-map ipv4-all class-map ipv4-all match-all ipv4 match child ZXR10(config)# Configuring EXP-Based Flow Classification Configuration Description 1. There are three methods to specify an MPLS-EXP value: specifying a single value, specifying multiple values, and specifying an MPLS-EXP value range. Any method can be used. 3-5

24 ZXR10 ZSR V2 Configuration Guide (QoS) 2. In a class-map, it is disallowed to configure multiple "match mpls-exp" rules. This is the same as most other matching rules. If multiple "match mpls-exp" rules are configured, an alarm is displayed. 3. The "match mpls-exp" rule collides with the "match child" rule. Configuration Flow 1. Create a class-map. Specify a name. Set the matching mode to "match all". Use the default protocol stack configuration, that is, supporting IPv4 and IPv6 at the same time. 2. Configure a "match" rule for this class-map. The classification rule is "mpls-exp". Configuration Commands Matching a single MPLS-EXP value: Set the name to exp, set the matching mode to "match all". Use the default protocol stack configuration, that is, supporting IPv4 and IPv6 at the same time. The classification rule is matching a single MPLS-EXP value. ZXR10(config)#class-map exp match-all ZXR10(config-cmap)#match mpls-exp 1 ZXR10(config-cmap)#exit Matching an MPLS-EXP value range: Set the name to exp1, set the matching mode to "match all". Use the default protocol stack configuration, that is, supporting IPv4 and IPv6 at the same time. The classification rule is matching an MPLS-EXP value range. It is only necessary to match a value in the value range. ZXR10(config)#class-map exp1 match-all ZXR10(config-cmap)#match mpls-exp 0-4 ZXR10(config-cmap)#exit Matching multiple MPLS-EXP values: In a "match mpls-exp" rule, several MPLS-EXP values can be configured. A value here can be a single value or a value range (consecutive single values will be automatically integrated into a value range). Set the name to exp2, set the matching mode to "match all". Use the default protocol stack configuration, that is, supporting IPv4 and IPv6 at the same time. The classification rule is matching four MPLS-EXP single values. ZXR10(config)#class-map exp2 match-all ZXR10(config-cmap)#match mpls-exp 0,2,4,7 ZXR10(config-cmap)#exit Set the name to exp3, set the matching mode to "match all". Use the default protocol stack configuration, that is, supporting IPv4 and IPv6 at the same time. The classification rule is matching the combination of three MPLS-EXP single values and an MPLS-EXP value range. ZXR10(config)#class-map exp3 match-all ZXR10(config-cmap)#match mpls-exp 0,2-5,7 ZXR10(config-cmap)#exit 3-6

25 Chapter 3 Flow Classification Configuration Configuration Verification View the configuration of matching a single MPLS-EXP value as follows. ZXR10(config)#show class-map class-map exp match-all match mpls-exp 1 View the configuration of matching an MPLS-EXP value range as follows. ZXR10(config)#show class-map exp1 class-map exp1 match-all match mpls-exp 0-4 /*If the MPLS-EXP value in a packet matches a value in the MPLS-EXP value range, the packet is classified into this class.*/ View the configuration of matching four MPLS-EXP single values as follows. ZXR10(config)#show class-map exp2 class-map exp2 match-all match mpls-exp 0,2,4,7 View the configuration of matching a combination of three MPLS-EXP single values and an MPLS-EXP value range as follows. ZXR10(config)#show class-map exp3 class-map exp3 match-all match mpls-exp 0,2-5, Configuring MAC Address-Based Flow Classification Configuration Description 1. In an L2VPN, you can configure MAC address-based flow classification. 2. Each L2VPN Ethernet private network packet contains a source MAC address and a destination MAC address. On the interfaces that send packets, flows can be classified based on the destination MAC addresses. On the interfaces that receive packets, flows can be classified based on the source MAC addresses. 3. In class-map configuration, when a rule is used to classify packets according to a MAC address, this MAC address is not specified to be a source MAC address or a destination MAC address. When the class-map is used by a policy-map, the direction (input or output) in which the policy-map is bound on an interface determines whether the source MAC address or the destination MAC address is matched. If the policy-map is bound in the input direction, the packets will be classified according to the source MAC address. If the policy-map is bound in the output direction, the packets will be classified according to the destination MAC address. 4. The match mac_address rule collides with the match child rule. 3-7

26 ZXR10 ZSR V2 Configuration Guide (QoS) Configuration Flow 1. Create a class-map named mac_address. Set the matching mode to match all. Use the default protocol stack configuration, that is, supporting IPv4 and IPv6 at the same time. 2. Configure a match rule for this class-map. The classification rule is matching a specified MAC address. Configuration Commands 1. Create a class-map named mac_address. PE1(config)#class-map mac_address match-all /*When the default protocol stack is used in a class-map, the class-map supports IPv4 and IPv6 at the same time.*/ 2. Configure a matching rule. PE1(config-cmap)#match mac-address /*The MAC address is in dotted hex notation.*/ PE1(config-cmap)#exit Configuration Verification View the configuration of MAC address-based flow classification as follows. PE1(config)#show class-map mac_address class-map mac_address match-all match mac-address Configuring IPv4 ACL-Based Flow Classification Configuration Description 1. If there are matching entities of the same type in a class-map, matching entities of the same type are not allowed to be configured any more, unless the previous matching entities are deleted. The match ipv4-access-list rule is an exception. In a class-map, at most 16 IPv4 ACLs can be configured. 2. If multiple match ipv4-access-list rules are configured in a class-map, the packets that match any of the ACLs can be classified into this class. 3. The match ipv4-access-list rule collides with the match child rule. Configuration Flow 1. Create a class-map. Set the name to v4_sip, set the matching mode to match all, and set the protocol stack to IPv4. 2. Configure a match rule for this class-map. The classification rule is matching the IPv4 access list named v4_sip. 3. Configure an IPv4 access list named v4_sip. In the IPv4 ACL, the packets with the source address are permitted. 3-8

27 Chapter 3 Flow Classification Configuration Configuration Commands Create a class-map named v4_sip and configure the matching rule. ZXR10(config)#class-map v4_sip match-all ipv4 ZXR10(config-cmap)#match ipv4-access-list v4_sip ZXR10(config-cmap)#exit ZXR10(config)# Create an IPv4 access list named v4_sip and specify the permitted packets. ZXR10(config)#ipv4-access-list v4_sip ZXR10(config-ipv4-acl)#rule permit ZXR10(config-ipv4-acl)#exit Configuration Verification 1. View the configuration of the IPv4 access list as follows. ZXR10(config)#show ipv4-access-lists name v4_sip ipv4-access-list v4_sip 1/1 (showed/total) 10 permit View the configuration of the class-map as follows. ZXR10(config)#show class-map v4_sip class-map v4_sip match-all ipv4 match ipv4-access-list v4_sip Classifying Flows in the Match-Any Mode Configuration Description 1. In class-map configuration, if the matching mode is match-any, the packets that match any matching rule in the class-map will be classified into this class. 2. In the match-any mode, the match child rule still collide with any other matching rule. 3. In a class-map whose matching mode is match-any, only one matching entity can be configured for each type (except for ACL). Configuration Flow 1. Create a class-map. Set the name to anyone, set the matching mode to match any. Set the class-map to take effect for IPv4 and IPv6 packets. Configure multiple matching rules in the class-map. The packets that match any rule will be classified into this class. 2. Configure another matching rule: matching the IPv4 ACL named v4_sip. In the IPv4 ACL, the packets with the source address are permitted. 3-9

28 ZXR10 ZSR V2 Configuration Guide (QoS) 3. Configure another matching rule: matching an MAC address. The MAC address is Configuration Commands The configuration of ZXR10 ZSR V2: ZXR10(config)#class-map anyone match-any ZXR10(config-cmap)#match ipv4-access-list v4_sip ZXR10(config-cmap)#match mac-address ZXR10(config-cmap)#exit The configuration of the IPv4 ACL named v4_sip is as follows. Create an IPv4 ACL named v4_sip and configure the permitted traffic. ZXR10(config)#ipv4-access-list v4_sip ZXR10(config-ipv4-acl)#rule permit ZXR10(config-ipv4-acl)#exit Configuration Verification View the configuration of the IPv4 ACL as follows. ZXR10(config)#show ipv4-access-lists name v4_sip ipv4-access-list v4_sip 1/1 (showed/total) 10 permit View the configuration of the class-map as follows. ZXR10(config)#show class-map anyone class-map anyone match-any match ipv4-access-list v4_sip match mac-address

29 Chapter 4 Flow Action Configuration Table of Contents Flow Action Overview Configuring Flow Actions Flow Action Configuration Instances Flow Action Overview Flow actions includes packet marking, traffic supervision and shaping, congestion avoidance, and congestion management. Packet Marking The packet marking tool is normally used to create the trust boundary relied by other QoS tools. Users can make different marks for different service classes in accordance with user policies. A mark of a packet can be the criteria for the next classification, and the mark also can be carried to other devices by the packet. In addition, the routers can re-mark packets in accordance with traffic policing result, such as packet degradation. Traffic Supervision and Traffic Sharing Traffic policies are helpful to accomplish QoS. Traffic supervision and traffic shaping can manage burst flows that enter a network. Traffic supervision CAR is used to limit the traffic of some type of packets. CAR uses the token bucket to control traffic. For the principle, see Figure 4-1Traffic Control Through CAR. 4-1

30 ZXR10 ZSR V2 Configuration Guide (QoS) Figure 4-1 Traffic Control Through CAR A device classifies packets in accordance with the predefined matching rules. For the packets with defined traffic characteristics, the device will send them directly without the processing of the token bucket. For the packets with no defined traffic characteristics, they will be sent to the token bucket for processing. If there are enough tokens to send the packets, the packets are allowed to pass and then be sent. If there are not enough tokens in the token bucket to send the packets, the packets will be dropped. In this way, packet traffic of a specific class can be controlled. Tokens can be put into the bucket in accordance with the rate set by users. Users also can set the capacity of the token bucket. When the amount of tokens is equal to the capacity, the amount will not increase. When a packet is handled by the token bucket, if there are enough tokens in the bucket, the packet will be allowed to pass and the amount of tokens in the bucket will reduce in accordance with the length of the packets. When there are not enough tokens, the packet will be dropped. When the bucket is full of tokens, all the packets represented by tokens can be transmitted. This allows the burst transmission of data. When there is no token in the bucket, packets will not be sent until enough new tokens are generated in the bucket. Therefore, the rate of packet traffic should not be larger than the rate to generate tokens, which achieves traffic limit. Traffic shaping The typical function of traffic shaping is to limit the traffic and burst that leave a connection in a network, so that the packets of this type can be sent out at an even speed. In general, traffic shaping uses a buffer and a token bucket to accomplish its function. When the packets are sent quickly, they are stored in the buffer, and then the buffered packets are sent at an even speed under the control of the token bucket. 4-2

31 Chapter 4 Flow Action Configuration The technology used by traffic shaping is called Generic Traffic Shaping (GTS). GTS can shape the traffic that is fitful or the traffic that does not meet the predefined traffic characteristics. It is helpful to match the bandwidths between upstream and downstream in the network. The same as CAR, GTS also uses the token bucket to control traffic. When CAR is used to control the traffic, it drops the packets that do not meet the predefined traffic characteristics. However, GTS buffers the packets that do not meet the predefined traffic characteristics, so the number of dropped packets is reduced. At the same time, the flow characteristics are met. This is the main difference between CAR and GTS. For the GTS principle, see Figure 4-2GTS Principle. The queue used to buffer the packets is called a GTS queue. Figure 4-2 GTS Principle GTS can shape specified packet traffic or all packet traffic on a specified interface. When packets arrive, the packets are classified first. If the packets do not need GTS processing, they are sent without being processed by the token bucket. If the packets need GTS processing, they are compared with the tokens in the bucket, and the tokens are put into the bucket in accordance with the rate defined by users. When there are enough tokens in the bucket, the packets are sent, and the number of the tokens in the bucket decreases in accordance with the length of the packets. When there are less tokens in the token bucket, the packets are buffered in the GTS queue. When there are packets in the GTS queue, GTS takes out the packets from the queue to send the packets at a specific interval. Before sending the packets, GTS compares the number of the packets with the number of the tokens in the bucket. GTS stops sending packets if there are not enough tokens or all packets are sent out. For example, Router A is connected to Router B. To reduce packet loss, packets can be handled by GTS on the egress of Router A. The packets that do not meet the GTS traffic characteristics are stored in the buffer of Router A. When Router A sends the next batch of packets, GTS takes out the packets from the buffer queue and sends the packets. In this way, the packets sent to Router B meet the traffic characteristics on Router B, and packet loss on Router B is reduced. If the packets are not processed by GTS on the egress of Router A, all packets that do not meet the traffic characteristics on Router B will be dropped by Router B. 4-3

32 ZXR10 ZSR V2 Configuration Guide (QoS) Congestion Management Congestion management is used to manage and control packet flows to meet the QoS requirements of services when congestion occurs. When there is no congestion on a network interface, data packets will be sent out immediately after the data packets arrive at the interface. When the speed of the data packets arriving at the interface is greater than the speed to handle the packets on the interface, the interface will be congested. For congestion management on an interface, it is necessary to classify the packets into different classes in accordance with the principle (such as the priority of the packets) and put the packets to different queues. Queue scheduling treats packets of different priorities with differences. Congestion management can be accomplished by using a queuing technology. The queuing technology consists of creating queues, classifying packets, and putting packets to different queues, and scheduling queues. Different queue algorithms can be used in different situations to make different congestion management effects. At present, the widely used queuing technologies include FIFO, PQ, WFQ, and CBWFQ. FIFO FIFO does not classify packets. Packets enter the queue in accordance with the arrival sequence. At the same time, packets are sent in accordance with the sequence in which the packets enter the queue, that is, the packets entering the queue first will be sent first, and the packets entering the queue later will be sent later. For the principle, see Figure 4-3FIFO Principle. Figure 4-3 FIFO Principle PQ PQ classifies packets first and then put the packets to the corresponding queues in accordance with the classes. When packets leave the queues, packets in the queue with high priority leave first. The packets in the medium priority queue leave the queue after all the packets in the high priority queue are sent. As the same, the packets in the normal priority queue leave the queue after all the packets in the medium priority 4-4

33 Chapter 4 Flow Action Configuration queue are sent. At last, the packets in the lower priority queue leave the queue after all the packets in the normal priority queue are sent. The packets in the higher priority queues are sent with preference to other packets. When congestion occurs on the network, the packets with lower priorities will be delayed by the packets with higher priorities. As a result, the packets for important services will always be processed first, and packets for unimportant services will be processed when the network is idle. In this way, the important services are handled timely and network resources are used fully. PQ always ensures that the packets with higher priority are sent in preference to other packets with lower priorities. When there is too much higher priority traffic, the traffic with lower priority may have no opportunity to be sent. It is necessary to plan the traffic of different priorities when PQ is used. The traffic with higher priority should be limited properly, so that the traffic with lower priority also has the opportunity to be sent. The PQ on the ZXR10 devices supports 4 priority queues. The priorities of the queues are in decreasing order. For the PQ principle, see Figure 4-4PQ Principle. Figure 4-4 PQ Principle WFQ WFQ classifies packets in accordance with flows, so it is also called flow-based WFQ. The packets with the same source IP address, destination IP address, source port number, and destination port number belong to a flow (sometimes, ToS/DSCP is also used as the criterion to classify flows). Each flow corresponds to a queue. When packets leave queues, WFQ schedules the queues in accordance with specified weights. The weights are defined through a certain algorithm. In this way, packets with different priorities are treated differently on the basis of fairness. For the WFQ principle, see Figure 4-5WFQ Principle. 4-5

34 ZXR10 ZSR V2 Configuration Guide (QoS) Figure 4-5 WFQ Principle CBWFQ CBWFQ classifies packets in accordance with the network device port, packet protocol, and ACL rule. Each class of traffic corresponds to a queue. Multiple classes are supported. Different classes of packets are put into different queues. The packets that do not match any class are put into the default queue. The queues use the Weighted Round Robin (WRR) algorithm when round-robin classification technique is used. Users can customize some transport characteristic for each traffic class, such as bandwidth, transport weight, and transport limit. The bandwidth specified for a queue is the bandwidth that is ensured for the queue when bandwidth congestion occurs. The scheduler ensures that each queue can obtain some bandwidths in accordance with the weights defined for each traffic class. Users can configure the limit of the length for the queue of each traffic class. The limit of the length is the maximum number of packets that can be put in a queue. If the length of a queue reaches the limit, the packet dropping policy takes effect. CBWFQ can be combined with dropping mechanisms (such as tail drop and WRED). In this way, when there is no congestion on an interface, packets of different traffic classes can obtain certain bandwidths. When congestion occurs on the interface, the bandwidths of the packets in the queue with higher priority will not exceed the defined value, which ensures that other packets can obtain corresponding bandwidths. CBWFQ provides certainty or rigid guarantee for the bandwidths that is allocated to each traffic class. High-speed links or backbone networks focus on the strict guarantee of bandwidth allocation. CBWFQ is a strong QoS tool. For the CBWFQ principle, see Figure 4-6CBWFQ Principle. 4-6

35 Chapter 4 Flow Action Configuration Figure 4-6 CBWFQ Principle Congestion Avoidance Network congestion will reduce the network performance, and bandwidth cannot be fully used. To avoid congestion, queues can prevent any possible congestion by dropping packets. The dropping policies include tail drop, RED, and WRED. 1. Tail drop Tail drop is used to drop packets that enter the queue later when the queue buffer is full. Tail drop may cause TCP global synchronization. Packet dropping consists of triggering Transfer Control Protocol (TCP) slow-start and the congestion avoidance mechanism to reduce TCP transmission rate by dropping packets on the base of the applicability characteristic of TCP communication. However, when a queue drops several TCP connection packets at the same time, the number of the packets sent to the queue by these TCP connections will decrease. So packets sent to the queue are less than that the packets sent by the connections, which reduces the bandwidth usage on the connections. When the connections start to send packets again, congestion will occur again. This causes wave-type network congestion on the network, that is, TCP global synchronization, see Figure 4-7Tail Drop. 4-7

36 ZXR10 ZSR V2 Configuration Guide (QoS) Figure 4-7 Tail Drop 2. RED RED solves the TCP global synchronization problem caused by simple dropping. The RED algorithm executes early dropping for specified packets (and specified connection) by monitoring the length of the queue buffer. Few TCP senders will withdraw and retransmit the packets. For the RED dropping policy, see Figure 4-8RED Dropping Policy. Figure 4-8 RED Dropping Policy RED sets the minimum threshold and the maximum threshold of the queue length in the output buffer. The device monitors the thresholds when making packet sending policies later. During the packet switching policy procedure, the average queue length is checked. If the average queue length is less than the minimum threshold, the packets enter the queue and they are switched later. If the average queue length is between the minimum threshold and the maximum threshold, the packets will be dropped in accordance with certain probability. 4-8

37 Chapter 4 Flow Action Configuration If the average queue length is greater than the maximum threshold, all packets will be dropped. 3. WRED WRED combines DSCP or precedence in IP headers with RED to provide the dropping thresholds for communication flows with higher priority. There are differentials between the dropping thresholds for a communication flow with higher priority and those of a standard communication flow with lower priority. That is to say, WRED drops packets in accordance with the DSCP field or precedence field in IP headers selectively. For different dropping thresholds accomplished by a WRED policy, see Figure 4-9WRED Principle. Figure 4-9 WRED Principle WRED monitors the average queue length in a network device, so it can determine when to start to drop packets in accordance with the queue length. The average queue length is the result of the queue length after low-pass filter. The average queue length reflects the change trend of queue changes, and it is not sensitive to the change burst of the queue length. This avoids unfair treatment to burst data flows. When the average queue length is greater than the defined minimum threshold, WRED starts to drop data packets (including TCP and UDP) in accordance with a certain probability. When the average queue length is greater than the defined maximum threshold, WRED uses the tail drop rule, that is, all packets arriving later will be dropped first. WRED intends to keep the queue length between the minimum threshold and the maximum threshold. 4-9

38 ZXR10 ZSR V2 Configuration Guide (QoS) 4.2 Configuring Flow Actions This procedure describes how to configure flow actions on packets in the network, so that different QoS abilities can be provided based on the requirements of applications. Steps 1. Configure flow actions. Step Command Function 1 ZXR10(config)#policy-map <policy-map-name> Creates a policy-map and enters policy mapping configuration mode. 2 ZXR10(config-pmap)#class <class-map-name> Associates a class with a class-map and enters policy class configuration mode. 3 ZXR10(config-pmap-c)#bandwidth percent <percentage> ZXR10(config-pmap-c)#priority-level <pq-level> ZXR10(config-pmap-c)#priority-llq ZXR10(config-pmap-c)#police cir <cir-value> cbs <cbs-value>[pir <pir-value> pbs <pbs-value>] conform-action <action> exceed-action <action> violate-action <action> ZXR10(config-pmap-c)#set dscp {<dscp-value> inherit-from {dscp precedence 8021p mpls-exp}} Configures the minimum available bandwidth of the policy class, range: Configures the PQ priority of the policy class, range: 1-4. Configures the Low Latency Queuing (LLQ) priority of the policy class. Configures the traffic supervision of the policy class. <cir>, CIR value, in the range of , in the unit of kbit/s. <cbs>, CBS value, in the range of , in the unit of kbytes. <pir>, PIR value, in the range of , in the unit of kbit/s. <pbs>, PBS value, in the range of , in the unit of kbytes. Configures the policy class to use a designated value to mark the DSCP field of packets. 4-10

39 Chapter 4 Flow Action Configuration Step Command Function ZXR10(config-pmap-c)#set precedence {<ipp-value> inherit-from { dscp precedence 8021p mpls-exp}} ZXR10(config-pmap-c)#set 8021p {<8021p-value> inherit-from {dscp precedence 8021p mpls-exp}} ZXR10(config-pmap-c)#set mpls-exp {<exp-value> inherit-from {dscp precedence 8021p mpls-exp}} ZXR10(config-pmap-c)#random-detect enable ZXR10(config-pmap-c)#random-detect weight <weight-len> ZXR10(config-pmap-c)#random-detect precedence <pre cedence><min-threshold><max-threshold><probability> ZXR10(config-pmap-c)#service-policy <policy-map-na me> 4 ZXR10(config)#service-policy <interface-name>{input output}<policy-map-name> Configures the policy class to use a designated value to mark the IP precedence field of packets. Configures the policy class to use an inheritance value to mark the 802.1p field of packets. Configures the policy class to use a designated value to mark the MPLS-EXP field of packets. Enables WRED of a policy. Configures the WRED weight for a policy class to calculate the average queue length. Configures the IP precedence-based WRED parameters. <min-threshold>, the WRED minimum threshold, in the rage of , in the unit of kilo bytes. <max-threshold>, the WRED maximum threshold, in the rage of , in the unit of kilo bytes. <probability>, WRED dropping probability, in the rage of Configures a hierarchical policy of the policy class. Binds the policy-map to an interface. 4-11

40 ZXR10 ZSR V2 Configuration Guide (QoS) Note: Set dscp collides with set precedence. The bandwidth action and priority-level action are mutually exclusive in the same policy-map, except for the default queue. Four priorities (not including the default priority) can be designated in the configuration of priority scheduling. Packets that do not match the QoS policy on an interface will go to the default queue. In configuration of bandwidth scheduling, users can designate a class explicitly and configure the weight. When users do not configure the class explicitly, the packets that do not match the QoS policy on the interface will go to the default queue. 2. Verify the configurations. Command ZXR10#show class-map [<class-map-name>] ZXR10#show policy-map [<policy-map-name>[class <class-name>]] ZXR10#show service-policy [<interface-name>] Function Displays all class-maps and configuration of matching rules. Displays all policy-maps and configuration of policy classes. Displays all policy bindings on interfaces. End of Steps 4.3 Flow Action Configuration Instances Configuring Packet Marking Configuration Description 1. The marking function is supported in the following fields in packets p: marking the 802.1p field in the Layer 2 header of packets Precedence/dscp: marking the precedence field (0 7)/DSCP field (0 63) in Layer 3 header of packets MPLS-EXP: marking the MPLS-EXP field of labeled packets 2. The set dscp action collides with the set precedence action. Other actions can be configured at the same time. 3. In a policy-map, if several actions are configured, the set mpls-exp action takes effect for the matching labeled flows, the set precedence action or the set dscp action takes effect for all matching flows, and the set 802.1p action takes effect for the matching with VLAN header flows. 4-12

41 Chapter 4 Flow Action Configuration 4. This instance shows how to configure the set 8021p, set mpls-exp and set precedence actions. Configuration Flow 1. Create a policy-map named mark. 2. Specify a class-map for this policy-map (to ensure that this class-map be able to match both labeled packets and ordinary packets, choose a class-map whose matching rule is match mac-address / match child ). Configure the set mpls-exp and set precedence actions in policy-map configuration mode. Configuration Commands 1. Configure a class-map whose matching rule is match child. ZXR10(config)#class-map child match-all ZXR10(config-cmp)#match child ZXR10(config-cmap)#exit 2. Configure flow action. ZXR10(config)#policy-map mark ZXR10(config-pmap)#class child ZXR10(config-pmap-c)#set 8021p 5 ZXR10(config-pmap-c)#set mpls-exp 7 ZXR10(config-pmap-c)#set precedence 2 ZXR10(config-pmap-c)#set dscp 0 %Error 5553: The set dscp is incompatible with the set precedence in the same policy class, please check! ZXR10(config-pmap-c)#exit Configuration Verification View the packet marking configuration as follows. ZXR10(config)#show policy-map mark policy-map mark class child set 8021p 5 set mpls-exp 7 set precedence Configuring Traffic Supervision Configuration Description 1. Traffic supervision (police) supports two rates, CIR and PIR, and their burst sizes, that is, CBS and PBS. 4-13

42 ZXR10 ZSR V2 Configuration Guide (QoS) 2. PIR and CIR are measured by the bytes of IP packets in every second. The unit is Kilo bits per second. The value of PIR must be greater than or equal to the value of CIR. 3. PBS and CBS mean that when the transient traffic does not reach the specified rates, the rest can be used for handle other traffic received before or after this moment. 4. PBS and CBS are measured by the number of bytes contained in IP packets. The unit is Kilo bytes. The values must be more than 0 and must be greater than or equal to the maximum bytes of IP packets that may pass. Configuration Flow 1. Create a policy-map named police. 2. Specify a class-map for this policy-map. Configure police rate limit in policy-map configuration mode. Configuration Commands The configuration on ZXR10 ZSR V2: ZXR10(config)#policy-map police ZXR10(config-pmap)#class exp3 ZXR10(config-pmap-c)#police cir cbs 10 pir pbs 10 conform-action transmit exceed-action transmit violate-action drop /*Police the traffic matching class exp3. The CIR is Kb (100 M). the PIR is Kb (120 M). The CBS and PBS are 10Kbytes.*/ ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#exit Configuration Verification View the traffic supervision configuration as follows. ZXR10(config)#show policy-map police policy-map police class exp3 police cir cbs 10 pir pbs 10 conform-action transmit exceed-action transmit violate-action drop Configuring PQ Configuration Description 1. There are several types of queue scheduling, including FIFO, PQ, WFQ and CBWFQ. The scheduling technologies are to accomplish congestion management. When the traffic does not exceed the bandwidths, queue scheduling does not affect the traffic. 2. Among the queue scheduling supported by ZXR10 ZSR V2, except the default FIFO queue, other queues perform scheduling on the basis of packet classification. In 4-14

43 Chapter 4 Flow Action Configuration policy-map configuration, a priority can be specified for the current type of traffic after the class-map is configured. 3. In PQ, there are four priorities. Each type of packet corresponds to a priority. Packets in the highest priority queue are always sent first. When all the packets in the highest priority queue are sent, the packets in the next priority queue are sent. 4. PQ always ensures that the packets with the high priorities are sent with precedence, so the packets with low priorities may have no change to be sent when there are too many packets with high priorities. Therefore, it is necessary to plan the traffic with different priorities reasonably when PQ is used. The traffic with high priorities should be limited properly so that the traffic with low priorities also have the change to be sent. 5. PQ configuration collides with bandwidth percent configuration. That is to say, in a policy-map, between PQ and bandwidth percent, only one can be used. Configuration Flow 1. This instance shows how to configure PQ. 2. According to the configuration description, configure different rate limits for the packets of different priorities. This ensures that the packets with high priorities can be sent with precedence, and also ensures that the packets with low priorities have the change to be sent. 3. This configuration instance is applicable to an MPLS forwarding situation. By classifying packets and configuring priorities according to the MPLS-EXP field values, the following effects can be achieved. The priority of the packets whose MPLS-EXP field value is 1 is the first highest. The rate limit is 100 M. The priority of the packets whose MPLS-EXP field value is 2 is the second highest. The rate limit is 50 M. The priority of the packets whose MPLS-EXP field value is 3 is the lowest. The rate limit is 30 M. Other packets are not affected and they are forwarded properly. Configuration Commands 1. Configure a class-map that will be used in the policy-map. ZXR10(config)#class-map exp1 match-all ZXR10(config-cmap)#match mpls-exp 1 ZXR10(config-cmap)#exit ZXR10(config)#class-map exp2 match-all ZXR10(config-cmap)#match mpls-exp 2 ZXR10(config-cmap)#exit ZXR10(config)#class-map exp3 match-all ZXR10(config-cmap)#match mpls-exp 3 ZXR10(config-cmap)#exit 2. Configure a policy-map. Set the name to pq. Use the class-map configured in Step 1 in this policy-map, and then configure the PQ police. ZXR10(config)#policy-map pq 4-15

44 ZXR10 ZSR V2 Configuration Guide (QoS) ZXR10(config-pmap)#class exp1 ZXR10(config-pmap-c)#priority-level 1 ZXR10(config-pmap-c)#police cir cbs 100 conform-action transmit exceed-action drop violate-action drop ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#class exp2 ZXR10(config-pmap-c)#priority-level 2 ZXR10(config-pmap-c)#police cir cbs 50 conform-action transmit exceed-action drop violate-action drop ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#class exp3 ZXR10(config-pmap-c)#priority-level 3 ZXR10(config-pmap-c)#police cir cbs 30 conform-action transmit exceed-action drop violate-action drop ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#exit Configuration Verification View the PQ configuration as follows. ZXR10(config)#show class-map class-map exp1 match-all match mpls-exp 1 class-map exp2 match-all match mpls-exp 2 class-map exp3 match-all match mpls-exp 3 ZXR10(config)#show policy-map pq policy-map pq class exp1 police cir cbs 100 conform-action transmit exceed-action drop violate-action drop priority-level 1 class exp2 police cir cbs 50 conform-action transmit exceed-action drop violate-action drop priority-level 2 class exp3 police cir cbs 30 conform-action transmit exceed-action drop violate-action drop priority-level

45 Chapter 4 Flow Action Configuration Configuring WFQ Configuration Description 1. WFQ is on the basis of flow classification. Each flow class corresponds to a WFQ queue. The WFQ queues are fair and there is no precedence. When the packets leave the queues, specific weights are used for scheduling. The queue weights are accomplished through a certain algorithm. In this way, on a fair base, services with different priorities are treated with differences. 2. For the all policy classes in a policy-map, the sum of the configured bandwidth percents must not be greater than Bandwidth percent configuration collides with PQ configuration. That is to say, in a policy-map, between PQ and bandwidth percent, only one can be used. 4. After WFQ is configured, interface traffic is forwarded properly if there is no congestion. When congestion occurs, bandwidths are allocated according to the configured weights. Configuration Flow 1. Classify packets into four classes according to the IP precedence field values in packets. 2. Configure a policy-map named WFQ. For the packets whose IP precedence is 1, set the bandwidth percent to 30. For the packets whose IP precedence is 2, set the bandwidth percent to 30. For the packets whose IP precedence is 3, set the bandwidth percent to 20. For the packets whose IP precedence is 4, set the bandwidth percent to 20. Configuration Commands 1. Configure class-maps. ZXR10(config)#class-map pre1 match-all ZXR10(config-cmap)#match precedence 1 ZXR10(config-cmap)#exit ZXR10(config)#class-map pre2 match-all ZXR10(config-cmap)#match precedence 2 ZXR10(config-cmap)#exit ZXR10(config)#class-map pre3 match-all ZXR10(config-cmap)#match precedence 3 ZXR10(config-cmap)#exit ZXR10(config)#class-map pre4 match-all ZXR10(config-cmap)#match precedence 4 ZXR10(config-cmap)#exit 2. Configure a policy-map and set the name to WFQ. ZXR10(config)#policy-map WFQ ZXR10(config-pmap)#class pre1 ZXR10(config-pmap-c)#bandwidth percent

46 ZXR10 ZSR V2 Configuration Guide (QoS) ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#class pre2 ZXR10(config-pmap-c)#bandwidth percent 30 ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#class pre3 ZXR10(config-pmap-c)#bandwidth percent 20 ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#class pre4 ZXR10(config-pmap-c)#bandwidth percent 20 ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#exit Configuration Verification View the configuration of the class-maps by using the show class-map command as follows. ZXR10(config)#show class-map class-map pre1 match-all match precedence 1 class-map pre2 match-all match precedence 2 class-map pre3 match-all match precedence 3 class-map pre4 match-all match precedence 4 View the configuration of the policy-map by using the show policy-map command as follows. ZXR10(config)#show policy-map WFQ policy-map WFQ class pre1 bandwidth percent 30 class pre2 bandwidth percent 30 class pre3 bandwidth percent 20 class pre4 bandwidth percent Configuring CBWFQ Configuration Description 1. CBWFQ is a queue scheduling technology on the basis of flow classification. Each flow class corresponds to a queue. Generally, it is only necessary to set one queue to the LLQ queue and set others to the WFQ queues. 4-18

47 Chapter 4 Flow Action Configuration 2. In CBWFQ, the bandwidth allocated to the LLQ queue is the committed bandwidth of this queue when bandwidth congestion occurs. The left bandwidths are allocated to each WFQ queue by the scheduler according to the weights. 3. In this way, when there is no congestion on a port, traffic can be forwarded properly. When congestion occurs on a port, the packets in the LLQ will not take up extra bandwidth, thus ensuring the bandwidths used by other packets. Configuration Flow 1. Assume that there are four users. The IP precedence of the users are different. They are 1, 2,3 and 4 respectively. Four class-maps can be configured according to these features. 2. Configure a policy-map named CBWFQ. User1 is an LLQ queue, and the rate limit is 500 M. User2 is a WFQ queue, and the bandwidth percents are 30. User3 is a WFQ queue, and the bandwidth percents are 20. User4 is a WFQ queue, and the bandwidth percents are 10. Configuration Commands 1. Configure class-maps. ZXR10(config)#class-map pre1 match-all ZXR10(config-cmap)#match precedence 1 ZXR10(config-cmap)#exit ZXR10(config)#class-map pre2 match-all ZXR10(config-cmap)#match precedence 2 ZXR10(config-cmap)#exit ZXR10(config)#class-map pre3 match-all ZXR10(config-cmap)#match precedence 3 ZXR10(config-cmap)#exit ZXR10(config)#class-map pre4 match-all ZXR10(config-cmap)#match precedence 4 ZXR10(config-cmap)#exit 2. Configure a policy-map named CBWFQ. Configure CBWFQ scheduling for the traffic of different classes. ZXR10(config)#policy-map CBWFQ ZXR10(config-pmap)#class pre1 ZXR10(config-pmap-c)#priority-llq ZXR10(config-pmap-c)#police cir cbs 500 conform-action transmit exceed-action drop violate-action drop ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#class pre2 ZXR10(config-pmap-c)#bandwidth percent 30 ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#class pre3 ZXR10(config-pmap-c)#bandwidth percent

48 ZXR10 ZSR V2 Configuration Guide (QoS) ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#class pre4 ZXR10(config-pmap-c)#bandwidth percent 10 ZXR10(config-pmap)#exit Configuration Verification View the class-map configuration by using the show class-map command as follows. ZXR10(config)#show class-map class-map pre1 match-all match precedence 1 class-map pre2 match-all match precedence 2 class-map pre3 match-all match precedence 3 class-map pre4 match-all match precedence 4 View the policy-map configuration by using the show policy-map command as follows. ZXR10(config)#show policy-map CBWFQ policy-map CBWFQ class pre1 priority-llq police cir cbs 500 conform-action transmit exceed-action drop violate-action drop class pre2 bandwidth percent 30 class pre3 bandwidth percent 20 class pre4 bandwidth percent Configuring WRED Configuration Description 1. WRED is used for dropping congested traffic randomly (congestion avoidance). 2. WRED monitors the average length of a queue on a device, so it can determine when to drop the packets according to the average length of the queue. 3. A high threshold and a low threshold are configured in WRED configuration. When the average queue length is greater than the defined minimum threshold, WRED starts to drop data packets according to a certain probability. When the average queue length is greater than the defined maximum threshold, WRED becomes tail drop, that is, all packets arriving later will be dropped. 4-20

49 Chapter 4 Flow Action Configuration 4. WRED intends to keep the queue length between the minimum threshold and the maximum threshold. Configuration Flow 1. Generally, WRED is used together with police rate limit and queue scheduling. 2. Create a policy-map named WRED. Call a class-map whose matching rule is match child. 3. Configure PQ queue and WRED in the policy-map. For the queue whose priority is 0, set the lower drop threshold to 30 KB, set the higher drop threshold to 100 KB, set the drop probability to 90%, and set the index of the average queue length to 8. For the queue whose priority is 1, set the lower drop threshold to 120 KB, set the higher drop threshold to 200 KB, set the drop probability to 80%, and set the index of the average queue length to 8. For the queue whose priority is 2, set the lower drop threshold to 220 KB, set the higher drop threshold to 300 KB, set the drop probability to 70%, and set the index of the average queue length to 8. Configuration Commands 1. Create a class-map. ZXR10(config)#class-map child match-all ZXR10(config-cmap)#match child ZXR10(config-cmap)#exit 2. Create a policy-map. Set the name to WRED. Configure PQ queue and WRED. ZXR10(config)#policy-map WRED ZXR10(config-pmap)#class child ZXR10(config-pmap-c)#random-detect enable ZXR10(config-pmap-c)#random-detect weight 8 ZXR10(config-pmap-c)#random-detect precedence ZXR10(config-pmap-c)#random-detect precedence ZXR10(config-pmap-c)#random-detect precedence ZXR10(config-pmap-c)#priority-level 1 ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#exit Configuration Verification View the configuration of the class-map as follows. ZXR10(config)#show class-map child class-map child match-all match child View the configuration of the policy-map as follows. ZXR10(config)#show policy-map WRED policy-map WRED 4-21

50 ZXR10 ZSR V2 Configuration Guide (QoS) class child random-detect enable random-detect weight 8 random-detect precedence random-detect precedence random-detect precedence priority-level 1 ZXR10(config)# 4-22

51 Chapter 5 H-QoS Configuration Table of Contents H-QoS Overview Configuring H-QoS H-QoS Configuration Instance H-QoS Overview Through the hierarchy-qos (H-QoS), users can set the hierarchical relationships of schedulers based on actual needs. Multi-layer logical schedulers are deployed, and the upper-layer scheduler controls the total bandwidth of lower-layer schedulers and decides the Committed Information Rate (CIR) and Peak Information Rate (PIR) of lower-layer schedulers in accordance with the layers and weights of the lower-layer schedulers. H-QoS controls the bandwidth flexibly through multi-layer schedulers. Specifically, it controls the total bandwidth of multiple queues that may result from one or more user services, and implements the total quality control of one or more services. For example, an operator allocate a bandwidth of 400 Kbps to a user, which is occupied by audio streams and data streams. Based on the user requirement, the data stream at least occupies 250 Kbps and the audio stream at least occupies 150 Kbps. If the bandwidth that the audio stream occupies does not reach 150 Kbps, the data stream can occupy a bandwidth of more than 250 Kbps. If the bandwidth that the data stream occupies does not reach Kbps, the audio stream can occupy a bandwidth of more than Kbps. For the introduction and principle of H-QoS, refer to Chapter 1 QoS Overview. 5.2 Configuring H-QoS This procedure describes how to configure H-QoS on the ZXR10 ZSR V2 to achieve the hierarchical traffic scheduling. Steps 1. Configure H-QoS. Command ZXR10(config)#service-policy <interface-name>{input output}<policy-map-name> Function Binds a policy to an interface. 2. Verify the configurations. 5-1

52 ZXR10 ZSR V2 Configuration Guide (QoS) Command ZXR10#show class-map [<class-map-name>] ZXR10#show policy-map [<policy-map-name>[class [class-name]]] ZXR10#show service-policy [ interface-name] ZXR10#show running-config hqos Function Displays all class-maps and configuration of matching rules. Displays all policy-maps and configuration of policy classes. Displays all policy bindings on interfaces. Displays the information of H-QoS. End of Steps 5.3 H-QoS Configuration Instance Configuration Description The gei-1/1 interface allows voice and data traffic, see Figure 5-1H-QoS Configuration Instance. The configuration requirements are as follows: The total CIR of the voice and data traffic is 400k. The CIR of voice is 150 k. The rate can be greater than 150 k. The CIR of data is 250 k. The rate can be greater than 250 k. Figure 5-1 H-QoS Configuration Instance Configuration Flow 1. Configure the H-QoS for the downlink of the gei-1/2 interface to ensure the CIR of each type of traffic. 2. Configure a class for these two types of traffic separately to classify them. The precedence of these two types of traffic is 1 and Configure a further policy to limit the rate. The total CIR is 400k. 4. For the second policy, the CIR of the voice traffic is 150k and the PIR of the voice traffic is 400k, while the CIR of the data traffic is 250k and the PIR of the data traffic is 400k. Configuration Commands 1. Run the following commands to configure interfaces: ZXR10(config)#interface gei-1/1 ZXR10(config-if-gei-1/1)#ip address

53 Chapter 5 H-QoS Configuration ZXR10(config-if-gei-1/1)#exit ZXR10(config)#interface gei-1/2 ZXR10(config-if-gei-1/2)#ip address ZXR10(config-if-gei-1/2)#exit 2. Run the following commands to configure class-maps: ZXR10(config)#class-map hqos match-all ZXR10(config-cmp)#match child ZXR10(config-cmp)#exit ZXR10(config)#class-map voice match-all ZXR10(config-cmp)#match precedence 1 ZXR10(config-cmp)#exit ZXR10(config)#class-map data match-all ZXR10(config-cmp)#match precedence 2 ZXR10(config-cmp)#exit 3. Run the following commands to configure a Level-2 policy-map: ZXR10(config)#policy-map car1 ZXR10(config-pmap)#class voice ZXR10(config-pmap-c)#police cir 150 cbs 15 pir 400 pbs 40 conform-action transmit exceed-action transmit violate-action drop ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#class data ZXR10(config-pmap-c)#police cir 250 cbs 25 pir 400 pbs 40 conform-action transmit exceed-action transmit violate-action drop ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#exit 4. Run the following commands to configure a Level-1 policy-map: ZXR10(config)#policy-map test ZXR10(config-pmap)#class hqos ZXR10(config-pmap-c)#police cir 400 cbs 40 conform-action transmit exceed-action drop violate-action drop ZXR10(config-pmap-c)#service-policy car1 ZXR10(config-pmap-c)#exit ZXR10(config-pmap)#exit 5. Run the following commands to bind the policy to the corresponding interface: ZXR10(config)#service-policy gei-1/2 output test Configuration Verification Run the show class-map command to check whether the class-map configuration is correct as follows. ZXR10(config)#show class-map class-map hqos match-all match child class-map voice match-all match precedence 1 5-3

54 ZXR10 ZSR V2 Configuration Guide (QoS) class-map data match-all match precedence 2 Run the show policy-map command to check whether the policy configuration is correct as follows. ZXR10(config)#show policy-map policy-map car1 class voice police cir 150 cbs 15 pir 400 pbs 40 conform-action transmit exceed-action transmit violate-action drop class data police cir 250 cbs 25 pir 400 pbs 40 conform-action transmit exceed-action transmit violate-action drop policy-map test class hqos police cir 400 cbs 40 conform-action transmit exceed-action drop violate-action drop service-policy car1 Run the show service-policy command to check whether interface binding is correct as follows. ZXR10#show service-policy service-policy gei-1/2 output test 5-4

55 Chapter 6 Priority Inheritance Configuration Table of Contents Priority Inheritance Overview Configuring Priority Inheritance Priority Inheritance Configuration Instances Priority Inheritance Overview Priority inheritance is an important function of QoS. It is used to accomplish priority inheritance among different types of packets (including common IP packets, Virtual Local Area Network (VLAN) packets and MPLS packets), that is, the conversion among IP-Precedence, VLAN-802.1p, and MPLS-EXP. There are two types of priority inheritances: Inheritance of priority field from Layer 2 to Layer 3 It is the mapping of priority field from Layer 2 to Layer 3, realizing mapping from 802.1p field to IPP field and MPLS-EXP field. Mapping from MPLS-EXP field to IP-Precedence field This mapping conforms to the RFC standard. There are three modes: Uniform mode: On the access ingress of a Provider Edge (PE) device, IPP, and Time To Live (TTL) are inherited to the EXP and TTL fields of a label. On the access egress of a PE device, the EXP and TTL fields of a label are inherited to IPP and TTL of an IP packet. Pipe mode: On the access ingress of a PE device, IPP and TTL are not inherited to the EXP and TTL fields of a label. On the access egress of a PE device, EXP field and TTL field of a label are not inherited to IPP and TTL of an IP packet. Therefore, a packet has two inconsistent priorities. The device has to designate a priority to be trusted during the QoS configuration. In pipe mode, when QoS is configured on the access egress of a PE device, the MPLS-EXP field is trusted, that is, the priority to send the packet is decided by the MPLS-EXP field. Short-pipe mode: On the access ingress of a PE device, IPP and TTL are not inherited to the EXP field and TTL fields of a label. On the access egress of a PE device, the EXP and TTL fields of a label are not inherited to IPP and TTL of an IP packet. Therefore, a packet has two inconsistent priorities. The device has 6-1

56 ZXR10 ZSR V2 Configuration Guide (QoS) to designate a priority to be trusted during the QoS configuration. In short-pipe mode, when QoS is configured on the access egress of a PE device, IPP field is trusted, that is, the priority to send the packet is decided by the IPP field. 6.2 Configuring Priority Inheritance This procedure describes how to configure priority inheritance on the ZXR10 ZSR V2, so that priority inheritance among different types of packets can be accomplished. Steps 1. Configure EXP-IPP priority inheritance and 802.1p inheritance on an interface. Step Command Function 1 ZXR10(config)#mls-qos-mode <interface-name >{uniform pipe short-pipe} 2 ZXR10(config)#qos-dot1p <interface-name>[cvla n-in] 3 ZXR10(config)#ttl-qos-mode <interface-name>{u niform pipe} Configures priority inheritance on a designated interface. Configures 802.1p inheritance on a designated interface. Configures TTL inheritance on a designated interface. 2. For the packets that match the flow classification in H-QoS, perform the following steps to configure EXP-IPP priority inheritance and 802.1p inheritance. a. Configure flow classification. For details, refer to Configuring Flow Classification. b. Configure the inheritance relationship among 802.1p, MPLS-EXP and IPP. Step Command Function 1 ZXR10(config)#policy-map<policy-map-n ame> 2 ZXR10(config-pmap)#class <class-map-na me> 3 ZXR10(config-pmap-c)#set {8021p mpls-exp precedence dscp} inherit-from {8021p mpls-exp precedence dscp} Creates a policy-map and enters policy mapping configuration mode. Associates with a class-map and enters policy class configuration mode. Configures the inheritance relationship among 802.1p, MPLS-EXP and IPP. c. Bind a policy to an interface. For details, refer to Configuring H-QoS. 3. Configure EXP-IPP priority inheritance and TTL inheritance on a VRF interface. Step Command Function 1 ZXR10(config)#ip vrf <vrf-name> Configures a VRF instance. The parameter <WORD> is the VRF instance name, with 1 32 characters. 6-2

57 Chapter 6 Priority Inheritance Configuration Step Command Function 2 ZXR10(config-vrf-vrf-name)#ds-mode {pipe short-pipe uniform } 3 ZXR10(config-vrf-vrf-name)#ttl-mode {pipe uniform} Configure the inheritance of the MPLS label priority and the priority field in an IP packet. Configure the inheritance of the MPLS label priority and the ttl value in an IP packet. 4. Verify the configurations. Command ZXR10#show mls-qos-mode [<interface-name>] ZXR10#show qos-dot1p [<interface-name>] ZXR10#show class-map [<class-map-name>] ZXR10#show policy-map [<policy-map-name>[class <class-name>]] ZXR10#show service-policy [<interface-name>] ZXR10#show running-config hqos ZXR10#show running-config hqos-if Function Displays all priority inheritance configuration on interfaces. Displays all 802.1p inheritance configuration on interfaces. Displays all class-maps and configuration of matching rules. Displays all policy-maps and configuration of policy classes. Displays all policy bindings on interfaces. Displays the information of H-QoS. Displays the priority inheritance policies. End of Steps 6.3 Priority Inheritance Configuration Instances P Inheritance Configuration Instance Configuration Description Figure P Inheritance Configuration Instance shows a network topology. It is required to map 802.1P of packets that enters R2 through VLAN sub-interface (gei-1/1.1) to IPP when the packets leave R2. Figure P Inheritance Configuration Instance 6-3