Table of Contents

Chapter 1 QoS Overview.. 1-1

1.1 Introduction. 1-1

1.2 Traditional Packets Forwarding Application. 1-1

1.3 New Requirements Caused by New Applications. 1-1

1.4 Congestion: Causes, Impact, and Countermeasures. 1-2

1.4.1 Causes. 1-2

1.4.2 Impact 1-3

1.4.3 Countermeasure. 1-3

1.5 Traffic Management Technologies. 1-3

Chapter 2 Traffic Classification and Traffic Shaping Configuration. 2-1

2.1 Traffic Classification Overview. 2-1

2.1.1 Traffic classification. 2-1

2.1.2 Priority. 2-2

2.2 Traffic Shaping Overview. 2-2

2.3 Traffic Evaluation and Token Bucket 2-2

2.4 Traffic Shaping Configuration. 2-5

Chapter 3 QoS Policy Configuration. 3-1

3.1 QoS Policy Overview. 3-1

3.2 QoS Policy Configuration Procedure. 3-1

3.3 Configuring QoS Policy. 3-2

3.3.1 Configuration Prerequisites. 3-2

3.3.2 Defining a Class. 3-2

3.3.3 Defining a Traffic Behavior 3-3

3.3.4 Defining a Policy. 3-6

3.3.5 Applying a Policy. 3-7

3.4 Implementing QoS in an MPLS Network. 3-9

3.4.1 Mapping Dot1p to EXP in L2VPN. 3-10

3.4.2 Implementing QoS in an MPLS Network. 3-10

3.5 Displaying and Maintaining QoS Policies. 3-14

Chapter 4 Hardware-based Congestion Management Configuration. 4-1

4.1 Congestion Management Overview. 4-1

4.1.1 SP Queuing. 4-1

4.1.2 WRR Queuing. 4-2

4.2 Configuring SP Queues. 4-3

4.2.1 Configuration Procedure. 4-3

4.2.2 Configuration Examples. 4-3

4.3 Configuring Group-based WRR Queues. 4-3

4.3.1 Configuration Procedure. 4-4

4.3.2 Configuration Examples. 4-4

Chapter 5 Priority Mapping. 5-1

5.1 Priority Mapping Overview. 5-1

5.2 Configuring a Priority Mapping Table. 5-2

5.2.1 Configuration Prerequisites. 5-3

5.2.2 Configuration Procedure. 5-3

5.2.3 Configuration Examples. 5-4

5.3 Configuring Port Priority. 5-5

5.3.1 Configuration Prerequisites. 5-5

5.3.2 Configuration Procedure. 5-6

5.3.3 Configuration Examples. 5-6

5.4 Configuring to Trust Packet Priority. 5-7

5.4.1 Configuration Procedure. 5-8

5.4.2 Configuration Examples. 5-8

Chapter 6 Congestion Avoidance. 6-1

6.1 Congestion Avoidance Overview. 6-1

6.2 Configuring WRED. 6-3

6.2.1 Description on WRED Parameters. 6-3

6.2.2 Configuration Procedure. 6-4

6.3 Displaying and Maintaining WRED. 6-5

6.4 WRED Configuration Examples. 6-5

Chapter 7 Aggregation CAR Configuration. 7-1

7.1 Aggregation CAR Overview. 7-1

7.2 Referencing Aggregation CAR in Traffic Behaviors. 7-1

7.2.1 Configuration Prerequisites. 7-1

7.2.2 Configuration Procedure. 7-1

7.2.3 Configuration Examples. 7-2

7.3 Displaying and Maintaining Aggregation CAR. 7-2

Chapter 8 VLAN Policy Configuration. 8-1

8.1 VLAN Policy Overview. 8-1

8.2 Configuring a VLAN Policy. 8-2

8.2.1 Configuration Prerequisites. 8-2

8.2.2 Configuration Procedure. 8-2

8.3 Displaying and Maintaining VLAN Policies. 8-2

8.4 VLAN Policy Configuration Examples. 8-2

8.4.1 Network Requirements. 8-2

8.4.2 Configuration Procedure. 8-3

Chapter 9 Traffic Mirroring Configuration. 9-1

9.1 Traffic Mirroring Overview. 9-1

9.2 Configuring Traffic Mirroring. 9-1

9.2.1 Mirroring Traffic to a Port 9-1

9.2.2 Mirroring Traffic to the CPU. 9-2

9.3 Displaying and Maintaining Traffic Mirroring. 9-3

9.4 Traffic Mirroring Configuration Examples. 9-3

Chapter 10 EACL Configuration. 10-1

10.1 EACL Overview. 10-1

10.2 EACL Configuration Task List 10-1

10.2.1 Configuring a Reflexive ACL Policy. 10-1

10.2.2 Configuring BT Traffic Limiting. 10-3

10.2.3 Configuring a QoS Policy. 10-5

10.3 EACL Configuration Examples. 10-7

10.3.1 Reflexive ACL Configuration Examples. 10-7

10.3.2 BT Traffic Limiting Configuration Examples. 10-8

10.4 Troubleshooting EACL. 10-10

Chapter 11 Outbound Traffic Accounting Configuration. 11-1

11.1 Outbound Traffic Accounting Overview. 11-1

11.2 Configuring Outbound Traffic Accounting. 11-1

11.3 Displaying and Maintaining Outbound Traffic Accounting. 11-2

 

Chapter 1  QoS Overview

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

l           Introduction

l           Traditional Packets Forwarding Application

l           New Requirements Caused by New Applications

l           Congestion: Causes, Impact, and Countermeasures

l           Traffic Management Technologies

1.1  Introduction

Quality of Service (QoS) measures the service performance of service providers in terms of client satisfaction. Instead of giving accurate marks, QoS emphasizes analyzing what good or imperfect services are, and they come in what kind of circumstances, so as to provide a cutting edge improvement.

In the Internet, QoS evaluates service performance for network packet forwarding. Due to various services offered by the network, the evaluation for QoS will be based on different aspects accordingly. Generally, QoS evaluates the service performance for those network core requirements during packet forwarding process, such as delay, jitter and packet loss ratio.

1.2  Traditional Packets Forwarding Application

On traditional IP networks, the devices treat all packets identically and handle them with the first in, first out (FIFO) policy, assigning forwarding resources by arrival sequence of packets. All the packets share the resources of the network devices. How many resources the packets can obtain will completely depend on the time they arrive.

This service policy is called Best-effort, which delivers the packets to their destination as it can, without any assurance and guarantee for delivery delay, jitter, packet loss ratio, reliability and so on for packet forwarding.

The traditional Best-Effort service policy is only suitable for applications insensitive to bandwidth and delay, such as WWW, file transfer and E-mail.

1.3  New Requirements Caused by New Applications

With the fast development of the network, more and more networks access the Internet. The Internet has been expanded in terms of its scale, coverage and users quantities. More and more users use Internet as their data transmission platform to implement various applications.

Apart from traditional applications of WWW, E-mail and FTP, network users try to expand some new applications, such as tele-education, telemedicine, video telephone, videoconference and Video-on-Demand (VoD), on the Internet. And the enterprise users expect to connect their regional branches together to develop some operational applications through VPN technology, for instance, to access the database of the company or monitor their remote equipment via Telnet.

Those new applications have one thing in common, i.e. high requirements for bandwidth, delay, and jitter. For instance, videoconference and VOD need the assurance of wide bandwidth, low delay and jitter. As for mission-critical applications, such as transaction and Telnet, they may not require wide bandwidth but do require lower delay and be handled by priority during congestion.

The new emerging applications demand higher service performance of IP network. Better network services during packets forwarding are required other than simply delivering the packets to their destination, such as providing user-specific bandwidth, reducing packet loss ratio, avoiding congestion, regulating network traffic, setting priority of the packets. To meet those requirements, the network should be provided with better service capability.

1.4  Congestion: Causes, Impact, and Countermeasures

Network congestion occurs when inadequate resources are available for traffic. It can degrade forwarding performance, introduce undesired delays, and hence degraded service quality.

1.4.1  Causes

Congestion will easily occur in complex packet switching circumstances in the Internet, with two cases illustrated in the following figure:

Figure 1-1 Traffic congestion causes

1)         The packet streams enter a device from a high speed link and are forwarded via a low speed link;

2)         The packet streams enter a device from several interfaces with a same speed and are forwarded through an interface with the same speed as well.

When traffic arrives at wire speed, congestion may occur for network resource bottleneck.

Besides the bottleneck of link bandwidth, congestion will also be caused by resources deficiency in normal packet forwarding, such as the deficiency of assignable processor time, buffer and memory. In addition, congestion may occur if the arrival traffic is not managed efficiently and the assignable network resources are inadequate.

1.4.2  Impact

Congestion may cause the following negative effects:

l           Increase the delay and jitter of packet transmission

l           Packet re-transmission caused by high delay

l           Decrease the efficient throughput of network and lower the utilization of network resources

l           Intensified congestion can occupy too many network resources (especially in memory), and the irrational assignment of resources even can lead to resource block and breakdown for the system

It is obvious that congestion will make the traffics unable to obtain the resources in time and degrade the service performance accordingly. No one wants congestion, but it occurs frequently in complex environments where packet switching and multi-users applications coexist. So it needs to be treated cautiously.

1.4.3  Countermeasure

A direct way to solve resources deficiency problem is to increase the bandwidth of network; however, it cannot resolve all the problems caused by congestion.

A more effective method to solve the problem of QoS is to enhance the functions of traffic control and resource allocation in the network, and to provide differentiated services for applications with different service requirement in order to allocate and use resources rightly. During the process of resources allocation and traffic control, the direct or indirect factors that might cause network congestion should be controlled with best effort to reduce the probability of congestion. As congestion occurs, resource allocation should be balanced according to features and demands of applications, to minimize the effects on QoS by congestion.

1.5  Traffic Management Technologies

