07 QoS Volume Book

i

Table of Contents

1 QoS Overview ············································································································································1-1 Introduction to QoS ·································································································································1-1 Traditional Packet Forwarding Services ·································································································1-1 New Requirements from Emerging Applications ····················································································1-1 Congestion: Causes, Impacts, and Countermeasures ···········································································1-2

Causes ············································································································································1-2 Impacts ············································································································································1-2 Countermeasures ····························································································································1-2

Major Traffic Management Technologies································································································1-3

2 Traffic Classification, Traffic Policing, and Traffic Shaping Configuration·········································2-1 Traffic Classification Overview················································································································2-1

Traffic Classification ························································································································2-1 IP Precedence ·································································································································2-1

Traffic Policing and Traffic Shaping Overview ························································································2-2 Traffic Evaluation and Token Bucket ······································································································2-2 Traffic Policing, GTS, and Line Rate Configuration ················································································2-5

Configuring Traffic Policing ·············································································································2-6 Configuring GTS······························································································································2-8 Configuring the Line Rate················································································································2-9

Displaying and Maintaining Traffic Policing, GTS and Line Rate ·························································2-10 Traffic Policing and GTS Configuration Example ·················································································2-10

3 QoS Policy Configuration ·························································································································3-1 QoS Policy Overview ······························································································································3-1 Configuring a QoS Policy························································································································3-1

Configuration Prerequisites ·············································································································3-1 Defining a Class ······························································································································3-2 Defining a Traffic Behavior ··············································································································3-2 Defining a Policy······························································································································3-3 QoS Policy Configuration Example ·································································································3-4

Applying the QoS Policy ·························································································································3-4 Applying the QoS Policy to an Interface or PVC ·············································································3-4

Configuring QoS Policy-Based Traffic Rate Measuring Interval·····························································3-5 Displaying and Maintaining QoS Policies ·······························································································3-6

4 Congestion Management Configuration ·································································································4-1 Congestion Management Overview········································································································4-1

Congestion Management Policies···································································································4-1 Congestion Management Technology Comparison ········································································4-6

Configuring FIFO·····································································································································4-8 FIFO Configuration Procedure ········································································································4-8 FIFO Configuration Example···········································································································4-8

Configuring PQ········································································································································4-8 PQ Configuration Procedure ···········································································································4-8

ii

PQ Configuration Example············································································································4-10 Configuring CQ ·····································································································································4-10

Configuration Procedure················································································································4-11 CQ Configuration Example············································································································4-12

Configuring WFQ ··································································································································4-12 Configuration Procedure················································································································4-12 WFQ Configuration Example·········································································································4-13

Configuring CBQ···································································································································4-13 Configuring the Maximum Available Interface Bandwidth·····························································4-14 Defining a Class ····························································································································4-15 Defining a Traffic Behavior ············································································································4-16 Defining a QoS Policy····················································································································4-22 Applying the QoS Policy················································································································4-22 CBQ Configuration Example ·········································································································4-23 Displaying and Maintaining CBQ···································································································4-25

Configuring RTP Priority Queuing·········································································································4-25 Configuration Procedure················································································································4-25 RTP Priority Queuing Configuration Example···············································································4-26

Configuring QoS Tokens·······················································································································4-26 QoS Token Configuration Procedure ····························································································4-26 QoS Token Configuration Example·······························································································4-27

Configuring Packet Information Pre-Extraction·····················································································4-27 Configuration Procedure················································································································4-27 Configuration Example ··················································································································4-27

Configuring Local Fragment Pre-drop···································································································4-28 Configuration Procedure················································································································4-28 Configuration Example ··················································································································4-28

5 Priority Mapping Configuration················································································································5-1 Priority Mapping Overview ······················································································································5-1 Configuring a Priority Mapping Table······································································································5-3

Configuration Prerequisites ·············································································································5-3 Configuration Procedure··················································································································5-3 Configuration Example ····················································································································5-3

Configuring the Priority for a Port············································································································5-4 Configuration Prerequisites ·············································································································5-4 Configuration Procedure··················································································································5-4 Configuration Example ····················································································································5-5

Configuring the Trusted Precedence Type for a Port ·············································································5-5 Configuration Prerequisites ·············································································································5-5 Configuration Procedure··················································································································5-5 Configuration Example ····················································································································5-6

Displaying and Maintaining Priority Mapping··························································································5-6 Priority Mapping Configuration Examples·······························································································5-6

Example 1········································································································································5-6 Example 2········································································································································5-8

6 Congestion Avoidance······························································································································6-1 Congestion Avoidance Overview············································································································6-1

iii

Introduction to WRED Configuration·······································································································6-2 Configuration Methods ····················································································································6-2 Introduction to WRED Parameters ··································································································6-3

Configuring WRED on an Interface·········································································································6-3 Configuration Prerequisites ·············································································································6-3 Configuration Procedure··················································································································6-3 Configuration Example ····················································································································6-4

Applying a WRED Table on an Interface ································································································6-4 Configuration Prerequisites ·············································································································6-4 Configuration Procedure··················································································································6-5

Displaying and Maintaining WRED·········································································································6-6 WRED Configuration Example················································································································6-6

7 MPLS QoS Configuration··························································································································7-1 MPLS QoS Overview ······························································································································7-1 Configuring MPLS QoS···························································································································7-2

Configuring MPLS PQ ·····················································································································7-2 Configuring MPLS CQ·····················································································································7-2 Configuring a MPLS QoS Policy ·····································································································7-3 Configuring MPLS CAR···················································································································7-4

MPLS QoS Configuration Examples·······································································································7-5 Configuring QoS for Traffic Within a VPN ·······················································································7-5

8 DAR Configuration ····································································································································8-1 DAR Overview·········································································································································8-1

IP Packet ·········································································································································8-1 TCP Packet ·····································································································································8-3 UDP Packet ·····································································································································8-4 HTTP Packet ···································································································································8-4 RTP Packet ·····································································································································8-5 RTCP Packet Overview···················································································································8-5 Static Protocol Overview ·················································································································8-6

Configuring DAR ·····································································································································8-9 Configuration Prerequisites ·············································································································8-9 Configuring Protocol Match Criteria ································································································8-9 Configuring Port Numbers for DAR Application Protocols ······························································8-9 Renaming User-defined Protocols ································································································8-10 Configuring DAR Packet Accounting·····························································································8-10 Configuring the Maximum Number of Recognizable Connections ···············································8-10

Displaying and Maintaining DAR ··········································································································8-11 DAR Configuration Examples ···············································································································8-11

BT Downloading Prohibition Configuration Example ····································································8-11 HTTP URL-Based DAR Configuration Example ···········································································8-12 HTTP Host-Based DAR Configuration Example ···········································································8-13

9 FR QoS Configuration·······························································································································9-1 FR QoS Overview ···································································································································9-1

FR QoS············································································································································9-1 Key Parameters·······························································································································9-1 FR QoS Implementation··················································································································9-2

iv

Configuring FR QoS································································································································9-7 FR QoS Configuration Task List······································································································9-7 Creating and Configuring a FR Class······························································································9-7 Configuring FRTS····························································································································9-8 Configuring FR Traffic Policing········································································································9-9 Configuring FR Congestion Management·····················································································9-10 Configuring FR DE Rule List ·········································································································9-11 Configuring FR Queuing················································································································9-12 Configuring FR Fragmentation ······································································································9-13

Displaying and Maintaining FR QoS·····································································································9-14 FR QoS Configuration Examples··········································································································9-15

FRTS Configuration Example········································································································9-15 FR Fragmentation Configuration Example····················································································9-16 FR WRED Configuration Example ································································································9-17

1-1

1 QoS Overview

This chapter covers the following topics:

Introduction to QoS

Traditional Packet Forwarding Services

New Requirements from Emerging Applications

Congestion: Causes, Impacts, and Countermeasures

Major Traffic Management Technologies

Introduction to QoS

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.

Traditional Packet Forwarding Services

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.

New Requirements from Emerging Applications

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

1-2

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.

Congestion: Causes, Impacts, and Countermeasures

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.

Causes

Congestion easily occurs in complex packet switching circumstances in the Internet. The following figure shows two common cases:

Figure 1-1 Traffic congestion causes

Congestion on interfaces with different speeds

Congestion on interfaces with the same speed

100M

100M

100M

100M

100M10M

The traffic enters a device from a high speed link and is forwarded over a low speed link.

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.

Impacts

Congestion may bring these negative results:

Increased delay and jitter during packet transmission

Decreased network throughput and resource use efficiency

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.

Countermeasures

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

1-3

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.

Major Traffic Management Technologies

Figure 1-2 End-to-end QoS model

As shown in Figure 1-2, traffic classification, traffic policing, traffic shaping, congestion management, and congestion avoidance are the foundations for a network to provide differentiated services. Mainly they implement the following functions:

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.

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.

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.

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.

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:

Traffic classification

Access control

Traffic policing and traffic shaping

1-4

Congestion management

Congestion avoidance

2-1

2 Traffic Classification, Traffic Policing, and Traffic Shaping Configuration

When configuring traffic classification, traffic policing, and traffic shaping, go to these sections for information you are interested in:

Traffic Classification Overview

Traffic Policing and Traffic Shaping Overview

Traffic Evaluation and Token Bucket

Traffic Policing, GTS, and Line Rate Configuration

Displaying and Maintaining Traffic Policing, GTS and Line Rate

Traffic Policing and GTS Configuration Example

Traffic Classification Overview

Traffic Classification

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.

IP Precedence

The following part introduces some precedence types.

2-2

Figure 2-1 DS field and ToS bytes

As shown in Figure 2-1, the ToS field of the IP header contains 8 bits: the first three bits (0 to 2) represent IP precedence from 0 to 7; the following 4 bits (3 to 6) represent a ToS value from 0 to 15. In RFC 2474, the ToS field of the IP header is redefined as the DS field, where a DiffServ code point (DSCP) precedence is represented by the first 6 bits (0 to 5) and is in the range 0 to 63. The remaining 2 bits (6 and 7) are reserved.

Traffic Policing and Traffic Shaping Overview

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.

Traffic Evaluation and Token Bucket

Token bucket features 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-2 Evaluate traffic with the token bucket

Token bucket

Packets dropped

Packet classification

Packets to be sent through this interface

Packets sent

Tokens are put into the bucket at the set rate

2-3

Evaluating 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:

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).

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.

Complicated evaluation 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:

CIR

CBS

Excess burst size (EBS)

The rate of putting tokens into the two buckets is CIR, 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”.

Traffic policing 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:

Forwarding the packets whose evaluation result is “conforming”.

Dropping the packets whose evaluation result is “excess”.

Modifying the IP precedence of the packets whose evaluation result is “conforming” and forwarding them.

Modifying the IP precedence of the packets whose evaluation result is “conforming” and delivering them into the next-level traffic policing.

Entering the next-level policing (you can set multiple traffic policing levels with each level focusing on specific objects).

2-4

Traffic shaping Traffic shaping provides measures to adjust the rate of outbound traffic actively. A typical traffic shaping application is to limit the local traffic output rate according to the downstream traffic policing parameters.

The difference between traffic policing and GTS is that packets to be dropped in traffic policing are cached in a buffer or queue in GTS, as shown in Figure 2-3. When there are enough tokens in the token bucket, these cached packets are sent at an even rate. Traffic shaping may result in an additional delay while traffic policing does not.

Figure 2-3 Diagram for GTS

For example, in Figure 2-4, Router A sends packets to Router B. Router B performs traffic policing on packets from Router A and drops packets exceeding the limit.

Figure 2-4 GTS application

You can perform traffic shaping for the packets on the outgoing interface of Router A to avoid unnecessary packet loss. Packets exceeding the limit are cached in Router A. Once resources are released, traffic shaping takes out the cached packets and sends them out. In this way, all the traffic sent to Router B conforms to the traffic specification defined in Router B.

Line rate 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.

2-5

Figure 2-5 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.

Traffic Policing, GTS, and Line Rate Configuration

Complete the following tasks to configure traffic policing, GTS, and line rate:

Task Remarks

Configure a CAR list Configuring CAR-list-based traffic policing

Apply CAR policies to the specified interface

Configure an ACL Configuring ACL-based traffic policing

Apply CAR policies to the specified interface

Configuring traffic policing for all traffic Apply CAR policies to the specified interface

Configure ACL Configuring ACL-based GTS

Configure GTS on interfaces

Configuring GTS for all traffic Configure GTS on interfaces

Configuring the Line Rate Configure line rate

2-6

Configuring Traffic Policing

Traffic policing configuration involves the following two tasks: the first task is to define the characteristics of packets to be policed; the second task is to define policing policies for the matched packets.

Configuring CAR-list-based traffic policing

Follow these steps to configure CAR-list-based traffic policing:

To do… Use the command… Remarks

Enter system view system-view —

Configure a committed

access rate (CAR) list

qos carl carl-index { precedence

precedence-value | mac mac-address | dscp

dscp-list | { destination-ip-address | source-ip-address } { subnet ip-address

mask-length | range start-ip-address to

end-ip-address } [ per-address

[ shared-bandwidth ] ] }

Required

Display the CAR list display qos carl [ carl-index ] Optional

Available in any view

Enter

interface

view

interface interface-type interface-number Enter

interface

view or

port group

view

Enter port

group

view

port-group manual port-group-name

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.

Configure a CAR list

based CAR policy on

the interface/port group

qos car { inbound | outbound } carl

carl-index cir committed-information-rate

[ cbs committed-burst-size [ ebs

excess-burst-size ] ] [ green action ] [ red

action ]

Required

Display CAR

configuration

information on the

interface/all interfaces

display qos car interface [ interface-type

interface-number ]

Optional


Configuring ACL-based traffic policing Follow these steps to configure ACL-based traffic policing:



Configure an ACL Refer to the ACL module Required

2-7


Enter

interface

view

interface interface-type interface-numberEnter

interface

view or port

group view Enter port

group view port-group manual port-group-name

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.

Configure an ACL based

CAR policy on the

interface/port group

qos car { inbound | outbound } acl

[ ipv6 ] acl-number cir

committed-information-rate [ cbs

committed-burst-size [ ebs


action ]

Required

Display CAR policy

information on the

interface/all interfaces

display qos car interface [ interface-type interface-number ]

Optional


Configuring traffic policing for all traffic Follow these steps to configure traffic policing for all traffic:



Enter

interface

view


interface

view or port



Use either command





Configure a CAR policy

for all traffic on the


qos car { inbound | outbound } any cir




action ]

Required

Display the CAR policy

information on the

specified interface

display qos car interface [ interface-type interface-number ]

Optional


Traffic policing configuration example Configure traffic policing on Ethernet 1/1: rate of packets sent on Ethernet 1/1 cannot exceed 1 Mbps, and excess packets are dropped.

# Enter system view. <Sysname> system-view

# Enter interface view. [Sysname] interface ethernet1/1

2-8

# Configure a CAR policy for the interface. [Sysname-Ethernet1/1] qos car outbound any cir 1000 cbs 1000000 ebs 0 green pass red discard

Configuring GTS

Traffic shaping configuration involves:

ACL-based generic traffic shaping (GTS): setting GTS parameters for the traffic matching the specific ACL. By specifying multiple ACLs, you can set GTS parameters for different classes of traffic.

GTS for all traffic: configuring GTS parameters for all traffic.

GTS for software forwarding does not support IPv6.

Configuring ACL-based GTS Follow these steps to configure ACL-based GTS:



Defining an ACL Refer to the ACL module Required

Enter

interface

view


interface

view or

port group

view Enter port


Use either command





Configure ACL-based

GTS on the interface/port

group

qos gts acl acl-number cir



excess-burst-size [ queue-length queue-length ] ] ]

Required

Display GTS

configuration information

on the interface

display qos gts interface [ interface-type

interface-number ]

Optional


Configuring GTS for all traffic Follow these steps to configure GTS for all traffic:



2-9


Enter

interface

view

interface interface-type

interface-number

Enter

interface

view or

port group

view Enter port


Use either command



port group view take effect on all ports

in the port group.

Configure GTS on the


qos gts any cir



excess-burst-size [ queue-length queue-length ] ] ]

Required

Display GTS configuration

on the interface

display qos gts interface [ interface-type interface-number ]

Optional


GTS configuration example Configure GTS on Ethernet 1/1, shaping the packets when the sending rate exceeds 500 kbps.


# Enter interface view. [Sysname] interface ethernet 1/1

# Configure GTS parameters. [Sysname-Ethernet1/1] qos gts any cir 500

Configuring the Line Rate

Configuration procedure 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:



Enter interface

view interface interface-type interface-number

Enter

interface

view or port

group view Enter port group

view port-group manual port-group-name

Use either command

Settings in interface view

take effect on the current

interface; settings in port

group view take effect on all


Configure the line rate for the


qos lr { inbound | outbound } cir



excess-burst-size ] ]

Required

2-10


Display line rate information on

the interface

display qos lr interface [ interface-type

interface-number ] Available in any view

Line rate configuration example Limit the outbound line rate of Ethernet 1/1 to 500 kbps.



