The evaluation can be based on different criteria because the network may provide various services. Generally, QoS performance is measured with respect to bandwidth, delay, jitter, and packet loss ratio during packet forwarding process.

Networks Without QoS Guarantee

On traditional IP networks without QoS guarantee, devices treat all packets equally and handle them using the first in first out (FIFO) policy. All packets share the resources of the network and devices. How many resources the packets can obtain completely depends on the time they arrive. This service is called best-effort. It delivers packets to their destinations as possibly as it can, without any guarantee for delay, jitter, packet loss ratio, and so on.

This service policy is only suitable for applications insensitive to bandwidth and delay, such as Word Wide Web (WWW) and E-Mail.

QoS Requirements of New Applications

The Internet has been growing along with the fast development of networking technologies.

Besides traditional applications such as WWW, E-Mail and FTP, network users are experiencing new services, such as tele-education, telemedicine, video telephone, videoconference and Video-on-Demand (VoD). Enterprise users expect to connect their regional branches together with VPN technologies to carry out operational applications, for instance, to access the database of the company or to monitor remote devices through Telnet.

These new applications have one thing in common, that is, they all have special requirements for bandwidth, delay, and jitter. For example, videoconference and VoD require high bandwidth, low delay and jitter. As for mission-critical applications, such as transactions and Telnet, they may not require high bandwidth but do require low delay and preferential service during congestion.

The emerging applications demand higher service performance of IP networks. Better network services during packets forwarding are required, such as providing dedicated bandwidth, reducing packet loss ratio, managing and avoiding congestion, and regulating network traffic. To meet these requirements, networks must provide more improved services.

Congestion: Causes, Impacts, and Countermeasures

Network congestion is a major factor contributed to service quality degrading on a traditional network. Congestion is a situation where the forwarding rate decreases due to insufficient resources, resulting in extra delay.

Causes

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

Figure 1-1 Traffic congestion causes

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

l The packet flows enter a device from several incoming interfaces and are forwarded out an outgoing interface, whose rate is smaller than the total rate of these incoming interfaces.

When traffic arrives at the line speed, a bottleneck is created at the outgoing interface causing congestion.

Besides bandwidth bottlenecks, congestion can be caused by resource shortage in various forms such as insufficient processor time, buffer, and memory, and by network resource exhaustion resulting from excessive arriving traffic in certain periods.

Impacts

Congestion may bring these negative results:

l Increased delay and jitter during packet transmission

l Decreased network throughput and resource use efficiency

l Network resource (memory in particular) exhaustion and even system breakdown

It is obvious that congestion hinders resource assignment for traffic and thus degrades service performance. Congestion is unavoidable in switched networks and multi-user application environments. To improve the service performance of your network, you must address the congestion issues.

Countermeasures

A simple solution for congestion is to increase network bandwidth, however, it cannot solve all the problems that cause congestion because you cannot increase network bandwidth infinitely.

A more effective solution is to provide differentiated services for different applications through traffic control and resource allocation. In this way, resources can be used more properly. During resources allocation and traffic control, the direct or indirect factors that might cause network congestion should be controlled to reduce the probability of congestion. Once congestion occurs, resource allocation should be performed according to the characteristics and demands of applications to minimize the effects of congestion.

QoS Technology Implementations

End-to-End QoS

Figure 1-2 End-to-end QoS model

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

l Traffic classification uses certain match criteria to organize packets with different characteristics into different classes. Traffic classification is usually applied in the inbound direction of a port.

l Traffic policing polices particular flows entering or leaving a device according to configured specifications and can be applied in both inbound and outbound directions of a port. When a flow exceeds the specification, some restriction or punishment measures can be taken to prevent overconsumption of network resources.

l Traffic shaping proactively adjusts the output rate of traffic to adapt traffic to the network resources of the downstream device and avoid unnecessary packet drop and congestion. Traffic shaping is usually applied in the outbound direction of a port.

l Congestion management provides a resource scheduling policy to arrange the forwarding sequence of packets when congestion occurs. Congestion management is usually applied in the outbound direction of a port.

l Congestion avoidance monitors the usage status of network resources and is usually applied in the outbound direction of a port. As congestion becomes worse, it actively reduces the amount of traffic by dropping packets.

Among these QoS technologies, traffic classification is the basis for providing differentiated services. Traffic policing, traffic shaping, congestion management, and congestion avoidance manage network traffic and resources in different ways to realize differentiated services.

This section is focused on traffic classification, and the subsequent sections will introduce the other technologies in details.

Traffic Classification

When defining match criteria for classifying traffic, you can use IP precedence bits in the type of service (ToS) field of the IP packet header, or other header information such as IP addresses, MAC addresses, IP protocol field and port numbers. You can define a class for packets with the same quintuple (source address, source port number, protocol number, destination address and destination port number for example), 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 directly adopted to classify the packets in the network. 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 use depends on the current phase and the resources of the network. For example, CAR is used 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.

Packet Precedences

This section introduces IP precedence, ToS precedence, differentiated services codepoint (DSCP) values, and 802.1p priority.

1) IP precedence, ToS precedence, and DSCP values

Figure 1-3 DS field and ToS bytes

As shown in Figure 1-3, the ToS field of the IP header contains eight bits: the first three bits (0 to 2) represent IP precedence from 0 to 7; the subsequent four bits (3 to 6) represent a ToS value from 0 to 15. According to RFC 2474, the ToS field of the IP header is redefined as the differentiated services (DS) field, where a DSCP value is represented by the first six bits (0 to 5) and is in the range 0 to 63. The remaining two bits (6 and 7) are reserved.

Table 1-1 Description on IP Precedence

IP Precedence (decimal)	IP Precedence (binary)	Description
0	000	Routine
1	001	priority
2	010	immediate
3	011	flash
4	100	flash-override
5	101	critical
6	110	internet
7	111	network

In a network in the Diff-Serve model, traffic is grouped into the following four classes, and packets are processed according to their DSCP values.

l Expedited Forwarding (EF) class: In this class, packets are forwarded regardless of link share of other traffic. The class is suitable for preferential services requiring low delay, low packet loss, low jitter, and high bandwidth.

l Assured forwarding (AF) class: This class is divided into four subclasses (AF 1 to AF 4), each containing three drop priorities for more granular classification. The QoS level of the AF class is lower than that of the EF class.

l Class selector (CS) class: This class is derived from the IP ToS field and includes eight subclasses;

l Best effort (BE) class: This class is a special CS class that does not provide any assurance. AF traffic exceeding the limit is degraded to the BE class. Currently, all IP network traffic belongs to this class by default.

Table 1-2 Description on DSCP values

DSCP value (decimal)	DSCP value (binary)	Description
46	101110	ef
10	001010	af11
12	001100	af12
14	001110	af13
18	010010	af21
20	010100	af22
22	010110	af23
26	011010	af31
28	011100	af32
30	011110	af33
34	100010	af41
36	100100	af42
38	100110	af43
8	001000	cs1
16	010000	cs2
24	011000	cs3
32	100000	cs4
40	101000	cs5
48	110000	cs6
56	111000	cs7
0	000000	be (default)

2) 802.1p priority