Traffic classification, traffic policing, traffic shaping, congestion management, and congestion avoidance are common traffic management techniques. They deliver the following functions:

l           Traffic classification: It is a prerequisite for differentiated service, to identify the interested objects based on a certain matching rule.

l           Traffic policing: polices the specification of particular traffics entering the switch. When the traffics exceed the specification, then some restriction or punishment measures can be taken to protect the commercial benefits of carriers and to prevent network resources from being damaged.

l           Traffic shaping: A traffic control measure of actively adjusting the output speed of traffics, generally it can enable the traffic to adapt to the network resources supplied by the downstream switch, to prevent the unwanted packet dropping and congestion. Same as traffic policing, traffic shaping is implemented at the IP layer.

l           Congestion management: handles resource competition during network congestion. Generally, it stores the packets in the queue first, and then takes a dispatching algorithm to assign the forwarding sequence of packets.

l           Congestion avoidance: Exceeding congestion consumes network resources. Congestion avoidance can monitor the usage status of network resources, and as congestion becomes worse, actively take the policy of dropping packets through adjusting traffic to resolve the overloading of the network.

Among those traffic management technologies, traffic classification is the basis. It is a prerequisite for differentiated services, which identifies the interested packets with certain matching rule. As for traffic policing, traffic shaping, congestion management and congestion avoidance, they implement management to network traffic and allocated resources from different aspects respectively to realize the differentiated service.

Normally, QoS provides the following functions:

l           Traffic classification

l           Access control

l           Traffic policing and shaping

l           Congestion management

l           Congestion avoidance

 

Chapter 2  Traffic Classification and Traffic Shaping Configuration

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

l           Traffic Classification Overview

l           Traffic Shaping Overview

l           Traffic Evaluation and Token Bucket

l           Traffic Shaping Configuration

2.1  Traffic Classification Overview

2.1.1  Traffic classification

Traffic classification is the prerequisite and foundation for differentiated services, which uses certain rules to identify the packets with certain features.

To discriminate flows, you can set traffic classification rules using the priority bits of ToS (type of service) field in the IP packet header. Alternatively, the network administrator may define a traffic classification policy, for instance, integrating information such as source IP address, destination IP address, MAC address, IP protocol, or port number of the applications to classify the traffic. In general, it can be a narrow range defined by a quintuple (source IP address, source port number, destination IP address, destination port number and the Transport Protocol), or can be all packets to a network segment.

In general, while packets being classified on the network border, the precedence bits in the ToS byte of IP header are set so that IP precedence can be used as a direct packet classification standard within the network. The queuing technologies can use IP precedence to handle the packets. Downstream network can receive the packets classification results from upstream network selectively, or re-classify the packets with its own standard.

Traffic classification is used to provide differentiated service, so it must be associated with certain kinds of traffic policing or resource-assignment mechanisms. To adopt what kind of traffic policing action will depend on the current stage and load status of the network. For example, to police the packets according to the committed rate when they enter the network, to make traffic shaping before they flow out the nodes, to perform queuing management in the event of congestion and to employ congestion avoidance when congestion becomes worse.

2.1.2  Priority

Several priorities are described as follows:

Figure 2-1 DS field and ToS byte

As shown in Figure 2-1, the ToS byte of IP header contains 8 bits: the first three bits (0 to 2) indicates IP precedence, valued in the range 0 to 7; the following 4 bits (3 to 6) indicates ToS priority, valued in the range 0 to 15. In RFC2474, the ToS field of IP packet header is redefined as DS field, where the DiffServ code point (DSCP) priority is indicated by the first 6 bits (0 to 5), valued in the range 0 to 63. The remaining 2 bits (6 and 7) are reserved.

2.2  Traffic Shaping Overview

If no restrictions are imposed on the traffics from the users, bursting data sent by mass users continuously will make the network become more congested. Thus for more efficient network function and better network service for more users, the traffics from the users must be restricted, for example, to restrict a traffic can only acquire the specific assigned resources in certain time interval so as to prevent the network congestion caused by excess burst.

Traffic shaping is a traffic monitoring policy to restrict the traffic and resources through comparing with the traffic specification. To know whether the traffic exceeds the specification or not is a prerequisite for traffic shaping. Then based upon the evaluation result you can implement a regulation policy. Usually, Token Bucket is used to value the traffic specification.

2.3  Traffic Evaluation and Token Bucket

I. Token bucket features

Token Bucket can be regarded as a container holding a number of tokens. The system will put Tokens into the Bucket at a defined rate. In case the Bucket is full, the extra Tokens will overflow and no more Tokens will be added.

Figure 2-2 Measuring the traffic with a token bucket

II. Measuring the traffic with Token Bucket

Whether or not the token quantity of the Token Bucket can satisfy the packets forwarding is the basis for Token Bucket to measure the traffic specification. If enough tokens are available for forwarding packets, traffic is regarded conforming the specification (generally, one token is associated to the forwarding ability of one bit), otherwise, non-conform or excess.

When measuring the traffic with Token Bucket, these parameters are included:

l           Mean rate: The rate of putting Token into Bucket, i.e. average rate of the permitting traffic. Generally set as CIR (Committed Information Rate).

l           Burst size: Token Bucket’s capability, i.e. the maximum traffic size of every burst. Generally, it is set as CBS (Committed Burst Size), and the bursting size must be greater than the maximum packets size.

A new evaluation will be made when a new packet arrives. If there are enough tokens in bucket for each evaluation, it shows that traffics are within the bound, and at this time the amount of tokens appropriate for the packets forwarding rights, need to be taken out. Otherwise, it shows that too many tokens have been used, and traffic specifications are exceeded.

III. Complicated evaluation

Two Token Buckets can be configured to evaluate conditions that are more complex and to implement more flexible regulation policy. For example, traffic policing has four parameters, as follows:

l           CIR (Committed information rate)

l           CBS (Committed burst size)

l           PIR (Peak information rate)

l           EBS (Excess burst size)

It uses two token buckets, with the token-putting rate of every bucket set as CIR and PIR and the capability of every bucket set as CBS and EBS (CBS < EBS, called C bucket and E bucket), which represents different bursting class permitted. In each evaluation, you may use different traffic control policies for different situations, such as "C bucket has enough tokens”; "Tokens of C bucket are deficient, but those of E bucket are enough”; "Tokens of C bucket and E bucket are all deficient”.

IV. Traffic policing

Typically, traffic policing is used to monitor the specification of certain traffic entering the network and keep it within a reasonable bound, or it will make “penalty” on the exceeding traffic so as to protect network resources and profits of carriers. For example, it can restrict HTTP packets to occupy network bandwidth of no more than 50%. Once finding the traffic of a connection exceeds, it may drop the packets or reset the precedence of packets.

Traffic policing allows you to define match rules based on IP precedence or DiffServ code point (DSCP). It is widely used by ISP to police the network traffic. Traffic policing also includes the traffic classification service for the policed traffics, and depending upon the different evaluation results, it will implement the pre-configured policing actions, which are described as the following:

l           Forward: For example, continue to forward the packets evaluated as “conform”.

l           Drop: For example, dropping the packets evaluated as “not conform”.

V. Traffic shaping

Traffic shaping is an active way to adjust the traffic output rate.

The main difference between traffic shaping and traffic policing is: the packets to be dropped in traffic policing will be stored during traffic shaping — generally they will be put into buffer or queues, as shown in Figure 2-3. Once there are enough tokens in token bucket, those stored packets will be evenly sent. Another difference is that traffic shaping may intensify delay, yet traffic policing seldom does so.

Figure 2-3 Traffic shaping diagram

For example, Switch A sends packets to Switch B. Switch B implements traffic policing on those packets, and directly drops exceeding traffic.

To reduce unnecessary packet drop, GTS can be applied to the packets on the egress interface of Switch A. The packets beyond the traffic specifications of GTS are stored in Switch A. While sending the next set of packets, GTS takes out those packets from buffer queues and sends them. Thus, all the packets sent to Switch B accord with the traffic specification of Switch B.

 

 

2.4  Traffic Shaping Configuration

Traffic shaping includes the following two types:

l           Queue-based traffic shaping: set traffic shaping parameters for packets in a queue.

l           Traffic shaping applicable to all the traffic: set traffic shaping parameters for all the traffic.

I. Configuring queue-based traffic shaping

Follow these steps to configure queue-based traffic shaping:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter Ethernet interface view or port group view	Enter Ethernet interface view	interface interface-type interface-number	Use either the command Configured in Ethernet interface view, the setting is effective on the current interface only; configured in port group view, the setting is effective on all the ports in the port group.
	Enter port group view	port-group { manual port-group-name | aggregation agg-id }
Configure traffic shaping on the specific port or ports in the specific port group		qos gts queue queue-number cir committed-information-rate [ cbs committed-burst-size ]	Required
Display the traffic shaping configuration information		display qos gts interface [ interface-type interface-number ]	Optional Available in any view

 

 

II. Configuring traffic shaping applicable to all traffics

Follow these steps to configure traffic shaping applicable to all traffics:

To do…		Use the command…	Remarks
Enter system view		system-view	—
Enter Ethernet interface view or port group view	Enter Ethernet interface view	interface interface-type interface-number	Use either the command Configured in Ethernet interface view, the setting is effective on the current interface only; configured in port group view, the setting is effective on all the ports in the port group.
	Enter port group view	port-group { manual port-group-name | aggregation agg-id }
Configure traffic shaping on the specific port or ports in the specific port group		qos gts any cir committed-information-rate [ cbs committed-burst-size ]	Required
Display the traffic shaping configuration information		display qos gts interface [ interface-type interface-number ]	Optional Available in any view

 

 

III. Traffic shaping configuration example

Configure traffic shaping on Ethernet 1/1/1 to shape the outgoing packets with traffic rate exceeding 500 kbps on the port.

# Enter system view.

<Sysname> system-view

# Enter Ethernet interface view.

[Sysname] interface ethernet1/1/1