# Limit the outbound line rate of Ethernet 1/1 to 500 kbps. [Sysname-Ethernet1/1] qos lr outbound cir 500

Displaying and Maintaining Traffic Policing, GTS and Line Rate


Display CAR list information display qos carl [ carl-index ] Available in any view

Display the CAR information on the

specified interface

display qos car interface [ interface-type


Display interface GTS


display qos gts interface [ interface-type


Display interface line rate


display qos lr interface [ interface-type


Traffic Policing and GTS Configuration Example

Network requirements Ethernet 1/3 of Router A is connected to Ethernet 1/1 of Router B.

Server, Host A, and Host B can access the Internet through Router A and Router B.

Server, Host A, and Ethernet 1/1 of Router A are in the same network segment.

Host B, and Ethernet 1/2 of Router A are in the same network segment.

Perform traffic control for packets received on Ethernet 1/1 of Router A from Server and Host A respectively as follows:

Limit the rate of packets from Server to 54 kbps. When the traffic rate is below 54 kbps, the traffic is forwarded normally. When the traffic rate exceeds 54 kbps, violating packets are marked with IP precedence 0 and then forwarded.

Limit the rate of packets from Host A to 8 kbps. When the traffic rate is below 8 kbps, the traffic is forwarded normally. When the traffic rate exceeds 8 kbps, the violating packets are dropped.

Traffic control for packets forwarded by Ethernet 1/1 and Ethernet 1/2 of Router B is as follows:

Limit the receiving rate on Ethernet 1/1 of Router B to 500 kbps, and violating packets are dropped.

2-11

Limit the sending rate on Ethernet 1/2 of Router B to 1000 kbps, and violating packets are dropped.

Figure 2-6 Network diagram for traffic policing and GTS

Configuration procedure 1) Configure Router A

# Configure GTS on Ethernet 1/3 of Router A, shaping the packets when the sending rate exceeds 500 kbps to decrease the packet loss ratio of Ethernet 1/1 of Router B. <RouterA> system-view

[RouterA] interface ethernet 1/3

[RouterA-Ethernet1/3] qos gts any cir 500

[RouterA-Ethernet1/3] quit

# Configure ACLs to permit the packets from Server and Host A. [RouterA] acl number 2001

[RouterA-acl-basic-2001] rule permit source 1.1.1.1 0

[RouterA-acl-basic-2001] quit

[RouterA] acl number 2002

[RouterA-acl-basic-2002] rule permit source 1.1.1.2 0

[RouterA-acl-basic-2002] quit

# Configure CAR policies for different flows received on Ethernet 1/1. [RouterA] interface ethernet 1/1

[RouterA-Ethernet1/1] qos car inbound acl 2001 cir 54 cbs 4000 ebs 0 green pass red remark-prec-pass 0

[RouterA-Ethernet1/1] qos car inbound acl 2002 cir 8 cbs 1875 ebs 0 green pass red discard

[RouterA-Ethernet1/1] qos car inbound any cir 500 cbs 32000 ebs 0 green pass red discard

[RouterA-Ethernet1/1] quit

2) Configure Router B

# Configure a CAR policy on Ethernet 1/2 to limit the sending rate to 1 Mbps. Violating packets are dropped. <RouterB> system-view

[RouterB] interface ethernet 1/2

[RouterB-Ethernet1/2] qos car outbound any cir 1000 cbs 65000 ebs 0 green pass red discard

3-1

3 QoS Policy Configuration

When configuring a QoS policy, go to these sections for information you are interested in:

QoS Policy Overview

Configuring a QoS Policy

Applying the QoS Policy

Configuring QoS Policy-Based Traffic Rate Measuring Interval

Displaying and Maintaining QoS Policies

QoS Policy Overview

A QoS policy involves three components: class, traffic behavior, and policy. You can associate a class with a traffic behavior using a QoS policy.

Class 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.

and: The device considers a packet belongs to a class only when the packet matches all the criteria in the class.

or: The device considers a packet belongs to a class as long as the packet matches one of the criteria in the class.

Traffic behavior A traffic behavior defines a set of QoS actions for packets.

Policy

A policy associates a class with a traffic behavior.

You can configure multiple class-to-traffic behavior associations in a policy.

Configuring a QoS 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.

Configuration Prerequisites

You need to decide on:

The class name and match criteria.

The traffic behavior name and actions in the traffic behavior.

The policy name.

3-2

Defining a Class

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:



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 [ not ] match-criteria Required

Display class information

display traffic classifier

{ system-defined | user-defined }

[ tcl-name ]

Optional


Defining a Traffic Behavior

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:



Create a traffic behavior and

enter traffic behavior view traffic behavior behavior-name Required

Configure a CAR policy

car cir committed-information-rate [ cbs

committed-burst-size [ ebs excess-burst-size ] ]

[ green action ] [ red action ]

Drop or send packets filter { deny | permit }

In absolute

value

gts cir committed-information-rate [ cbs

committed-burst-size [ ebs excess-burst-size

[ queue-length queue-length ] ] ] Configure a

GTS policy In

percentage

gts percent cir cir-percent [ cbs cbs-time [ ebs

ebs-time ] ]

Set the cell loss priority (CLP)

bit for ATM cells remark atm-clp atm-clp-value

Set the DSCP value for packets remark dscp dscp-value

Set the 802.1p precedence for

packets remark dot1p 8021p

Required

You can

configure the

corresponding

traffic behavior

as required.

3-3


Set the drop precedence for

packets remark drop-precedence drop-precedence-value

Set the DE bit for FR packets remark fr-de fr-de-value

Set the IP precedence for

packets remark ip-precedence ip-precedence-value

Set the EXP value for MPLS

packets remark mpls-exp exp-value

Set the QoS local ID for packets remark qos-local-id local-id-value

Display traffic behavior


display traffic behavior { system-defined |

user-defined } [ behavior-name ]

Optional

Available in any

view

Defining a Policy

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:



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


If an ACL is referenced by a QoS policy for defining traffic match criteria, the operation of the QoS policy varies by interface or PVC:

3-4

If the QoS policy is applied to a software interface or PVC and the match mode of the if-match clause is deny, the if-match clause for matching the ACL does not take effect and packets go to the next match criterion.

With the QoS policy applied to a hardware interface, packets matching the ACL are organized as a class and the behavior defined in the QoS policy applies to the class regardless of whether the match mode of the if-match clause is deny or permit.

QoS Policy Configuration Example

Network requirements

Configure a QoS policy test_policy to limit the rate of packets with IP precedence 6 to 100 kbps.

Configuration procedure

# 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 100

[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:

In interface or PVC view, the policy applies to the inbound or outbound direction of an interface or PVC.

You can modify the classification rules, traffic behaviors, and classifier-behavior associations of a QoS policy already applied.

Applying the QoS Policy to an Interface or PVC

A policy can be applied to multiple interfaces or PVCs. Only one policy can be applied in one direction (inbound or outbound) of an interface or PVC.

Configuration procedure Follow these steps to apply the QoS policy to an interface or PVC:


3-5



Enter

interface

view


interface-number

Enter port


interface atm interface-number

Enter

interface

view, port

group view,

or PVC view Enter PVC

view pvc vpi/vci

Use either command




effect on all ports in the port group;

settings in PVC view take effect on

the current PVC.

Apply the policy to the

interface/port group/PVC

qos apply policy policy-name

{ inbound | outbound } Required

QoS policies can be applied to all physical interfaces except interfaces encapsulated with X.25 or LAPB.

If a QoS policy is applied in the outbound direction of an interface or PVC, the QoS policy cannot influence local packets (local packets refer to the important protocol packets that maintain the normal operation of the device. QoS must not process such packets to avoid packet drop. Commonly used local packets are: link maintenance packets, ISIS packets, OSPF packets, RIP packets, BGP packets, LDP packets, RSVP packets, and SSH packets and so on.)

Configuration example # Apply QoS policy test_policy to the inbound direction of Ethernet 1/1. <Sysname> system-view

[Sysname] interface ethernet 1/1

[Sysname-Ethernet1/1] qos apply policy test_policy inbound

Configuring QoS Policy-Based Traffic Rate Measuring Interval

The QoS policy-based traffic rate measuring function can collect statistics about the average forwarding and drop rates of traffic over an interval on a per-class basis. The measuring interval is user configurable and the statistics are refreshed every 15 seconds. You can use the display qos policy interface command to view the collected traffic rate statistics.

Follow these steps to configure the QoS policy-based traffic rate measuring interval:



Enter interface view interface interface-type

interface-number —

3-6


Configure the QoS policy-based traffic rate

measuring interval qos flow-interval interval

Optional

5 minutes by default.

The QoS policy-based traffic rate measuring interval of an ATM PVC is the same as that of the ATM interface.

The QoS policy-based traffic rate measuring interval of an FR DLCI is the same as that of the FR interface.

The QoS policy-based traffic rate measuring interval of a subinterface is the same as that of the main interface.

Displaying and Maintaining QoS Policies


Display traffic class information display traffic classifier { system-defined |

user-defined } [ tcl-name ] Available in any view



display traffic behavior { system-defined |

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 { system-defined |

user-defined } [ policy-name [ classifier tcl-name ] ]


Display QoS policy configuration

on the specified or all

interfaces/PVCs

display qos policy interface [ interface-type

interface-number ] [ inbound | outbound ]

[ pvc { pvc-name [ vpi/vci ] | vpi/vci } ]


4-1

4 Congestion Management Configuration

When configuring congestion management, go to these sections for information you are interested in:

Congestion Management Overview

Configuring FIFO

Configuring PQ

Configuring CQ

Configuring WFQ

Configuring CBQ

Configuring RTP Priority Queuing

Configuring QoS Tokens

Configuring Packet Information Pre-Extraction

Configuring Local Fragment Pre-drop

Congestion Management Overview

Congestion occurs on an 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, thus leading to a vicious circle.

The key to congestion management is how to define a dispatching policy for resources to decide the order of forwarding packets when congestion occurs.

Congestion Management Policies

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 is used to handle a particular network traffic problem and has significant impacts on bandwidth resource assignment, delay, and jitter.

Several common queue-scheduling mechanisms are introduced here.

FIFO

Figure 4-1 FIFO queuing

Packets to be sent through this interface Packets sent

Sending queue

Queue Interface

4-2

As shown in Figure 4-1, First in First Out (FIFO) queuing determines the order of forwarding packets according to the arrival time. On a device, the resources assigned for the packets are based on the arrival time of the packets and the current load status of the device. The best-effort service model adopts FIFO queuing.

If there is only one FIFO output/input queue on each port of a device, malicious applications may occupy all network resources and seriously affect mission-critical data transmission.

FIFO queuing is adopted by default.

Priority queuing

Figure 4-2 Priority queuing (PQ)

Packets to be sent through this interface

Classify Schedule

High queue

Middle queue

Normal queue

Bottom queue

Packets sent

Sending queue

Interface

Priority queuing is designed for mission-critical applications. The key feature of mission-critical applications is that they require preferential service to reduce the response delay when congestion occurs. Priority queuing can flexibly determine the order of forwarding packets by network protocol (for example, IP and IPX), incoming interface, packet length, source/destination address, and so on. Priority queuing classifies packets into four queues: top, middle, normal, and bottom, in descending priority order. By default, packets are assigned to the normal queue.

Priority queuing schedules the four 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. In this way, you can assign the mission-critical packets to the high priority queue to ensure that they are always served first. The common service packets are assigned to the low priority queues and transmitted when the high priority queues are empty.

The disadvantage of priority queuing is that packets in the lower priority queues cannot be transmitted if there are packets in the higher queues for a long time.

4-3

Custom queuing

Figure 4-3 Custom queuing (CQ)

CQ organizes packets into 16 classes (corresponding to 16 queues) by certain rules. A certain class of packets enters the corresponding custom queue according to FIFO queuing.

Queues 1 through 16 are customer queues, as shown in Figure 4-3. You can define traffic classification rules and assign a percentage of interface/PVC bandwidth for each of these 16 customer queues. During a cycle of queue scheduling, packets in the system queue are sent preferentially till the system queue is empty. Then round robin queue scheduling is performed for the 16 customer queues, that is, a certain number of packets (based on the percentage of interface bandwidth assigned for each queue) are taken out from a queue and forwarded in the ascending order of queue 1 to queue 16. In CQ, packets of different applications are assigned with different bandwidths. In this way, mission-critical packets are assigned with more bandwidth, and at the same time, normal packets are also assigned with certain bandwidth. By default, packets are assigned to queue 1.

Another advantage of CQ is that bandwidth can be assigned according to the utilization of applications, so CQ is suitable for applications with the special requirement for bandwidth. Though round robin queue scheduling is performed for the 16 customer queues, no fixed service time segment is assigned for each queue. When there are no packets of certain classes, the bandwidth allocated to packets of the existing classes increases.

4-4

Weighted fair queuing

Figure 4-4 Weighted fair queuing (WFQ)

Before WFQ is introduced, you need to understand fair queuing (FQ). FQ is designed for fairly sharing network resources, reducing the delay and jitter of all traffic. FQ takes all the aspects into consideration:

Different queues have fair dispatching opportunities for delay balancing among streams.

Short packets and long packets are fairly scheduled: if there are long packets and short packets in queues, statistically the short packets should be scheduled preferentially to reduce the jitter between packets on the 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, etc), 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 on a whole. When dequeuing packets, WFQ assigns the outgoing interface bandwidth to each traffic flow by the precedence. The higher precedence value a traffic flow has, the more bandwidth it gets.

For example, assume that there are five flows in the current interface, with the precedence being 0, 1, 2, 3, and 4 respectively. The total bandwidth quota is the sum of all the (precedence value + 1)s, that is, 1 + 2 + 3 + 4 + 5 = 15.

The bandwidth percentage assigned to each flow is (precedence value of the flow + 1)/total bandwidth quota. The bandwidth percentages for flows are 1/15, 2/15, 3/15, 4/15, and 5/15 respectively.

Because WFQ can balance the delay and jitter of every flow when congestion occurs, it is effectively applied in some special occasions. For example, WFQ is adopted in the assured forwarding (AF) services of the Resource Reservation Protocol (RSVP). In Generic Traffic Shaping (GTS), WFQ is used to schedule buffered packets.

CBQ Class-based queuing (CBQ) extends WFQ by supporting user-defined classes. CBQ assigns an independent reserved FIFO queue for each user-defined class to buffer data of the class. In the case of network congestion, CBQ assigns packets to queues by user-defined traffic classification rules. It is necessary to perform the congestion avoidance mechanism (tail drop or weighted random early

4-5

detection (WRED)) and bandwidth restriction check before packets are enqueued. When being dequeued, packets are scheduled by WFQ.

CBQ provides an emergency queue to enqueue emergent packets. The emergency queue is a FIFO queue without bandwidth restriction. However, delay sensitive flows like voice packets may not be transmitted timely in CBQ since packets are fairly treated. To solve this issue, Low Latency Queuing (LLQ) was introduced to combine PQ and CBQ to transmit delay sensitive flows like voice packets preferentially.

When defining traffic classes for LLQ, you can configure a class of packets to be transmitted preferentially. Such a class is called a priority class. The packets of all priority classes are assigned to the same priority queue. It is necessary to check bandwidth restriction of each class of packets before the packets are enqueued. During the dequeuing operation, packets in the priority queue are transmitted first. WFQ is used to dequeue packets in the other queues.

In order to reduce the delay of the other queues except the priority queue, LLQ assigns the maximum available bandwidth for each priority class. The bandwidth value is used to police traffic in the case of congestion. In the case of no congestion, a priority class can use more than the bandwidth assigned to it. In the case of congestion, the packets of each priority class exceeding the assigned bandwidth are discarded. LLQ can also specify burst-size.

The system matches packets with classification rules in the following order:

Match packets with priority classes and then the other classes.

Match packets with priority classes in the order configured.

Match packets with other classes in the order configured.

Match packets with classification rules in a class in the order configured.

RTP priority queuing Real-time transport protocol (RTP) priority queuing is a simple queuing technology designed to guarantee QoS for real-time services (including voice and video services). It assigns RTP voice or video packets to high-priority queues for preferential sending, thus minimizing delay and jitter and ensuring QoS for voice or video services sensitive to delay.

Figure 4-5 RTP queuing

As shown in Figure 4-5, RTP priority queuing assigns RTP packets to a high-priority queue. An RTP packet is a UDP packet with an even destination port number in a configurable range. RTP priority queuing can be used in conjunction with any queuing (such as, FIFO, PQ, CQ, WFQ and CBQ), while it always has the highest priority. Since LLQ of CBQ can also be used to guarantee real-time service data transmission, it is not recommended to use RTP priority queuing in conjunction with CBQ.

4-6

Congestion Management Technology Comparison

Breaking through the single congestion management policy of FIFO for traditional IP devices, the current device provides all the congestion management technologies above mentioned to offer powerful QoS capabilities, meeting different QoS requirements of different applications. The following table compares these queuing technologies for efficient use.

Table 4-1 Congestion management technology comparison

Type Number of

queues Advantages Disadvantages

FIFO 1 No need to configure, easy to use

Easy to operate, low delay

All packets are treated equally. The

available bandwidth, delay and drop

probability are determined by the

arrival order of the packets.

No restriction on the incooperative

data sources (that is, flows without

flow control mechanism, UDP for

example), resulting in bandwidth

loss of cooperative data sources

such as TCP.

No delay guarantee to

time-sensitive real-time applications,

such as VoIP

PQ 4

Provide absolute bandwidth and delay

guarantees for real-time and mission

critical applications such as VoIP

Need to configure; low processing

speed

If there is no restriction on

bandwidth assigned to high-priority

packets, low-priority packets may

fail to get bandwidth.

CQ 16

Provide different bandwidth

percentages for different

applications

If packets of certain classes do not

exist, it can increase the bandwidth

for existing packets.

Need to configure; low processing

speed

4-7

Type Number of

queues Advantages Disadvantages

WFQ Configurable

Easy to configure

Provide a bandwidth guarantee for

packets from cooperative

(interactive) sources (such as TCP

packets)

Reduce jitter

Reduce the delay for interactive

applications with a small amount of

data

Assign different bandwidths to traffic

flows with different priorities

When the number of traffic classes

decreases, it can automatically

increase the bandwidth for the

existing classes.

The processing speed is faster than that

of PQ and CQ but slower than that of

FIFO

CBQ Configurable

(0 to 64)

Flexibly classify traffic based on

various rules and provide different

queue scheduling mechanisms for

expedited forwarding (EF), assured

forwarding (AF) and best-effort (BE)

services.

Provide a highly precise bandwidth

guarantee and queue scheduling on

the basis of AF service weights for

various AF services.

Provide absolutely preferential

queue scheduling for the EF service

to meet the delay requirement of

real-time data; overcome the

disadvantage of PQ that some

low-priority queues are not serviced

by restricting the high-priority traffic.

Provide WFQ scheduling for

best-effort traffic (the default class).

The system overhead is large.

If the burst traffic is too heavy, you can increase the queue length to make queue scheduling more accurate.

4-8

Configuring FIFO

FIFO is the default queue scheduling mechanism for an interface or PVC, and the FIFO queue size is configurable.

FIFO Configuration Procedure

Follow these steps to configure FIFO:



Enter interface



Enter interface

view or PVC

view Enter PVC view pvc vpi/vci

—

Set the FIFO queue size qos fifo queue-length queue-length Required

75 by default

For the queuing function to take effect on Tunnel interfaces, sub-interfaces, or VT/dialer interfaces using PPPoE, PPPoA, PPPoEoA, or PPPoFR at the data link layer, you must enable line rate on them.

FIFO Configuration Example

# Set the FIFO queue size to 100. <Sysname> system-view

[Sysname] interface ethernet1/1

[Sysname-Ethernet1/1] qos fifo queue-length 100

Configuring PQ

You can define multiple rules for a priority queue list (PQL) and apply the list to an interface or PVC. When a packet arrives at the interface or PVC, the system matches the packet with each rule in the order configured. If a match is found, the packet is assigned to the corresponding queue and the match procedure is complete. If the packet cannot match any rule, the packet is assigned to the default queue normal.

PQ Configuration Procedure

Apply a PQ list to an interface or PVC. For an interface or PVC, a newly applied PQ list overwrites the previous one.

Follow these steps to configure PQ:


4-9



Configure a PQ list

qos pql pql-index protocol ip [ queue-key

key-value ] queue { bottom | middle | normal

| top }

or

qos pql pql-index inbound-interface

interface-type interface-number queue

{ bottom | middle | normal | top }

Required

Use either command.

Specify the default queue for the

PQ list

qos pql pql-index default-queue { bottom | middle | normal | top }

Optional

This command specifies

the queue to which

unmatched packets are

assigned.

Set the queue size qos pql pql-index queue { bottom | middle |

normal | top } queue-length queue-length Optional

Enter

interface view interface interface-type interface-number


Enter interface

view or PVC

view Enter PVC

view pvc vpi/vci

—

Apply the PQ list to the interface qos pq pql pql-index Required

FIFO applies by default

Display PQ list configuration

information

display qos pq interface [ interface-type

interface-number ] [ pvc { pvc-name [ vpi/vci ] |

vpi/vci } ]

Optional


Display the contents of the

specific PQ list or all the PQ lists display qos pql [ pql-number ]

Optional


PQ is applicable to all physical interfaces except interfaces using the X.25 or LAPB protocol at the data link layer.


4-10

PQ Configuration Example

Network requirements As shown in the figure below, both Server and Host A send data to Host B through Router A. Suppose Server sends critical packets and Host A sends non-critical packets. Congestion may occur on Serial 1/1 and result in packet loss because the rate of the incoming interface Ethernet 1/1 is greater than that of the outgoing interface Serial 1/1 on Router A. It is required that the critical packets from Server be transmitted preferentially when congestion occurs in the network.

Figure 4-6 Network diagram for PQ


Configure Router A:

# Configure ACLs to match the packets from Server and Host A respectively. [RouterA] acl number 2001

[RouterA-acl-basic-2001] rule permit source 1.1.1.1 0.0.0.0

[RouterA] acl number 2002

[RouterA-acl-basic-2002] rule permit source 1.1.1.2 0.0.0.0

# Configure a PQ list that assigns the packets from Server to the top queue and those from Host A to the bottom queue when congestion occurs. The maximum queue size of the top queue is set to 50 while that of the bottom queue is set to 100. [RouterA] qos pql 1 protocol ip acl 2001 queue top

[RouterA] qos pql 1 protocol ip acl 2002 queue bottom

[RouterA] qos pql 1 queue top queue-length 50

[RouterA] qos pql 1 queue bottom queue-length 100

# Apply PQ list 1 to Serial 1/1. [RouterA] interface serial 1/1

[RouterA-Serial1/1] qos pq pql 1

Configuring CQ

You can configure a CQ list that contains up to 16 queues (1-16), with each queue including the match criteria for packets to enter the queue, the length of the queue and the bytes sent from the queue during a cycle of round robin queue scheduling. Only one CQ list can be applied to an interface or PVC.

4-11

Configuration Procedure

Follow these steps to configure CQ:



Configure a CQ list

qos cql cql-index protocol ip [ queue-key

key-value ] queue queue-number

or

qos cql cql-index inbound-interface

interface-type interface-number queue

queue-number

Optional

Use either command.

Specify the default queue qos cql cql-index default-queue

queue-number

Optional

This command specifies

the queue to which

unmatched packets are

assigned.

Set the length of a queue qos cql cql-index queue queue-number

queue-length queue-length Optional

Configure the bytes sent from a

queue during a cycle of round

robin queue scheduling

qos cql cql-index queue queue-number

serving byte-count Optional

Enter interface



Enter interface

view or PVC


—

Apply the CQ list to the interface or

PVC qos cq cql cql-index

Required

FIFO applies by default.

Display interface/PVC CQ list


display qos cq interface [ interface-type

interface-number ] [ pvc { pvc-name

[ vpi/vci ] | vpi/vci } ]

Optional


Display information about CQ lists display qos cql Optional


4-12

CQ is applicable to all physical interfaces except interfaces using X.25 or LAPB protocol at the data link layer.


CQ Configuration Example

Network requirements Configure CQ to assign packets from Ethernet 1/1 to queue 1 and specify queue 1 to send 2000 bytes during a cycle of round robin queue scheduling.

Configuration procedure # Enter system view. <Sysname> system-view

# Configure CQ list 1. [Sysname] qos cql 1 inbound-interface ethernet 1/1 queue 1

[Sysname] qos cql 1 queue 1 serving 2000

# Apply CQ list 1 to Serial 1/0. [Sysname] interface serial 1/0

[Sysname-Serial 1/0] qos cq cql 1

Configuring WFQ


On an interface/PVC without WFQ configured, the qos wfq command can be used to enable WFQ and configure WFQ-related parameters. If WFQ is configured for the interface/PVC, the qos wfq command can be used to modify the WFQ-related parameters.

Follow these steps to configure WFQ:



Enter interface



Enter interface

view Enter PVC view

pvc vpi/vci

—

Configure WFQ

qos wfq [ precedence | dscp ] [ queue-length max-queue-length

[ queue-number total-queue-number ] ]

Required

FIFO applies by default

Display interface/PVC WFQ


display qos wfq interface [ interface-type

interface-number ] [ pvc { pvc-name [ vpi/vci ]

| vpi/vci } ]

Optional


4-13

WFQ is applicable to all physical interfaces except interfaces using X.25 or LAPB at the data link layer.


WFQ Configuration Example

Network requirements Configure WFQ on Serial 2/0, setting the maximum queue size to 100, and the total number of queues to 512.


# Enter interface view. [Sysname] interface serial 2/0

# Configure WFQ on Serial 2/0, setting the maximum queue size to 100, and the total number of queues to 512. [Sysname-Serial2/0] qos wfq queue-length 100 queue-number 512

Configuring CBQ

Follow these steps to configured CBQ:

1) Create a class and define a set of traffic match criteria in class view.

2) Create a traffic behavior, and define a group of QoS features in traffic behavior view.