802.1p priority lies in Layer 2 packet headers and is applicable to occasions where Layer 3 header analysis is not needed and QoS must be assured at Layer 2.

Figure 1-4 An Ethernet frame with an 802.1Q tag header

As shown in Figure 1-4, the 4-byte 802.1Q tag header consists of the tag protocol identifier (TPID, two bytes in length), whose value is 0x8100, and the tag control information (TCI, two bytes in length). Figure 1-5 presents the format of the 802.1Q tag header.

Figure 1-5 802.1Q tag header

The priority in the 802.1Q tag header is called 802.1p priority, because its use is defined in IEEE 802.1p. Table 1-3 presents the values for 802.1p priority.

Table 1-3 Description on 802.1p priority

802.1p priority (decimal)	802.1p priority (binary)	Description
0	000	best-effort
1	001	background
2	010	spare
3	011	excellent-effort
4	100	controlled-load
5	101	video
6	110	voice
7	111	network-management

2 QoS Policy Configuration

Interfaces mentioned in this section represent Layer 2 Ethernet ports and Layer 3 Ethernet interfaces. Layer 3 Ethernet interfaces refer to Ethernet ports configured to operate in route mode. For how to switch the operating mode of an Ethernet port, refer to Ethernet Interface Configuration in the Access Volume.

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

l QoS Policy Overview

l Configuring a QoS Policy

l Applying the QoS Policy

l Displaying and Maintaining QoS Policies

QoS Policy Overview

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

Class

Classes are used to identify traffic.

A class is identified by a class name and contains some match criteria.

You can define a set of match criteria to classify packets, and the relationship between criteria can be and or or.

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

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

Traffic behavior

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

Policy

A policy associates a class with a traffic behavior.

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

Configuring a QoS Policy

Follow these steps to configure a QoS policy:

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

2) Create a traffic behavior and define a set of QoS actions in traffic behavior view.

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

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
Enter system view	system-view	—
Create a class and enter class view	traffic classifier tcl-name [ operator { and \| or } ]	Required By default, the relation between match criteria is and.
Define a match criterion	if-match match-criteria	Required

match-criteria: Matching clauses to be defined for a class. Table 2-1 describes the available keyword and argument combinations for this argument.

Table 2-1 The keyword and argument combinations for the match-criteria argument

Keyword and argument combination	Description
acl { access-list-number \| name acl-name }	Matches an IPv4 ACL specified by its number or name. The access-list-number argument specifies an ACL by its number, which ranges from 2000 to 4999; the name acl-name keyword-argument combination specifies an ACL by its name. Note that a packet is regarded matching the ACL if it matches a rule in the ACL, regardless of whether the operator configured in the class is and or or.
acl ipv6 { access-list-number \| name acl-name }	Matches an IPv6 ACL specified by its number or name. The access-list-number argument specifies an ACL by its number, which ranges from 2000 to 3999; the name acl-name keyword-argument combination specifies an ACL by its name. Note that a packet is regarded matching the ACL if it matches a rule in the ACL, regardless of whether the operator configured in the class is and or or.
any	Matches all packets.
customer-dot1p 8021p-list	Matches packets by 802.1p precedence of customer network. The 8021p-list argument is a list of CoS values, in the range of 0 to 7.
customer-vlan-id vlan-id-list	Matches the packets of specified VLANs of user networks. The vlan-id-list argument specifies a list of VLAN IDs, in the form of vlan-id to vlan-id or multiple discontinuous VLAN IDs (separated by space). You can specify up to eight VLAN IDs for this argument at a time. VLAN ID is in the range 1 to 4094.
destination-mac mac-address	Matches the packets with a specified destination MAC address.
dscp dscp-list	Matches packets by DSCP precedence. The dscp-list argument is a list of DSCP values. You can provide up to eight space-separated DSCP values for this argument. DSCP is in the range of 0 to 63.
ip-precedence ip-precedence-list	Matches packets by IP precedence. The ip-precedence-list argument is a list of IP precedence values. You can provide up to eight space-separated IP precedence values for this argument. IP precedence is in the range 0 to 7.
protocol protocol-name	Matches the packets of a specified protocol. The protocol-name argument can be IP, IPv6.
service-dot1p 8021p-list	Matches packets by 802.1p precedence of the service provider network. The 8021p-list argument is a list of CoS values in the range of 0 to 7.
service-vlan-id vlan-id-list	Matches the packets of the VLANs of the operator’s network. The vlan-id-list argument is a list of VLAN IDs, in the form of vlan-id to vlan-id or multiple discontinuous VLAN IDs (separated by space). You can specify up to eight VLAN IDs for this argument at a time. VLAN ID is in the range of 1 to 4094.
source-mac mac-address	Matches the packets with the specified source MAC address.

Configuration example

1) Network requirements

Configure a class named test to match the packets with their IP precedence being 6.

2) Configuration procedure

# Enter system view.

<Sysname> system-view

# Create the class and enter the class view.

[Sysname] traffic classifier test

# Define the classification rule.

[Sysname-classifier-test] if-match ip-precedence 6

Defining a Traffic Behavior

A traffic behavior is a set of QoS actions. To define a traffic behavior, you must first create it and then configure actions for the behavior as required in traffic behavior view.

If you want to define a primap behavior, you need to define a priority mapping table as required. Refer to Priority Mapping Configuration for more information.

Follow these steps to define a traffic behavior:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a traffic behavior and enter traffic behavior view	traffic behavior behavior-name	Required
Enable traffic accounting	accounting	Optional
Configure a CAR policy	car cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ pir peak-information-rate ] [ red action ]	Optional For detailed information about CAR, refer to Traffic Policing and Traffic Shaping Configuration.
Reference an aggregation CAR policy	car name car-name	Optional For detailed information about aggregation CAR, refer to Aggregation CAR Configuration.
Drop or send packets	filter { deny \| permit }	Optional l deny Dropping packets. l permit Permitting packets to pass through.
Configure a GTS policy	gts cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size [ queue-length queue-length ] ] ] [ pir peak-information-rate ]	Optional For detailed information about GTS, refer to Traffic Policing and Traffic Shaping Configuration.
Mirror packets to the CPU or an interface	mirror-to { cpu \| interface interface-type interface-number }	Optional For detailed information about traffic mirroring, refer to Traffic Mirroring Configuration.
Insert a VLAN tag	nest top-most vlan-id vlan-id	Optional
Perform priority mapping with the specified priority mapping table to obtain a set of QoS priority values for the interesting packets	primap pre-defined { dscp-lp \| dscp-dp \| dscp-dot1p \| dscp-dscp }	Optional
Redirect traffic to a specified target	redirect { cpu \| interface interface-type interface-number \| next-hop { ipv4-add [ ipv4-add ] \| ipv6-add [ interface-type interface-number ] [ ipv6-add [ interface-type interface-number ] ] } }	Optional
Set the DSCP value for packets	remark dscp dscp-value	Optional
Set the 802.1p priority for packets	remark dot1p 8021p	Optional
Set the drop precedence for packets	remark drop-precedence drop-precedence-value	Optional
Set the IP precedence for packets	remark ip-precedence ip-precedence-value	Optional
Set the local precedence for packets	remark local-precedence local-precedence	Optional
Set the provider network VLAN ID for packets	remark service-vlan-id vlan-id-value	Optional
Display traffic behavior configuration information	display traffic behavior { system-defined \| user-defined } [ behavior-name ]	Optional Available in any view