# Configure traffic shaping parameters.

[Sysname-Ethernet1/1/1] qos gts any cir 500

 

Chapter 3  QoS Policy Configuration

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

l           QoS Policy Overview

l           QoS Policy Configuration Procedure

l           Configuring QoS Policy

l           Implementing QoS in an MPLS Network

3.1  QoS Policy Overview

A QoS policy includes three elements: class, traffic behavior, and policy. You can bind the specified class to a traffic behavior through the QoS policy so as to configure QoS conveniently.

I. Class

A class is used to identify traffic.

Class elements include class name and rule.

You can define a series of rules by executing some commands to classify packets. Also you can use commands to specify the relationship between rules: and or or.

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

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

II. Traffic behavior

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

III. Policy

A policy associates a class with a traffic behavior.

You can configure multiple classifier-behavior associations in a policy.

3.2  QoS Policy Configuration Procedure

Follow these steps to configure a QoS policy:

1)         Create a class and define a group of traffic classification rules in class view.

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

3)         Create the QoS policy, and specify the traffic behavior for the class in QoS policy view.

4)         Apply the QoS policy.

3.3  Configuring QoS Policy

3.3.1  Configuration Prerequisites

l           The class name and rules of the class are defined in a policy.

l           The traffic behavior name and actions in the traffic behavior are defined,

l           The policy name is defined.

l           The interface to which policy is applied is defined.

3.3.2  Defining a Class

Before you can define a class, you must first create its class name. Then you can configure matching rules in this class view.

I. Configuration procedure

Follow these steps to define a class:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Define a class and enter class view	traffic classifier tcl-name [ operator { and | or } ]	Required The operator keyword defaults to and. That is, the relation between the matching rules in the class view is logic AND.
Define rules to match packets	if-match match-criteria	Required
Display class information	display traffic classifier user-defined [ tcl-name ]	Optional Available in any view

 

 

II. Configuration example

1)         Network requirements

Configure class test to match the packets with the destination MAC address 0050-BA27-BED3.

2)         Configuration procedure

# Enter system view.

<Sysname> system-view

# Define a class and enter class view.

[Sysname] traffic classifier test

# Configure the classification rule.

[Sysname-classifier-test] if-match destination-mac 0050-ba27-bed3

[Sysname-classifier-test]

3.3.3  Defining a Traffic Behavior

To define a traffic behavior, you must first create a traffic behavior name and then configure features for it in the traffic behavior view.

I. Configuration procedure

Follow these steps to define a traffic behavior:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Define a traffic behavior and enter traffic behavior view	traffic behavior behavior-name	Required behavior-name: Traffic behavior name.
Configure the traffic accounting action	accounting	Required Configure corresponding traffic behaviors as needed.
Configure the traffic policing action	car cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ pir peak-information-rate ] [ red action ]
Configure the traffic filtering action	filter { deny | permit }
Configure the action of creating an outer VLAN tag	nest top-most vlan-id vlan-id-value
Configure the traffic redirecting action	redirect { cpu | interface interface-type interface-number | link-aggregation group group-id | next-hop { ipv4-add [ ipv4-add ] | ipv6-add [ interface-type interface-number ] [ ipv6-add [ interface-type interface-number ] ] } }
Configure the DSCP marking action	remark dscp dscp-value
Configure the 802.1p precedence marking action	remark dot1p 8021p
Configure the drop precedence marking action	remark drop-precedence drop-precedence-value
Configure the local precedence marking action	remark local-precedence local-precedence
Configure the action of marking service provider network VLAN ID	remark service-vlan-id vlan-id-value
Configure the action of obtaining other precedence values through the corresponding priority mapping table	primap pre-defined { dscp-lp | dscp-dp | dscp-dot1p | dscp-dscp }
Configure the action of obtaining other precedence values through the corresponding colored priority mapping table	primap pre-defined color { dscp-dot1p | dscp-dp | dscp-dscp | dscp-lp | lp-dot1p | lp-dp | lp-dscp | lp-lp }
Display traffic behavior information	display traffic behavior user-defined [ behavior-name ]	Optional Available in any view

 

Note that:

l           For the description on the default values of CIR, CBS, EBS, and PIR, refer to the related part in QoS Commands.

l           When the traffic redirecting action is configured, if the outbound interface to be redirected to is bound with an NAT virtual interface, packets sent from this outbound interface are redirected to the L3+NAT card, thus resulting in traffic redirecting failure.

l           Multiple traffic actions can be used together. How ever, the traffic filtering action defined by the filter deny command can only be used in conjunction with the traffic accounting action, and the action of redirecting traffic to the CPU cannot be used in conjunction with any other traffic actions.

l           The nest command and the remark service-vlan-id command are supported only on D-type boards with the suffix DA, DB, or DC.

l           The tunnel redirecting policy can be configured only in port view on D-type boards.

l           Given a B-type board, when configuring priority marking, you must configure all the four CoS values (dot1p, dscp, drop-precedence, and local-precedence) instead of an incomplete set of them.

l           The action of marking DSCP also marks the EXP. The EXP value is the low-order three bits in the DSCP value in binary. Refer to Implementing QoS in an MPLS Network for detailed information about QoS in an MPLS network.

l           All the priority mapping tables related to DSCP apply to EXP. That is, dsp-lp mappings are also used as exp-lp mappings; dscp-dscp mappings are also used as dscp-exp, exp-dscp, and exp-exp mappings. For MPLS packets, the priority mappings from EXP to other types of precedence apply; for non-MPLS packets, the priority mappings from DSCP to other types of precedence apply. Refer to Implementing QoS in an MPLS Network for detailed information about QoS in an MPLS network.

l           A colored priority mapping table must be used in conjunction with the traffic policing action (configured with the car command).

l           QoS policies configured with an if-match mpls-exp clause can be applied only to the ports on boards suffixed with C, CA, or CB.

l           On B-type boards, the priority marking action cannot be configured in conjunction with the traffic policing action or the traffic accounting action.

l           On all boards, in the action of obtaining other precedence values through a colored priority mapping table, the DSCP precedence and the 802.1p precedence must be modified at the same time and cannot be modified separately.

l           On all the boards, the 802.1p precedence marking action, the local precedence marking action, and the drop precedence marking action cannot be configured with the action of obtaining other precedence values through an uncolored priority mapping table at the same time.

l           When configuring the action of redirecting traffic to an aggregation group and applying the corresponding policy to a port, make sure that the action of marking service provider network VLAN ID is configured at the same time. If the corresponding policy is applied in VLAN view, the action of marking service provider network VLAN ID is unnecessary to be configured at the same time.

l           When configuring the action of redirecting traffic to the next hop, make sure that the type of ACL rules is consistent with that of the address the traffic is to be redirected to. That is, you cannot redirect traffic to an IPv6 address using IPv4 ACL rules or redirect traffic to an IPv4 address using IPv6 ACL rules.

l           The interface that traffic is to be redirected to must be an EACL interface or tunnel interface.

l           The aggregation CAR action cannot be configured in conjunction with the traffic accounting action.

l           If redirecting traffic to CPU has been configured, you cannot configure any other traffic actions.

l           Marking service provider network VLAN ID (or the action of creating an outer VLAN tag) cannot be configured with any traffic redirecting action except redirecting traffic to an aggregation group.

l           Marking service provider network VLAN ID cannot be configured in conjunction with the action of creating an outer VLAN tag.

II. Configuration example

1)         Network requirements

Configure a traffic behavior test and perform traffic policing with the CAR being 100 kbps.

2)         Configuration procedure

# Enter system view.

<Sysname> system-view

# Define a traffic behavior and enter traffic behavior view.

[Sysname] traffic behavior test

# Configure the traffic behavior.

[Sysname-behavior-test] car cir 100

3.3.4  Defining a Policy

A policy defines the mapping relationship between a class and a traffic behavior (configured with multiple QoS actions).

In a policy, multiple class-to-traffic-behavior mappings are configured, and these mapping are executed according to the order they are configured.

Follow these steps to specify the traffic behavior for a class in the policy:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Define the policy and enter the policy view	qos policy policy-name	Required
Specify the traffic behavior for the class in the policy	classifier tcl-name behavior behavior-name	Required tcl-name: Name of a class. behavior-name: Name of a traffic behavior.
Display configuration information of the specified class of the specified policy and the traffic behavior associated with the class	display qos policy user-defined [ policy-name [ classifier tcl-name ] ]	Optional Available in any view

 

 

3.3.5  Applying a Policy

I. Configuration procedure

The qos apply policy command maps a policy to a specific interface. One policy mapping can be applied to multiple interfaces. Only one policy can be applied on one direction (inbound or outbound) of an interface.

Follow these steps to apply a policy to the 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 the command Configured in Ethernet interface view, the setting is effective on the current interface only; configured in port group view, the setting is effective on all the ports in the port group.
	Enter port group view	port-group { manual port-group-name | aggregation agg-id }
Apply a policy on the interface		qos apply policy policy-name { inbound | outbound }	Required
Display the policy configuration information and operating condition of the specified interface or all the interfaces		display qos policy interface [ interface-type interface-number ] [ inbound | outbound ]	Optional Available in any view
Display configuration information of the specified class (or all the classes) of the specified policy (or all the policies) and configuration information of behaviors associated with these classes		display qos policy user-defined [ policy-name [ classifier tcl-name ] ]

 

 

II. Configuration example

1)         Network requirements

Configure a policy test_policy and in the policy specify the traffic behavior for the data belonging to the class test_class as test_behavior, and then apply the policy to the inbound interface Ethernet1/1/1.

2)         Configuration procedure

# Enter system view.

<Sysname> system-view

# Define a policy and enter policy view,

[Sysname] qos policy test_policy

[Sysname-qospolicy-test_policy]

# Specify the traffic behavior for the class.

[Sysname-qospolicy-test_policy] classifier test_class behavior test_behavior

[Sysname-qospolicy-test_policy] quit