3) Create a policy, and associate a traffic behavior with a class in policy view.

4) Apply the QoS policy in the interface or PVC view.

The system pre-defines some classes, traffic behaviors and policies. The detailed description is given below.

Pre-defined classes The system pre-defines some classes and defines general rules for them. You can use these pre-defined classes when defining a policy.

The default class

default-class: Matches the default traffic.

DSCP-based pre-defined classes

ef, af1, af2, af3, af4: Matches IP DSCP value ef, af1, af2, af3, af4 respectively.

IP precedence-based pre-defined classes

ip-prec0, ip-prec1, …ip-prec7: Matches IP precedence value 0, 1, …7 respectively.

MPLS EXP-based pre-defined classes

mpls-exp0, mpls-exp1, …mpls-exp7: Matches MPLS EXP value 0, 1, …7 respectively.

4-14

Pre-defined traffic behaviors The system pre-defines some traffic behaviors and defines QoS features for them.

ef: Assigns a class of packets to the EF queue and assigns 20% of the available interface/PVC bandwidth to the class of packets.

af: Assigns a class of packets to the AF queue and assigns 20% of the available interface/PVC bandwidth to the class of packets.

be: Defines no features.

Pre-defined QoS policy The system pre-defines a QoS policy, specifies a pre-defined class for the policy and associates a pre-defined behavior with the class. The policy is named default, with the default CBQ action.

The policy default is defined as follows:

Associates the pre-defined class ef with the pre-defined traffic behavior ef.

Associates pre-defined classes af1 through af4 with the pre-defined traffic behavior af.

Associates the pre-defined class default-class with the pre-defined traffic behavior be.

Configuring the Maximum Available Interface Bandwidth

Configuration procedure The maximum available interface bandwidth refers to the maximum interface bandwidth used for bandwidth check when CBQ enqueues packets, rather than the actual bandwidth of the physical interface.

Follow these steps to configure the maximum interface available bandwidth:



Enter interface view interface interface-type interface-number —

Configure the maximum available

interface bandwidth qos max-bandwidth bandwidth Required

If no maximum available interface bandwidth is configured for any type of interfaces, the bandwidth used in CBQ calculation is as follows:

The actual baudrate or rate of a physical interface.

Total bandwidth of the bound logical serial interfaces, such as T1/E1 interfaces and multilink frame relay (MFR) interfaces.

1000000 kbps for template interfaces such as VT, dialer, BRI, and PRI interfaces.

0 kbps for the other virtual interfaces such as tunnel interfaces.

4-15

You are recommended to configure the maximum available interface bandwidth to be smaller than the actual available bandwidth of a physical interface or logical link.

On a primary channel interface (such as VT, dialer, BRI, or PRI) configured with the qos max-bandwidth command, AF and EF perform queue bandwidth check and calculation based on the bandwidth specified with the qos max-bandwidth command. The same is true of AF and EF synchronized to the sub-channel interfaces (such as VA interfaces or B channels), where sub-channel interface bandwidth is ignored. As the QoS configurations of the primary channel interface and the sub-channel interfaces are the same in this case, prompts are output only for the primary channel interface. If the qos max-bandwidth command is not configured, AF and EF on the primary channel interface calculate queue bandwidth based on 1 Gbps of bandwidth, while AF and EF synchronized to the sub-channel interfaces calculate queue bandwidth based on actual sub-channel interface bandwidth. In this case, if queuing on a sub-channel interface fails due to bandwidth change, the prompt will be output for the sub-channel interface.

On an MP-group interface or MFR interface configured with the qos max-bandwidth command, AF and EF perform queue bandwidth check and calculation based on the bandwidth specified with the qos max-bandwidth command. On an MP-group interface or MFR interface without the qos max-bandwidth command configured, if the sum of sub-channel bandwidth equals to or exceeds the sum of AF bandwidth and EF bandwidth, AF and EF calculate bandwidth based on the actual interface bandwidth; otherwise, AF and EF calculate bandwidth based on 1 Gbps of bandwidth, and the message indicating insufficient bandwidth is displayed. In the latter case, the queuing function may fail to take effect. You can use the qos reserved-bandwidth command to set the maximum percentage of the reserved bandwidth to the available bandwidth.

On Tunnel interfaces, sub-interfaces, or VT/dialer interfaces using PPPoE, PPPoA, PPPoEoA, or PPPoFR at the data link layer, you should configure the qos max-bandwidth command to provide base bandwidth for CBQ bandwidth calculation.

Maximum available interface bandwidth configuration example

1) Network requirements

Set the maximum available interface bandwidth to 60 kbps.

2) Configuration procedure



# Set the maximum available bandwidth of Ethernet 1/1 to 60 kbps. [Sysname-Ethernet1/1] qos max-bandwidth 60

Defining a Class

To define a class, you need to create the class with a name specified and then configure matching criteria in class view.

Configuration procedure Follow these steps to define a class:

4-16



Create a class and enter

class view

traffic classifier tcl-name [ operator

{ and | or } ]

Required

By default, the and keyword is used.

That is, the relation between matching

criteria is logic AND.

Define a match criterion if-match [ not ] match-criteria Required

Display class information

display traffic classifier { system-defined | user-defined }

[ tcl-name ]

Optional


Configuration example

1) Network requirements

Define a class named test to match packets having an IP precedence value of 6.



# Define a class and enter class view. [Sysname] traffic classifier test

# Define the match criterion. [Sysname-classifier-test] if-match ip-precedence 6

Defining a Traffic Behavior

To define a traffic behavior, you should first create the traffic behavior with a name specified and then configure attributes for it in traffic behavior view.

Configuration procedure 1) Configure AF and the minimum guaranteed bandwidth

Follow these steps to configure AF and the minimum available bandwidth:



Create a traffic behavior and enter

traffic behavior view traffic behavior behavior-name

Required

The entered

behavior-name cannot be

the name of a traffic

behavior pre-defined by

the system.

Configure AF and the minimum

guaranteed bandwidth

queue af bandwidth { bandwidth | pct percentage }

Required



display traffic behavior { system-defined

| user-defined } [ behavior-name ]

Optional


4-17

This traffic behavior can be applied only in the outbound direction of an interface or ATM PVC.

In the same traffic behavior, the same bandwidth unit must be used to configure the queue ef command and the queue af command, either bandwidth or percentage.

2) Configuring EF and the maximum bandwidth

Follow these steps to configure EF and the maximum bandwidth:




enter traffic behavior view traffic behavior behavior-name

Required

The entered traffic behavior name

cannot be the name of a traffic

behavior pre-defined by the

system.

Configure EF and the

maximum bandwidth

queue ef bandwidth { bandwidth

[ cbs burst ] | pct percentage

[ cbs-ratio ratio] }

Required



display traffic behavior

{ system-defined | user-defined } [ behavior-name ]

Optional


The queue ef command can not be used in conjunction with the commands queue af, queue-length, and wred for the same traffic behavior.

The default class cannot be associated with a traffic behavior including EF.

In the same traffic behavior, the same bandwidth unit must be used to configure the queue ef command and the queue af command, either bandwidth or percentage.

3) Configuring WFQ

Follow these steps to configure WFQ:



4-18




Required




system.

Configure WFQ queue wfq [ queue-number total-queue-number ]

Required





Optional


A traffic behavior with WFQ applied can only be associated with the default class.

4) Configuring the maximum queue size

Configure the maximum queue size and adopt tail drop.

Follow these steps to configure the maximum queue size:





Required

The entered traffic behavior

name cannot be the name of a

traffic behavior pre-defined by

the system.

Set the maximum queue size queue-length queue-length Required





Optional


The queue-length command can be used only after the queue af command or the queue wfq command has been configured. Executing the undo queue af command or the undo queue wfq command cancels the queue-length command configuration as well.

5) Adopting WRED drop

Follow these steps to adopt WRED drop:

4-19





Required

The entered traffic behavior name cannot

be the name of a traffic behavior

pre-defined by the system.

Adopt WRED drop wred [ dscp | ip-precedence ]

Required

dscp: Uses the DSCP precedence value

for calculating drop probability for a

packet.

ip-precedence: Uses the IP precedence

value for calculating drop probability for a