Some actions are conflicting. Avoid configuring them in the same traffic behavior, because doing so can prevent the policy referencing the behavior from being successfully applied.

l The accounting command is conflicting with the aggregation CAR action.

l The filter deny command is conflicting with all other actions.

l The primap command is conflicting with all remark commands but the remark dscp command.

l The redirect next-hop command is conflicting with the remark service-vlan-id command and the nest command.

l The remark service-vlan-id command is conflicting with the nest command.

Configuration example

1) Network requirements

Create a traffic behavior named test, configuring TP action for it, with the CAR being 100 kbps.

2) Configuration procedure

# Enter system view.

<Sysname> system-view

# Create the traffic behavior (This operation leads you to traffic behavior view).

[Sysname] traffic behavior test

# Configure TP action for the traffic behavior.

[Sysname-behavior-test] car cir 100

Defining a Policy

Configuration procedure

A policy is a set of associations between classes and traffic behaviors. These associations are executed in the order they are configured.

QoS can collaborate with some other functions to limit the effective scope of a class-behavior association. These collaborative functions include VLAN mapping, IP source guard, and voice VLAN.

l With VLAN mapping, the class-behavior association applies only for VLAN mapping.

l With IP source guard, the class-behavior association applies to only the packets passing the check of the IP source guard module. For information about IP source guard, refer to IP Source Guard Configuration in the Security Volume.

l With voice VLAN, the class-behavior association applies to only the packets recognized as voice packets by the switch. A switch considers a packet as a voice packet if its source MAC address matches the OUI list maintained by the switch for identifying voice traffic. For information about OUI addresses, refer to VLAN Configuration in the Access Volume.

To collaborate with the IP source guard or voice VLAN module, a class-behavior association must be configured with the if-match any clause as its classifier for matching any packets.

To reduce your configuration efforts, the multi-service cooperation QoS mode is provided. This mode is a global configuration. After it is enabled,

l All class-behavior associations configured with the if-match any clause as the only traffic classifier apply to only the packets passing the check of the IP source guard function.

l All class-behavior associations configured with the if-match source-mac oui-mac (oui-mac is a MAC address matching the OUI list of the device) clause as the only traffic classifier collaborates with the voice VLAN feature, that is, the class-behavior association applies to all packets whose source MAC addresses are in the OUI list of the switch.

Multi-service cooperation QoS mode takes effect on all QoS policies applied to ports.

If neither a collaborative function nor the multi-service cooperation QoS mode is specified, a QoS policy applies to all packets.

Follow these steps to associate a class with a behavior in a QoS policy:

To do …	Use the command…	Remarks
Enter system view	system-view	—
Enable the multi-service cooperation QoS mode globally	policy mode multi-service-cooperation	Optional This mode applies to only the QoS policies configured after it is enabled.
Create a policy and enter the policy view	qos policy policy-name	Required
Associate a traffic behavior with a class	classifier tcl-name behavior behavior-name [ mode { do1q-tag-manipulation \| ip-source-guard \| voice-vlan } ]	Required If needed, you can specify a collaborative module to limit the effective scope of the class-behavior association. If you have enabled the multi-service cooperation QoS mode, you are recommended not to specify the ip-source-guard or voice-vlan keyword.
Display the configuration of the specified class in the specified policy and the behavior associated with the class	display qos policy user-defined [ policy-name [ classifier tcl-name ] ]	Optional Available in any view

Configuration example

Configure IP source guard on port Ethernet 1/0/1, enabling its dynamic binding function (which collaborates with DHCP snooping to obtain IP-MAC address entries) and creating a static binding for IP address 1.1.1.1 and MAC address 0000-0000-0002. Enable the IP source guard to collaborate with a QoS policy to limit the rate of the traffic originated from any of its IP-MAC address binding entry to 10 Mbps.

# Create a CAR policy to limit the traffic rate to 10 Mbps. When associating a behavior with a class in the policy, configure the class-behavior association to apply to only the IP source guard function.

<Sysname> system-view

[Sysname] traffic classifier cl

[Sysname-classifier-c1] if-match any

[Sysname-classifier-c1] quit

[Sysname] traffic behavior be

[Sysname-behavior-be] car cir 10000

[Sysname-behavior-be] quit

[Sysname] qos policy ipcheck

[Sysname-qospolicy-ipcheck] classifier cl behavior be mode ip-source-guard

[Sysname-qospolicy-ipcheck] quit

# Apply the policy to the inbound direction of Ethernet 1/0/1.

[Sysname]interface Ethernet 1/0/1

[Sysname-Ethernet1/0/1]qos apply policy ipcheck inbound

# Configure the dynamic binding function of IP source guard and enable DHCP snooping on Ethernet 1/0/1.

[Sysname-Ethernet1/0/1] ip check source ip-address mac-address

[Sysname-Ethernet1/0/1]quit

[Sysname] dhcp-snooping

# Bind IP address 1.1.1.1 and MAC address 0000-0000-0002 with Ethernet 1/0/1.

[Sysname-Ethernet1/0/1] user-bind ip-address 1.1.1.1 mac-address 0-0-2

Applying the QoS Policy

You can apply the QoS policy to different occasions:

l Applied to an interface, the policy takes effect on the traffic sent or received on the interface;

l Applied to a VLAN, the policy takes effect on the traffic sent or received on all ports in the VLAN;

l Applied globally, the policy takes effect on the traffic sent or received on all ports.

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

Applying the QoS Policy to an Interface

A policy can be applied to multiple interfaces. Only one policy can be applied in one direction of an interface. Currently, the S3610 and S5510 series switches support QoS policies only in the inbound direction.

Configuration procedure

Follow these steps to apply the QoS policy to an interface:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Apply the policy to the interface/port group		qos apply policy policy-name inbound	Required

Configuration example

1) Network requirements

Configure a policy named test to associate the traffic behavior named test_behavior with the class named test_class. Apply the policy to the inbound direction of Ethernet 1/0/1 port.

2) Configuration procedure

# Enter system view.

<Sysname> system-view

# Create a policy and enter the policy view.

[Sysname]qos policy test

[Sysname-qospolicy-test]

# Associate the traffic behavior named test_behavior with the class named test_class.

[Sysname-qospolicy-test] classifier test_class behavior test_behavior

[Sysname-qospolicy-test] quit

# Enter port view.

[Sysname] interface Ethernet 1/0/1

[Sysname-Ethernet1/0/1]

# Apply the policy to the port.

[Sysname-Ethernet1/0/1] qos apply policy test inbound

Applying the QoS Policy to a VLAN

You can apply a QoS policy to a VLAN to regulate traffic of the VLAN.

Configuration procedure

Follow these steps to apply the QoS policy to a VLAN:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Apply the QoS policy to the specified VLAN(s)	qos vlan-policy policy-name vlan vlan-id-list inbound	Required

l QoS policies cannot be applied to dynamic VLANs, for example, VLANs created by GVRP.