# Enter Ethernet interface view.

[Sysname] interface ethernet 1/1/1

# Apply the policy to the port.

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

3.4  Implementing QoS in an MPLS Network

Unless otherwise stated, the MPLS services talked about in this part do not include VPLS, which does not support QoS.

For L2VPN running on MPLS TE tunnels, 802.1p precedence, local precedence, and drop precedence are fixed to 0, 5, and 0. You cannot modify them through configuring policies.

3.4.1  Mapping Dot1p to EXP in L2VPN

Currently, the S9500 series do not support dot1p-to-EXP mapping during the push operation on L2VPN. Still, you can achieve dot1p-to-EXP mapping as follows:

1)         Configure to trust dot1p on the port connecting L2VPN to the public network. In this case, the local precedence is obtained through dot1p-lp mapping, where the 802.1p precedence is taken from the VLAN tag.

2)         Apply a QoS policy configured with colored lp-dscp and lp-dot1p mappings to the port to match the L2VPN traffic. The CAR parameters set in the policy should be large enough for the device to color all packets green.

3)         Configure the lp-exp mapping table for green packets.

3.4.2  Implementing QoS in an MPLS Network

As the S9500 series support the EXP field for MPLS, MPLS QoS can be achieved. In an MPLS network, a device performs QoS depending on its role.

I. QoS on the ingress PE

1)         EXP precedence marking

The following table presents how an ingress PE makes EXP precedence marking decisions for received packets:

For …packets	If…	Marking EXP in the label with the value obtained from…
IPv4 packets	No QoS policy is configured	The uncolored dscp-exp mapping table
	An explicit EXP mapping policy is configured with the primap pre-defined dscp-dscp or primap pre-defined color dscp-dscp command	The corresponding mapping table
	A policy configured with the DSCP marking action configured with the remark dscp dscp-value command	The EXP value in the entry corresponding to the specified DSCP value in the dscp-exp mapping table
TCP/UDP packets	––	The low-order three bits in the DSCP field

 

2)         DSCP precedence marking

The following table presents how an ingress PE makes DSCP precedence marking decisions for received packets:

If packets are received from…	Marking DSCP?	Remarks
L2VPN	No	This is because L2VPN packets are handled as Layer 2 packets.
Non L2VPN	Yes	The ingress device marks DSCP depending on the adopted QoS policy.

 

3)         Local precedence and drop precedence marking

Local precedence and drop precedence can be marked as per the mapping action.

4)         802.1p precedence marking

The following table presents how an ingress PE makes 802.1p precedence marking decisions for received packets:

If the packets are received from…	Marking the 802.1p?		Remarks
An L2VPN	For the outer VLAN tag	Yes	The ingress device marks the 802.1p precedence in the outer VLAN tag depending on the adopted QoS policy.
	For the inner VLAN tag	No
Non L2VPN	Yes		Yes. The ingress device marks the DSCP depending on the adopted QoS policy.

 

II. QoS on a P device

1)         EXP precedence marking

The following table presents how a P device makes EXP precedence marking decisions for received packets:

Label operation	Marking EXP?	Remarks
Swap	Yes	The P device marks the EXP in the outer label according to the adopted mapping. When the remark dscp dscp-value command is configured, the EXP is the low-order three bits in dscp-value.
PHP	No	The P device keeps the EXP value in the inner MPLS label intact.

 

2)         DSCP precedence marking

The following table presents how a P device makes DSCP precedence marking decisions for received packets:

Label operation	Marking DSCP?	Remarks
Swap	No	The P devices in an MPLS network do not touch IPv4 packets.
PHP	No

 

3)         Local precedence and drop precedence marking

The local precedence and the drop precedence can be modified as per the mapping action.

Label operation	Marking local precedence/drop precedence?		Remarks
Swap	Yes		The P device can mark the local precedence and the drop precedence as per the mapping action.
PHP	On boards suffixed with CA or CB	Yes	The P device can mark the local precedence and the drop precedence as per the mapping action.
	On boards suffixed with C	Yes	As the packets are to be forwarded through IPv4 routing, the P device obtains a new value for the local/drop precedence by looking up the uncolored dscp-lp/dscp-dp mapping table based on DSCP.

 

4)         802.1p precedence marking

The following table presents how a P device makes 802.1p precedence marking decisions for received packets:

Label operation	Marking 802.1p?		Remarks
Swap	Yes		The P device marks the 802.1p precedence in the VLAN tag depending on the adopted mapping action.
PHP	On boards suffixed with CA or CB	Yes	The P device marks the 802.1p precedence in the VLAN tag depending on the adopted mapping action.
	On boards suffixed with C	Yes	As the packets are to be forwarded through IPv4 routing, the P device obtains a new value for the 802.1p precedence by looking up the uncolored dscp-dot1p mapping table based on DSCP.

 

III. QoS on the egress PE

1)         EXP precedence marking

The egress PE does not mark the EXP in the inner MPLS label.

2)         DSCP precedence marking

The egress PE does not mark the DSCP value in the IPv4 packets with the MPLS label untagged.

3)         Local precedence and drop precedence marking

The following table presents how the egress PE makes local precedence and drop precedence marking decisions for received packets:

If the packets are intended for…	Marking local/drop precedence?	Remarks
L2VPN	Yes	The egress PE marks the local precedence and the drop precedence as per the mapping action.
Non L2VPN	Yes	As the packets are to be forwarded through IPv4 routing, the P device obtains new values for the local precedence and drop precedence by looking up the uncolored dscp-lp mapping table and the uncolored dscp-dp mapping table based on DSCP precedence of the IPv4 packets.

 

4)         802.1p precedence marking

The following table presents how the egress PE makes 802.1p precedence marking decisions for received packets:

If the packets are intended for…	Marking 802.1p?	Remarks
L2VPN	No	––
Non L2VPN	Yes	As the packets are to be forwarded through IPv4 routing, the P device obtains a new value for the 802.1p precedence by looking up the uncolored dscp-dot1p mapping table based on DSCP precedence of the IPv4 packets.

 

3.5  Displaying and Maintaining QoS Policies

Follow these steps to display and maintain QoS policies:

To do...	Use the command...	Remarks
Display configuration information of specified class of specified policy and behavior associated with these classes	display qos policy user-defined [ policy-name [ classifier tcl-name ] ]	Available in any view
Display policy configuration information and operating condition on specified or all interfaces	display qos policy interface [ interface-type interface-number ] [ inbound | outbound ]
Display the configured traffic behavior information	display traffic behavior user-defined [ behavior-name ]
Display the configured class information	display traffic classifier user-defined [ tcl-name ]

 

Chapter 4  Hardware-based Congestion Management Configuration

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

l           Congestion Management Overview

l           Configuring SP Queues

l           Configuring Group-based WRR Queues

4.1  Congestion Management Overview

As to a network device, congestion will occur on the interface where the arrival rate of packets is faster than the sending rate. If there is no enough buffer capacity to store those packets and then a part of them will be lost, which may cause the packet retransmission from the device because of timeout, and lead to a vicious circle.

The key to congestion management is how to define a dispatching policy for resources to decide the forwarding order of packets when congestion occurs. This chapter describes hardware-based congestion management configuration.

4.1.1  SP Queuing

Strict priority (SP) queues include:

l           Basic SP queues: a basic SP queue contains multiple queues, with each queue corresponding to a different priority. These queues are scheduled in the descending order of priority.

l           Multi-mode SP queues: the queue scheduling modes are extended from that of basic SP queues.

Multi-mode SP queues operate in one of the following three modes:

l           SP mode 0: in this mode, multi-mode SP queues are all basic SP queues and are scheduled in the descending order of priority.

l           SP mode 1: in this mode, when the remaining external memory space is sufficient, SP queue scheduling algorithm is adopted; when the remaining external memory space is 0, the scheduling algorithm can preferentially forward the packets stored in the internal memory of the chip even if packets with higher priority are waiting to be scheduled in the external memory.

l           SP mode 2: in this mode, packets stored in the internal memory of the chip are forwarded preferentially; if no packets are stored in the internal memory of the chip, all the packets are scheduled using the SP queue scheduling algorithm. The disadvantage of SP mode 2 is that the bus bandwidth of the external memory is decreased.

 

 

4.1.2  WRR Queuing

Weighted round robin (WRR) queues include:

l           Basic WRR queues: a basic WRR queue contains multiple queues. You can configure weight, percentage or byte count for each queue and WRR schedules these queues based on the user-defined parameters.

l           Group-based WRR queues: all the queues in a group-based WRR queue are scheduled in the mix of WRR queue scheduling algorithm and SP queue scheduling algorithm. You can allocate all an output queue to WRR priority queue group 1, WRR priority queue group 2, or SP queue group as required. Queues are scheduled as follows: each group selects a candidate queue according to its own queue scheduling algorithm, and then the three candidate queues are scheduled using the SP algorithm.

l           WRR queues with the maximum delay: the queue scheduling algorithm for WRR queues with the maximum delay is similar to that for the basic WRR queues except that the WRR queues with the maximum delay assure that packets in the queue with the highest priority are transmitted through the queue within the specified maximum delay.

 

 

4.2  Configuring SP Queues

4.2.1  Configuration Procedure

Follow these steps to configure SP queues:

To do...		Use the command...	Remarks
Enter system view		system-view	—
Enter Ethernet interface view or port group view	Enter Ethernet interface view	interface interface-type interface-number	Use either the command Configured in Ethernet interface view, the setting is effective on the current interface only; configured in port group view, the setting is effective on all the ports in the port group.
	Enter port group view	port-group { manual port-group-name | aggregation agg-id }
Configure SP queues		qos sp	Optional
Display SP queuing information		display qos sp interface [ interface-type interface-number ]	Optional Available in any view

 

4.2.2  Configuration Examples

I. Network requirements

Enable SP queuing on Ethernet 1/1/1.

II. Configuration procedure

# Enter system view.