packet. This keyword is adopted by

default.




{ system-defined |

user-defined } [ behavior-name ]

Optional


The wred [ dscp | ip-precedence ] command must be issued after the queue af command or the queue wfq command is used.

The wred command and the queue-length command are mutually exclusive.

If the WRED drop configuration is removed, other configurations under it are deleted.

When a QoS policy including the WRED traffic behavior is applied to an interface, the previous interface-level WRED configuration gets invalid.

6) Configuring the exponent for WRED to calculate average queue size

Follow these steps to configure the exponent for WRED to calculate average queue size:





Required




system.

Configure the exponent for WRED

to calculate average queue size

wred weighting-constant exponent

Required

The default exponent is 9.

4-20






Optional


Before configuring the wred weighting-constant command, make sure the queue af command or the queue wfq command has been configured and the wred command has been used to enable WRED drop.

7) Configuring the lower limit, upper limit and drop probability denominator for each DSCP value in WRED

To perform this configuration, make sure DSCP-based WRED drop has been enabled with the wred dscp command.

Follow these steps to configure the lower limit, upper limit, and drop probability denominator for a DSCP value in WRED:





Required


name cannot be the name of a

traffic behavior pre-defined by

the system.

Configure the lower limit, upper

limit and drop probability

denominator for a DSCP value in

WRED

wred dscp dscp-value low-limit

low-limit high-limit high-limit

[ discard-probability discard-prob ]

Required





Optional


dscp-value: DSCP value in the range of 0 to 63, which can also be any of the following keywords: ef, af11, af12, af13, af21, af22, af23, af31, af32, af33, af41, af42, af43, cs1, cs2, cs3, cs4, cs5, cs6, cs7, and default.

4-21

When the wred command is disabled, the wred dscp command is also disabled.

The WRED drop-related parameters are disabled if the queue af command or the queue wfq command is disabled.

8) Configuring the lower limit, upper limit and drop probability denominator for each IP precedence value in WRED

To perform this configuration, make sure IP precedence-based WRED drop has been enabled with the wred ip-precedence command.

Follow these steps to configure the lower limit, upper limit, and drop probability denominator for an IP precedence value in WRED:





Required


name cannot be the name of

a traffic behavior pre-defined

by the system.

Configure the lower limit, upper

limit and drop probability

denominator for an IP precedence

value in WRED

wred ip-precedence precedence low-limit low-limit high-limit high-limit


Required





Optional


The wred ip-precedence command is disabled when the wred command is disabled.

The WRED drop-related parameters are disabled if the queue af command or the queue wfq command is disabled.

Configuration procedure 1) Network requirements

Define traffic behavior test, enabling AF and setting the minimum guaranteed bandwidth to 200 kbps.



# Define traffic and enter traffic behavior view. [Sysname] traffic behavior test

4-22

# Enable AF and set the minimum guaranteed bandwidth to 200 kbps. [Sysname-behavior-test] queue af bandwidth 200

Defining a QoS Policy

A QoS policy associates a class with a traffic behavior, which contains multiple QoS actions, include queue scheduling, EF, AF, WFQ, traffic policing, GTS, WRED, traffic marking, and so on.

Follow these steps to associate a traffic behavior with a specific class in policy view:



Create a policy and enter

policy view qos policy policy-name —

Associate a traffic behavior

with a class in the policy

classifier tcl-name behavior behavior-name

Required

tcl-name: Class name. It must be the

name of an existing system-defined or

user-defined class.

behavior-name: Name of a behavior. It

must be the name of an existing

system-defined or user-defined

behavior.

Display QoS policy


display qos policy

{ system-defined | user-defined }

[ policy-name [ classifier tcl-name ] ]

Optional



Configuration procedure Use the qos apply policy command to apply a policy to a specific physical interface or ATM PVC. A policy can be applied to multiple physical interfaces or ATM PVCs.

Follow these steps to apply a policy to the specific interface or ATM PVC:



Enter

interface

view


interface-number

Enter port



Enter

interface

view, port

group view,

or PVC view Enter PVC

view pvc vpi/vci

Use either command




effect on all ports in the port group;

settings in PVC view take effect on

the current PVC.

4-23


Apply a policy to the

interface or PVC



Display interface/PVC policy


display qos policy interface [ interface-type interface-number

[ inbound | outbound ] [ pvc

{ pvc-name [ vpi/vci ] | vpi/vci } ]

Optional


Specifications for applying QoS policies are as follows:

A policy configured with any features (including remark, car, gts, queue af, queue ef, queue wfq, wred) is applicable to common physical interfaces and the VTs referenced by MPs.

A policy configured with GTS or queuing (queue ef, queue af, queue wfq) features cannot be applied in the inbound direction of an incoming interface.

For the queuing function to take effect on Tunnel interfaces, sub-interfaces, or VT/dialer interfaces using PPPoE, PPPoA, PPPoEoA, or PPPoFR at the data link layer, you must enable line rate on them. At the same time, you should configure the qos max-bandwidth command to provide base bandwidth for CBQ bandwidth calculation.

Configuration example 1) Network requirements

Create a policy named test. Associate the traffic behavior test_behavior with the traffic class test_class in the policy, and apply the policy in the inbound direction of Ethernet 1/1.



# Create the policy and enter policy view [Sysname] qos policy test

# Associate the traffic behavior with the class. [Sysname-qospolicy-test] classifier test_class behavior test_behavior

[Sysname-qospolicy-test] quit


# Apply the policy to Ethernet 1/1. [Sysname-Ethernet1/1] qos apply policy test inbound

CBQ Configuration Example

Network requirements As shown in Figure 4-7, traffic travels from Router C to Router D through Router A and Router B. Configure a QoS policy to meet the following requirements:

Traffic from Router C is classified into three classes based on DSCP precedence; perform AF for traffic with the DSCP precedence being AF11 and AF21 and set a minimum guaranteed bandwidth percentage of 5% for the traffic.

Perform EF for traffic with the DSCP precedence being EF and set the maximum bandwidth percentage for the traffic to 30%.

Before performing the configuration, make sure that:

4-24

The route from Router C to Router D through Router A and Router B is reachable.

The DSCP fields have been set for the traffic before the traffic enters Router A.

Figure 4-7 Network diagram for CBQ configuration


Configure Router A:

# Define three classes to match the IP packets with the DSCP precedence AF11, AF21 and EF respectively. [RouterA] traffic classifier af11_class

[RouterA-classifier-af11_class] if-match dscp af11

[RouterA-classifier-af11_class] quit

[RouterA]traffic classifier af21

[RouterA-classifier-af21] if-match dscp af21

[RouterA-classifier-af21] quit

[RouterA] traffic classifier ef_class

[RouterA-classifier-ef_class] if-match dscp ef

[RouterA-classifier-ef_class] quit

# Define two traffic behaviors, enable AF and set a minimum guaranteed bandwidth percentage of 5%. [RouterA] traffic behavior af11_behav

[RouterA-behavior-af11_behav] queue af bandwidth pct 5

[RouterA-behavior-af11_behav] quit

[RouterA] traffic behavior af21_behav

[RouterA-behavior-af21_behav] queue af bandwidth pct 5

[RouterA-behavior-af21_behav] quit

# Define a traffic behavior, enable EF and set a maximum bandwidth percentage of 30% (both bandwidth and delay guarantees are provided). [RouterA] traffic behavior ef_behav

[RouterA-behavior-ef_behav] queue ef bandwidth pct 30

[RouterA-behavior-ef_behav] quit

# Define a QoS policy to associate the configured traffic behaviors with classes respectively. [RouterA] qos policy dscp

[RouterA-qospolicy-dscp] classifier af11_class behavior af11_behav

[RouterA-qospolicy-dscp] classifier af21_class behavior af21_behav

[RouterA-qospolicy-dscp] classifier ef_class behavior ef_behav

[RouterA-qospolicy-dscp] quit

# Apply the QoS policy in the outbound direction of an ATM PVC of Router A. [RouterA] interface atm 1/0

[RouterA-atm1/0] ip address 1.1.1.1 255.255.255.0

[RouterA-atm1/0] pvc qostest 0/40

4-25

[RouterA-atm-pvc-atm1/0-0/40-qostest] qos apply policy dscp outbound

With the above configurations complete, EF traffic is forwarded preferentially when congestion occurs.

Displaying and Maintaining CBQ

To do… Use the command…

Display class configuration

information

display traffic classifier { system-defined | user-defined } [ tcl-name ]

Display traffic behavior configuration

information

display traffic behavior { system-defined | user-defined } [ behavior-name ]

Display QoS policy configuration

information

display qos policy { system-defined | user-defined } [ policy-name

[ classifier tcl-name ] ]

Display interface/PVC QoS policy


display qos policy interface [ interface-type interface-number ]

[ inbound | outbound ] [ pvc { pvc-name [ vpi/vci ] | vpi/vci } ]

Display interface/PVC CBQ