l On an S5510 series switch, if the QoS policy containing a traffic policing action is applied to a VLAN containing any of the first 12 ports and any of the last 16 ports at the same time, traffic twice the defined traffic limit may pass.

Configuration example

# Apply QoS policy test_policy to the inbound direction of VLAN 200, VLAN 300, VLAN 400, and VLAN 500.

<Sysname> system-view

[Sysname] qos vlan-policy test_policy vlan 200 300 400 500 inbound

Applying the QoS Policy Globally

You can apply the QoS policy globally to the inbound direction of all ports.

Configuration procedure

Follow these steps to apply a QoS policy globally:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Apply a QoS policy globally	qos apply policy policy-name global inbound	Required

Configuration example

# Apply QoS policy test_policy to the inbound direction globally.

<Sysname> system-view

[Sysname] qos apply policy test_policy global inbound

Displaying and Maintaining QoS Policies

To do…	Use the command…	Remarks
Display traffic class information	display traffic classifier user-defined [ tcl-name ]	Available in any view
Display traffic behavior configuration information	display traffic behavior user-defined [ behavior-name ]	Available in any view
Display system-defined or user-defined QoS policy configuration information	display qos policy user-defined [ policy-name [ classifier tcl-name ] ]	Available in any view
Display QoS policy configuration on the specified or all interfaces	display qos policy interface [ interface-type interface-number ] [ inbound ]	Available in any view
Display VLAN QoS policy information	display qos vlan-policy { name policy-name \| vlan vlan-id }	Available in any view
Display information of global QoS policies	display qos policy global inbound	Available in any view
Clear VLAN QoS policy statistics	reset qos vlan-policy [ vlan vlan-id ]	Available in user view
Clear statistics of a global QoS policy	reset qos policy global { inbound \| outbound }	Available in user view

3 Priority Mapping Configuration

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

l Priority Mapping Overview

l Configuring a Priority Mapping Table

l Configuring the 802.1P Priority of a Port

l Configuring the Trusted Precedence Type for a Port

l Displaying and Maintaining Priority Mapping

Priority Mapping Overview

Introduction to Priority Mapping

When a packet enters a network, it will be marked with a certain value, which indicates the scheduling weight or forwarding priority of the packet. Then, the intermediate nodes in the network process the packet according to the priority.

When a packet enters a device, the device assigns to the packet a set of predefined parameters (including the 802.1p priority, DSCP values, IP precedence, local precedence, and drop precedence).

Concepts

For more information about 802.1p priority, DSCP values, and IP precedence, refer to Packet Precedences.

The local precedence and drop precedence are described as follows.

l Local precedence is the precedence that the switch assigns to a packet and it corresponds to the number of an output queue on the port. Local precedence takes effect only on the local switch.

l Drop precedence is a parameter that is referred to when dropping packets. The higher the drop precedence, the more likely a packet is dropped.

For packets without 802.1q tags, the switch uses the priority of the receiving port as the 802.1p precedence of the received packets, and then obtains the local precedence of the received packets by mapping the 802.1p precedence.

For packets with 802.1q tags, the switch provides the following two priority trust modes:

l Trusting packet priority

The switch looks up the 802.1p-to-local and 802.1p-to-drop priority mapping tables based on the 802.1p priority of received packets for the local precedence and drop precedence to be assigned to the received packets.

l Trusting port priority

The switch looks up the 802.1p-to-local and 802.1p-to-drop priority mapping tables based on the 802.1p priority of the receiving port instead of that carried in the received packets for the local precedence and drop precedence to be assigned to the received packets.

Introduction to Priority Mapping Tables

The device provides various types of priority mapping table, as listed below.

l dot1p-dp: 802.1p-to-drop priority mapping table.

l dot1p-lp: 802.1p-to-local priority mapping table.

l dscp-dot1p: DSCP-to-802.1p priority mapping table, which is applicable to only IP packets.

l dscp-dp: DSCP-to-drop priority mapping table, which is applicable to only IP packets.

l dscp-dscp: DSCP-to-DSCP priority mapping table, which is applicable to only IP packets.

l dscp-lp: DSCP-to-local priority mapping table, which is applicable to only IP packets.

Table 3-1 and Table 3-2 list the default priority mapping tables.

Table 3-1 The default dot1p-lp and dot1p-dp mappings

Input priority value	dot1p-lp mapping	dot1p-dp mapping
802.1p priority (dot1p)	Local precedence (lp)	Drop precedence (dp)
0	2	0
1	0	0
2	1	0
3	3	0
4	4	0
5	5	0
6	6	0
7	7	0

Table 3-2 The default dscp-lp, dscp-dp, and dscp-dot1p mappings

Input priority value	dscp-lp mapping	dscp-dp mapping	dscp-dot1p mapping
dscp	Local precedence (lp)	Drop precedence (dp)	802.1p priority (dot1p)
0 to 7	0	0	0
8 to 15	1	0	1
16 to 23	2	0	2
24 to 31	3	0	3
32 to 39	4	0	4
40 to 47	5	0	5
48 to 55	6	0	6
56 to 63	7	0	7

For the default dscp-dscp mappings, an input value yields a target value that is equal to it.

Configuring a Priority Mapping Table

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

Configuration Prerequisites

You need to decide on the new mapping values.

Configuration Procedure

Follow these steps to configure a priority mapping table:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter priority mapping table view	qos map-table { dot1p-lp \| dot1p-dp \| dscp-lp \| dscp-dp \| dscp-dot1p \| dscp-dscp }	Required You can enter the corresponding priority mapping table view as required.
Configure the priority mapping table	import import-value-list export export-value	Required Newly configured mappings overwrite the previous ones.

Configuration Example

Network requirements

Configure a dot1p-lp priority mapping table as shown below.

Table 3-3 dot1p-lp mappings

802.1p priority	Local precedence
0	0
1	0
2	1
3	1
4	2
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 dot1p-lp

# Modify dot1p-lp priority mapping parameters.

[Sysname-maptbl-dot1p-lp] import 0 1 export 0

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

[Sysname-maptbl-dot1p-lp] import 4 5 export 2

[Sysname-maptbl-dot1p-lp] import 6 7 export 3

Configuring the 802.1P Priority of a Port

By default, the switch uses the priority of the receiving port as the 802.1p priority of the received packets, and based on it looks up the 802.1p-to-local priority mapping table for local precedence, and assigns the local precedence to the received packets. The packets are then put into output queues by their local precedence.

Port priority is in the range 0 to 7. You can tune the 802.1p priority of a port as needed.

Configuration Prerequisites

You need to decide on a priority for the port.

Configuration Procedure

Follow these steps to configure port priority:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Configure a priority for the port		qos priority priority-value	Required The default port priority is 0.

Configuration Example

Network requirements

Set the port priority of port Ethernet 1/0/1 to 7.

Configuration procedure

# Enter system view.

<Sysname> system-view

# Set the priority of Ethernet 1/0/1 to 7.

[Sysname] interface ethernet 1/0/1

[Sysname-Ethernet1/0/1] qos priority 7

Configuring the Trusted Precedence Type for a Port

You can configure your switch to trust the 802.1p precedence carried in received packets instead of using the priority of the receiving port as the 802.1p precedence of the received packets.

Configuration Prerequisites

It is determined to trust the 802.1p precedence of received packets.

