Professional Documents
Culture Documents
i
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
6 Congestion Avoidance······························································································································6-1
Congestion Avoidance Overview ············································································································6-1
ii
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
iii
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
iv
1 QoS Overview
This chapter covers the following topics:
z Introduction to QoS
z Traditional Packet Forwarding Services
z New Requirements from Emerging Applications
z Congestion: Causes, Impacts, and Countermeasures
z 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.
1-1
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.
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
100M
Congestion on interfaces
with different speeds 100M
Congestion on interfaces
with the same speed
z The traffic enters a device from a high speed link and is forwarded over a low speed link.
z 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
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-2
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.
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:
z 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.
z 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.
z 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.
z 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.
z 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:
z Traffic classification
z Access control
z Traffic policing and traffic shaping
1-3
z Congestion management
z Congestion avoidance
1-4
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:
z Traffic Classification Overview
z Traffic Policing and Traffic Shaping Overview
z Traffic Evaluation and Token Bucket
z Traffic Policing, GTS, and Line Rate Configuration
z Displaying and Maintaining Traffic Policing, GTS and Line Rate
z Traffic Policing and GTS Configuration Example
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
2-1
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.
Packets sent
Packet
classification
Token
bucket
Packets dropped
2-2
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:
z 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).
z 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:
z CIR
z CBS
z 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:
z Forwarding the packets whose evaluation result is “conforming”.
z Dropping the packets whose evaluation result is “excess”.
z Modifying the IP precedence of the packets whose evaluation result is “conforming” and
forwarding them.
z Modifying the IP precedence of the packets whose evaluation result is “conforming” and delivering
them into the next-level traffic policing.
z Entering the next-level policing (you can set multiple traffic policing levels with each level focusing
on specific objects).
2-3
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-4
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.
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
2-5
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
Optional
Display the CAR list display qos carl [ carl-index ]
Available in any view
Enter
Enter Use either command
interface interface interface-type interface-number
interface view Settings in interface view take
view or effect on the current interface;
port group Enter port
settings in port group view take
view group port-group manual port-group-name
effect on all ports in the port group.
view
Display CAR
configuration display qos car interface [ interface-type Optional
information on the interface-number ] Available in any view
interface/all interfaces
2-6
To do… Use the command… Remarks
2-7
# 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
Display GTS
display qos gts interface [ interface-type Optional
configuration information
interface-number ] Available in any view
on the interface
2-8
To do… Use the command… Remarks
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:
To do… Use the command… Remarks
2-9
To do… Use the command… Remarks
Display CAR list information display qos carl [ carl-index ] Available in any view
Display the CAR information on the display qos car interface [ interface-type
Available in any view
specified interface interface-number ]
2-10
z 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
2-11
3 QoS Policy Configuration
When configuring a QoS policy, go to these sections for information you are interested in:
z QoS Policy Overview
z Configuring a QoS Policy
z Applying the QoS Policy
z Configuring QoS Policy-Based Traffic Rate Measuring Interval
z Displaying and Maintaining QoS Policies
Configuration Prerequisites
3-1
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:
To do… Use the command… Remarks
Required
Create a class and enter class traffic classifier tcl-name
By default, the relation between
view [ operator { and | or } ]
match criteria is logic and.
To define a traffic behavior, you should first create a traffic behavior name and then configure attributes
in traffic behavior view.
Follow these steps to define a traffic behavior:
To do… Use the command… Remarks
3-2
To do… Use the command… Remarks
Optional
Display traffic behavior display traffic behavior { system-defined |
Available in any
configuration information user-defined } [ behavior-name ]
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:
To do… Use the command… Remarks
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-3
z 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.
z 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.
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 modify the classification rules, traffic behaviors, and classifier-behavior associations of a QoS
policy already applied.
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:
To do… Use the command… Remarks
3-4
To do… Use the command… Remarks
Enter
interface interface-type Use either command
interface
interface-number
Enter view Settings in interface view take
interface effect on the current interface;
view, port Enter port
port-group manual port-group-name settings in port group view take
group view, group view
effect on all ports in the port group;
or PVC view settings in PVC view take effect on
Enter PVC interface atm interface-number
the current PVC.
view
pvc vpi/vci
z QoS policies can be applied to all physical interfaces except interfaces encapsulated with X.25 or
LAPB.
z 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
interface interface-type
Enter interface view —
interface-number
3-5
To do… Use the command… Remarks
z The QoS policy-based traffic rate measuring interval of an ATM PVC is the same as that of the
ATM interface.
z The QoS policy-based traffic rate measuring interval of an FR DLCI is the same as that of the FR
interface.
z The QoS policy-based traffic rate measuring interval of a subinterface is the same as that of the
main interface.
3-6
4 Congestion Management Configuration
When configuring congestion management, go to these sections for information you are interested in:
z Congestion Management Overview
z Configuring FIFO
z Configuring PQ
z Configuring CQ
z Configuring WFQ
z Configuring CBQ
z Configuring RTP Priority Queuing
z Configuring QoS Tokens
z Configuring Packet Information Pre-Extraction
z Configuring Local Fragment Pre-drop
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
Queue Interface
Sending queue
4-1
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)
High queue
Packets to be sent
through this interface Packets sent
Middle queue
Interface
Normal queue
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-2
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-3
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:
z Different queues have fair dispatching opportunities for delay balancing among streams.
z 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-4
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:
z Match packets with priority classes and then the other classes.
z Match packets with priority classes in the order configured.
z Match packets with other classes in the order configured.
z 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-5
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
Number of
Type Advantages Disadvantages
queues
4-6
Number of
Type Advantages Disadvantages
queues
z Easy to configure
z Provide a bandwidth guarantee for
packets from cooperative
(interactive) sources (such as TCP
packets)
z Reduce jitter
z Reduce the delay for interactive The processing speed is faster than that
WFQ Configurable applications with a small amount of of PQ and CQ but slower than that of
data FIFO
If the burst traffic is too heavy, you can increase the queue length to make queue scheduling more
accurate.
4-7
Configuring FIFO
FIFO is the default queue scheduling mechanism for an interface or PVC, and the FIFO queue size is
configurable.
Enter interface
interface interface-type interface-number
Enter interface view
view or PVC —
interface atm interface-number
view Enter PVC view
pvc vpi/vci
Required
Set the FIFO queue size qos fifo queue-length queue-length
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.
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:
To do… Use the command… Remarks
4-8
To do… Use the command… Remarks
Optional
Enter
interface interface-type interface-number
Enter interface interface view
view or PVC —
Enter PVC interface atm interface-number
view
view
pvc vpi/vci
Required
Apply the PQ list to the interface qos pq pql pql-index
FIFO applies by default
z PQ is applicable to all physical interfaces except interfaces using the X.25 or LAPB protocol at the
data link layer.
z 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.
4-9
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
Configuration procedure
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-10
Configuration Procedure
or Optional
Configure a CQ list
qos cql cql-index inbound-interface Use either command.
interface-type interface-number queue
queue-number
Optional
Enter interface
interface interface-type interface-number
Enter interface view
view or PVC —
interface atm interface-number
view Enter PVC view
pvc vpi/vci
Optional
Display information about CQ lists display qos cql
Available in any view
4-11
z CQ is applicable to all physical interfaces except interfaces using X.25 or LAPB protocol at the
data link layer.
z 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.
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
Configuration Procedure
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:
To do… Use the command… Remarks
Enter interface
interface interface-type interface-number
view
Enter interface
—
view interface atm interface-number
Enter PVC view
pvc vpi/vci
4-12
z WFQ is applicable to all physical interfaces except interfaces using X.25 or LAPB at the data link
layer.
z 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.
Network requirements
Configure WFQ on Serial 2/0, setting the maximum queue size to 100, and the total number of queues
to 512.
Configuration procedure
# Enter system view.
<Sysname> system-view
# 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.
z The default class
default-class: Matches the default traffic.
z DSCP-based pre-defined classes
ef, af1, af2, af3, af4: Matches IP DSCP value ef, af1, af2, af3, af4 respectively.
z IP precedence-based pre-defined classes
ip-prec0, ip-prec1, …ip-prec7: Matches IP precedence value 0, 1, …7 respectively.
z MPLS EXP-based pre-defined classes
mpls-exp0, mpls-exp1, …mpls-exp7: Matches MPLS EXP value 0, 1, …7 respectively.
4-13
Pre-defined traffic behaviors
The system pre-defines some traffic behaviors and defines QoS features for them.
z ef: Assigns a class of packets to the EF queue and assigns 20% of the available interface/PVC
bandwidth to the class of packets.
z af: Assigns a class of packets to the AF queue and assigns 20% of the available interface/PVC
bandwidth to the class of packets.
z 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:
z Associates the pre-defined class ef with the pre-defined traffic behavior ef.
z Associates pre-defined classes af1 through af4 with the pre-defined traffic behavior af.
z Associates the pre-defined class default-class with the pre-defined traffic behavior be.
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:
To do… Use the command… Remarks
If no maximum available interface bandwidth is configured for any type of interfaces, the bandwidth
used in CBQ calculation is as follows:
z The actual baudrate or rate of a physical interface.
z Total bandwidth of the bound logical serial interfaces, such as T1/E1 interfaces and multilink
frame relay (MFR) interfaces.
z 1000000 kbps for template interfaces such as VT, dialer, BRI, and PRI interfaces.
z 0 kbps for the other virtual interfaces such as tunnel interfaces.
4-14
z 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.
z 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.
z 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.
z 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.
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-15
To do… Use the command… Remarks
Required
Create a class and enter traffic classifier tcl-name [ operator By default, the and keyword is used.
class view { and | or } ] That is, the relation between matching
criteria is logic AND.
Configuration example
1) Network requirements
Define a class named test to match packets having an IP precedence value of 6.
2) Configuration procedure
# Enter system view.
<Sysname> system-view
# Define a class and enter class view.
[Sysname] traffic classifier test
# Define the match criterion.
[Sysname-classifier-test] if-match ip-precedence 6
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:
To do… Use the command… Remarks
Required
The entered
Create a traffic behavior and enter behavior-name cannot be
traffic behavior behavior-name
traffic behavior view the name of a traffic
behavior pre-defined by
the system.
4-16
z This traffic behavior can be applied only in the outbound direction of an interface or ATM PVC.
z 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.
Required
z The queue ef command can not be used in conjunction with the commands queue af,
queue-length, and wred for the same traffic behavior.
z The default class cannot be associated with a traffic behavior including EF.
z 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:
To do… Use the command… Remarks
4-17
To do… Use the command… Remarks
Required
A traffic behavior with WFQ applied can only be associated with the default class.
Required
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.
4-18
To do… Use the command… Remarks
Required
Create a traffic behavior and The entered traffic behavior name cannot
traffic behavior behavior-name
enter traffic behavior view be the name of a traffic behavior
pre-defined by the system.
Required
z The wred [ dscp | ip-precedence ] command must be issued after the queue af command or the
queue wfq command is used.
z The wred command and the queue-length command are mutually exclusive.
z If the WRED drop configuration is removed, other configurations under it are deleted.
z When a QoS policy including the WRED traffic behavior is applied to an interface, the previous
interface-level WRED configuration gets invalid.
Required
4-19
To do… Use the command… Remarks
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:
To do… Use the command… Remarks
Required
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-20
z When the wred command is disabled, the wred dscp command is also disabled.
z 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:
To do… Use the command… Remarks
Required
z The wred ip-precedence command is disabled when the wred command is disabled.
z 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.
2) Configuration procedure
# Enter system view.
<Sysname> system-view
# Define traffic and enter traffic behavior view.
[Sysname] traffic behavior test
4-21
# Enable AF and set the minimum guaranteed bandwidth to 200 kbps.
[Sysname-behavior-test] queue af bandwidth 200
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:
To do… Use the command… Remarks
Required
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:
To do… Use the command… Remarks
Enter
interface interface-type Use either command
interface
interface-number
Enter view Settings in interface view take
interface effect on the current interface;
view, port Enter port
port-group manual port-group-name settings in port group view take
group view, group view
effect on all ports in the port group;
or PVC view settings in PVC view take effect on
Enter PVC interface atm interface-number
the current PVC.
view
pvc vpi/vci
4-22
To do… Use the command… Remarks
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:
z 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.
z 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-23
z The route from Router C to Router D through Router A and Router B is reachable.
z The DSCP fields have been set for the traffic before the traffic enters Router A.
Figure 4-7 Network diagram for CBQ configuration
Configuration procedure
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-24
[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.
Display QoS policy configuration display qos policy { system-defined | user-defined } [ policy-name
information [ classifier tcl-name ] ]
Display interface/PVC QoS policy display qos policy interface [ interface-type interface-number ]
configuration information [ inbound | outbound ] [ pvc { pvc-name [ vpi/vci ] | vpi/vci } ]
Display interface/PVC CBQ display qos cbq interface [ interface-type interface-number ] [ pvc
configuration information { pvc-name [ vpi/vci ] | vpi/vci } ]
Enter interface
interface interface-type interface-number
Enter interface view
view or PVC —
interface atm interface-number
view Enter PVC view
pvc vpi/vci
4-25
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.
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.
Configuration procedure
# Enter system view.
<Sysname> system-view
# Enter interface view.
[Sysname] interface serial 1/0
# 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
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:
To do… Use the command… Remarks
Required
Specify the number of QoS
qos qmtoken token-number The QoS token feature is
tokens
disabled by default.
4-26
z To validate the above configuration, you must execute the shutdown command and then the
undo shutdown command on the interface.
z So far, this feature is available only for serial interfaces and BRI interfaces.
Network requirements
Specify the number of QoS tokens on an interface.
Configuration procedure
# Enter system view.
<Sysname> system-view
# Enter interface view.
[Sysname] interface serial 2/0
# Set the number of QoS tokens to 1.
[Sysname-Serial2/0] qos qmtoken 1
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:
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-27
[Sysname-Tunnel0] qos pre-classify
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:
Configuration Example
Network requirements
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
4-28
5 Priority Mapping Configuration
When configuring priority mapping, go to these sections for information you are interested in:
z Priority Mapping Overview
z Configuring a Priority Mapping Table
z Configuring the Trusted Precedence Type for a Port
z Displaying and Maintaining Priority Mapping
z Priority Mapping Configuration Examples
5-1
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
0 1
1 2
2 0
3 3
4 4
5 5
6 6
7 7
0 0
1 1
2 2
3 3
4 4
5 5
6 6
7 7
0 1
1 0
2 1
3 0
4 2
5-2
Local precedence Queue
5 2
6 3
7 3
Configuration Prerequisites
Configuration Procedure
Required
Enter priority mapping table
qos map-table dot1p-lp You can enter the corresponding priority
view
mapping table view as required.
Required
Configure the priority mapping import import-value-list
Newly configured mappings overwrite the
table export export-value
previous ones.
Configuration Example
Network requirements
Configure a dot1p-lp mapping table as shown below.
Table 5-4 dot1p-lp mappings
0 0
1 0
2 1
3 1
4 2
5-3
802.1p precedence Local precedence
5 2
6 3
7 3
Configuration procedure
# Enter system view.
<Sysname> system-view
# 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
[Sysname-maptbl-in-dot1p-lp] import 4 5 export 2
[Sysname-maptbl-in-dot1p-lp] import 6 7 export 3
Configuration Prerequisites
Configuration Procedure
Required
If the device supports only one port
Configure a priority for the Given the device supporting only one
priority type, use qos priority
port port priority type, the default port priority
priority-value
is 0.
5-4
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).
Configuration Example
Network requirements
Set the priority of the port to 7.
Configuration procedure
# Enter system view.
<Sysname> system-view
# Set the priority of Ethernet 1/1 to 7.
[Sysname] interface ethernet 1/1
[Sysname-Ethernet1/1] qos priority 7
Configuration Prerequisites
Configuration Procedure
5-5
To do… Use the command… Remarks
Required
Configure the trusted
qos trust dot1p The default trusted precedence
precedence type
type varies by device.
Configuration Example
Network requirements
Configure the port to trust the 802.1p precedence.
Configuration procedure
# Enter system view.
<Sysname> system-view
# Enter port view.
[Sysname] interface ethernet 1/1
# Configure the port to trust the 802.1p precedence.
[Sysname-Ethernet1/1] qos trust dot1p
Network requirements
z It is required that Router enqueue packets based on the 802.1p precedence of packets.
z 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-6
802.1p precedence Local precedence
4 2
5 2
6 3
7 3
Server
Router
Eth1/2 Eth1/1
Eth1/3 Eth1/4
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] import 2 3 export 1
[Switch-maptbl-in-dot1p-lp] import 4 5 export 2
[Switch-maptbl-in-dot1p-lp] import 6 7 export 3
[Switch-maptbl-in-dot1p-lp] quit
# Configure Ethernet 1/1 to trust the 802.1p precedence.
[Switch] interface ethernet 1/1
[Switch-Ethernet1/1] qos trust dot1p
[Switch-Ethernet1/1] quit
# Configure Ethernet 1/2 to trust the 802.1p precedence.
[Switch] interface ethernet 1/2
[Switch-Ethernet1/2] qos trust dot1p
[Switch-Ethernet1/2] quit
# Configure Ethernet 1/3 to trust the 802.1p precedence.
[Switch] interface ethernet 1/3
[Switch-Ethernet1/3] qos trust dot1p
[Switch-Ethernet1/3] quit
# Configure Ethernet 1/4 to trust the 802.1p precedence.
[Switch] interface ethernet 1/4
5-7
[Switch-Ethernet1/4] qos trust dot1p
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
Server
Router
Eth1/2 Eth1/1
Eth1/3 Eth1/4
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
[Switch-Ethernet1/1] quit
# Set the priority of Ethernet 1/2 to 3.
[Switch] interface ethernet 1/2
[Switch-Ethernet1/2] qos priority 3
[Switch-Ethernet1/2] quit
# Set the priority of Ethernet 1/3 to 5.
[Switch] interface ethernet 1/3
[Switch-Ethernet1/3] qos priority 5
[Switch-Ethernet1/3] quit
# Set the priority of Ethernet 1/4 to 7.
[Switch] interface ethernet 1/4
[Switch-Ethernet1/4] qos priority 7
5-8
6 Congestion Avoidance
When configuring congestion avoidance, go to these sections for information you are interested in:
z Congestion Avoidance Overview
z Introduction to WRED Configuration
z Configuring WRED on an Interface
z Applying a WRED Table on an Interface
z Displaying and Maintaining WRED
z WRED Configuration Example
6-1
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.
You can configure WRED using one of the following two methods:
z Interface configuration: configure WRED parameters on an interface or PVC and enable WRED.
6-2
z 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.
z The WRED exponent for average queue size calculation is determined (optional).
z The upper threshold and lower threshold for the queue corresponding to the precedence is
determined (optional).
Configuration Procedure
6-3
To do… Use the command… Remarks
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.
Configuration Example
Network requirements
z Enable IP precedence-based WRED on an interface.
z Set the following parameters for packets with IP precedence 3: lower threshold 20, upper
threshold 40, and drop probability denominator 15.
z Set the exponential factor for the average queue size calculation to 6.
Configuration procedure
# Enter system view.
<Sysname> system-view
# Enter interface view.
[Sysname] interface ethernet 1/1
# 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
Configuration Prerequisites
6-4
Configuration Procedure
Optional
Configure the other WRED queue queue-value low-limit low-limit
By default, the low-limit is 10
parameters [ discard-probability discard-prob ]
and the discard-prob is 30.
Required
Apply the WRED table to the
qos wred apply table-name A queue-based WRED table is
interface/port group
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):
To do… Use the command… Remarks
Required
Display configuration
Optional
information about a WRED display qos wred table [ table-name ]
Available in any view
table or all WRED tables
6-5
Displaying and Maintaining WRED
To do… Use the command… Remarks
6-6
7 MPLS QoS Configuration
When configuring MPLS QoS, go to these sections for information you are interested in:
z MPLS QoS Overview
z Configuring MPLS QoS
z MPLS QoS Configuration Examples
The MPLS-related knowledge is necessary for understanding MPLS QoS. Refer to MPLS Basic
Configuration in the MPLS Volume for more information about MPLS.
7-1
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:
z MPLS PQ: refer to Configuring MPLS PQ for the configuration procedure.
z MPLS CQ: refer to Configuring MPLS CQ for the configuration procedure.
z MPLS QoS policy: refer to Configuring a MPLS QoS Policy for the configuration procedure.
z MPLS CAR: refer to Configuring MPLS CAR for the configuration procedure.
Configuring MPLS PQ
Configuration prerequisites
z MPLS related configurations are completed.
z The relation between the MPLS PQ list and MPLS EXP value is determined.
z The interface to which the PQ list is to be applied is determined.
Configuration procedure
Follow these steps to configure MPLS PQ:
To do… Use the command… Remarks
Configuration example
z Create a classification rule for MPLS-based PQ list 10, assigning packets with an EXP value of 5
to the queue top.
z 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] interface ethernet 1/1
[Sysname-Ethernet1/1] qos pq pql 10
Configuring MPLS CQ
Configuration prerequisites
z MPLS related configurations are completed.
z The relation between the MPLS CQ list and MPLS EXP value is determined.
z The interface to which the CQ list is to be applied is determined.
7-2
Configuration procedure
Follow these steps to configure MPLS CQ:
To do… Use the command… Remarks
Configuration example
z Create a classification rule for MPLS-based CQ list 10, assigning packets with an EXP value of 1
to queue 2.
z 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] interface ethernet 1/1
[Sysname-Ethernet1/1] qos cq cql 10
Configuration prerequisites
z MPLS related configurations are completed.
z Match criteria are determined.
z Traffic behaviors are determined.
z The QoS policy is determined.
z Interfaces to which the MPLS QoS policy is to be applied are determined.
Configuration procedure
Follow these steps to configure a MPLS QoS policy:
To do… Use the command… Remarks
Required
Required
if-match [ not ] mpls-exp
This rule applies only to MPLS
exp-value-list
packets.
7-3
To do… Use the command… Remarks
Configuration prerequisites
z MPLS related configurations are completed.
z The MPLS CAR policy is determined.
z Interfaces where the MPLS CAR is to be applied are determined.
Configuration procedure
Follow these steps to configure MPLS CAR:
To do… Use the command… Remarks
7-4
To do… Use the command… Remarks
Network requirements
As shown in Figure 7-1:
z Both CE 1 and CE 2 belong to VPN 1.
z The bandwidth of the link between PE 1 and P is 2 M.
z 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:
z Run OSPF between PE 1 and P, and between PE 2 and P.
z Form a MP-EBGP neighborship between PE and CE.
z Form a MP-IBGP neighborship between PE and PE.
Second, configure MPLS QoS on PE 1 and P as follows:
z 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.
z
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-5
Refer to MPLS Configuration in the MPLS Volume for the MPLS VPN configuration. This section
introduces only the MPLS QoS configuration.
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] if-match dscp af21
[PE1-classifier-af21] traffic classifier af31
[PE1-classifier-af31] if-match dscp 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
[PE1-behavior-exp2] remark mpls-exp 2
[PE1-behavior-exp2] traffic behavior exp3
[PE1-behavior-exp3] remark mpls-exp 3
[PE1-behavior-exp3] traffic behavior exp4
[PE1-behavior-exp4] remark mpls-exp 4
7-6
[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 af21 behavior exp2
[PE1-qospolicy-REMARK] classifier af31 behavior exp3
[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-EXP2] if-match mpls-exp 2
[P-classifier-EXP2] traffic classifier EXP3
[P-classifier-EXP3] if-match mpls-exp 3
[P-classifier-EXP3] traffic classifier EXP4
[P-classifier-EXP4] if-match mpls-exp 4
[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] queue af bandwidth pct 20
[P-behavior-AF21] traffic behavior AF31
[P-behavior-AF31] queue af bandwidth pct 30
[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 EXP2 behavior AF21
[P-qospolicy-QUEUE] classifier EXP3 behavior AF31
[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.
7-7
7-8
8 DAR Configuration
When configuring DAR, go to these sections for information you are interested in:
z DAR Overview
z Configuring DAR
z Displaying and Maintaining DAR
z DAR Configuration Examples
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:
z 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.
z 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-1
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
1 ICMP
2 IGMP
4 IPinIP
6 TCP
8 EGP
17 UDP
47 GRE
50 ESP
51 AH
88 EIGRP
The lower 2 bits of the flags field control IP packet fragmentation. The 3 bits in the flags field are
defined as follows:
z Reserved: must be 0.
8-2
z Do not fragment: 0 indicates that fragmentation is allowed, and 1 indicates that fragmentation is
forbidden.
z 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
PSH The receiver should pass the data to the application layer as soon as possible.
FIN The sender has finished sending data. This field is used to terminate a connection.
8-3
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
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
z 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-4
z 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.
z 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.
z 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 2 3 8 15 31
V P X CC M PT Sequence Number
Time Stamp
SSRC
CSRC identifiers
……
Payload
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-5
Figure 8-8 Compound RTCP packet format
SSRC
SSRC
SSRC
SSRC
SSRC
SSRC
SSRC
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
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
8-6
Protocol name Protocol type Port number
DNS TCP/UDP 53
Finger TCP 79
Gopher TCP/UDP 70
8-7
Protocol name Protocol type Port number
SMTP TCP 25
SSH TCP 22
Telnet TCP 23
Tftp UDP 69
8-8
Configuring DAR
Configuration Prerequisites
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:
Optional
if-match [ not ] protocol http [ url DAR can classify HTTP packets by
Configure the match criterion for
url-string | host hostname-string | the URL address, host name, or
HTTP
mime mime-type ] MIME type in HTTP packets.
Optional
if-match [ not ] protocol rtp
Configure the match criterion for DAR can classify RTP packets by
[ payload-type { audio | video |
RTP the payload type in RTP packets.
payload-string&<1-16> }* ]
Not configured by default.
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:
To do… Use the command… Remarks
8-9
To do… Use the command… Remarks
Optional
dar protocol protocol-name { tcp | By default, known protocols have
Configure port numbers for
udp } port { port-value&<1-16> | default port numbers, but the 10
DAR application protocols
range port-min port-max } * user-defined protocols have no
port numbers.
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:
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:
To do… Use the command… Remarks
Required
Enable DAR packet accounting dar protocol-statistic [ flow-interval time ]
Disabled by default
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:
To do… Use the command… Remarks
8-10
To do… Use the command… Remarks
Optional
Configure the maximum number of
dar max-session-count count The default maximum number
recognizable connections
varies by device.
Display DAR protocol information display dar protocol { all | protocol-name } Available in any view
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
Configuration procedure
# Configure the classifier classsample for matching BT packets.
8-11
<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.
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 packet filtering behavior.
[Router] traffic behavior deny
[Router-behavior-deny] filter deny
[Router-behavior-deny] 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-12
After the configurations above, Client cannot access the webpage
http://www.abcd.com:8080/news/index.html on Web server.
z 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.
z 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.
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
Configuration procedure
# 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 packet filtering behavior.
[Router] traffic behavior deny
[Router-behavior-deny] filter deny
[Router-behavior-deny] 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-13
z 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.
z 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.
8-14
9 FR QoS Configuration
When configuring FR QoS, go to these sections for information you are interested in:
z FR QoS Overview
z Configuring FR QoS
z Displaying and Maintaining FR QoS
z 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:
z 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-1
z 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.
z 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.
z 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
z 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.
z 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-2
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:
z The sum of CBS and EBS equals the token bucket size.
z 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)
15 K=1/CIR
10
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-3
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
CIR: 32Kbps
0s 1s 2s 3s 4s 5s 6s TIME
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-4
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
150Kbps
DE
CIR ALLOW: 64Kbps
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-5
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
9-6
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
BECN
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
Task Remarks
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-7
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:
z The frame class associated with the FR PVC
z The FR class of the FR interface to which the FR PVC belongs
Follow these steps to configure and create a FR class:
Required
Create a FR class and enter FR class view fr class class-name By default, no FR
class is created.
interface
Associate Enter FR interface
interface-type
the FR view
interface-number
class with
Associate the FR
a FR
Associate
class with the FR fr-class class-name Use either command
interface
the FR
interface or all commands
class with
interface By default, no FR
a FR Enter FR interface
interface-type class is associated
interface view
interface-number with a FR PVC or a
or FR Associate
FR interface.
PVC the FR
Enter FR PVC view fr dlci dlci
class with
a FR PVC Associate the FR
class with the FR fr-class class-name
PVC
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
9-8
To do... Use the command... Remarks
interface interface-type
Enter FR interface view —
interface-number
Required
Enable FRTS fr traffic-shaping
Disabled by default
Optional
Set CIR for FR PVCs cir committed-information-rate
56000 bps by default
Optional
traffic-shaping adaptation By default, the command is
Enable FRTS adaptation { becn percentage | enabled with the percentage
interface-congestion number } argument being 25 for traffic with
the BECN flag.
z FRTS is applied to the interfaces sending FR packets and is usually applied to the DTE side of a
FR network.
z 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.
z 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.
z Numerically, CBS should be no less than CIR ALLOW. Otherwise, large-size packets may fail to
be sent.
9-9
To do... Use the command... Remarks
interface interface-type
Enter FR interface view —
interface-number
Required
Enable FR traffic policing fr traffic-policing
Disabled by default
Optional
Set EBS for FR PVCs ebs [ inbound ] excess-burst-size
0 bit by default
z FR traffic policing is applied to the interfaces receiving FR packets and can only be applied to the
DCE of a FR network.
z 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.
9-10
To do... Use the command... Remarks
interface interface-type
Enter FR interface view —
interface-number
Configure an
fr del list-number inbound-interface
interface-based DE
Configure interface-type interface-number Use either command
rule list
a DE rule By default, no DE rule
list fr del list-number protocol ip [ acl
Configure an list is created.
acl-number | fragments | greater-than bytes
IP-based DE rule list
| less-than bytes | tcp ports | udp ports ]
9-11
To do... Use the command... Remarks
Required
Apply the DE rule list to the By default, no DE rule
fr de del list-number dlci dlci-number
specified FR PVC 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
wfq [ congestive-discard-threshold
Apply WFQ to the FR PVC Optional
[ dynamic-queues ] ]
9-12
z By default, FR PVCs adopt FIFO queuing.
z With FR congestion management enabled on a FR PVC, only FIFO queuing is available on the
interface.
z Refer to QoS Configuration in the QoS volume for PQ, CQ, WFQ, CBQ, and RTPQ configuration.
interface interface-type
Enter FR interface view —
interface-number
Optional
Set the PVC PQ priority queue for pvc-pq { bottom | middle |
By default, packets from a FR PVC
the FR PVC normal | top }
are assigned to the normal queue.
Configuring FR Fragmentation
9-13
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...
z 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.
z 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.
9-14
To do... Use the command... Remarks
display fr fragment-info
Display the information about FR
[ interface interface-type Available in any view
fragmentation
interface-number ] [ dlci-number ]
Network requirements
As shown in Figure 9-10,
z The device Router is connected to the FR network through Serial 2/0.
z 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.
z 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
Configuration procedure
# Define ACL 2001 and PQL 1 to assign IP packets sourced from the 10.0.0.0 network segment to the
top queue.
9-15
<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
Network requirements
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
Configuration procedure
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-16
[RouterA-Serial2/0] fr dlci 16
# Apply the FR class test1 to DLCI 16.
[RouterA-fr-dlci-Serial2/0-16] fr-class test1
2) Configure Router B
# 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
Network requirements
As shown in Figure 9-12,
z Router A is connected to Router B through a FR network.
z Apply WFQ to the FR PVCs of Router A and enable DSCP-based WRED.
z 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.
Configuration procedure
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-17
[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
2) Configure Router B
# 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-18
[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
9-19