display qos cbq interface [ interface-type interface-number ] [ pvc


Configuring RTP Priority Queuing


Follow these steps to configure RTP priority queuing:



Enter interface



Enter interface

view or PVC


—

Configure RTP priority queuing

qos rtpq start-port first-rtp-port-number

end-port last-rtp-port-number bandwidth

bandwidth [ cbs cbs ]

Required

Set the maximum percentage of

the available interface bandwidth

to be reserved for the RTP priority

queue

qos reserved-bandwidth pct percent Optional

80 by default

Display RTP priority queuing

configuration information on the

interface/PVC or all

interfaces/PVCs

display qos rtpq interface [ interface-type

interface-number ] [ pvc { pvc-name

[ vpi/vci ] | vpi/vci } ]

Optional


4-26


RTP Priority Queuing Configuration Example

Network requirements Configure RTP priority queuing on an interface, and specify up to 70% of the available interface bandwidth to be reserved for the RTP priority queue.

Configure RTP priority queuing on Serial 1/0: the start port number is 16384, the end port number is 32767, and 64 kbps bandwidth is reserved for RTP packets. When congestion occurs to the outgoing interface, RTP packets are assigned to the RTP priority queue.



# Specify up to 70% of the available bandwidth to be reserved for the RTP priority queue. [Sysname-Serial1/0] qos reserved-bandwidth pct 70

# Configure RTP priority queuing on Serial 1/0: the start port number is 16384, the end port number is 32767, and 64 kbps of bandwidth is reserved for RTP packets. When congestion occurs to the outgoing interface, RTP packets are assigned to the RTP priority queue. [Sysname-Serial1/0] qos rtpq start-port 16384 end-port 32767 bandwidth 64

Configuring QoS Tokens

QoS Token Configuration Procedure

Since the upper layer protocol TCP provides traffic control, CQ and WFQ may become invalid during FTP transmission. QoS tokens are used to solve this problem. The token feature of QoS provides a flow control mechanism for underlying-layer queues. This feature can control the number of packets sent to the interface underlying-layer queues based on the number of tokens.

You are recommended to set the token number to 1 on an interface for FTP transmission.

If the upper layer protocol, UDP for example, does not provide flow control, you are recommended not to use the QoS token function in order to improve data transmission efficiency.

Follow these steps to configure QoS tokens:




Specify the number of QoS

tokens qos qmtoken token-number

Required

The QoS token feature is

disabled by default.

4-27

To validate the above configuration, you must execute the shutdown command and then the undo shutdown command on the interface.

So far, this feature is available only for serial interfaces and BRI interfaces.

QoS Token Configuration Example

Network requirements Specify the number of QoS tokens on an interface.



# Set the number of QoS tokens to 1. [Sysname-Serial2/0] qos qmtoken 1

Configuring Packet Information Pre-Extraction


The packets that a tunnel interface passes to a physical interface are encapsulated in GRE. Thus, the IP data (including Layer-3 and Layer-4 information) that the QoS module obtains from the physical interface is the IP data encapsulated in GRE rather than the IP data in the original packets.

To address the problem, you can configure packet information pre-extraction on the tunnel interface to buffer the IP data in the original packets for its corresponding physical interface to use.

Follow these steps to configure packet information pre-extraction:



Enter tunnel interface view interface tunnel interface-number —

Enable packet information

pre-extraction qos pre-classify

Required

Disabled by default

Configuration Example

Network requirements Enable packet information pre-extraction on a tunnel interface.

Configuration procedure # Enable packet information pre-extraction on tunnel interface Tunnel 0. <Sysname> system-view

[Sysname] interface tunnel 0

4-28

[Sysname-Tunnel0] qos pre-classify

Configuring Local Fragment Pre-drop


If the packet size is bigger than the MTU of the egress interface, the packet is fragmented into local fragments. If the first fragment is dropped, the subsequent fragments become invalid fragments, and therefore it is insignificant to process and transmit these invalid fragments.

With local fragment pre-drop, if the first fragment of a packet is dropped by the QoS module, the subsequent fragments will be dropped directly without undergoing QoS processing. The local fragment pre-drop function thus improves the local fragment processing and transmitting efficiency, and reduces subsequent invalid fragments’ occupation of system resources and network bandwidth.

Local fragment pre-drop is mutually exclusive with matching fragments by fragment attributes or size. With local fragment pre-drop enabled, non-first fragments inherit the matching result of the first fragment.

Local fragment pre-drop applies to IPv4 and IPv6 local fragments.

Follow these steps to configure local fragment pre-drop:




Enable local fragment

pre-drop qos fragment pre-drop

Required

Disabled by default



Enable local fragment pre-drop on an interface.

Configuration procedure # Enable local fragment pre-drop on interface Serial 2/0. <Sysname> system-view

[Sysname] interface serial 2/0

[Sysname-Serial2/0] qos fragment pre-drop

5-1

5 Priority Mapping Configuration

When configuring priority mapping, go to these sections for information you are interested in:

Priority Mapping Overview

Configuring a Priority Mapping Table

Configuring the Trusted Precedence Type for a Port

Displaying and Maintaining Priority Mapping

Priority Mapping Configuration Examples

Priority Mapping Overview

When a packet enters a device, the device assigns to the packet a series of predefined parameters (including 802.11e precedence, 802.1p precedence, DSCP precedence, EXP precedence, IP precedence, local precedence, and drop precedence).

The local precedence and drop precedence are defined as follows:

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.

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.

The device provides two priority trust modes on a port:

Trust packet priority: the device assigns to the packet the priority parameters corresponding to the packet’s priority from the mapping table.

Trust port priority: the device assigns a priority to a packet by mapping the priority of the receiving port.

You can select one priority trust mode as needed. Figure 5-1 shows the process of priority mapping on a device.

Figure 5-1 Priority mapping process

5-2

The device provides the dot1p-lp priority mapping table, that is, 802.1p-priority-to-local-precedence mapping table. The following tables list the default priority mapping tables.

Table 5-1 The default lp-dot1p mappings

Input priority value lp-dot1p mapping

Local precedence (lp) 802.1p precedence (dot1p)

0 1

1 2

2 0

3 3

4 4

5 5

6 6

7 7

Table 5-2 Port-priority-to-local-precedence mappings

Port priority Local precedence

0 0

1 1

2 2

3 3

4 4

5 5

6 6

7 7

Table 5-3 Local-precedence-to-queue mappings

Local precedence Queue

0 1

1 0

2 1

3 0

4 2

5-3

Local precedence Queue

5 2

6 3

7 3

Configuring a Priority Mapping Table

You can modify the priority mapping tables of a device as needed.


You need to decide on the new mapping values.


Follow these steps to configure a priority mapping table:



Enter priority mapping table

view qos map-table dot1p-lp

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-lp

Optional




Configure a dot1p-lp mapping table as shown below.

Table 5-4 dot1p-lp mappings

802.1p precedence Local precedence

0 0

1 0

2 1

3 1

4 2

5-4


5 2

6 3

7 3


# Enter the inbound dot1p-lp priority mapping table view. [Sysname] qos map-table inbound dot1p-lp

# Modify dot1p-lp priority mapping parameters. [Sysname-maptbl-in-dot1p-lp] import 0 1 export 0

[Sysname-maptbl-in-dot1p-lp] import 2 3 export 1



Configuring the Priority for a Port

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:



Enter interface

view


interface-number Enter

interface

view or

port group

view

Enter port

group view


Use either command

Settings in interface view (Ethernet or

WLAN-ESS) take effect on the current

interface; settings in port group view

take effect on all ports in the port group.

Configure a priority for the

port

If the device supports only one port

priority type, use qos priority priority-value

Required

Given the device supporting only one

port priority type, the default port priority

is 0.

5-5

If a WLAN-ESS interface in use has WLAN-DBSS interfaces created, its priority cannot be modified. To modify the priority of the WLAN-ESS interface, you must stop the service the interface provides (that is, make the current users on the interface offline).


Network requirements Set the priority of the port to 7.


# Set the priority of Ethernet 1/1 to 7. [Sysname] interface ethernet 1/1

[Sysname-Ethernet1/1] qos priority 7

Configuring the Trusted Precedence Type for a Port

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 dot1p for a port. This trusted precedence type trusts the 802.1p precedence of the received packets and uses the 802.1p precedence for mapping.


It is determined to trust port priority.

The trusted precedence type for the port is determined.

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:



Enter interface

view



interface

view or port

group view Enter port group

view port-group manual port-group-name

Use either command

Settings in interface view

(Ethernet or WLAN-ESS) take



effect on all ports in the port

group.

5-6


Configure the trusted

precedence type qos trust dot1p

Required

The default trusted precedence

type varies by device.

Display the trusted precedence

type configuration

display qos trust interface

[ interface-type interface-number ]

Optional



Network requirements Configure the port to trust the 802.1p precedence.


# Enter port view. [Sysname] interface ethernet 1/1

# Configure the port to trust the 802.1p precedence. [Sysname-Ethernet1/1] qos trust dot1p

Displaying and Maintaining Priority Mapping


Display priority mapping table

configuration information display qos map-table [ dot1p-lp ] Available in any view

Display the trusted precedence type on

the port

display qos trust interface

[ interface-type interface-number ] Available in any view

Priority Mapping Configuration Examples

Example 1

Network requirements It is required that Router enqueue packets based on the 802.1p precedence of packets.

The priority mapping table is user-defined, as shown in the table below.

Table 5-5 dot1p-lp mappings


0 0

1 0

2 1

3 1

5-7


4 2

5 2

6 3

7 3

Figure 5-2 Network diagram for trusted precedence type configuration

Eth1/1Eth1/2

Eth1/3 Eth1/4

Router

Server

Server

Configuration procedure # 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] quit

# Configure Ethernet 1/1 to trust the 802.1p precedence. [Switch] interface ethernet 1/1

[Switch-Ethernet1/1] qos trust dot1p

[Switch-Ethernet1/1] quit








5-8


Example 2

Network requirements The router assigns local precedences for packets according to the mappings between precedence and interface. The precedences of Ethernet 1/1, Ethernet 1/2, Ethernet 1/3, and Ethernet 1/4 are 1, 3, 5, and 7, respectively.

The default priority mapping table is adopted.

Figure 5-3 Network diagram for trusted precedence type configuration

Eth1/1Eth1/2

Eth1/3 Eth1/4

Router

Server

Server

Configuration procedure # Enter system view. <Switch> system-view

# Set the priority of Ethernet 1/1 to 1. [Switch] interface ethernet 1/1

[Switch-Ethernet1/1] qos priority 1










6-1

6 Congestion Avoidance

When configuring congestion avoidance, go to these sections for information you are interested in:

Congestion Avoidance Overview

Introduction to WRED Configuration

Configuring WRED on an Interface

Applying a WRED Table on an Interface

Displaying and Maintaining WRED

WRED Configuration Example

Congestion Avoidance Overview

Serious congestion causes great damages to the network resources, and therefore some measures must be taken to avoid such congestion. As a flow control mechanism, congestion avoidance can actively drop packets when congestion deteriorates through monitoring the utilization of network resources (such as queues or memory buffers) to prevent network overload.

Compared to point-to-point flow control, this flow control mechanism is of broader sense because it can control the load of more flows in a device. When dropping packets from a source end, it can still cooperate well with the flow control mechanism (such as TCP flow control) at the source end to better adjust the network traffic to a reasonable load status. The combination of the packet drop policy of the local device and the flow control mechanism at the source end can maximize throughput and utilization rate of the network and minimize packet loss and delay.

Traditional packet drop policy The traditional packet drop policy is tail drop. When the length of a queue reaches the maximum threshold, all the subsequent packets are dropped.

Such a policy results in global TCP synchronization. That is, if packets from multiple TCP connections are dropped, these TCP connections go into the state of congestion avoidance and slow start to reduce traffic, but traffic peak occurs later. Consequently, the network traffic jitters all the time.

RED and WRED

You can use random early detection (RED) or weighted random early detection (WRED) to avoid global TCP synchronization.

The RED or WRED algorithm sets an upper threshold and lower threshold for each queue, and processes the packets in a queue as follows:

When the queue size is shorter than the lower threshold, no packet is dropped;

When the queue size reaches the upper threshold, all subsequent packets are dropped;

When the queue size is between the lower threshold and the upper threshold, the received packets are dropped at random. The longer a queue is, the higher the drop probability is. However, a maximum drop probability exists.

Different from RED, WRED determines differentiated drop policies for packets with different IP precedence values. Packets with a lower IP precedence are more likely to be dropped.

Both RED and WRED avoid global TCP synchronization by randomly dropping packets. When the sending rate of a TCP session slows down after its packets are dropped, the other TCP sessions

6-2

remain in high packet sending rates. In this way, some TCP sessions remain in high sending rates in any case, and the link bandwidth can be fully utilized.

Average queue size If the current queue size is compared with the upper threshold and lower threshold to determine the drop policy, bursty traffic is not fairly treated. To solve this problem, WRED compares the average queue size with the upper threshold and lower threshold to determine the drop probability.

The average queue size reflects the queue size change trend but is not sensitive to bursty queue size changes, and thus bursty traffic can be fairly treated. The average queue size is calculated using the formula: average queue size = previous average queue size × (1-2-n) + current queue size × 2-n, where n can be configured with the qos wred weighting-constant command.

With WFQ queuing adopted, you can set the exponent for average queue size calculation, upper threshold, lower threshold, and drop probability for packets with different precedence values respectively to provide differentiated drop policies.

With FIFO queuing, PQ, or CQ adopted, you can set the exponent for average queue size calculation, upper threshold, lower threshold, and drop probability for each queue to provide differentiated drop policies for different classes of packets.

Relation between WRED and queuing mechanism The relation between WRED and queuing mechanism is shown in the following figure:

Figure 6-1 Relationship between WRED and queuing mechanism

Through combining WRED with WFQ, the flow-based WRED can be realized. Because each flow has its own queue after classification, a flow with a smaller queue size has a lower packet drop probability, while a flow with a larger queue size has a higher packet drop probability. In this way, the benefits of the flow with a smaller queue size are protected.

Introduction to WRED Configuration

Configuration Methods

You can configure WRED using one of the following two methods:

Interface configuration: configure WRED parameters on an interface or PVC and enable WRED.

6-3

WRED table configuration: configure a WRED table in system view and then apply the WRED table to an interface.

Support for WRED configuration methods depends on the device model.

Introduction to WRED Parameters

Determine the following parameters before configuring WRED:

The upper threshold and lower threshold: when the average queue size is smaller than the lower threshold, no packet is dropped. When the average queue size is between the lower threshold and the upper threshold, the packets are dropped at random. The longer the queue is, the higher the drop probability is. When the average queue size exceeds the upper threshold, subsequent packets are dropped.

The exponent used for average queue size calculation: a bigger exponent makes the average queue size less sensitive to real-time queue size changes.

Denominator for drop probability calculation: the bigger the denominator is, the smaller the calculated drop probability is.

Configuring WRED on an Interface


The WRED exponent for average queue size calculation is determined (optional).

The upper threshold and lower threshold for the queue corresponding to the precedence is determined (optional).


Follow these steps to configure WRED:



Enter interface

view


interface-number


Enter interface

view or PVC


—

Enable WRED qos wred [ dscp | ip-precedence ]

enable Required

Set the WRED exponent for

average queue size calculation

qos wred weighting-constant exponent

Optional

9 by default

Set the drop-related parameters for

the precedence

qos wred { ip-precedence

ip-precedence | dscp dscp-value }

low-limit low-limit high-limit high-limit

discard-probability discard-prob

Optional

By default, the low-limit is 10,

the high-limit is 30, and the

discard-prob is 10.

6-4


Display WRED configuration

information on the interface/PVC

or all interfaces/PVCs

display qos wred interface

[ interface-type interface-number ] [ pvc


Optional


The qos wred enable command can be configured on a hardware interface without any prerequisites. However, to configure this command on a software interface, make sure that WFQ queuing has been applied on the software interface.


Network requirements Enable IP precedence-based WRED on an interface.

Set the following parameters for packets with IP precedence 3: lower threshold 20, upper threshold 40, and drop probability denominator 15.

Set the exponential factor for the average queue size calculation to 6.



# Enable IP precedence-based WRED. [Sysname-Ethernet1/1] qos wred ip-precedence enable

# Set the following parameters for packets with IP precedence 3: lower threshold 20, upper threshold 40, and drop probability denominator 15. [Sysname-Ethernet1/1] qos wred ip-precedence 3 low-limit 20 high-limit 40 discard-probability 15

# Set the exponential factor for the average queue size calculation to 6. [Sysname-Ethernet1/1] qos wred weighting-constant 6

Applying a WRED Table on an Interface

A WRED table contains global WRED parameters. Currently, queue (Queue-based table) is supported. Packets are dropped based on the queue when congestion occurs.

A queue-based WRED table can only be applied to Layer-2 ports, and only queue-based WRED tables can be applied to Layer 2 ports.

A WRED table can be applied to multiple interfaces. For a WRED table already applied to an interface, you can modify the values of the WRED table, but you cannot remove the WRED table.


The type and values of the WRED table are determined.

Interfaces where the WRED table is to be applied are determined.

6-5


Configuring and applying a queue-based WRED table Follow these steps to configure and apply a queue-based WRED table:



Create a WRED table and

enter its view qos wred queue table table-name —

Configure the other WRED

parameters

queue queue-value low-limit low-limit


Optional

By default, the low-limit is 10

and the discard-prob is 30.

Enter

interface

view


interface

view or port



Use either command





group.

Apply the WRED table to the

interface/port group qos wred apply table-name

Required

A queue-based WRED table is

available on only Layer 2 ports.

Configuring and applying a WRED table of another type (except queue-based WRED table) Follow these steps to configure and apply a WRED table of another type (except queue-based WRED table):



Enter

interface

view


interface

view or port



Use either command





group.

Apply the WRED table to an

interface/port group qos wred apply table-name

Required

WRED tables except

queue-based WRED tables are

applicable on only Layer 3 ports.

Display configuration

information about a WRED

table or all WRED tables

display qos wred table [ table-name ] Optional


6-6

Displaying and Maintaining WRED


Display WRED configuration

information on the interface/PVC or all

interfaces/PVCs

display qos wred interface

[ interface-type interface-number ] [ pvc

{ pvc-name [ vpi/vci ] | vpi/vci } ] Available in any view

Display configuration information

about a WRED table or all WRED

tables

display qos wred table [ table-name ] Available in any view

WRED Configuration Example

Network requirements Apply a queue-based WRED table to a Layer 2 port.

Configuration procedure # Enter system view <Sysname> system-view

# Configure a queue-based WRED table. [Sysname] qos wred queue table queue-table1

[Sysname-wred-table-queue-table1] quit


# Apply the WRED table to Ethernet 1/1. [Sysname-Ethernet1/1] qos wred apply queue-table1

7-1

7 MPLS QoS Configuration

When configuring MPLS QoS, go to these sections for information you are interested in:

MPLS QoS Overview

Configuring MPLS QoS

MPLS QoS Configuration Examples

MPLS QoS Overview

The MPLS-related knowledge is necessary for understanding MPLS QoS. Refer to MPLS Basic Configuration in the MPLS Volume for more information about MPLS.

MPLS QoS provides the following functions:

Classify traffic on the CE or PE as required. For example, MPLS QoS can classify traffic into three classes: voice, video, and data.

When a PE labels a packet, it maps the IP precedence to the EXP field of the label. In this way, the class information carried in the IP header is carried in the label.

Differentiated dispatching (such as PQ, WFQ, or CBQ) is performed between two PEs according to the EXP field to provide differentiated QoS for labeled traffic on an LSP.

The EXP field in an MPLS label is processed as follows:

Any QoS-capable device can reset the EXP field of the outer label.

During label encapsulation, the ToS field of the IP packet is directly changed into the EXP field of the MPLS label.

The EXP field remains unchanged when label swapping is performed.

During a label push operation, the EXP field of the newly pushed outer label inherits the EXP field of the inner label.

After a label pop operation, if the packet is still an MPLS packet, the EXP field of the popped label is not copied to the inner label; if the packet is an IP packet, the EXP field of the popped label is not copied to the ToS field of the IP packet.

7-2

Configuring MPLS QoS

Before configuring MPLS QoS, you need to perform the MPLS related configuration and specify the explicitly routed forwarding. Refer to MPLS Configuration in the MPLS Volume for the detailed MPLS configuration. This chapter introduces only MPLS QoS configuration.

MPLS QoS has the following four types:

MPLS PQ: refer to Configuring MPLS PQ for the configuration procedure.

MPLS CQ: refer to Configuring MPLS CQ for the configuration procedure.

MPLS QoS policy: refer to Configuring a MPLS QoS Policy for the configuration procedure.

MPLS CAR: refer to Configuring MPLS CAR for the configuration procedure.

Configuring MPLS PQ

Configuration prerequisites MPLS related configurations are completed.

The relation between the MPLS PQ list and MPLS EXP value is determined.

The interface to which the PQ list is to be applied is determined.

Configuration procedure Follow these steps to configure MPLS PQ:



Configure a PQ list qos pql pql-index protocol mpls exp exp-value-list queue

{ bottom | middle | normal | top } Required


Apply the PQ list to the

interface qos pq pql pql-index Required

Configuration example Create a classification rule for MPLS-based PQ list 10, assigning packets with an EXP value of 5

to the queue top.

Apply PQ list 10 to Ethernet 1/1.

The configuration procedure is as follows: <Sysname> system-view

[Sysname] qos pql 10 protocol mpls exp 5 queue top


[Sysname-Ethernet1/1] qos pq pql 10

Configuring MPLS CQ


The relation between the MPLS CQ list and MPLS EXP value is determined.

The interface to which the CQ list is to be applied is determined.

7-3

Configuration procedure Follow these steps to configure MPLS CQ:



Configure a EXP based CQ list qos cql cql-index protocol mpls exp

exp-value-list queue queue-number Required


Apply the CQ list to the interface qos cq cql cql-index Required

Configuration example Create a classification rule for MPLS-based CQ list 10, assigning packets with an EXP value of 1

to queue 2.

Apply CQ list 10 to Ethernet 1/1.

The configuration procedure is as follows: <Sysname> system-view

[Sysname] qos cql 10 protocol mpls exp 1 queue 2


[Sysname-Ethernet1/1] qos cq cql 10

Configuring a MPLS QoS Policy


Match criteria are determined.

Traffic behaviors are determined.

The QoS policy is determined.

Interfaces to which the MPLS QoS policy is to be applied are determined.

Configuration procedure Follow these steps to configure a MPLS QoS policy:



traffic classifier tcl-name [ operator

{ and | or } ]

Required

The tcl-name cannot be the name of

any class pre-defined by the system.

By default, the relation between match

criteria is logic and. Define a class

if-match [ not ] mpls-exp

exp-value-list

Required

This rule applies only to MPLS

packets.

Exit the current view quit —

7-4


traffic behavior behavior-name Required Define a traffic behavior

remark mpls-exp exp-value Required


qos policy policy-name Required

Define a QoS policy classifier tcl-name behavior behavior-name

Required

Associate the class with the traffic

behavior in MPLS QoS policy view.


Enter

interface

view



interface

view or port


group view


Use either command



port group view take effect on all ports

in the port group..

Apply the QoS policy to the




Configuring MPLS CAR

Configuration prerequisites

MPLS related configurations are completed.

The MPLS CAR policy is determined.

Interfaces where the MPLS CAR is to be applied are determined.

Configuration procedure Follow these steps to configure MPLS CAR:



Enter

interface

view


interface

view or port



Use either command



settings in port group view

take effect on all ports in the

port group.

7-5


Apply the MPLS CAR policy

to the interface/port group

qos car { inbound | outbound } { any | acl

acl-number | carl carl-index } cir




action ]

Required

The action argument for MPLS can be:

remark-mpls-exp-continue new-exp: Sets the EXP value to new-exp and continues to process the packet using the next CAR policy. The new-exp is in the range of 0 to 7.

remark-mpls-exp-pass new-exp: Sets the EXP value to new-exp and permits the packet to pass through. The new-exp is in the range of 0 to 7.

The EXP field of an MPLS packet can be set only on the incoming interface of a PE. If incoming packets are IP packets and outgoing packets are MPLS packets on the interface, the configured MPS CAR policy is effective.

MPLS QoS Configuration Examples

Configuring QoS for Traffic Within a VPN


As shown in Figure 7-1:

Both CE 1 and CE 2 belong to VPN 1.

The bandwidth of the link between PE 1 and P is 2 M.

The bandwidth of the link between PE 2 and P is 2 M.

It is required to provide differentiated QoS services for flows with different precedence values in VPN 1:

The configuration in this example involves the following two parts:

First, configure MPLS VPN on CE 1, PE 1, P, PE 2, and CE 2 as follows:

Run OSPF between PE 1 and P, and between PE 2 and P.

Form a MP-EBGP neighborship between PE and CE.

Form a MP-IBGP neighborship between PE and PE.

Second, configure MPLS QoS on PE 1 and P as follows:

Configure a QoS policy on the incoming interface Ethernet 1/1 on PE 1 and set the EXP field value for an MPLS packet according to the DSCP attribute of the MPLS packets.

On the device P, classify traffic on the basis of the EXP field and configure flow-based CBQ: guarantee 10% of the bandwidth for traffic with an EXP value of 1; guarantee 20% of the bandwidth for traffic with an EXP value of 2; guarantee 30% of the bandwidth for traffic with an EXP value of 3; guarantee the delay and 40% of the bandwidth for traffic with an EXP value of 4.

7-6

Refer to MPLS Configuration in the MPLS Volume for the MPLS VPN configuration. This section introduces only the MPLS QoS configuration.

Figure 7-1 Network diagram for MPLS QoS

Device Interface IP address Device Interface IP address CE 1 Eth1/2 10.1.1.2/24 CE 2 Eth1/3 10.2.1.2/24 PE 1 Eth1/1 10.1.1.1/24 PE 2 Eth1/2 10.2.1.1/24 S2/1 12.1.1.1/24 S2/2 12.2.1.1/24 Loop0 1.1.1.1/32 Loop0 1.1.1.2/32 P S2/1 12.1.1.2/24 S2/2 12.2.1.2/24

Configuration procedure 1) Configure PE 1