Configuration Procedure

Follow these steps to configure the trusted precedence type:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group..
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Configure to trust the 802.1p priority carried in the received packets		qos trust dot1p	Required By default, port priority is trusted.

Configuration Example

Network requirements

Configure port Ethernet 1/0/1 to trust the 802.1p priority of received packets.

Configuration procedure

# Enter system view.

<Sysname> system-view

# Enter port view.

[Sysname] interface ethernet 1/0/1

# Configure port Ethernet 1/0/1 to trust the 802.1p priority of received packets.

[Sysname-Ethernet1/0/1] qos trust dot1p

Displaying and Maintaining Priority Mapping

To do…	Use the command…	Remarks
Display priority mapping table configuration information	display qos map-table [ dot1p-lp \| dot1p-dp \| dscp-lp \| dscp-dp \| dscp-dot1p \| dscp-dscp ]	Available in any view
Display the trusted precedence type on the port	display qos trust interface [ interface-type interface-number ]	Available in any view

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

l Traffic Policing and Traffic Shaping Overview

l Traffic Policing, GTS and Line Rate Configuration

l Displaying and Maintaining Traffic Policing, GTS and Line Rate

Traffic Policing and Traffic Shaping Overview

If user traffic is not limited, burst traffic will make the network more congested. Therefore it is necessary to limit user traffic in order to better utilize the network resources and provide better services for more users. For example, you can configure a flow to use only the resources committed to it in a time range, thus avoiding network congestion caused by burst traffic.

Traffic policing and generic traffic shaping (GTS) limit traffic rate and resource usage according to traffic specifications. The prerequisite for traffic policing or GTS is to know whether a traffic flow has exceeded the specification. If yes, proper traffic control policies are applied. Generally, token buckets are used to evaluate traffic specifications.

Traffic Evaluation and Token Bucket

Token bucket features

A token bucket can be considered as a container holding a certain number of tokens. The system puts tokens into the bucket at a set rate. When the token bucket is full, the extra tokens will overflow.

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:

l Mean rate: At which tokens are put into the bucket, namely, the permitted average rate of traffic. It is usually set to the committed information rate (CIR).

l Burst size: the capacity of the token bucket, namely, the maximum traffic size that is permitted in each burst. It is usually set to the committed burst size (CBS). The set burst size must be greater than the maximum packet size.

One evaluation is performed on each arriving packet. In each evaluation, if the number of tokens in the bucket is enough, the traffic conforms to the specification and the corresponding tokens for forwarding the packet are taken away; if the number of tokens in the bucket is not enough, it means that too many tokens have been used and the traffic is excessive.

Complicated evaluation

You can set two token buckets (referred to as the C bucket and E bucket respectively) in order to evaluate more complicated conditions and implement more flexible regulation policies. For example, traffic policing uses four parameters:

l CIR: Rate at which tokens are put into the C bucket, that is, the average packet transmission or forwarding rate allowed by the C bucket.

l CBS: Size of the C bucket, that is, transient burst of traffic that the C bucket can forward.

l Peak information rate (PIR): Rate at which tokens are put into the E bucket, that is, the average packet transmission or forwarding rate allowed by the E bucket.

l Excess burst size (EBS): Size of the E bucket, that is, transient burst of traffic that the E bucket can forward.

Two token buckets are used in this evaluation. Their rates of putting tokens into the buckets are CIR and PIR respectively, and their sizes are CBS and EBS respectively (the two buckets are called C bucket and E bucket respectively for short), representing different permitted burst levels.

In each evaluation, packets are measured against the buckets:

l If the C bucket has enough tokens, packets are colored green.

l If the C bucket does not have enough tokens but the E bucket has enough tokens, packets are colored yellow.

l If neither the C bucket nor the E bucket has sufficient tokens, packets are colored red.

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.

Figure 4-1 Schematic diagram for GTS

Traffic policing is widely used in policing traffic entering the networks of internet service providers (ISPs). It can classify the policed traffic and perform pre-defined policing actions based on different evaluation results. These actions include:

l Forwarding the packets whose evaluation result is “conforming”.

l Dropping the packets whose evaluation result is “excess”.

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 4-2. 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 4-2 Schematic diagram for GTS

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

Figure 4-3 GTS application

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

Traffic Policing, GTS and Line Rate Configuration

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

Task	Remarks
Configuring traffic policing	Configure an ACL
Configuring traffic policing	Apply CAR policies to the specified interface
Configuring queue-based GTS	Configure GTS on interfaces
Configuring GTS for all traffic	Configure GTS on interfaces

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 traffic policing

Follow these steps to configure ACL-based traffic policing:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Configure an ACL		Refer to the ACL module	Required
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Configure an ACL based CAR policy on the interface/port group		qos car inbound acl [ ipv6 ] acl-number cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ pir peak-information-rate ] [ red action ]	Required CBS defaults to 100,000 bytes. EBS defaults to 100,000 bytes. PIR defaults to 0. The red action keyword is discard by default.

Traffic policing configuration example

Configure TP on Ethernet1/0/1 to control the packets received by Ethernet1/0/1 port and matching IPv4 ACL 2000. Packets are dropped if the traffic rate exceeds 1000 kbps.

# Enter system view.

<Sysname> system-view

# Enter port view.

[Sysname] interface Ethernet 1/0/1

# Configure TP parameters.

[Sysname-Ethernet1/0/1] qos car inbound acl 2000 cir 1000 red discard

Configuring GTS

Traffic shaping configuration involves:

l Queue-based GTS: configuring GTS parameters for packets of a certain queue.

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

Configuring queue-based GTS

Follow these steps to configure queue-based GTS:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Configure GTS for a queue		qos gts queue queue-number cir committed-information-rate [ cbs committed-burst-size ]	Required CIR must be a multiple of 650. CBS must be a multiple of 4000.

Configuring GTS for all traffic

Follow these steps to configure GTS for all traffic:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Configure GTS on the interface/port group		qos gts any cir committed-information-rate [ cbs committed-burst-size ]	Required CIR must be a multiple of 650. CBS must be a multiple of 4000.

GTS configuration example

Configure GTS for Ethernet1/0/1 port. Cache the packets when the traffic rate exceeds 1,300 kbps.

# Enter system view.

<Sysname> system-view

# Enter port view.

[Sysname] interface Ethernet 1/0/1

# Configure TS parameters.

[Sysname-Ethernet1/0/1] qos gts any cir 1300

Displaying and Maintaining Traffic Policing, GTS and Line Rate

To do…	Use the command…	Remarks
Display the CAR information on the specified interface	display qos car interface [ interface-type interface-number ]	Available in any view
Display interface GTS configuration information	display qos gts interface [ interface-type interface-number ]	Available in any view

5 Aggregation CAR Configuration

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

l Aggregation CAR Overview

l Configuring an Aggregation CAR Policy

l Referencing Aggregation CAR in a Traffic Behavior

l Displaying and Maintaining Aggregation CAR

Aggregation CAR Overview

Aggregation CAR means to use the same CAR for traffic on multiple ports. If aggregation CAR is enabled for multiple ports, the total traffic on these ports must conform to the traffic policing parameters set in the aggregation CAR.