<Sysname> system-view

# Enable SP queuing on Ethernet 1/1/1.

[Sysname] interface ethernet 1/1/1

[Sysname-Ethernet1/1/1] qos sp

4.3  Configuring Group-based WRR Queues

With a queue on a port configured as a group-based WRR queue, the queue scheduling algorithm on the current port is the mix of WRR queue scheduling algorithm and SP queue scheduling algorithm. The queues which are not configured as group-based WRR queues are allocated to the SP queue group.

4.3.1  Configuration Procedure

I. Group-based WRR queue configuration task list

Follow these steps to configure group-based WRR queues:

To do...		Use the command...	Remarks
Enter system view		system-view	—
Enter Ethernet interface view or port group view	Enter Ethernet interface view	interface interface-type interface-number	Use either the command Configured in Ethernet interface view, the setting is effective on the current interface only; configured in port group view, the setting is effective on all the ports in the port group.
	Enter port group view	port-group { manual port-group-name | aggregation agg-id }
Enable WRR queuing		qos wrr	Required
Configure group-based WRR queues		qos wrr queue-id group { { 1 | 2 } weight schedule-value | sp }	Required
Display WRR queuing configuration		display qos wrr interface [ interface-type interface-number ]	Optional Available in any view

 

 

4.3.2  Configuration Examples

I. Network requirements

l           Configure the queues on a port as WRR queues.

l           Allocate queue 1, queue 3, and queue 4 to WRR group 1, with the weight 1, 5, and 10.

l           Allocate queue 5 and queue 6 to WRR group 2, with the weight 20 and 10.

II. Configuration procedure

# Enter system view.

<Sysname> system-view

# Configure WRR queues on Ethernet 1/1/1.

[Sysname] interface ethernet 1/1/1

[Sysname-Ethernet1/1/1] qos wrr

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

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

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

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

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

 

Chapter 5  Priority Mapping

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

l           Priority Mapping Overview

l           Configuring a Priority Mapping Table

l           Configuring Port Priority

l           Configuring to Trust Packet Priority

5.1  Priority Mapping Overview

When packets enter the switch, the switch allocate a series of parameters including 802.1p precedence, DSCP, local precedence, and drop precedence to the packets according to the capability of the switch and the corresponding rules.

The local precedence and drop precedence are defined as follows:

l           Local precedence: locally significant precedence that the switch assigns to the packets. A local precedence corresponds to an output queue ID.

l           Drop precedence: parameter referenced for packet drop. The drop precedence for red packets, yellow packets, and green packets is 2, 1, and 0.

The S9500 series can be configured to trust the packet priority. With packet priority trust mode configured, the switch looks up the priority mapping table based on the priority of a packet to assign priority parameters to the packet.

The packet priority mapping process on an S9500 series routing switch is shown in Figure 5-1.

Figure 5-1 Priority mapping process

The S9500 series provide uncolored priority mapping tables and colored mapping tables. The uncolored priority mapping tables are as follows:

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

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

l           dot1p-rpr: 802.1p-to-RPR-precedence mapping table.

l           dscp-dot1p: DSCP-to-802.1p-precedence mapping table.

l           dscp-dp: DSCP-to-drop-precedence mapping table.

l           dscp-dscp: DSCP-to-DSCP mapping table.

l           dscp-exp: DSCP-to-EXP-precedence mapping table.

l           dscp-lp: DSCP-to-local-precedence mapping table.

l           exp-dot1p: EXP-to-802.1p-precedence mapping table.

l           exp-dp: EXP-to-drop-precedence mapping table.

l           exp-exp: EXP-to-EXP-precedence mapping table.

l           exp-lp: EXP-to-local-precedence mapping table.

l           exp-rpr: EXP-to-RPR-precedence mapping table.

l           ippre-rpr: IP-precedence-to-RPR-precedence mapping table.

The colored priority mapping tables are as follows:

l           dscp-dot1p: DSCP-to-802.1p-precedence mapping table.

l           dscp-dp: DSCP-to-drop-precedence mapping table.

l           dscp-dscp: DSCP-to-DSCP mapping table.

l           dscp-exp: DSCP-to-EXP-precedence mapping table.

l           dscp-lp: DSCP-to-local-precedence mapping table.

l           exp-dot1p: EXP-to-802.1p-precedence mapping table.

l           exp-dp: EXP-to-drop-precedence mapping table.

l           exp-exp: EXP-to-EXP-precedence mapping table.

l           exp-lp: EXP-to-local-precedence mapping table.

l           lp-dot1p: Local-to-802.1p-precedence mapping table.

l           lp-dp: Local-to-drop-precedence mapping table.

l           lp-dscp: Local-to-DSCP-precedence mapping table.

l           lp-exp: Local-to-EXP-precedence mapping table.

l           lp-lp: Local-to-local-precedence mapping table.

 

 

5.2  Configuring a Priority Mapping Table

The priority mapping tables in the switch can be modified as required.

Follow these steps to configure a priority mapping table:

1)         Enter priority mapping table view;

2)         Configure mapping table parameters.

5.2.1  Configuration Prerequisites

New priority mapping relationship is determined.

5.2.2  Configuration Procedure

Follow these steps to configure a priority mapping table:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter uncolored mapping table view	qos map-table { dot1p-dp | dot1p-lp | dot1p-rpr | dscp-dot1p | dscp-dp | dscp-dscp | dscp-exp | dscp-lp | exp-dot1p | exp-dp | exp-exp | exp-lp | exp-rpr | ippre-rpr }	Required Enter the corresponding priority mapping table view as required.
Enter colored mapping table view	qos map-table color { green | yellow | red } { dscp-dot1p | dscp-dp | dscp-dscp | dscp-exp | dscp-lp | exp-dot1p | exp-dp | exp-exp | exp-lp | lp-dot1p | lp-dp | lp-dscp | lp-exp | lp-lp }
Create a mapping	import import-value-list export export-value	Required The new mapping overwrites the previous one, if any.
Display an uncolored mapping table	display qos map-table [ dot1p-dp | dot1p-lp | dot1p-rpr | dscp-dot1p | dscp-dp | dscp-dscp | dscp-exp | dscp-lp | exp-dot1p | exp-dp | exp-exp | exp-lp | exp-rpr | ippre-rpr ]	Optional Available in any view
Display the configured colored mapping table	display qos map-table color [ green | yellow | red ] [ dscp-dot1p | dscp-dp | dscp-dscp | dscp-exp | dscp-lp | exp-dot1p | exp-dp | exp-exp | exp-lp | lp-dot1p | lp-dp | lp-dscp | lp-exp | lp-lp ]

 

5.2.3  Configuration Examples

I. Uncolored mapping table configuration example

l           Network requirements

Modify the 802.1p-precedence-to-local-precedence mapping table as follows:

Table 5-1 The specified 802.1p-precedence-to-local-precedence mapping table

802. 1p precedence	Local precedence
0	0
1	0
2	1
3	1
4	2
5	2
6	3
7	3

 

l           Configuration procedure

# Enter system view.

<Sysname> system-view

# Enter 802.1p-precedence-to-local-precedence mapping table view.

[Sysname] qos map-table dot1p-lp

# Modify the 802.1p-precedence-to-local-precedence mapping table 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

II. Colored mapping table configuration example

l           Network requirements

Modify the exp-lp mapping table for green packets as follows:

Table 5-2 The exp-lp mapping table for green packets

Green + EXP	Local precedence
0	0
1	0
2	1
3	1
4	2
5	2
6	3
7	3

 

l           Configuration procedure

# Enter system view.

<Sysname> system-view

# Enter the view of the exp-lp mapping table for green packets.

[Sysname] qos map-table color green exp-lp

# Modify mapping entries.

[Sysname-maptbl-green-exp-lp] import 0 1 export 0

[Sysname-maptbl-green-exp-lp] import 2 3 export 1

[Sysname-maptbl-green-exp-lp] import 4 5 export 2

[Sysname-maptbl-green-exp-lp] import 6 7 export 3

5.3  Configuring Port Priority

The S9500 series provide the following two priority trust modes:

l           Trust packet priority: the switch looks up the priority mapping table based on the priority of a packet to assign priority parameters to the packet.

l           Trust port priority: the switch assigns local precedence values to all the packets by looking up the priority mapping table based on the pre-defined port priority of the receiving port.

You can configure the priority trust mode for a switch as required. By default, port priority is trusted. You can set the port priority as needed.

5.3.1  Configuration Prerequisites

The port priority value of the corresponding port is determined.

5.3.2  Configuration Procedure

Follow these steps to configure port priority:

To do...		Use the command...	Remarks
Enter system view		system-view	—
Enter Ethernet interface view or port group view	Enter Ethernet interface view	interface interface-type interface-number	Use either the command Configured in Ethernet interface view, the setting is effective on the current interface only; configured in port group view, the setting is effective on all the ports in the port group.
	Enter port group view	port-group { manual port-group-name | aggregation agg-id }
Configure port priority		qos priority priority-value	Optional 0 by default

 

 

5.3.3  Configuration Examples

I. Network requirements

l           All departments in the enterprise network are interconnected through Switch. The network creates different VLANs for different departments.

l           It is required that Switch assign local precedence values to packets through priority mapping on the incoming port.

l           The default priority mapping tables of Switch are adopted in priority mapping.

II. Network diagram

Figure 5-2 Network diagram for priority trust mode configuration

III. Configuration procedure

# Enter system view.

<Sysname> system-view

# Configure port priority for Ethernet 1/1/1.

[Sysname] interface ethernet 1/1/1

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

[Sysname-Ethernet1/1/1] quit

# Configure port priority for Ethernet 1/1/2.

[Sysname] interface ethernet 1/1/2

[Sysname-Ethernet1/1/2] qos priority 3

[Sysname-Ethernet1/1/2] quit

# Configure port priority for Ethernet 1/1/3.

[Sysname] interface ethernet 1/1/3