# Define four classes, matching respectively the DSCP values AF11, AF21, AF31 and EF of the MPLS packets in the same VPN. <PE1> system-view

[PE1] traffic classifier af11

[PE1-classifier-af11] if-match dscp af11

[PE1-classifier-af11] traffic classifier af21


[PE1-classifier-af21] traffic classifier af31


[PE1-classifier-af31] traffic classifier efclass

[PE1-classifier-efclass] if-match dscp ef

[PE1-classifier-efclass] quit

# Define four traffic behaviors to set the EXP field value for MPLS packets. [PE1] traffic behavior exp1

[PE1-behavior-exp1] remark mpls-exp 1

[PE1-behavior-exp1] traffic behavior exp2






7-7

[PE1-behavior-exp4] quit

# Define a QoS policy to associate configured traffic behaviors with traffic classes, that is, mark different classes of packets with different EXP values. [PE1] qos policy REMARK

[PE1-qospolicy-REMARK] classifier af11 behavior exp1



[PE1-qospolicy-REMARK] classifier efclass behavior exp4

[PE1-qospolicy-REMARK] quit

# Apply the QoS policy in the inbound direction of the interface of the PE in the MPLS network. [PE1] interface ethernet 1/1

[PE1-Ethernet1/1] qos apply policy REMARK inbound

[PE1-Ethernet1/1] quit

2) Configure P

# Define four classes, matching respectively EXP values 1, 2, 3 and 4 of the MPLS packets. <P> system-view

[P] traffic classifier EXP1

[P-classifier-EXP1] if-match mpls-exp 1

[P-classifier-EXP1] traffic classifier EXP2






[P-classifier-EXP4] quit

# Define traffic behaviors to set respective bandwidth percentages and delays. [P] traffic behavior AF11

[P-behavior-AF11] queue af bandwidth pct 10

[P-behavior-AF11] traffic behavior AF21


[P-behavior-AF21] traffic behavior AF31


[P-behavior-AF31] traffic behavior EF

[P-behavior-EF] queue ef bandwidth pct 40

[P-behavior-EF] quit

# Define a QoS policy that satisfies the following requirements: guarantee 10% of the bandwidth for traffic with an EXP value of 1; guarantee 20% of the bandwidth for traffic with an EXP value of 2; guarantee 30% of the bandwidth for traffic with an EXP value of 3; guarantee the delay and 40% of the bandwidth for traffic with an EXP value of 4. [P] qos policy QUEUE

[P-qospolicy-QUEUE] classifier EXP1 behavior AF11



[P-qospolicy-QUEUE] classifier EXP4 behavior EF

[P-qospolicy-QUEUE] quit

# Apply the QoS policy in the outbound direction of Serial 2/2 on device P. [P] interface serial 2/2

[P-Serial2/2] qos apply policy QUEUE outbound

After the above configuration, when congestion occurs in VPN 1, the bandwidth proportion between flows with the DSCP value being af11, af21, af31, and ef is 1:2:3:4, and the delay for the flow with the DSCP value being ef is smaller than the other traffic flows.

8-1

8 DAR Configuration

When configuring DAR, go to these sections for information you are interested in:

DAR Overview

Configuring DAR

Displaying and Maintaining DAR

DAR Configuration Examples

The DAR feature is only applicable to IP packets.

DAR Overview

Today, the Internet has become the major media for enterprises to implement their ever growing service oriented applications. The simple mechanism that only checks the IP header in packets cannot meet the requirements of current complicated networks any longer. Therefore, the concept of Deeper Application Recognition (DAR) based on service was put forward.

DAR is an intelligent recognition and classification tool that is capable of checking and recognizing the contents and dynamic protocols from Layer 4 to Layer 7 (for example, BT, HTTP, FTP, RTP) in the packets, to distinguish the application-based protocols. This overcomes the disadvantage that the packets can only be classified in a simple way previously.

DAR recognizes different protocols in the following ways:

Protocols such as HTTP, FTP, RTP, RTCP and BitTorrent are recognized by protocol rules. DAR can automatically recognize their dynamic port numbers; match both protocol and data packets.

All other TCP/UDP based protocols are recognized by port number, that is, only protocol packets rather than data packets are matched.

Recognizing and classifying packets deeper help enhance users’ control granularity on data streams and implement high-priority policies for critical service data, thus to better protect users’ investment.

IP Packet

IP packet format The IP packet format is shown in Figure 8-1. An IP header without the option field is 20 bytes in length.

8-2

Figure 8-1 The format and fields of an IP datagram

The protocol field in the header is 8-bit long. The protocol field value indicates the protocol type of the data.

Table 8-1 lists the recognizable protocol field values and corresponding protocols.

Table 8-1 Protocols corresponding to the protocol field values

Protocol field value Protocol

1 ICMP

2 IGMP

4 IPinIP

6 TCP

8 EGP

17 UDP

47 GRE

50 ESP

51 AH

88 EIGRP

Flags field for fragmentation in the IP header Figure 8-2 shows the format of the 3-bit flags in an IP packet.

Figure 8-2 Format of the 3-bit flags

The lower 2 bits of the flags field control IP packet fragmentation. The 3 bits in the flags field are defined as follows:

Reserved: must be 0.

8-3

Do not fragment: 0 indicates that fragmentation is allowed, and 1 indicates that fragmentation is forbidden.

More fragments: 0 indicates that the packet is the last fragment, and 1 indicates that it is not the last fragment.

Therefore, the 3-bit flags field 001 indicates that the IP packet is an IP fragment, and the 3-bit flags field 000 indicates that the IP packet is the last IP fragment.

TCP Packet

TCP packet format Figure 8-3 shows the format of a TCP packet.

Figure 8-3 TCP packet format

Table 8-2 describes the 6 flag bits in the TCP header.

Table 8-2 Description on the 6 flag bits in the TCP header

Flag bit Description

URG The urgent pointer is valid.

ACK The acknowledgement number is valid.

PSH The receiver should pass the data to the application layer as soon as possible.

RST Reset the connection.

SYN Synchronize sequence numbers to initiate a connection

FIN The sender has finished sending data. This field is used to terminate a connection.

TCP state transition Figure 8-4 shows TCP state transition.

8-4

Figure 8-4 TCP state transition diagram

The protocols using TCP can be static or dynamic. Static protocols use fixed port numbers for interaction, while dynamic protocols use negotiated port numbers.

UDP Packet

Figure 8-5 shows the UDP packet format.

Figure 8-5 UDP packet format

Like TCP, protocols employing UDP can be static or dynamic. Static protocols use fixed port numbers for interaction, while dynamic protocols use negotiated port numbers.

HTTP Packet

There are two types of HTTP packets: request packets and response packets. Figure 8-6 shows the HTTP packets format.

Figure 8-6 HTTP packet format

The header of an HTTP request packet consists of a request line and header. The request line consists of the request type field, the URL field, and the HTTP version field separated by spaces.

8-5

The header of an HTTP response packet consists of a status line and header. The status line consists of the HTTP version field, the status code field, and the status phrase field separated by spaces.

Both the request packet headers and the response packet headers consist of several optional fields. The response packet header contains the HOST field, which is used to identify the host name and the port number of the server. The header of a packet with body load contains the Content-Type field, which is used to identify the MIME type of body load.

When the length of an HTTP packet with body load exceeds the maximum segment size (MSS) of TCP, the packet is fragmented.

RTP Packet

A Real-time Transport Protocol (RTP) packet is encapsulated in a UDP packet. Usually a UDP packet carries only one RTP packet.

Figure 8-7 shows the format of a RTP packet.

Figure 8-7 RTP packet format

0 15

Payload

V Sequence Number

31

Time Stamp

P X CC M PT

2 3 8

SSRC

CSRC identifiers……

The fields are described as follows:

V: 2 bits, version number.

P: 1 bit, padding flag.

X: 1 bit, packet header extension flag.

CC: 4 bits, contributor count.

M: 1 bit, special event flag.

PT: 7 bit, payload type flag.

Sequence Number: 16 bits, data packet sequence number.

Time Stamp: 32 bits, time stamp.

SSRC: 32 bits, synchronization source flag.

CSRC list; 32 bits, contributing source flag list. The number of contributing source flags depends on the value of the CC field. The CSRC list field can contain up to 15 contributing source flags.

Payload: packet payload.

RTCP Packet Overview

A Real-time Transport Control Protocol (RTCP) packet is encapsulated in a UDP packet. Usually a UDP packet carries at least two RTP packets, and such a UDP packet is called a compound RTCP packet.

Figure 8-8 shows the format of a RTCP packet.

8-6

Figure 8-8 Compound RTCP packet format

SS

RC

SS

RC

SS

RC

SS

RC

SS

RC

SS

RC

SS

RC

As shown in the above figure, the random 32-bit prefix in the header exists only when the RTCP packet is encrypted. An encrypted RTCP packet no longer has the features of an RTCP packet and therefore requires no special processing. Each packet in the figure represents an RTCP packet, and there is no space between two RTCP packets. The type of the first RTCP packet in a compound RTCP packet must be SR or RR. Figure 8-9 shows the header format of an SR-type RTCP packet.

Figure 8-9 Header format of an SR-type RTCP packet

The fields are described as follows:

V: 2 bits, version number.

P: 1 bits, padding flag.

RC: 5 bits, the number of receiving report blocks in the RTCP packet.

PT: 8 bits, RTCP packet type flag. This field is 200 for SR-type RTCP packets.

Length: 16 bits, length of the RTCP packet.

SSRC of sender: 32 bits, SSRC of the sender.

The structure of the RR-type RTCP packet header is similar to that of the SR-type RTCP packet header, except that the PT field of the RR type is 201.

Static Protocol Overview

Some protocols using TCP and UDP are identified by TCP or UDP port numbers. See the following table for their names and the corresponding port numbers.

Table 8-3 Static port protocols

Protocol name Protocol type Port number

BGP TCP/UDP 179

Citrix TCP 1494

Citrix UDP 1604

CU-SeeMe TCP 7648, 7649

CU-SeeMe UDP 7648, 7649,24032

DHCP/BOOTP UDP 67, 68

8-7


DNS TCP/UDP 53

eDonkey TCP 4662

Exchange TCP 135

Fasttrack TCP 1214

Finger TCP 79

Gnutella TCP 6346,6347,6348,6349,6355,5634

Gopher TCP/UDP 70

H323 TCP 1300,1718,1719,1720,11000 to 11999

H323 UDP 1300 ,1718 ,1719 ,1720 ,11720

IMAP TCP/UDP 143, 220

IRC TCP/UDP 194

Kerberos TCP/UDP 88, 749

L2TP UDP 1701

LDAP TCP/UDP 389

Mgcp TCP 2427, 2428, 2727

Mgcp UDP 2427, 2727

Napster TCP 6699, 8875, 8888, 7777, 6700, 6666, 6677,

6688, 4444, 5555

NetBIOS TCP 137, 138, 139

NetBIOS UDP 137, 138, 139

Netshow TCP 1755

NFS TCP/UDP 2049

NNTP TCP/UDP 119

Notes TCP/UDP 1352

Novadign TCP/UDP 3460,3461,3462,3463,3464,3465

NTP TCP/UDP 123

PCAnywhere TCP 5631, 65301

PCAnywhere UDP 22, 5632

POP3 TCP/UDP 110

Pptp TCP 1723

8-8


Printer TCP/UDP 515

Rcmd TCP 512 ,513 ,514

RIP UDP 520

RSVP UDP 1698, 1699

RTSP TCP 554

Secure-FTP TCP 990

Secure-HTTP TCP 443

Secure-IMAP TCP/ UDP 585, 993

Secure-IRC TCP/ UDP 994

Secure-LDAP TCP/ UDP 636

Secure-NNTP TCP/ UDP 563

Secure-POP3 TCP/ UDP 995

Secure-TELNET TCP 992

SIP TCP/ UDP 5060

Skinny TCP 2000, 2001, 2002

SMTP TCP 25

SNMP TCP/UDP 161, 162

SOCKS TCP 1080

Sqlnet TCP 1521

Sqlserver TCP 1433

SSH TCP 22

Streamwork UDP 1558

Sunrpc TCP/UDP 111

Syslog UDP 514

Telnet TCP 23

Tftp UDP 69

Vdolive TCP 7000

Winmx TCP 6699

X Windows TCP 6000, 6001, 6002, 6003

8-9

Configuring DAR


A device that supports DAR is required.

Configuring Protocol Match Criteria

To apply various policies (e.g. setting packet priority, allocating bandwidth for data streams) to corresponding data streams, you need to use DAR to classify the data streams first.

Follow these steps to configure protocol match criteria:



Enter class view traffic classifier tcl-name

[ operator { and | or } ] Required

Configure the match criterion for

HTTP

if-match [ not ] protocol http [ url url-string | host hostname-string |

mime mime-type ]

Optional

DAR can classify HTTP packets by

the URL address, host name, or

MIME type in HTTP packets.

Not configured by default.

Configure the match criterion for

RTP

if-match [ not ] protocol rtp

[ payload-type { audio | video |

payload-string&<1-16> }* ]

Optional

DAR can classify RTP packets by

the payload type in RTP packets.


Configure the match criterion for a

protocol

if-match [ not ] protocol protocol-name

Optional


Configure the match criterion for a

protocol group

if-match [ not ] protocol-group protocol-group-id

Optional


Configuring Port Numbers for DAR Application Protocols

The system pre-defines large numbers of protocols and their port numbers. The protocols include known protocols and 10 user-defined protocols, namely user-defined01, user-defined02, …, user-defined10. You can define port numbers for these protocols to enhance scalability of DAR.

Follow these steps to configure port numbers for DAR application protocols:



8-10


Configure port numbers for

DAR application protocols

dar protocol protocol-name { tcp |

udp } port { port-value&<1-16> |

range port-min port-max } *

Optional

By default, known protocols have

default port numbers, but the 10

user-defined protocols have no

port numbers.

Renaming User-defined Protocols

By default, the names of the ten user-defined protocols are user-defined01, user-defined02,…, user-defined10. You can rename them following these steps to facilitate memorizing and management.

Follow these steps to rename user-defined protocols:



Rename a user-defined protocol dar protocol-rename old-name

user-defined-name Optional

Configuring DAR Packet Accounting

With the packet accounting function of DAR, you can monitor the number of packets, the amount of data traffic, the historical average traffic rate, and the historical maximum traffic rate of application protocols on each interface. According to the statistics, you can apply corresponding policies for the traffic.

Follow these steps to configure DAR packets accounting:




Enable DAR packet accounting dar protocol-statistic [ flow-interval time ] Required

Disabled by default

Configuring the Maximum Number of Recognizable Connections

When a large amount of data traffic passes a device, if DAR recognizes all the traffic, tremendous system resources are occupied, and the normal operation of other functional modules is affected. To solve this problem, you can limit the maximum number of connections that DAR can recognize, thus saving the system resources. When the connection number exceeds the maximum threshold, DAR will not recognize the corresponding packets and directly mark them as unrecognizable.

Follow these steps to configure the maximum number of connections recognizable to DAR:


8-11



Configure the maximum number of

recognizable connections dar max-session-count count

Optional

The default maximum number

varies by device.

Displaying and Maintaining DAR


Display information about the

DAR module display dar information Available in any view

Display DAR protocol information display dar protocol { all | protocol-name } Available in any view

Display information about

renamed user-defined protocols display dar protocol-rename Available in any view

Display DAR protocol packet

statistics

display dar protocol-statistic [ protocol

protocol-name | top top-number | all ]

[ interface interface-type interface-number ]

[ direction { in | out } ]


Clear DAR protocol packet

statistics

reset dar protocol-statistic { { { protocol

protocol-name } | interface interface-type

interface-number } * | all }

Available in user view

Clear the cache information of all

the sessions reset dar session Available in user view

DAR Configuration Examples

BT Downloading Prohibition Configuration Example

Network requirements As shown in Figure 8-10, a router provides access to the BT seed server for the PCs on a network attached to it.

Make configuration on the router to prohibit PCs from downloading files from the BT seed server.

Figure 8-10 Network diagram for BT downloading prohibition configuration