For the S5510 series Ethernet switches, if you apply the same aggregation CAR to any of the first 12 ports on the switch and any of the last 16 ports on a switch at the same time, the actual traffic limit may be twice the limit defined in the aggregation CAR.

Configuring an Aggregation CAR Policy

Configuration Prerequisites

You need to decide on:

l Aggregation CAR parameters.

l Interfaces where the aggregation CAR policy is to be applied.

l Traffic match criteria; the ACL must be predefined.

l Refer to ACL configuration in the Security Volume for how to define ACL rules.

Configuration Procedure

Follow these steps to configure aggregation CAR:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Configure an aggregation CAR policy		qos car global-car-name aggregative cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ pir peak-information-rate ] [ red action ]	Required CBS is 100,000 bytes by default. EBS is 100,000 bytes by default. PIR is 0 by default. The default action for red packets is discard.
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Apply the aggregation CAR policy on the interface/port group		qos car inbound acl [ ipv6 ] acl-number name global-car-name	Required

Configuration Example

Configure aggregation CAR on Ethernet 1/0/1 and Ethernet 1/0/2 to limit the rate of received traffic matching IPv4 ACL 2001 of the two ports to 1000 kbps and drop the exceeding packets.

Configuration procedure:

# Enter system view.

<Sysname> system-view

# Configure aggregation CAR aggcar-1.

[Sysname] qos car aggcar-1 aggregative cir 1000

# Apply aggregation CAR aggcar-1 in the inbound direction of Ethernet 1/0/1 and Ethernet 1/0/2.

[Sysname] interface Ethernet 1/0/1

[Sysname-Ethernet1/0/1] qos car inbound acl 2001 name aggcar-1

[Sysname-Ethernet1/0/1] quit

[Sysname] interface Ethernet 1/0/2

[Sysname-Ethernet1/0/2] qos car inbound acl 2001 name aggcar-1

Referencing Aggregation CAR in a Traffic Behavior

Configuration Prerequisites

You need to decide on:

l Aggregation CAR parameters

l Traffic behavior to reference the aggregation CAR.

Configuration Procedure

Follow these steps to reference aggregation CAR in a traffic behavior:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Configure aggregation CAR parameters	qos car global-car-name aggregative cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ pir peak-information-rate ] [ red action ]	Required CBS is 100,000 bytes by default. EBS is 100,000 bytes by default. PIR is 0 by default. The default action for red packets is discard.
Enter traffic behavior view	traffic behavior behavior-name	Required
Reference the aggregation CAR	car name car-name	Required

Configuration Example

# Specify the aggregation CAR aggcar-1 to adopt the following parameters: CIR is 200, CBS is 2,000, and red packets are dropped. Reference aggregation CAR aggcar-1 in traffic behavior be1.

<Sysname> system-view

[Sysname] qos car aggcar-1 aggregative cir 200 cbs 2000 red discard

[Sysname] traffic behavior be1

[Sysname-behavior-be1] car name aggcar-1

Displaying and Maintaining Aggregation CAR

To do…	Use the command…	Remarks
Display the statistics for the specified aggregation CAR	display qos car name [ car-name ]	Required Available in any view
Clear the statistics for the specified aggregation CAR	reset qos car name [ car-name ]	Required Available in user view

To do…

Use the command…

Remarks

Display the statistics for the specified aggregation CAR

display qos car name [ car-name ]

Required

Available in any view

Clear the statistics for the specified aggregation CAR

reset qos car name [ car-name ]

Required

Available in user view

6 Congestion Management Configuration

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

l Overview

l Configuring SP Queuing

l Configuring WRR Queuing

l Configuring SP+WRR Queuing

l Displaying Congestion Management

Overview

Congestion occurs on an interface when the arrival rate of packets is faster than the sending rate. If there is no enough buffer capacity to store these packets, a part of them will be lost, which may cause the sending device to retransmit these packets because of timeout, deteriorating the congestion.

The key to congestion management is defining a dispatching policy for resources to decide the order of forwarding packets when congestion occurs. Congestion management involves queue creation, traffic classification, packet enqueuing, and queue scheduling.

Congestion Management Policies

In general, congestion management adopts queuing technology. The system uses a certain queuing algorithm for traffic classification, and then uses a certain precedence algorithm to send the traffic. Each queuing algorithm deals with a particular network traffic problem and has significant impacts on bandwidth resource assignment, delay, and jitter.

Queue scheduling processes packets by their priorities, preferentially forwarding high-priority packets. In the following section, Strict Priority (SP) queuing, Weighted Fair Queuing (WFQ), and Weighted Round Robin (WRR) queuing are introduced.

SP queuing

SP queuing is specially designed for mission-critical applications, which require preferential service to reduce the response delay when congestion occurs.

Figure 6-1 Schematic diagram for SP queuing

As shown in Figure 6-1, SP queuing classifies eight queues on a port into eight classes, numbered 7 to 0 in descending priority order.

SP queuing schedules the eight queues strictly according to the descending order of priority. It sends packets in the queue with the highest priority first. When the queue with the highest priority is empty, it sends packets in the queue with the second highest priority, and so on. Thus, you can assign mission-critical packets to the high priority queue to ensure that they are always served first and common service packets to the low priority queues and transmitted when the high priority queues are empty.

The disadvantage of SP queuing is that packets in the lower priority queues cannot be transmitted if there are packets in the higher priority queues. This may cause lower priority traffic to starve to death.

WRR queuing

WRR queuing schedules all the queues in turn to ensure that every queue can be served for a certain time, as shown in Figure 6-2.

Figure 6-2 Schematic diagram for WRR queuing

Assume there are eight output queues on a port. WRR assigns each queue a weight value (represented by w7, w6, w5, w4, w3, w2, w1, or w0) to decide the proportion of resources assigned to the queue. On a 100 Mbps port, you can configure the weight values of WRR queuing to 50, 50, 50, 50, 10, 10, 10, and 10 (corresponding to w7, w6, w5, w4, w3, w2, w1, and w0 respectively). In this way, the queue with the lowest priority is assured of 5 Mbps of bandwidth at least, thus avoiding the disadvantage of SP queuing that packets in low-priority queues may fail to be served for a long time.

Another advantage of WRR queuing is that while the queues are scheduled in turn, the service time for each queue is not fixed, that is, if a queue is empty, the next queue will be scheduled immediately. This improves bandwidth resource use efficiency.

The H3C S3610 and S5510 Series Ethernet Switches support the following three queue scheduling algorithms:

l SP only: All the queues are scheduled with the SP algorithm.

l WRR only: All the queues are scheduled with the WRR algorithm.

l SP+WRR: Some queues are scheduled with the SP algorithm, while other queues are scheduled with the WRR algorithm.

Configuring SP Queuing

Configuration procedure

Follow these steps to configure SP queuing:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Configure SP queuing		undo qos wrr	Required By default, the SP queue scheduling algorithm is adopted on all the ports.

Configuration example

Network requirements

Configure Ethernet 1/0/1 to adopt SP queuing.

Configuration procedure

# Enter system view

<Sysname> system-view

# Configure Ethernet1/0/1 to adopt SP queuing.

[Sysname]interface ethernet 1/0/1

[Sysname-Ethernet1/0/1] undo qos wrr