[Sysname-Ethernet1/1/3] qos priority 5

[Sysname-Ethernet1/1/3] quit

# Configure port priority for Ethernet 1/1/4.

[Sysname] interface ethernet 1/1/4

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

[Sysname-Ethernet1/1/4] quit

5.4  Configuring to Trust Packet Priority

You can configure to trust the 802.1p precedence of a packet. For the packet priority mapping process, refer to Priority Mapping Overview.

5.4.1  Configuration Procedure

Follow these steps to configure to trust packet priority:

To do...		Use the command...	Remarks
Enter system view		system-view	—
Enter Ethernet interface view or port group view	Enter Ethernet interface view	interface interface-type interface-number	Use either the command Configured in Ethernet interface view, the setting is effective on the current interface only; configured in port group view, the setting is effective on all the ports in the port group.
	Enter port group view	port-group { manual port-group-name | aggregation agg-id }
Configure to trust the 802.1p precedence of a packet		qos trust dot1p	Optional By default, the port priority is trusted.
Display the priority trust mode of a port		display qos trust interface [ interface-type interface-number ]	Optional Available in any view

 

 

5.4.2  Configuration Examples

I. Network requirement

l           All departments in the enterprise network are interconnected through Switch. The network creates different VLANs for different departments.

l           It is required that Switch assign local precedence values to packets through priority mapping on the incoming port.

l           The default priority mapping tables of Switch are adopted in priority mapping.

II. Network diagram

Figure 5-3 Network diagram for priority trust mode configuration

III. Configuration procedure

# Enter system view

<Sysname> system-view

# Enter 802.1p-precedence-to-local-precedence mapping table view to modify the mapping table parameters.

[Sysname] qos map-table dot1p-lp

[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

[Sysname-maptbl-dot1p-lp] quit

# Configure to trust 802.1p precedence on Ethernet 1/1/1.

[Sysname] interface ethernet 1/1/1

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

[Sysname-Ethernet1/1/1] quit

# Configure to trust 802.1p precedence on Ethernet 1/1/2.

[Sysname] interface ethernet 1/1/2

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

[Sysname-Ethernet1/1/2] quit

# Configure to trust 802.1p precedence on Ethernet 1/1/3.

[Sysname] interface ethernet 1/1/3

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

[Sysname-Ethernet1/1/3] quit

# Configure to trust 802.1p precedence on Ethernet 1/1/4.

[Sysname] interface ethernet 1/1/4

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

 

Chapter 6  Congestion Avoidance

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

l           Congestion Avoidance Overview

l           Configuring WRED

l           Displaying and Maintaining WRED

l           WRED Configuration Examples

6.1  Congestion Avoidance Overview

Excessive congestion can endanger network resources greatly, so some congestion avoidance measures must be taken. Congestion avoidance refers to a traffic control mechanism that can monitor the occupancy status of network resources (such as the queues or buffer). As congestion becomes worse, the system actively drops packets and tries to avoid the network overload through adjusting the network traffics.

Comparing with the end-to-end traffic control, this traffic control herein is of broader significance, which affects more loads of application streams through a device. Of course, while dropping packets, the device may cooperate with traffic control actions (such as TCP traffic control) on the source end to adjust the network's traffic to a reasonable load level. A good combination of packet-drop policies with traffic control mechanisms can maximize the throughput and utilization of network and minimize the packet drop and delay.

I. Traditional packet-drop policy

The traditional packet-drop policy is tail-drop, that is, when the amount of packets in a queue reaches the maximum value, all newly arrived packets are dropped.

This drop policy leads to global TCP synchronization, that is, when queues drop packets of several TCP links at the same time, these TCP links enter congestion avoidance and slow start status to adjust traffics simultaneously, and then reach traffic peak simultaneously. In this way, network traffic keeps in frequent rises and decreases.

II. RED and WRED

To avoid global TCP synchronization, random early detection (RED) or weighted random early detection (WRED) can be used.

In RED algorithm, a maximum threshold and a minimum threshold are set for each queue. The packets in the queue are processed as follows:

l           When the queue length is smaller than the minimum threshold, no packet is dropped.

l           When the queue length exceeds the maximum threshold, all the incoming packets are dropped.

l           When the queue length is between the maximum threshold and the minimum threshold, the packets are dropped randomly. The longer the queue is, the higher the drop probability is, but a maximum drop probability exists.

Unlike RED, the random numbers of WRED is generated based on priority. It uses IP precedence to determine the drop policy, and thus the drop probability of packets with high priority is relatively low.

RED and WRED employ the random packet drop policy to avoid global TCP synchronization. When packets of a TCP link are dropped and sent at a low rate, the other TCP links still send packets at high rates. There are always some TCP links sending packets at high rates, thus improving link bandwidth utilization.

III. Average queue length

Dropping packets through comparing the queue length with the maximum/minimum threshold treat the burst traffic unfairly and affect traffic transmission. WRED compares the average queue length with the maximum/minimum threshold to determine the drop probability.

The average queue length reflects the queue change tendency and is insensitive to bursting change of the queue length, thus preventing the unfair treatment for the bursting traffic. The average queue length is calculated using the following formula: average queue length = (Previous average queue length × (1-2^-n)) + (Current queue length ×2^-n), where n can be configured through the qos wred weighting-constant command.

IV. Relationship between WRED and queuing mechanisms

The relationship between WRED and queuing mechanisms is shown as in the following figure:

Figure 6-1 Relationship between WRED and queuing mechanisms

Through associating WRED with WFQ, the flow-based WRED can be realized. Because different flow has its own queue during packet classification, the flow with small traffic always has a small queue length, so the packet drop probability is low. The flow with big traffic has bigger queue length, so more packets are dropped. In this way, the benefits of the flow with small traffic are protected.

6.2  Configuring WRED

6.2.1  Description on WRED Parameters

Determine the following parameters before configuring WRED:

l           Drop level: specifies the range of packets for which the following WRED parameters will take effect. If no drop level is specified, the parameters take effect on all the packets in the current queue; if a drop level is specified, the following parameters take effect on packets with the specified drop level.

l           The maximum threshold and minimum threshold: when the average queue length is smaller than the minimum threshold, no packet is dropped. When the average queue length is between the maximum threshold and the minimum threshold, the packets are dropped randomly. The longer the queue is, the higher the drop probability is. When the average queue length exceeds the average queue length, all the incoming packets are dropped.

l           The exponent used for calculating average queue length: as the exponent increases, the average queue length calculation becomes more sensitive to real-time queue change.

l           The denominator used for calculating the drop probability: this argument functions as the denominator when the drop probability is calculated. The bigger the denominator is, the smaller the calculated drop probability is.

 

l           GV48D, GP48D, and XP4DB boards do not support WRED.

 

6.2.2  Configuration Procedure

I. Configuring and applying a queue-based WRED table

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

To do…		Use the command…	Remarks
Enter system view		system-view	—
Configure a WRED table		qos wred queue table table-name	Required
Configure the exponent used for calculating average queue length		queue queue-value weighting-constant exponent	Optional 9 by default
Configure other parameters for the WRED table		queue queue-value [ drop-level drop-level ] low-limit low-limit high-limit high-limit [ discard-probability discard-prob ]	Optional
Enter Ethernet interface view or port group view	Enter Ethernet interface view	interface interface-type interface-number	Use either the command Configured in Ethernet interface view, the setting is effective on the current interface only; configured in port group view, the setting is effective on all the ports in the port group.
	Enter port group view	port-group { manual port-group-name | aggregation agg-id }
Apply the WRED table to the port		qos wred apply table-name	Required

 

 

6.3  Displaying and Maintaining WRED

Follow these steps to display and maintain WRED:

To do...	Use the command...	Remarks
Display WRED configuration and statistics information on the interface	display qos wred interface [ interface-type interface-number ]	Available in any view
Display WRED table configuration status	display qos wred table [ table-name ]	Available in any view

 

6.4  WRED Configuration Examples

I. Network requirement

Apply a queue-based WRED table to Ethernet 1/1/1.

II. Configuration procedure

# Enter system view.

<Sysname> system-view

# Configure a queue-based WRED table.

[Sysname] qos wred queue table queue-table1

[Sysname-wred-table-queue-table1] queue 2 weighting-constant 10

[Sysname-wred-table-queue-table1] queue 2 drop-level 0 low-limit 100 high-limit 1000 discard-probability 1

[Sysname-wred-table-queue-table1] queue 2 drop-level 1 low-limit 50 high-limit 100 discard-probability 2

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

# Enter Ethernet interface view.

[Sysname] interface ethernet 1/1/1

# Apply the WRED table to Ethernet 1/1/1.

[Sysname-Ethernet1/1/1] qos wred apply queue-table1

 

Chapter 7  Aggregation CAR Configuration

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

l           Aggregation CAR Overview

l           Referencing Aggregation CAR in Traffic Behaviors

7.1  Aggregation CAR Overview

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

7.2  Referencing Aggregation CAR in Traffic Behaviors

7.2.1  Configuration Prerequisites

l           Parameters of the CAR used for aggregation CAR are specified.

l           Traffic behaviors where the aggregation CAR is referenced are specified.

7.2.2  Configuration Procedure

Follow these steps to reference an aggregation CAR in traffic behaviors:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Configure parameters for CAR	qos car car-name aggregative cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ pir peek-information-rate ] [ red action ]	Required By default: l      CBS is MAX (CIR × 62.5, 1875). l      EBS is 0. l      PIR is 0. l      The red packets are dropped.
Enter traffic behavior view	traffic behavior behavior-name	Required
Reference the aggregation CAR in the traffic behavior	car name car-name	Required

 

 

7.2.3  Configuration Examples

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

The configuration procedure is as follows:

<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

7.3  Displaying and Maintaining Aggregation CAR

To do…	Use the command…	Remarks
Display the configurations and statistics about aggregation CARs	display qos car name [ car-name ]	Available in any view
Clear the statistics for aggregation CARs	reset qos car name [ car-name ]	Available in any view

 