# Configure the classifier classsample for matching BT packets.

8-12

<Router> system-view

[Router] traffic classifier bt

[Router-classifier-bt] if-match protocol bittorrent

[Router-classifier-bt] quit

# Configure a packet filtering behavior. [Router] traffic behavior deny

[Router-behavior-deny] filter deny

[Router-behavior-deny] quit

# Configure a QoS policy to match and filter BT packets. [Router] qos policy bt

[Router-qospolicy-bt] classifier bt behavior deny

[Router-qospolicy-bt] quit

# Apply the QoS policy in the inbound direction of Ethernet 1/1. [Router] interface ethernet1/1

[Router-Ethernet1/1] qos apply policy bt inbound

Run BT seed software on the BT seed server, and run BT client software on PC to start BT downloading.

Check BT client software and you can see that PC cannot perform BT downloading.

HTTP URL-Based DAR Configuration Example

Network requirements As shown in Figure 8-11, a router provides access to the Web server for the clients on a network attached to it.

Make configurations on Router to prohibit Client from accessing the webpage http://www.abcd.com:8080/news/index.html on Web server.

Figure 8-11 Network diagram for HTTP URL-based DAR configuration

Configuration procedure # Configure the HTTP URL as the match criterion. <Router> system-view

[Router] traffic classifier httpurl

[Router-classifier-httpurl] if-match protocol http url /news/index.html

[Router-classifier-httpurl] quit




# Configure a QoS policy. [Router] qos policy httpurl

[Router-qospolicy-httpurl] classifier httpurl behavior deny

[Router-qospolicy-httpurl] quit

# Apply the QoS policy in the inbound direction of Ethernet 1/1. [Router] interface ethernet 1/1

[Router-Ethernet1/1] qos apply policy httpurl inbound

8-13

After the configurations above, Client cannot access the webpage http://www.abcd.com:8080/news/index.html on Web server.

When the HTTP URL is configured as the match criterion, url-string only matches the URL fields in request packets. For example, url-string just matches /news/index.html of the webpage http://www.abcd.com:8080/news/index.html.

As url-string matches the fields in request packets, to have the QoS policy take effect, you should apply the QoS policy to a direction with HTTP URL request packets.

HTTP Host-Based DAR Configuration Example

Network requirements As shown in Figure 8-12, a router provides access to the Web server for the clients on a network attached to it.

Make configurations on Router to prohibit Client from accessing the webpage http://www.abcd.com:8080/news/index.html on Web server.

Figure 8-12 Network diagram for HTTP host-based DAR configuration


# Configure the HTTP Host as the match criterion. <Router> system-view

[Router] traffic classifier httphost

[Router-classifier-httphost] if-match protocol http host www.abcd.com:8080

[Router-classifier-httphost] quit




# Configure a QoS policy. [Router] qos policy httphost

[Router-qospolicy-httphost] classifier httphost behavior deny

[Router-qospolicy-httphost] quit

# Apply the QoS policy in the inbound direction of Ethernet 1/1. [Router] interface ethernet 1/1

[Router-Ethernet1/1] qos apply policy httphost inbound

After the configurations above, Client cannot access the webpage http://www.abcd.com:8080/news/index.html on Web server.

8-14

When the HTTP host is configured as a match criterion, hostname-string only matches the host names and port numbers in request packets. For example, hostname-string just matches www.abcd.com:8080 of the webpage http://www.abcd.com:8080/news/index.html.

As hostname-string matches the fields in request packets, to have the QoS policy take effect, you should apply the QoS policy to a direction with HTTP Host request packets.

9-1

9 FR QoS Configuration

When configuring FR QoS, go to these sections for information you are interested in:

FR QoS Overview

Configuring FR QoS

Displaying and Maintaining FR QoS

FR QoS Configuration Examples

FR QoS Overview

FR QoS

On a FR interface, you can use general QoS services to provide the services such as traffic policing, traffic shaping, congestion management, and congestion avoidance. Furthermore, a FR network offers its own QoS mechanisms, including FR traffic shaping, FR traffic policing, FR congestion management, FR discard eligibility (DE) rule list, and FR queuing management.

Compared with the general QoS, FR QoS can provide QoS service for each PVC on an interface. However, the general QoS can only provide the QoS service on the whole interface. Therefore, the FR QoS can provide more flexible QoS services for users.

Figure 9-1 FR QoS implementation

Refer to Frame Relay Configuration in the Access Volume for detailed information about Frame Relay.

Key Parameters

Several key parameters listed below are used for FR flow control:

Allowed committed information rate (CIR ALLOW): transmitting rate that the FR network allows normally. When no congestion occurs in the network, CIR ALLOW is guaranteed for data transmission.

9-2

Committed information rate (CIR): the minimum transmitting rate that a virtual circuit (VC) provides. CIR is guaranteed for data transmission even if congestion occurs in the network.

Committed burst size (CBS): traffic that the FR network is committed to transmit within the interval of Tc. When congestion occurs in the network, transmission of traffic of CBS is guaranteed by the FR network.

Excess burst size (EBS): the maximum traffic that can exceed CBS in a FR network within the interval of Tc. When congestion occurs in the network, the traffic of EBS is dropped first. That is to say, transmission of traffic of EBS is not guaranteed by the FR network.

FR QoS Implementation

FRTS

The functionality of FRTS

Frame Relay Traffic Shaping (FRTS) limits traffic of packets and bursty packets sent from a PVC, so that these packets can be transmitted at relatively even rate.

In a FR network, the bottleneck often occurs at the network segment juncture if the bandwidth of different segments does not match. As shown in Figure 9-2, Router B transmits packets to Router A at the rate of 128 kbps whereas the maximum interface rate of Router A is only 64 kbps. In this case, the bottleneck occurs at the place where Router A is connected to the FR network, thereby resulting in congestion that interrupts normal data transmission. With FRTS applied on the outgoing interface Serial 2/0 of Router B, the interface can transmit packets at a relatively even rate of 64 kbps, thus avoiding the network congestion. Even if congestion occurs in the network, Router B can still transmit packets at the rate of 32 kbps.

Figure 9-2 FRTS implementation

FRTS is applied on the outgoing interfaces of a device. It can provide you with parameters like CIR ALLOW, CIR, CBS and EBS. FR PVCs can transmit packets at the rate of CIR ALLOW. In case of bursty packets, FRTS allows a FR PVC to transmit packets at a rate exceeding CIR ALLOW.

How FRTS works

FRTS is implemented using token buckets. The meanings of the related parameters in the protocol are modified as required by the actual algorithm and principles. See Figure 9-3 for how a token bucket works.

9-3

Figure 9-3 How a token bucket works

In the token bucket approach, packets requiring traffic control are put into the token bucket for processing before transmission. If enough tokens are available in the token bucket for sending these packets, the packets are allowed to pass, that is, the packets are sent normally. If the number of tokens in the token bucket is not enough for sending these packets, these packets are put into the FR class queue (that is the FRTS queue in FRTS implementation). Once enough tokens are available in the token bucket, the packets are taken out of the FR class queue for transmission. In this way, you can control the traffic of a certain class of packets. Tokens are in the unit of bits.

The FR protocol-provisioned related parameters correspond to the FRTS parameters as follows:

The sum of CBS and EBS equals the token bucket size. CIR ALLOW defines the number of tokens put into the token bucket per second.

For efficiency sake, the FRTS solution introduces the concept of dynamic Tc. Tc (Tc=size of packet/CIR) is in the range of 10 milliseconds to 100 milliseconds, and allows of dynamic adjustment depending on the transmitted packet size. That is, the device allocates the required tokens to the current packets waiting for transmission within the latest Tc regardless of the packet size (which is smaller than 1500 bytes).

Figure 9-4 Relationship between Tc and CIR

Tc (ms)

Size of packet (byte)

K=1/CIR

5

10

15

400 800 1200

For example, to send an 800-byte packet, 6400 bits (800 × 8) of tokens are required. Given the CIR of 64000 kbps, it takes 6400/64000=0.1s to put the required tokens into the token bucket, that is, the Tc for the packet is 100 ms. The packet is transmitted after 6400 bits of tokens are put into the token bucket within 100 ms. In some special cases, for example, if CIR is 8000 bps, the Tc for the packet is calculated as 6400/8000 = 800 ms > 100 ms. However, as Tc is defined to be in the range of 10 ms to 100 ms, the Tc for the packet adopts the upper threshold value, that is, 100 ms, instead of 800 ms

9-4

calculated. Likewise, if CIR is 1024000 bps, the Tc for the packet is calculated as 6400/1024000 = 6.25 ms < 10 ms, but the actual Tc adopts the lower threshold value, that is, 10 ms.

As mentioned above, the token bucket size equals the sum of CBS and EBS, and the tokens required for packet transmission are allocated at a time on the device. To ensure that tokens in the token bucket are enough for sending a packet of any size, especially a large packet (like a 1500-byte packet that requires 1500 × 8 = 12 kbits of tokens), CBS must be no smaller than 15 kbits, and you are recommended to set CBS to the same size of CIR.

As stipulated in the standard protocol, given Tc = 20 ms and CIR = 64000 bps, only 1280 bits (0. 02 × 64000 bits) of tokens can be put into the token bucket within each Tc. Therefore, to send an 800-byte packet, the device needs to put tokens into the token bucket for five times. Compared to the standard protocol implementation, the device in this implementation can put all the tokens required for sending the same packet at a time, hence significantly improving the efficiency.

When congestion occurs in the network, if the FR switching device is configured with the congestion management function (refer to FR congestion management for details) on the outgoing interface, the device notifies the network of congestion. Upon receiving the congestion notification, the device gradually slows down the transmit rate to CIR so as to relieve congestion in the network. In this case, you can still transmit data at the rate of CIR. If the device receives no congestion notification within a certain period, the device gradually raises the transmit rate from CIR to CIR ALLOW.

Figure 9-5 FRTS fundamentals

RATE

TIME

CIR ALLOW+PIR: 128Kbps

0s 1s 2s

CIR ALLOW: 64Kbps

CIR: 32Kbps

3s 4s 5s 6s

As shown in Figure 9-5, the FRTS parameters are set as follows: CIR ALLOW is 64 kbps, CIR is 32 kbps, CBS is 64000 bits, EBS is 64000 bits, the token bucket size is 128000 bits, the rate of putting tokens into the token bucket is 64 kbps before 4s, and the PVC sends packets at the rate of 64 kbps. At the point of 4s, the device receives the FR packet whose backward explicit congestion notification (BECN) flag bit is 1, indicating that congestion occurs in the network, the rate of putting tokens into the bucket is decreased to CIR (that is, 32 kbps), and the PVC sends packets at the rate of 32 kbps.

FR traffic policing

FR traffic policing monitors the traffic entering the network from each PVC, and restricts the traffic within a permitted range. If the traffic on a PVC exceeds the user-defined threshold, the device takes some measures like packet drop to protect the network resources.

9-5

Figure 9-6 FR traffic policing implementation

As shown in Figure 9-6, Router A at the user side transmits packets at the rate of 192 kbps to Router B at the switching side. However, Router B only wants to provide the bandwidth of 64 kbps for Router A. In this case, you need to configure FR traffic policing at the DCE side of Router B.

FR traffic policing can only be applied to the DCE interface of a device. FR traffic policing can monitor the traffic transmitted from the DTE side. When the traffic is smaller than CBS, the packets can be normally transmitted, and the device does not process the packets. When the traffic is larger than CBS and smaller than EBS + CBS, the packets can be normally transmitted. In this case, however, as for those packets of the traffic exceeding CBS, the device sets the DE flag bits in the FR packet headers to 1. When the traffic is larger than CBS + EBS, the device transmits the traffic of CBS + EBS and drops the traffic exceeding CBS + EBS. As for the traffic exceeding CBS, the device sets the DE flag bits in the FR packet headers to 1.

Figure 9-7 FR traffic policing fundamentals

RATE

TIME

CIR ALLOW+PIR: 128Kbps

0ms 125ms 250ms

CIR ALLOW: 64Kbps

100Kbps

375ms 500ms 625ms 750ms

150Kbps

Discarded

DE

Transmit

As shown in Figure 9-7, the parameters of FR traffic policing are set as follows: CIR ALLOW is 64 kbps, CIR is 32 kbps, CBS is 64000 bits, and EBS is 64000 bits. From 0 ms to 250 ms, DTE transmit packets to DCE at the rate of 64 kbps and DCE normally forwards these packets at the rate of 64 kbps. From 250 ms to 250 ms, DTE transmit packets to DCE at the rate of 100 kbps and DCE forwards these packets at the rate of 100 kbps. In this case, however, the DE flag bits in the packets exceeding CBS are set to 1. After 500 ms, DTE transmit packets to DCE at the rate of 150 kbps and DCE forwards these packets at the rate of 128 kbps. In this case, the DE flag bits in the packets of the traffic between CBS and CBS + EBS are set to 1, and the packets of the traffic exceeding CBS + EBS are directly dropped.

9-6

FR queuing

Besides FR PVC queues, FR interfaces also have interface queues. With FRTS disabled, only FR interface queues take effect, that is, the pre-defined FR PVC queues take effect only in the case that FRTS is enabled.

The relationship between PVC queues and interface queues is shown in Figure 9-8.

Figure 9-8 FR queuing

The following queuing mechanisms are available on FR interfaces:

FIFO PQ CQ WFQ CBQ RTPQ PVC PQ

Of these queuing mechanisms, FIFO, PQ, CQ, WFQ, CBQ, and RTPQ are universal queuing mechanisms. Refer to QoS Configuration in the QoS volume for detailed information.

PVC PQ can only be applied on FR interfaces. There are four types of PVC priority queues: top, middle, normal, and bottom, in the descending priority order. The packets from a certain PVC must be assigned to one PVC priority queue, and the packets from PVCs are assigned to PVC priority queues on the interface by PVC priority. PVC PQ dequeue and sends packets in the high-priority queue and then packets in the low-priority queue.

FR PVC queuing mechanisms include FIFO, PQ, CQ, WFQ, CBQ, and RTPQ. Only RTPQ can coexist with another queuing mechanism.

With FRTS enabled on an interface, only FIFO, RTPQ, or PVC PQ is available on the interface.

FR congestion management FR congestion management can process FR packets when congestion occurs in the network. It drops the packets with the DE flag bits set to 1 and notifies other devices on the network about the congestion.

FR congestion management is applied on the outgoing interface of a FR switching device. If no congestion occurs, the FR switching device forwards the FR packets normally without any processing. If congestion occurs, packets with the FE flag bits set to 1 are dropped; as for forward packets to be forwarded, the FECN flag bits in the FR packet headers are set to 1; as for backward packets on the same PVC, the BECN flag bits in the FR packet headers are set to 1. If no backward packets is

9-7

transmitted within a period, the device automatically transmits the Q.922A Test Response packets with the BECN flag bits set to 1 to the calling DTE.

Figure 9-9 FR congestion management implementation

帧中继网络DTE DCE NNI

Router A Router B

Data flow direction

BECN

FECN

Frame-Relay network

Frame relay network

FR DE rule list In a FR network, packets with the DE flag bits set to 1 are dropped first when congestion occurs in the network. DE rule lists are applied on the FR PVCs of a device, with each DE rule list containing multiple DE rules. If a packet transmitted over the PVC matches the rules in the DE rule list, its DE flag bit is set to 1. The packet is dropped first when congestion occurs in the network.

FR WRED

In current FR QoS, only WRED and AF and BE queues in Class Based Weighted Fair Queuing (CBWFQ) support WRED, and EF queues in CBWFQ do not support WRED.

Configuring FR QoS

FR QoS Configuration Task List

Complete the following tasks to configure FR QoS:

Task Remarks

Creating and Configuring a FR Class Required

Configuring FRTS Optional

Configuring FR Traffic Policing Optional

Configuring FR Congestion Management Optional

Configuring FR DE Rule List Optional

Configuring FR Queuing Optional

Configuring FR Fragmentation Optional

Creating and Configuring a FR Class

The system integrates QoS services on FR PVCs into FR classes to provide a flexible and complete solution for FR traffic control and service quality. Before configuring QoS services such as FRTS, you need to create a FR class first, and then you can configure all the QoS parameters in the FR class. Thus, a FR class equals to a set of QoS network service solutions. Then, you can associate the FR

9-8

class with a FR PVC, that is, apply a set of QoS network service solutions to the FR PVC. You can associate a FR class with one or more PVCs.

An FR PVC providing QoS services searches the corresponding FR class in the following order:

The frame class associated with the FR PVC The FR class of the FR interface to which the FR PVC belongs

Follow these steps to configure and create a FR class:

To do... Use the command... Remarks


Create a FR class and enter FR class view fr class class-name

Required

By default, no FR

class is created.

Exit FR class view quit —

Enter FR interface

view

interface interface-type interface-number

Associate

the FR

class with

a FR

interface

Associate the FR

class with the FR

interface fr-class class-name

Enter FR interface

view

interface interface-type interface-number

Enter FR PVC view fr dlci dlci

Associate

the FR

class with

a FR

interface

or FR

PVC

Associate