Configuring WRR Queuing

You can assign the output queues into WRR scheduling group 1 and WRR scheduling group 2. The queues assigned to each group must be consecutive. Within each group, queues are scheduled with WRR. Between the two groups, SP scheduling is adopted, with the group containing the highest queue scheduled preferentially. For example, queues 0 to 3 are in WRR group 1, and queues 4 to 7 are in group 2. Round robin queuing is performed in WRR group 2 first. If no packet is to be sent in WRR group 2, round robin queuing is performed in WRR group 1.

Configuration procedure

Follow these steps to configure group-based WRR queuing:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Configure a WRR queue		qos wrr queue-id group group-id weight queue-weight	Required By default, the SP queue scheduling algorithm is adopted on all the ports.

Queues assigned to each WRR scheduling group must be consecutive.

Configuration example

Network requirements

Configure Ethernet 1/0/1 to use the WRR queue scheduling algorithm as follows:

l Assign queues 0, 1, 2, and 3 to WRR group 1, with the weight of 10, 20, 50, and 70 respectively.

l Assign queues 4, 5, 6, and 7 to WRR group 2, with the weight of 20, 50, 70, and 100 respectively.

Configuration procedure

# Enter system view.

<Sysname> system-view

# Configure WRR queuing on Ethernet 1/0/1.

[Sysname] interface Ethernet 1/0/1

[Sysname-Ethernet1/0/1] qos wrr 0 group 1 weight 10

[Sysname-Ethernet1/0/1] qos wrr 1 group 1 weight 20

[Sysname-Ethernet1/0/1] qos wrr 2 group 1 weight 50

[Sysname-Ethernet1/0/1] qos wrr 3 group 1 weight 70

[Sysname-Ethernet1/0/1] qos wrr 4 group 2 weight 20

[Sysname-Ethernet1/0/1] qos wrr 5 group 2 weight 50

[Sysname-Ethernet1/0/1] qos wrr 6 group 2 weight 70

[Sysname-Ethernet1/0/1] qos wrr 7 group 2 weight 100

Configuring SP+WRR Queuing

With SP+WRR queue scheduling, you can assign some queues on a port to an SP scheduling group and the others to two WRR scheduling groups (WRR scheduling groups 1 and 2). Queues assigned to each scheduling group must be consecutive. Between the groups, SP scheduling is adopted, with the group containing the highest queue scheduled preferentially.

For example, assign queues 0 and 1 to the SP queue scheduling group, and queues 2 to 4 to WRR scheduling group 1, queues 5 to 7 to WRR scheduling group 2. Queues in WRR group 2 are scheduled in a round robin way first. When no packet is to be sent in WRR group 2, round robin is performed in WRR group 1. At last, queues in the SP scheduling group are scheduled.

Configuration Procedure

Follow these steps to configure SP+WRR queuing:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter port view or port group view	Enter port view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter port view or port group view	Enter port group view	port-group manual port-group-name
Assign a queue to the SP scheduling group		qos wrr queue-id group sp	Required
Assign a queue to a WRR scheduling group		qos wrr queue-id group group-id weight queue-weight	Required

With SP+WRR, queues assigned to each scheduling group must be consecutive.

Configuration Example

Network requirements

Configure SP+WRR queue scheduling on Ethernet1/0/1:

l Assign queue 0 and queue 1 to the SP queue scheduling group.

l Assign queues 2 to 4 to WRR scheduling group 1, with their weights being 20, 70, and 100 respectively.

l Assign queues 5 to 7 to WRR scheduling group 2, with their weights being 10, 50, and 80 respectively.

Configuration procedure

# Enter system view.

<Sysname> system-view

# Configure SP+WRR queue scheduling on Ethernet1/0/1.

[Sysname] interface Ethernet 1/0/1

[Sysname-Ethernet1/0/1] qos wrr 0 group sp

[Sysname-Ethernet1/0/1] qos wrr 1 group sp

[Sysname-Ethernet1/0/1] qos wrr 2 group 1 weight 20

[Sysname-Ethernet1/0/1] qos wrr 3 group 1 weight 70

[Sysname-Ethernet1/0/1] qos wrr 4 group 1 weight 100

[Sysname-Ethernet1/0/1] qos wrr 5 group 2 weight 10

[Sysname-Ethernet1/0/1] qos wrr 6 group 2 weight 50

[Sysname-Ethernet1/0/1] qos wrr 7 group 2 weight 80

Displaying Congestion Management

To do…	Use the command…	Remarks
Display WRR queue configuration information	display qos wrr interface [ interface-type interface-number ]	Available in any view

7 Congestion Avoidance

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

l Congestion Avoidance Overview

l Configuring WRED

l Configuring Queue Length

l Displaying and Maintaining WRED

Congestion Avoidance Overview

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

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

Traditional packet drop policy

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

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

RED and WRED

When congestion is too serious, the switch can adopt the random early detection (RED) or weighted RED (WRED) algorithm to solve the problem of excessive congestion and avoid global TCP synchronization caused by the tail-drop algorithm.

In the RED algorithm, an upper limit and a lower limit are set for each queue, and it is stipulated that:

l When the queue length is smaller than the lower limit, packets are not dropped.

l When the queue length is bigger than the upper limit, all inbound packets all dropped.

l When the queue length is in the range of the upper limit and the lower limit, the inbound packets are dropped at random. In this case, a number is assigned to each inbound packet and then compared with the drop probability of the current queue. If the number is bigger than the drop probability, the inbound packet is dropped. The longer a queue is, the higher the drop probability is. However, there is a top drop probability.

Compared with the RED algorithm, the WRED algorithm generates precedence-based random numbers. It adopts IP precedence in determining drop policy and takes the benefits of high-precedence packets into consideration, so the drop probability is comparatively low.

In the RED and WRED algorithm, packets are dropped at random so that global TCP synchronization is avoided. When packets in a TCP connection are dropped and sent at a low rate, packets in other TCP connections are still sent at a high rate. In this way, packets in a part of connections are sent at a high rate in any case. Thus, the utilization rate of bandwidth is improved.

Queue length

In the following cases, you can increase the queue length to buffer more packets and improve packet forwarding performance:

l Network with dense broadcast or multicast traffic and large burst traffic

l Packets of high-speed links are forwarded through low-speed links, or packets received through multiple equal-rate interfaces at the same time are forwarded to one interface that is of the same rate.

By increasing the queue length, you can reduce the packet loss ratio and packet processing capability of the device in the cases mentioned above. Although increasing queue length improves the ability to process burst traffic, it reduces the ability of congestion avoidance.

Configuring WRED

Configuration Procedure

Follow these steps to configure WRED on an interface:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Enable WRED		qos wred enable	Required

Configuration Example

Network requirements

Enable WRED on Ethernet1/0/1.

Configuration procedure

# Enter system view.

<Sysname> system-view

# Enter port view.

[Sysname] interface Ethernet 1/0/1

# Enable WRED.

[Sysname-Ethernet1/0/1] qos wred enable

Configuring Queue Length

Configuration Prerequisites

The ports or port group requiring this configuration and the intended queue length values for each queue are determined.

Configuration Procedure