Chapter 8  VLAN Policy Configuration

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

l           VLAN Policy Overview

l           Configuring a VLAN Policy

l           Displaying and Maintaining VLAN Policies

l           VLAN Policy Configuration Examples

8.1  VLAN Policy Overview

A QoS policy can be applied to an interface to regulate the inbound or outbound traffic on the interface or to a VLAN to regulate the traffic of the VLAN.

A QoS policy applied to an interface is called an interface policy and a QoS policy applied to a VLAN is called a VLAN policy in this manual.

On C-type and D-type boards, VLAN policies take effect preferentially. That is, if packets match the VLAN policy, they do not try to match an interface policy; otherwise, they search an interface policy. On B-type boards, interface policies take effect preferentially. With an interface policy applied to an interface, the packets do not search a VLAN policy no matter whether they match the interface policy or not.

VLAN policies are invalid on user authentication interfaces. A user authentication interface joins and exits a VLAN dynamically, and the corresponding VLAN policy is not applied to the interface.

VLAN policies are invalid on dynamic VLANs. VLAN policies cannot be applied to dynamic VLANs. For example, with GARP VLAN registration protocol (GVRP) running, the switch may create a VLAN dynamically, and the corresponding VLAN policy does not take effect on the dynamic VLAN.

 

 

8.2  Configuring a VLAN Policy

8.2.1  Configuration Prerequisites

l           Configure a VLAN policy. Refer to Configuring QoS Policy for details.

l           Apply the VLAN policy to the specified VLAN(s).

8.2.2  Configuration Procedure

Follow these steps to apply the VLAN policy to the specific VLAN:

Operation	Command	Description
Enter system view	system-view	—
Apply the VLAN policy to the inbound direction of the specific VLAN(s)	qos vlan-policy policy-name vlan vlan-id-list inbound	Required If the action of redirecting traffic to an EACL is configured in the traffic behavior, you need to create a VLAN interface for the specified VLAN first.
Apply the VLAN policy to the outbound direction of the specified VLAN(s)	qos vlan-policy policy-name vlan vlan-id-list outbound	Optional This configuration is available only for EACL. Refer to Configuring a Reflexive ACL Policy and Configuring BT Traffic Limiting for related information.

 

8.3  Displaying and Maintaining VLAN Policies

Follow these steps to display and maintain VLAN policies:

To do…	Use the command…	Remarks
Display the information about a VLAN policy	display qos vlan-policy { name policy-name | vlan [ vlan-id ] } [ slot slot-id ]	Available in user view
Clear the statistics information about VLAN policies applied to a VLAN	reset qos vlan-policy [ vlan vlan-id ]

 

8.4  VLAN Policy Configuration Examples

8.4.1  Network Requirements

l           The VLAN policy test is defined to perform traffic policing for packets matching ACL 2000, with the CIR parameter being 8.

l           Apply the VLAN policy to the inbound direction of VLAN 200, VLAN 300, VLAN 400, VLAN 500, VLAN 600, VLAN 700, and VLAN 800.

8.4.2  Configuration Procedure

<Sysname> system-view

[Sysname] traffic classifier cl1 operator or

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

[Sysname-classifier-cl1] quit

[Sysname] traffic behavior be1

[Sysname-behavior-be1] car cir 8

[Sysname-behavior-be1] quit

[Sysname] qos policy test

[Sysname-qospolicy-test] classifier cl1 behavior be1

[Sysname-qospolicy-test] quit

[Sysname] qos vlan-policy test vlan 200 300 400 500 600 700 800 inbound

 

Chapter 9  Traffic Mirroring Configuration

When configuring traffic classification and traffic shaping, 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

9.1  Traffic Mirroring Overview

Traffic mirroring copies packets matching specific traffic classification rules to the specified destination for packet analysis and monitoring.

You can configure to mirror traffic to a port or the CPU.

l           Mirroring traffic to a port: copies the matching packets on a port and forwards these packets to the destination port.

l           Mirroring traffic to the CPU: copies the matching packets on an interface and forwards these packets to the CPU (the CPU of the board where the traffic mirroring-enabled interface is seated).

9.2  Configuring Traffic Mirroring

To configure traffic mirroring, you must create a traffic behavior and enter traffic behavior view.

 

 

9.2.1  Mirroring Traffic to a Port

Follow these steps to mirror traffic to a port:

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

 

 

9.2.2  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	—
Configure the action of mirroring traffic to the traffic for the traffic behavior	mirror-to cpu	Required The CPU here refers to the CPU of the board where the interface resides.

 

 

9.3  Displaying and Maintaining Traffic Mirroring

Follow these steps to display and maintain traffic mirroring:

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

 

9.4  Traffic Mirroring Configuration Examples

I. Network requirements

The user's network is as described below:

l           Host is connected to Ethernet 1/1/2 of the switch, and Server is connected to Ethernet 1/1/1 of the switch.

l           Server is installed with two network adapters.

It is required that Server analyze and monitor all the packets with the source IP address 1.1.1.1 that Host forwards.

II. Network diagram

Figure 9-1 Network diagram for mirroring traffic to a port

III. Configuration procedure

Configure Switch:

# Enter system view.

<Sysname> system-view

# Configure ACL 2000 to permit all packets with the source address 1.1.1.1.

[Sysname] acl number 2000

[Sysname-acl-basic-2000] rule 1 permit source 1.1.1.1 0

[Sysname-acl-basic-2000] quit

# Configure a traffic classifier and 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 with the action of mirroring traffic to Ethernet 1/1/1.

[Sysname] traffic behavior 1

[Sysname-behavior-1] mirror-to interface ethernet 1/1/1

[Sysname-behavior-1] quit

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

[Sysname] qos policy 1

[Sysname-qospolicy-1] classifier 1 behavior 1

[Sysname-qospolicy-1] quit

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

[Sysname] interface ethernet 1/1/2

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

After the configuration above, you can analyze and monitor all the packets with the source address 1.1.1.1 that Host forwards on Server.

 

Chapter 10  EACL Configuration

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

l           EACL Overview

l           EACL Configuration Task List

l           Configuring a Reflexive ACL Policy

l           Configuring BT Traffic Limiting

l           Troubleshooting EACL

10.1  EACL Overview

An enhanced ACL (EACL) is used to redirect traffic matching certain ACL rules to a service card. Currently, the S9500 series support reflexive ACL and BitTorrent (BT) traffic limiting for EACL.

 

 

10.2  EACL Configuration Task List

Complete the following tasks to configure EACL:

Task	Remarks
Configuring a Reflexive ACL Policy	Optional
Configuring BT Traffic Limiting	Optional
Configuring a QoS Policy	Required

 

10.2.1  Configuring a Reflexive ACL Policy

A reflexive ACL is a dynamic ACL used to enhance the system security. Dynamic ACLs are ACL entries created dynamically based on how the internal network accesses the external network. Dynamic ACLs are used to control how the external network accesses the internal network. If the internal network does not access the external network, the external network cannot initiate access to the internal network.

Follow these steps to configure a reflexive ACL policy:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Create a VLAN	vlan vlan-id	Required
Exit to system view	quit	—
Create a VLAN interface and enter VLAN interface view	interface vlan-interface vlan-interface-id	Required
Exit to system view	quit	—
Create an advanced ACL and enter advanced ACL view	acl number acl-number [ match-order { config | auto } ]	—
Configure reflexive ACL rules	rule [ rule-id ] permit { icmp | tcp | udp } [ destination { dest-addr dest-wildcard | any } | destination-port operator port1 [ port2 ] | dscp dscp | established | fragment | icmp-type { icmp-type icmp-code | icmp-message } | logging | precedence precedence | reflective | source { sour-addr sour-wildcard | any } | source-port operator port1 [ port2 ] | time-range time-name | tos tos ] *	Required The protocol type can only be ICMP, TCP, or UDP. The reflective keyword is required. You can repeat this step to create multiple rules. Refer to ACL Commands in the QoS ACL Volume for the use of the rule command.
Exit to system view	quit	—
Create a class and enter class view	traffic classifier tcl-name [ operator and ]	Required In class view, the relationship between match criteria is logical AND.
Configure a match criterion	if-match acl acl-number	Required Only one ACL match criterion can be configured.
Exit to system view	quit	—
Create a traffic behavior and enter traffic behavior view	traffic behavior behavior-name	—
Configure the traffic filtering action	filter permit	Required Permitting the conformance traffic is the only filtering action you can configure here.
Exit to system view	quit	—
Create a policy and enter policy view	qos policy policy-name	—
Associate the traffic behavior with the class in the policy	classifier tcl-name behavior behavior-name	Required
Exit to system view	quit	—
Enter EACL service subinterface view	interface eacl interface-number	—
Apply the reflective ACL policy to the interface	qos apply policy policy-name { inbound | outbound }	Required A QoS policy can be applied only to the outbound direction of an EACL service subinterface.
Configure interface binding	qos binding interface interface-type interface-number	Required
Exit to user view	return	—

 

10.2.2  Configuring BT Traffic Limiting

BitTorrent (BT) is shared software used for file downloading. It is featured that the more users are downloading with BT, the faster the download speed is. As BT greatly reduces the load of the download server, it causes significantly increased data downloading. To ensure the operation of other services, the administrators must control BT traffic.

The QoS implementation on the S9500 series can identify BT traffic based on the characteristics of the BT peer protocol, allowing you to manipulate BT traffic as needed.