the FR

class with

a FR PVC Associate the FR

class with the FR

PVC fr-class class-name

Use either command

or all commands

By default, no FR

class is associated

with a FR PVC or a

FR interface.

After using the fr class command to create a FR class, you can enter FR class view, where you can configure parameters for QoS services such as FRTS, FR traffic policing, FR congestion management, and FR queuing. Refer to the following sections for detailed parameter configuration.

Configuring FRTS

Follow these steps to configure FRTS:



9-9


Enter FR interface view interface interface-type


Enable FRTS fr traffic-shaping Required

Disabled by default

Exit FR interface view quit —

Enter FR class view fr class class-name —

Set CBS for FR PVCs cbs [ outbound ]

committed-burst-size

Optional

56000 bps by default

Set EBS for FR PVCs ebs [ outbound ]

excess-burst-size

Optional

0 bit by default

Set CIR ALLOW for FR PVCs cir allow [ outbound ]

committed-information-rate

Optional


Set CIR for FR PVCs cir committed-information-rate Optional


Enable FRTS adaptation

traffic-shaping adaptation

{ becn percentage |

interface-congestion number }

Optional

By default, the command is

enabled with the percentage

argument being 25 for traffic with

the BECN flag.

FRTS is applied to the interfaces sending FR packets and is usually applied to the DTE side of a FR network.

FRTS does not support fast forwarding. The configured FRTS takes effect after fast forwarding is disabled. For detailed information about fast forwarding, refer to Fast Forwarding Configuration in the IP Services Volume.

The cbs, ebs, and cir allow commands can be used to set both inbound and outbound parameters for FR PVCs. But only outbound parameters take effect for FRTS.

Numerically, CBS should be no less than CIR ALLOW. Otherwise, large-size packets may fail to be sent.

Configuring FR Traffic Policing

Follow these steps to configure FR traffic policing:

9-10





Enable FR traffic policing fr traffic-policing Required

Disabled by default



Set CBS for FR PVCs cbs [ inbound ]

committed-burst-size

Optional


Set EBS for FR PVCs ebs [ inbound ] excess-burst-sizeOptional

0 bit by default

Set CIR ALLOW for FR PVCs cir allow [ inbound ]

committed-information-rate

Optional


FR traffic policing is applied to the interfaces receiving FR packets and can only be applied to the DCE of a FR network.

The cbs, ebs, and cir allow commands can be used to set both inbound and outbound parameters for FR PVCs. But only inbound parameters take effect for FR traffic policing.

Configuring FR Congestion Management

FR congestion management includes congestion management on the FR interface and congestion management on the FR PVC. You can set the congestion thresholds in FR PVC view or FR interface view for a specific FR class. The device determines whether congestion occurs based on the percentage of the current FR interface queue length or FR PVC queue length to the total interface queue length. When the percentage of the current interface queue length or PVC queue length to the total queue length exceeds the set congestion threshold, the device considers that congestion occurs and processes packets accordingly (such as dropping).

Configuring FR congestion management for a FR interface

Follow these steps to configure FR congestion management for a FR interface:



9-11




Enable FR congestion

management on the FR interface

fr congestion-threshold { de |

ecn } queue-percentage

Required

Disabled by default

Configuring FR congestion management for a FR PVC

Follow these steps to configure FR congestion management for a FR PVC:




Enable FR congestion

management for FR PVCs

congestion-threshold { de | ecn }

queue-percentage

Required

Disabled by default

With FR congestion management enabled on a FR interface, only FIFO queuing or PVC PQ is available on the FR interface.

With FR congestion management enabled on a FR PVC, only FIFO queuing is available on the FR PVC.

The configured congestion management on a FR PVC does not take effect if FRTS is not enabled on the interface that the FR PVC belongs to.

Configuring FR DE Rule List

Follow these steps to configure FR DE rule list:



Configure an

interface-based DE

rule list

fr del list-number inbound-interface

interface-type interface-number Configure

a DE rule

list Configure an

IP-based DE rule list

fr del list-number protocol ip [ acl

acl-number | fragments | greater-than bytes

| less-than bytes | tcp ports | udp ports ]

Use either command

By default, no DE rule

list is created.

Enter FR interface view interface interface-type interface-number —

9-12


Apply the DE rule list to the

specified FR PVC fr de del list-number dlci dlci-number

Required

By default, no DE rule

list is applied to a FR

PVC.

Up to 10 DE rule lists can be applied to a device, and a DE rule list can be configured with up to 100 DE rules.

Configuring FR Queuing

Configuring FR PVC queuing

With FRTS enabled on a FR interface, each FR PVC of the interface is configured with an independent queuing mechanism

Follow these steps to configure FR PVC queuing:




Configure FIFO queue length for

the FR PVC fifo queue-length queue-length

Optional

40 by default

Apply PQ to the FR PVC pq pql pql-index Optional

Apply CQ to the FR PVC cq cql cql-index Optional

Apply WFQ to the FR PVC wfq [ congestive-discard-threshold

[ dynamic-queues ] ] Optional

Apply CBQ to the FR PVC apply policy policy-name

outbound Optional

Apply RTPQ to the FR PVC

rtpq start-port min-dest-port

end-port max-dest-port

bandwidth bandwidth

Optional

9-13

By default, FR PVCs adopt FIFO queuing.

With FR congestion management enabled on a FR PVC, only FIFO queuing is available on the interface.

Refer to QoS Configuration in the QoS volume for PQ, CQ, WFQ, CBQ, and RTPQ configuration.

Configuring FR interface queuing

Universal queuing mechanisms (including FIFO, PQ, CQ, WFQ, CBQ, and RTPQ) are available on FR interfaces. Refer to QoS Configuration in the QoS volume for FIFO, PQ, CQ, WFQ, CBQ, and RTPQ.

PVC PQ is specific to FR interfaces and is available only on FR interfaces. With FRTS enabled on a FR interface, only FIFO or PVC PQ is available on the FR interface. With FR congestion management enabled on a FR interface, only FIFO or PVC PQ is available on the FR interface.

PVC PQ contains four queues, that is, top queue, middle queue, normal queue, and bottom queue, in descending priority order. Packets in the four queues are sent in the descending priority order, that is, the packets in the top queue are sent first, then the packets in the middle queue followed by the packets in the normal queue, and finally the packets in the bottom queue. Each PVC on an interface corresponds to a PVC PQ priority queue, and all the packets from the PVC are assigned to the corresponding PVC PQ priority queue.

Follow these steps to configure PVC PQ:





Apply PVC PQ to the FR interface

and set the length of each PVC PQ

priority queue

fr pvc-pq [ top-limit middle-limit

normal-limit bottom-limit ] Required



Set the PVC PQ priority queue for

the FR PVC

pvc-pq { bottom | middle |

normal | top }

Optional

By default, packets from a FR PVC

are assigned to the normal queue.

Configuring FR Fragmentation

The devices support end-to-end FRF.12 fragmentation.

9-14

On low-speed FR links, large data packets cause excessive delay. FR fragmentation can fragment large FR packets into several small packets which can be transmitted on low-speed links with low delay.

When voice packets and data packets are transmitted simultaneously, large data packets occupy the bandwidth for a long time. As a result, voice packets are delayed or even dropped, thus affecting voice quality. The purpose of FR fragmentation configuration is to reduce delay for voice packets and guarantee the real-time transmission of voice packets. With FR fragmentation configured, large data packets are fragmented into small data fragments. Voice packets and the data fragments are sent alternatively, so that voice packets can be timely and evenly processed and the delay for voice packets is reduced.

Follow these steps to configure FR fragmentation:

To do... Use the command...



Enable FR fragmentation fragment [ fragment-size ]

[ data-level | voice-level ]

Required

Disabled by default

The configured FR fragmentation function takes effect after you associate the FR PVCs requiring FR fragmentation with the FR class and enable FRTS on the FR PVCs.

MFR interfaces do not support FRF.12 fragmentation. If the interfaces at both ends of a link are MFR interfaces with FRF.12 fragmentation enabled, FRF.12 fragmentation does not take effect. Packets are sent out from the local end without being fragmented and can be received by the remote end. When pinging the remote end on the local end, you can get response from the remote end. If the local MFR interface is connected to a normal FR interface (that is, a serial interface encapsulated with FR), FRF.12 fragmentation does not work at the local end and packets are sent out from the local end without being fragmented, however, FRF.12 fragmentation takes effect on the remote end.

Displaying and Maintaining FR QoS


Display the mapping relationship

between FR classes and

interfaces (including the DLCIs of

an interface, subinterfaces of an

interface, and the DLCIs of

subinterfaces)

display fr class-map { fr-class

class-name | interface

interface-type interface-number }


9-15


Display the configuration and

statistics information about FR

QoS

display fr pvc-info [ interface

interface-type interface-number ]

[ dlci-number ]


Display the information about all

the configured FR switching PVCs

display fr switch-table { all |

name switch-name | interface

interface-type interface-number }


Display the information about CBQ

applied to an interface

display qos policy interface

[ interface-type interface-number

[ dlci dlci-number [ outbound ] |

inbound | outbound ] ]


Display the information about PVC

PQ on a FR interface

display qos pvc-pq interface

[ interface-type interface-number ]Available in any view

Display the information about FR

fragmentation

display fr fragment-info

[ interface interface-type

interface-number ] [ dlci-number ]


Display the statistics information

about data transmitted and

received through FR

display fr statistics [ interface

interface-type interface-number ] Available in any view

FR QoS Configuration Examples

FRTS Configuration Example


As shown in Figure 9-10,

The device Router is connected to the FR network through Serial 2/0. The average transmit rate of the device is 96 kbps, the maximum transmit rate is 128 kbps, and

the minimum transmit rate is 32 kbps. The device is capable of FRTS adaptation. Apply PQ to make sure that the IP packets sourced from the 10.0.0.0 network segment are

transmitted preferentially.

Figure 9-10 Network diagram for FRTS configuration


# Define ACL 2001 and PQL 1 to assign IP packets sourced from the 10.0.0.0 network segment to the top queue.

9-16

<Router> system-view

[Router] acl number 2001

[Router-acl-basic-2001] rule permit source 10.0.0.0 0 0.255.255.255

[Router-acl-basic-2001] quit

[Router] qos pql 1 protocol ip acl 2001 queue top

# Create a FR class and configure FRTS parameters for the FR class. [Router] fr class 96k

[Router-fr-class-96k] cir allow 96000

[Router-fr-class-96k] cir 32000

[Router-fr-class-96k] cbs 96000

[Router-fr-class-96k] ebs 32000

[Router-fr-class-96k] traffic-shaping adaptation becn 20

[Router-fr-class-96k] pq pql 1

[Router-fr-class-96k] quit

# Configure Serial 2/0 as a FR interface and enable FRTS on Serial 2/0. [Router] interface serial 2/0

[Router-Serial2/0] link-protocol fr

[Router-Serial2/0] ip address 1.1.1.1 255.255.255.0

[Router-Serial2/0] fr traffic-shaping

# Create a FR PVC and associate the FR PVC with FR class 96k. [Router-Serial2/0] fr dlci 16

[Router-fr-dlci-Serial2/0-16] fr-class 96k

FR Fragmentation Configuration Example


As shown in Figure 9-11, Router A is connected to Router B through a FR network. Enable FR fragmentation (FRF.12) on the two devices.

Figure 9-11 Networking diagram for FR fragmentation (FRF.12) configuration


1) Configure Router A

# Create and configure the FR class test1. <RouterA> system-view

[RouterA] fr class test1

[RouterA-fr-class-test1] fragment 80

[RouterA-fr-class-test1] quit

# Configure Serial 2/0 as a FR interface and enable FRTS on Serial 2/0. [RouterA] interface serial 2/0

[RouterA-Serial2/0] link-protocol fr

[RouterA-Serial2/0] ip address 10.1.1.2 255.0.0.0

[RouterA-Serial2/0] fr traffic-shaping

# Create DLCI 16.

9-17

[RouterA-Serial2/0] fr dlci 16

# Apply the FR class test1 to DLCI 16. [RouterA-fr-dlci-Serial2/0-16] fr-class test1


# Create and configure the FR class test1. <RouterB> system-view

[RouterB] fr class test1

[RouterB-fr-class-test1] fragment 80

[RouterB-fr-class-test1] quit

# Configure Serial 2/0 as a FR interface and enable FRTS on Serial 2/0. [RouterB] interface serial 2/0

[RouterB-Serial2/0] link-protocol fr

[RouterB-Serial2/0] ip address 10.1.1.1 255.0.0.0

[RouterB-Serial2/0] fr traffic-shaping

# Create DLCI 16. [RouterB-Serial2/0] fr dlci 16

# Apply the FR class test1 to DLCI 16. [RouterB-fr-dlci-Serial2/0-16] fr-class test1

FR WRED Configuration Example


As shown in Figure 9-12,

Router A is connected to Router B through a FR network. Apply WFQ to the FR PVCs of Router A and enable DSCP-based WRED. On PVCs of Router B, allocate bandwidth for packets with the specific DSCP values and enable

DSCP-based WRED for these packets, and apply WFQ and the corresponding WRED policy to the other packets.

Figure 9-12 Network diagram for FR WRED configuration


1) Configure Router A

# Define the traffic behavior wfqwred. [RouterA] traffic behavior wfqwred

[RouterA-behavior-wfqwred] queue wfq queue-number 256

[RouterA-behavior-wfqwred] queue-length 512

[RouterA-behavior-wfqwred] wred dscp

[RouterA-behavior-wfqwred] wred dscp af11 low-limit 5 high-limit 10 discard-probability 6

[RouterA-behavior-wfqwred] wred dscp af21 low-limit 10 high-limit 20 discard-probability 8

[RouterA-behavior-wfqwred] quit

# Configure the QoS policy test, and apply the traffic behavior wfqwred to the default class in the QoS policy.

9-18

[RouterA] qos policy test

[RouterA-qospolicy-test] classifier default-class behavior wfqwred

[RouterA-qospolicy-test] quit

# Configure the FR class frclass and apply the QoS policy test to the FR class frclass. [RouterA]fr class frclass

[RouterA-fr-class-frclass] apply policy test outbound

[RouterA-fr-class-frclass] quit

# Configure FR-related parameters for Serial 2/1. [RouterA] interface Serial 2/1

[RouterA-Serial2/1] link-protocol fr

[RouterA-Serial2/1] fr map ip 192.168.1.2 60

[RouterA-Serial2/1] ip address 192.168.1.1 255.255.255.0

# Configure the maximum reserved bandwidth for queues on Serial 2/1. [RouterA-Serial2/1] qos reserved-bandwidth pct 70

# Apply the FR class frclass to DLCI 60 of Serial 2/1. [RouterA-Serial2/1] fr dlci 60

[RouterA-fr-dlci-Serial2/1-60] fr-class frclass


# Define a traffic class af11_31. <RouterB> system-view

[RouterB] traffic classifier af11_31 operator or

[RouterB-classifier-af11_31] if-match dscp af11

[RouterB-classifier-af11_31] if-match dscp af31

[RouterB-classifier-af11_31] quit

# Define the traffic behavior for AF queues. [RouterB] traffic behavior afwred

[RouterB-behavior-afwred] queue af bandwidth pct 50

[RouterB-behavior-afwred] wred dscp

[RouterB-behavior-afwred] wred dscp af11 low-limit 10 high-limit 40 discard-probabilty 15

[RouterB-behavior-afwred] wred dscp af31 low-limit 10 high-limit 60 discard-probabilty 20

[RouterB-behavior-afwred] quit

# Define the traffic behavior for WFQ queues. [RouterB] traffic behavior wfqwred

[RouterB-behavior-wfqwred] queue wfq

[RouterB-behavior-wfqwred] wred dscp

[RouterB-behavior-wfqwred] wred dscp 0 low-limit 10 high-limit 20 discard-probabilty 8

[RouterB-behavior-wfqwred] quit

# Configure a QoS policy and apply WFQ queuing to the default classes. [RouterB] qos policy test

[RouterB-qospolicy-test] classifier default-class behavior wfqwred

[RouterB-qospolicy-test] classifier af11_31 behavior afwred

[RouterB-qospolicy-test] quit

# Create a FR class and apply the QoS policy test to the FR class. [RouterB]fr class frclass

[RouterB-fr-class-frclass] apply policy test outbound

[RouterB-fr-class-frclass] quit

# Configure FR-related parameters for Serial 2/2. [RouterB] interface serial 2/2

9-19

[RouterB-Serial2/2] link-protocol fr

[RouterB-Serial2/2] ip address 192.168.1.2 255.255.255.0

[RouterB-Serial2/2] fr traffic-shaping

[RouterB-Serial2/2] fr map ip 192.168.1.1 50

# Configure the maximum reserved bandwidth for queues on Serial 2/2. [RouterB-Serial2/2] qos reserved-bandwidth pct 70

# Apply the FR class frclass to DLCI 50. [RouterB-Serial2/2] fr dlci 50

[RouterB-fr-dlci-Serial2/2-50] fr-class frclass

07 QoS Volume Book

Documents

Transcript of 07 QoS Volume Book