Follow these steps to configure WRED on an interface:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter interface view or port group view	Enter interface view	interface interface-type interface-number	Use either command Settings in interface view take effect on the current interface; settings in port group view take effect on all ports in the port group.
Enter interface view or port group view	Enter port group view	port-group manual port-group-name
Configure queue length		burst-traffic { queue queue-id length queue-length }&<1-8>	Required

Configuration Example

Network requirements

Set the queue length of queue 1 and queue 3 to 8 and 32 on Ethernet 1/0/1.

Configuration procedure

# Enter system view.

<Sysname> system-view

# Enter port view.

[Sysname] interface Ethernet 1/0/1

# Configure the length of each queue.

[Sysname-Ethernet1/0/1] burst-traffic queue 1 length 8 queue 3 length 32

Displaying and Maintaining WRED

To do…	Use the command…	Remarks
Display the configuration and statistics about WRED on ports	display qos wred interface [ interface-type interface-number ]	Available in any view
Display the queue length configuration on ports	display burst-traffic interface [ interface-type interface-number ]	Available in any view

8 Traffic Mirroring Configuration

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

l Traffic Mirroring Overview

l Configuring Traffic Mirroring

l Displaying and Maintaining Traffic Mirroring

l Traffic Mirroring Configuration Examples

Traffic Mirroring Overview

Traffic mirroring refers to the process of copying the specified packets to the specified destination for packet analysis and monitoring.

You can configure mirroring traffic to an interface, to the CPU, or to a VLAN.

l Mirroring traffic to an interface: copies the matching packets on an interface to a destination interface.

l Mirroring traffic to the CPU: copies the matching packets on an interface to a CPU (the CPU of the board where the traffic mirroring-enabled interface resides).

l Mirroring traffic to a VLAN: copies the matching packets on an interface to a VLAN. In this case, all the ports in the VLAN can receive the mirrored packets. Even if the VLAN does not exist, you can pre-define the action of mirroring traffic to the VLAN. After the VLAN is created and some ports join the VLAN, the action of mirroring traffic to the VLAN takes effect automatically.

On S3610 and S5510 series Ethernet switches, traffic can only be mirrored to ports and to CPU.

Configuring Traffic Mirroring

To configure traffic mirroring, you must enter the view of an existing traffic behavior.

In a traffic behavior, the action of mirroring traffic to a port, and the action of mirroring traffic to a CPU are mutually exclusive.

Mirroring Traffic to an Interface

Follow these steps to mirror traffic to an interface:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter traffic behavior view	traffic behavior behavior-name	—
Specify the destination interface for traffic mirroring	mirror-to interface interface-type interface-number	Required

Mirroring Traffic to the CPU

Follow these steps to mirror traffic to the CPU:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter traffic behavior view	traffic behavior behavior-name	—
Mirror traffic to the CPU	mirror-to cpu	Required The CPU refers to the CPU of the board where the interface to which the policy referencing the mirroring action is applied resides.

Displaying and Maintaining Traffic Mirroring

To do…	Use the command…	Remarks
Display traffic behavior configuration information	display traffic behavior user-defined [ behavior-name ]	Available in any view
Display QoS policy configuration information	display qos policy user-defined [ policy-name [ classifier tcl-name ] ]	Available in any view

Traffic Mirroring Configuration Examples

Example for Mirroring Traffic to an Interface

Network requirements

The user's network is as described below:

l Host A (with the IP address 192.168.0.1) and Host B are connected to Ethernet 1/0/1 of the switch.

l The data monitoring device is connected to Ethernet 1/0/2 of the switch.

It is required to monitor and analyze packets sent by Host A on the data monitoring device.

Figure 8-1 Network diagram for mirroring traffic to an interface

Configuration procedure

# Enter system view.

<Sysname> system-view

# Configure basic IPv4 ACL 2000 to match packets with the source IP address 192.168.0.1.

[Sysname] acl number 2000

[Sysname-acl-basic-2000] rule permit source 192.168.0.1 0

[Sysname-acl-basic-2000] quit

# Configure a traffic classification rule to use ACL 2000 for traffic classification.

[Sysname] traffic classfier 1

[Sysname-classifier-1] if-match acl 2000

[Sysname-classifier-1] quit

# Configure a traffic behavior and define the action of mirroring traffic to Ethernet1/0/2 in the traffic behavior.

[Sysname] traffic behavior 1

[Sysname-behavior-1] mirror-to interface Ethernet 1/0/2

[Sysname-behavior-1] quit

# Configure a QoS policy and associate traffic behavior 1 with classification rule 1.

[Sysname] qos policy 1

[Sysname-policy-1] classifier 1 behavior 1

[Sysname-policy-1] quit

# Apply the policy in the inbound direction of Ethernet1/0/1.

[Sysname] interface Ethernet 1/0/1

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

After the configurations, you can monitor all packets sent from Host A on the data monitoring device.

9 Burst Configuration

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

l Overview

l Configuring Burst

l Burst Configuration Example

Overview

The burst function improves packet buffering and forwarding performance in the following scenarios:

l Dense broadcast or multicast traffic and massive burst traffic are present.

l High-speed traffic is forwarded over a low-speed link or traffic received from multiple interfaces at the same speed is forwarded through an interface at the same speed.

By enabling the burst function on your device, you can improve the processing performance of the device operating in the above scenarios and thus reduce packet loss.

Configuring Burst

Follow these steps to enable the burst function:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enable the burst function	burst-mode enable	Required Disabled by default

To do…

Use the command…

Remarks

Enter system view

system-view

—

Enable the burst function

burst-mode enable

Required

Disabled by default

Burst Configuration Example

Network Requirements

In a customer network shown in Figure 9-1,

l A server connects to the switch through a 1000 Mbps Ethernet interface. The server sends dense broadcast or multicast traffic to the hosts irregularly.

l Each host connects to the switch through a 100 Mbps network adapter.

Configure the switch to process dense traffic from the server to guarantee that packets can reach the hosts.

Figure 9-1 Network diagram for burst configuration

Configuration Procedure

# Enter system view.

<Switch> system-view

# Enable the burst function.

[Switch] burst-mode enable

05-QoS Volume

1 QoS Overview

2 QoS Policy Configuration

Class

Traffic behavior

Policy

Defining a Class

Configuration example

Defining a Traffic Behavior

Configuration example

Defining a Policy

Configuration procedure

Configuration example

Configuration procedure

Configuration example

Applying the QoS Policy to a VLAN

Configuration procedure

Configuration example

Configuration procedure

Configuration example

Displaying and Maintaining QoS Policies

Configuration Prerequisites

Network requirements

Configuration procedure

Configuring the 802.1P Priority of a Port

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Token bucket features

Evaluating traffic with the token bucket

Complicated evaluation

Configuring Traffic Policing

Configuring traffic policing

Traffic policing configuration example

Configuring GTS

Configuring queue-based GTS

GTS configuration example

Displaying and Maintaining Traffic Policing, GTS and Line Rate

SP queuing

WRR queuing

Configuring SP Queuing

Configuration procedure

Configuration example

Network requirements

Configuration procedure

Configuration procedure

Configuration example

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Traditional packet drop policy

RED and WRED

Queue length

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Intelligent Terminal Products