Follow these steps to configure BT traffic limiting:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Create a VLAN	vlan vlan-id	Required
Exit to system view	quit	—
Create a VLAN interface and enter VLAN interface view	interface vlan-interface vlan-interface-id	Required
Exit to system view	quit	—
Create an advanced ACL and enter advanced ACL view	acl number acl-number [ match-order { config | auto } ]	—
Define ACL rules	rule [ rule-id ] permit tcp [ rule-string ]	Required The action of the ACL must be permit and the protocol type must be tcp.
Exit to system view	quit	—
Create a class and enter class view	traffic classifier tcl-name [ operator and ]	Required In class view, the relationship between all match criteria is logical and.
Configure match criteria	if-match acl acl-number	Required Only one ACL match criterion can be configured.
Bind the match criterion to the BT protocol	if-match protocol bittorrent	Required
Configure the other match criteria	if-match match-criteria	Optional
Exit to system view	quit	—
Create a traffic behavior and enter traffic behavior view	traffic behavior behavior-name	—
Configure the CAR action	car cir committed-information-rate cbs committed-burst-size ebs excess-burst-size [ red action ]	Required The traffic behavior can be configured with only one action and the action must be a CAR action. The relevant parameters must satisfy the following requirements: cir *128ŸcbsŸ ebs Ÿcir*128*90
Exit to system view	quit	—
Define a policy and enter the policy view	qos policy policy-name	—
Associate the traffic behavior with the class in the policy	classifier tcl-name behavior behavior-name	Required
Exit to system view	quit	—
Enter EACL service subinterface view	interface eacl interface-number	—
Apply the BT traffic limiting policy to the EACL service subinterface	qos apply policy policy-name { inbound | outbound }	Required A QoS policy can only be applied to the outbound direction of an EACL service subinterface.
Configure interface binding	qos binding interface interface-type interface-number	Required

 

10.2.3  Configuring a QoS Policy

For an EACL to take effect, you need to associate the EACL with a QoS policy and apply the policy to the outbound or inbound direction of the specified VLAN.

I. For the outbound direction of a VLAN

Follow these steps to configure a QoS policy for traffic redirecting and apply the QoS policy to the outbound direction of the specified VLAN:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Create a basic ACL and enter basic ACL view	acl number acl-number [ match-order { auto | config } ]	Required
Define a rule	rule permit	Required You can configure only the rule that permits the traffic matching the ACL.
Exit to system view	quit	—
Create a class and enter class view	traffic classifier tcl-name	—
Configure a match criterion	if-match acl acl-number	Required Only one ACL match criterion can be configured.
Create a traffic behavior and enter traffic behavior view	traffic behavior behavior-name	—
Configure the action of redirecting traffic to an EACL service sub-interface	redirect interface eacl interface-number	Required Only one action can be configured for the traffic behavior and the action must be redirecting traffic to an EACL service sub-interface.
Exit to system view	quit	—
Create a policy and enter policy view	qos policy policy-name	—
Associate the traffic behavior with the class in the policy	classifier tcl-name behavior behavior-name	Required
Exit to system view	quit	—
Apply the policy to the outbound direction of the specified VLAN(s)	qos vlan-policy policy-name vlan vlan-id-list outbound	Required You need to create a VLAN interface for each specified VLAN first.

 

II. For the inbound direction of a VLAN

Follow these steps to configure a QoS policy and apply the QoS policy to the inbound direction of the specified VLAN:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Apply a VLAN QoS policy to the inbound direction of the specified VLAN(s)	qos vlan-policy policy-name vlan vlan-id-list inbound	Required If the traffic behavior is configured with the action of redirecting traffic to EACL, you need to create a VLAN interface for the specified VLAN.

 

 

10.3  EACL Configuration Examples

10.3.1  Reflexive ACL Configuration Examples

I. Network requirements

Through configuring reflexive ACL, achieve the aim that the external network can access the internal network only after the internal network accesses the external network. In this way, the internal network is protected from the external network attack.

In this example, reflexive ACL is configured through configuring an appropriate ACL and ACL rules to allow Host A to actively initiate access to Host B and disable Host B to actively initiate access to Host A.

The LSB1NAMB board resides in slot 8.

II. Network diagram

Figure 10-1 Network diagram for reflexive ACL configuration

III. Configuration procedure

# Enter system view and create the VLAN and VLAN interface.

<Sysname> system-view

[Sysname] vlan 3

[Sysname-vlan3] quit

[Sysname] interface vlan-interface 3

[Sysname-Vlan-interface3] quit

# Configure the reflexive ACL and apply it to the service card.

[Sysname] acl number 3000

[Sysname-acl-adv-3000] rule permit tcp reflective

[Sysname-acl-adv-3000] rule permit udp reflective

[Sysname-acl-adv-3000] rule permit icmp reflective

[Sysname-acl-adv-3000] quit

[Sysname] traffic classifier 1

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

[Sysname-classifier-1] quit

[Sysname] traffic behavior 1

[Sysname-behavior-1] filter permit

[Sysname-behavior-1] quit

[Sysname] qos policy 1

[Sysname-qospolicy-1] classifier 1 behavior 1

[Sysname-qospolicy-1] quit

[Sysname] interface eacl 8/0/1.1

[Sysname-EACL8/0/1.1] qos apply policy 1 outbound

[Sysname-EACL8/0/1.1] qos binding interface vlan-interface 3

[Sysname-EACL8/0/1.1] quit

# Configure a QoS policy and apply this policy to VLAN 3.

[Sysname] acl number 2000

[Sysname-acl-basic-2000] rule permit

[Sysname-acl-basic-2000] quit

[Sysname] traffic classifier 2

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

[Sysname-classifier-2] quit

[Sysname] traffic behavior 2

[Sysname-behavior-2] redirect interface eacl8/0/1

[Sysname-behavior-2] quit

[Sysname] qos policy 2

[Sysname-qospolicy-2] classifier 2 behavior 2

[Sysname-qospolicy-2] quit

[Sysname] qos vlan-policy 2 vlan 3 inbound

[Sysname] qos vlan-policy 2 vlan 3 outbound

10.3.2  BT Traffic Limiting Configuration Examples

I. Network requirements

Configure an appropriate ACL and its rules to implement BT traffic limiting on the LPU. It is required to control the rate of BT traffic downloaded from Host B to Host A within 100 kbps.

II. Network diagram

Figure 10-2 Network diagram for BT traffic limiting

III. Configuration procedure

# Enter system view and create the VLAN and VLAN interface.

<Sysname> system-view

[Sysname] vlan 3

[Sysname-vlan3] quit

[Sysname] interface vlan-interface 3

[Sysname-Vlan-interface3] quit

# Configure a BT traffic limiting policy and apply it to the service card. The LSB1NAMB resides in slot 8.

[Sysname] acl number 3000

[Sysname-acl-adv-3000] rule permit tcp

[Sysname-acl-adv-3000] quit

[Sysname] traffic classifier 1

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

[Sysname-classifier-1] if-match protocol bittorrent

[Sysname-classifier-1] quit

[Sysname] traffic behavior 1

[Sysname-behavior-1] car cir 100 cbs 150000 ebs 200000

[Sysname-behavior-1] quit

[Sysname] qos policy 1

[Sysname-qospolicy-1] classifier 1 behavior 1

[Sysname-qospolicy-1] quit

[Sysname] interface eacl 8/0/1.1

[Sysname-EACL8/0/1.1] qos apply policy 1 outbound

[Sysname-EACL8/0/1.1] qos binding interface vlan-interface 3

[Sysname-EACL8/0/1.1] quit

# Configure a QoS policy and apply this policy to VLAN 3.

[Sysname] acl number 2000

[Sysname-acl-basic-2000] rule permit

[Sysname-acl-basic-2000] quit

[Sysname] traffic classifier 2

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

[Sysname-classifier-2] quit

[Sysname] traffic behavior 2

[Sysname-behavior-2] redirect interface eacl 8/0/1

[Sysname-behavior-2] quit

[Sysname] qos policy 2

[Sysname-policy-2] classifier 2 behavior 2

[Sysname-qospolicy-2] quit

[Sysname] qos vlan-policy 2 vlan 3 inbound

[Sysname] qos vlan-policy 2 vlan 3 outbound

10.4  Troubleshooting EACL

I. Symptom

The EACL function fails to take effect on the switch.

II. Analysis

l           Whether appropriate matching rules are configured.

l           Whether a traffic behavior is specified for a class in the policy.

l           Whether the packets on the specific interface are redirected to the LPU.

III. Solution

1)         Check the if-match commands to see whether appropriate rules are configured.

2)         Check the classifier tcl-name behavior behavior-name command to see whether a traffic behavior is specified for a traffic class in the policy.

3)         Check the qos apply policy command and the qos binding interface command to see whether the QoS policy is applied to the specific interface and whether the EACL service subinterface is bound to the specific layer-3 interface.

 

Chapter 11  Outbound Traffic Accounting Configuration

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

l           Outbound Traffic Accounting Overview

l           Configuring Outbound Traffic Accounting

l           Displaying and Maintaining Outbound Traffic Accounting

11.1  Outbound Traffic Accounting Overview

A S9500 series switch provides two counters for each board to collect statistics on the outbound traffic. You can specify the traffic type for each counter. The traffic type can be all the outbound traffic of the board or the outbound traffic of the combination of the elements (including interface, VLAN, local precedence and drop precedence) on a board.

You can enable the two counters at the same time to collect statistics on the same type of traffic or different types of traffic.

11.2  Configuring Outbound Traffic Accounting

Follow these steps to configure outbound traffic accounting:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enable outbound traffic accounting and specify the type of outbound traffic	qos traffic-counter outbound { counter0 | counter1 } slot slot-num [ interface interface-type interface-number | vlan vlan-id | local-precedence lp-value | drop-priority dp-value ] *	By default, the outbound traffic accounting function is disabled.

 

 

11.3  Displaying and Maintaining Outbound Traffic Accounting

Follow these steps to display and maintain outbound traffic accounting:

To do…	Use the command…	Remarks
Display the outbound traffic statistics	display qos traffic-counter outbound { counter0 | counter1 } slot slot-num	Available in any view
Clear the outbound traffic statistics collected by a counter	reset qos traffic-counter outbound { counter0 | counter1 } slot slot-num	Available in user view