Aruba JH147A HPE FlexNetwork Switch Installation Guide

Applying the QoS policy to a

VLAN

•

Applying the QoS policy to a user profile

N/A

Choose one of the application destinations as needed.

By default, no QoS policy is applied.

12. (Optional.) Display traffic policing configuration. user-defined [ behavior-name ]

Available in any view.

Configuring GTS

The switch supports configuring queue-based GTS by using the non-MQC approach. In queue-based GTS, you set GTS parameters for packets of a queue.

To configure GTS:

Step Command Remarks

1. Enter system view. system-view N/A

2. Enter interface view. interface interface-type interface-number N/A

3. Configure GTS for a queue. qos gts queue queue-id cir

committed-information-rate

committed-burst-size ]

[ cbs

By default, GTS is not configured on an interface.

Configuring the rate limit

This feature is available on both Layer 2 and Layer 3 Ethernet interfaces. The term "interface" in this section collectively refers to these two types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see Layer 2—LAN

Switching Configuration Guide ).

The rate limit of a physical interface specifies the maximum rate of incoming packets or outgoing packets.

To configure the rate limit:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Enter interface view.

3. Configure the rate limit for the interface. interface interface-number interface-type

N/A qos lr { inbound | outbound } cir committed-information-rate [ cbs committed-burst-size ]

By default, rate limit is not configured on an interface.

Displaying and maintaining traffic policing, GTS, and rate limit

Execute display commands in any view.

Task

Display QoS and ACL resource usage.

Command display qos-acl resource [ slot slot-number ]

Display traffic behavior configuration. display traffic behavior user-defined [ behavior-name ]

Display GTS configuration on an interface. display qos gts interface [ interface-type interface-number ]

Display rate limit configuration on an interface. display qos lr interface [ interface-type interface-number ]

Traffic policing configuration example

Network requirements

As shown in Figure 12 , configure traffic policing on GigabitEthernet 1/0/1 of Switch A to meet the

following requirements:

•

Limit the rate of traffic from the server to 102400 kbps: Transmit the conforming traffic, mark the excess traffic with DSCP value 0, and then transmit the excess traffic.

•

Limit the rate of traffic from Host A to 25600 kbps: Transmit the conforming traffic, and drop the excess traffic.

Configure traffic policing on GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2 of Switch B to meet the following requirements:

•

Limit the total incoming traffic rate of GigabitEthernet 1/0/1 to 204800 kbps and drop the excess traffic.

•

Limit the outgoing HTTP traffic (traffic accessing the Internet) rate of GigabitEthernet 1/0/2 to

102400 kbps and drop the excess traffic.

Figure 12 Network diagram

Server

1.1.1.1/8 Ethernet

Host A

1.1.1.2/8 GE1/0/1

Switch B

GE1/0/2

Internet

Host B GE1/0/1

Switch A

GE1/0/3

GE1/0/2

Configuration procedure

1. Configure Switch A:

# Configure ACL 2001 and ACL 2002 to match traffic from the server and Host A, respectively.

<SwitchA> system-view

[SwitchA] acl number 2001

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

[SwitchA-acl-basic-2001] quit

[SwitchA] acl number 2002

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

[SwitchA-acl-basic-2002] quit

# Create a class named server and use ACL 2001 as the match criterion. Create a class named host and use ACL 2002 as the match criterion.

[SwitchA] traffic classifier server

[SwitchA-classifier-server] if-match acl 2001

[SwitchA-classifier-server] quit

[SwitchA] traffic classifier host

[SwitchA-classifier-host] if-match acl 2002

[SwitchA-classifier-host] quit

# Create a behavior named server and configure the CAR action for the behavior as follows:

Set the CIR to 102400 kbps, and mark the excess packets (red packets) with DSCP value 0 and transmit them.

[SwitchA] traffic behavior server

[SwitchA-behavior-server] car cir 102400 red remark-dscp-pass 0

[SwitchA-behavior-server] quit

# Create a behavior named host and configure the CAR action for the behavior as follows: Set the CIR to 25600 kbps.

[SwitchA] traffic behavior host

[SwitchA-behavior-host] car cir 25600

[SwitchA-behavior-host] quit

# Create a QoS policy named car and associate class server with behavior server and class host with behavior host .

[SwitchA] qos policy car

[SwitchA-qospolicy-car] classifier server behavior server

[SwitchA-qospolicy-car] classifier host behavior host

[SwitchA-qospolicy-car] quit

# Apply QoS policy car to the incoming traffic of GigabitEthernet 1/0/1.

[SwitchA] interface GigabitEthernet 1/0/1

[SwitchA-GigabitEthernet1/0/1] qos apply policy car inbound

2. Configure Switch B:

# Configure advanced ACL 3001 to match HTTP traffic.

<SwitchB> system-view

[SwitchB] acl number 3001

[SwitchB-acl-adv-3001] rule permit tcp destination-port eq 80

[SwitchB-acl-adv-3001] quit

# Create a class named http and use ACL 3001 as the match criterion.

[SwitchB] traffic classifier http

[SwitchB-classifier-http] if-match acl 3001

[SwitchB-classifier-http] quit

# Create a class named class and configure the class to match all packets.

[SwitchB] traffic classifier class

[SwitchB-classifier-class] if-match any

[SwitchB-classifier-class] quit

# Create a behavior named car_inbound and configure the CAR action for the behavior as follows: Set the CIR to 204800 kbps.

[SwitchB] traffic behavior car_inbound

[SwitchB-behavior-car_inbound] car cir 204800

[SwitchB-behavior-car_inbound] quit

# Create a behavior named car_outbound and configure a CAR action for the behavior as follows: Set the CIR to 102400 kbps.

[SwitchB] traffic behavior car_outbound

[SwitchB-behavior-car_outbound] car cir 102400

[SwitchB-behavior-car_outbound] quit

# Create a QoS policy named car_inbound and associate class class with traffic behavior car_inbound in the QoS policy.

[SwitchB] qos policy car_inbound

[SwitchB-qospolicy-car_inbound] classifier class behavior car_inbound

[SwitchB-qospolicy-car_inbound] quit

# Create a QoS policy named car_outbound and associate class http with traffic behavior car_outbound in the QoS policy.

[SwitchB] qos policy car_outbound

[SwitchB-qospolicy-car_outbound] classifier http behavior car_outbound

[SwitchB-qospolicy-car_outbound] quit

# Apply QoS policy car_inbound to the incoming traffic of GigabitEthernet 1/0/1.

[SwitchB] interface GigabitEthernet 1/0/1

[SwitchB-GigabitEthernet1/0/1] qos apply policy car_inbound inbound

# Apply QoS policy car_outbound to the outgoing traffic of GigabitEthernet 1/0/2.

[SwitchB] interface GigabitEthernet 1/0/2

[SwitchB-GigabitEthernet1/0/2] qos apply policy car_outbound outbound

Configuring congestion management

Overview

Congestion occurs on a link or node when traffic size exceeds the processing capability of the link or node. It is typical of a statistical multiplexing network and can be caused by link failures, insufficient resources, and various other causes.

Figure 13 shows two typical congestion scenarios.

Figure 13 Traffic congestion scenarios

100M

100M 10M 100M 10M

100M > 10M

50M

(100M + 10M + 50M) > 100M

(1) (2)

Congestion produces the following negative results:

•

Increased delay and jitter during packet transmission.

•

Decreased network throughput and resource use efficiency.

•

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

Congestion is unavoidable in switched networks and multiuser application environments. To improve the service performance of your network, take measures to manage and control it.

The key to congestion management is defining a resource dispatching policy to prioritize packets for forwarding when congestion occurs.

Congestion management uses queuing and scheduling algorithms to classify and sort traffic leaving a port.

The Switch Series supports the following queue-scheduling mechanisms.

SP queuing

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

Figure 14 SP queuing

Queue 7

High priority

Packets to be sent through this port

Queue 6 Sent packets

Interface

……

Queue 1

Packet classification

Queue scheduling

Sending queue

Queue 0

Low priority

In Figure 14 , SP queuing classifies eight queues on a port into eight classes, numbered 7 to 0 in

descending priority order.

SP queuing schedules the eight queues in descending order of priority. SP queuing sends packets in the queue with the highest priority first. When the queue with the highest priority is empty, it sends packets in the queue with the second highest priority, and so on. You can assign mission-critical packets to a high priority queue to make sure they are always served first. Common service packets can be assigned to low priority queues to be transmitted when high priority queues are empty.

The disadvantage of SP queuing is that packets in the lower priority queues cannot be transmitted if packets exist in the higher priority queues for a long time. In the worst case, lower priority traffic might never get serviced.

WRR queuing

WRR queuing schedules all the queues in turn to ensure that every queue is served for a certain

time, as shown in Figure 15 .

Figure 15 WRR queuing

Queue 0 Weight 1

Packets to be sent through this port Queue 1 Weight 2 Sent packets

Interface

……

Queue N-2 Weight N-1

Packet classification

Queue N-1 Weight N

Queue scheduling

Sending queue

Assume a port provides eight output queues. WRR assigns each queue a weight value (represented by w7, w6, w5, w4, w3, w2, w1, or w0) to decide the proportion of resources assigned to the queue.

The switch implements the weight of a queue by scheduling a certain number of bytes (byte-count

WRR) or packets (packet-based WRR) for that queue. Take byte-count WRR as an example: On a

10 Gbps port, you can set the weight values of WRR queuing to 5, 5, 3, 3, 1, 1, 1, and 1

(corresponding to w7, w6, w5, w4, w3, w2, w1, and w0, respectively). In this way, the queue with the lowest priority can get a minimum of 500 Mbps of bandwidth. WRR solves the problem that SP queuing might fail to serve packets in low-priority queues for a long time.

WFQ queuing

Figure 16 WFQ queuing

Queue 0 Weight 1

Packets to be sent through this port Queue 1 Weight 2 Sent packets

Interface

……

Queue N-2 Weight N-1

Packet classification

Queue N-1 Weight N

Queue scheduling

Sending queue

WFQ is similar to WRR. The difference is that WFQ enables you to set guaranteed bandwidth that a

WFQ queue can get during congestion.

SP+WRR queuing

You can configure some queues on an interface to use SP queuing and others to use WRR queuing by assigning the queues to the SP group and the WRR group (group 1). With this SP+WRR queuing method, the system first schedules the queues in the SP group and then schedules queues in the

WRR group when all queues in the SP group are empty. The queues in the SP group are scheduled based on their priorities. The queues in the WRR group are scheduled based on their weights.

SP+WFQ queuing

You can configure some queues on an interface to use SP queuing and others to use WFQ queuing by assigning the queues to the SP group and the WFQ group (group 1). With this SP+WFQ queuing method, the system schedules traffic as follows:

1. The system schedules the traffic conforming to the minimum guaranteed bandwidth in the WFQ group.

2. The system uses SP to schedule queues in the SP group.

3. If there is remaining bandwidth, the system schedules the traffic of queues in the WFQ group based on their weights.

Congestion management configuration task list

Tasks at a glance

(Required.) Configuring queuing

•

Configuring SP queuing

•

Configuring WRR queuing

•

Configuring WFQ queuing

•

Configuring SP+WRR queuing

•

Configuring SP+WFQ queuing

(Optional.) Configuring queue scheduling profiles

Remarks

Perform one of the tasks.

N/A

Configuring queuing

This feature is available on both Layer 2 and Layer 3 Ethernet interfaces. The term "interface" in this chapter collectively refers to these two types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see Layer 2—LAN

Switching Configuration Guide ).

Configuring SP queuing

Configuration procedure

To configure SP queuing:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Enter interface view. interface interface-number interface-type

N/A

The default queuing algorithm on an interface is WRR queuing.

3. Configure SP queuing.

qos sp

Configuration example

Configure GigabitEthernet 1/0/1 to use SP queuing:

# Enter system view

<Sysname> system-view

# Configure GigabitEthernet1/0/1 to use SP queuing.

[Sysname] interface gigabitethernet 1/0/1

[Sysname-GigabitEthernet1/0/1] qos sp

Configuring WRR queuing

Configuration procedure

To configure WRR queuing:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Enter interface view. interface interface-type interface-number

3. Enable byte-count or packet-based WRR queuing.

qos wrr { byte-count | weight }

N/A

By default, byte-count WRR queuing is used.

4. Assign a queue to a

WRR group, and 1 configure scheduling { byte-count | weight } parameters for the schedule-value queue.

Select weight or byte-count according to the type (byte-count or packet-based) of

WRR you have enabled.

By default, all queues are in group 1, and the weights of queues 0 through 7 are 1, 2, 3, 4,

5, 9, 13, and 15, respectively.

Configuration example

1. Network requirements

Enable packet-based WRR on port GigabitEthernet 1/0/1, and assign queues 0 through 7 to the

WRR group, with their weights being 1, 2, 4, 6, 1, 2, 4, and 6, respectively.

2. Configuration procedure

# Enter system view.

<Sysname> system-view

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

[Sysname] interface GigabitEthernet 1/0/1

[Sysname-GigabitEthernet1/0/1] qos wrr weight

[Sysname-GigabitEthernet1/0/1] qos wrr 0 group 1 weight 1

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

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

[Sysname-GigabitEthernet1/0/1] qos wrr 3 group 1 weight 6

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

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

[Sysname-GigabitEthernet1/0/1] qos wrr 6 group 1 weight 4

[Sysname-GigabitEthernet1/0/1] qos wrr 7 group 1 weight 6

Configuring WFQ queuing

Configuration procedure

To configure WFQ queuing:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Enter interface view. interface interface-type interface-number

N/A

3. Enable byte-count or { byte-count | packet-based WFQ queuing.

weight }

The default queuing algorithm on an interface is WRR queuing.

4. Assign a queue to a WFQ group, qos wfq queue-id group 1 and configure scheduling byte-count | weight } parameters for the queue.

schedule-value

Select weight or byte-count according to the type (byte-count or packet-based) of WFQ you have enabled.

Step Command Remarks

By default, all queues are in WFQ group 1 and have a weight of 1.

5. (Optional.) Set the minimum guaranteed bandwidth for a

WFQ queue. qos bandwidth queue

The default setting is 64 kbps for

queue-id min

bandwidth-value each queue.

Configuration example

1. Network requirements



Configure byte-count WFQ queuing on interface GigabitEthernet 1/0/1.

Assign queues 0 through 7 to the WFQ group, with their weights being 1, 1, 2, 5, 10, 10, 10, and 10, respectively.

Set the minimum guaranteed bandwidth to 100 Mbps for each queue.

2. Configuration procedure

# Enter system view.

<Sysname> system-view

# Configure byte-count WFQ queuing on interface GigabitEthernet 1/0/1.

[Sysname] interface GigabitEthernet 1/0/1

[Sysname-GigabitEthernet1/0/1] qos wfq byte-count

[Sysname-GigabitEthernet1/0/1] qos wfq 0 group 1 byte-count 1

[Sysname-GigabitEthernet1/0/1] qos wfq 1 group 1 byte-count 1

[Sysname-GigabitEthernet1/0/1] qos wfq 2 group 1 byte-count 2

[Sysname-GigabitEthernet1/0/1] qos wfq 3 group 1 byte-count 5

[Sysname-GigabitEthernet1/0/1] qos wfq 4 group 1 byte-count 10

[Sysname-GigabitEthernet1/0/1] qos wfq 5 group 1 byte-count 10

[Sysname-GigabitEthernet1/0/1] qos wfq 6 group 1 byte-count 10

[Sysname-GigabitEthernet1/0/1] qos wfq 7 group 1 byte-count 10

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 0 min 100000

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 1 min 100000

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 2 min 100000

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 3 min 100000

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 4 min 100000

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 5 min 100000

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 6 min 100000

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 7 min 100000

Configuring SP+WRR queuing

Configuration procedure

To configure SP+WRR queuing:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Enter interface view.

interface interface-type interface-number

N/A

3. Enable byte-count or { byte-count | packet-based WRR }

By default, all ports use WRR queuing.

Step queuing.

Command Remarks

4. Assign a queue to the SP group.

qos wrr queue-id group sp

By default, all the queues of a WRR-enabled port are in WRR group 1.

5. Assign a queue to a WRR group, and set the scheduling weight for the queue.

qos wrr queue-id group

1 { weight | byte-count }

schedule-value

Select weight or byte-count according to the type (byte-count or packet-based) of

WRR you have enabled.

By default, all queues are in WRR group 1, and the weights of queues 0 through 7 are 1,

2, 3, 4, 5, 9, 13, and 15, respectively.

Configuration example

1. Network requirements



Configure SP+WRR queuing on GigabitEthernet 1/0/1, and use byte-count WRR.



Assign queues 4 through 7 on GigabitEthernet 1/0/1 to the SP group.

Assign queues 0, 1, 2, and 3 on GigabitEthernet 1/0/1 to WRR group 1, with the weights being 1, 2, 1, and 3, respectively.

2. Configuration procedure

# Enter system view.

<Sysname> system-view

# Configure SP+WRR queuing on GigabitEthernet1/0/1.

[Sysname] interface GigabitEthernet 1/0/1

[Sysname-GigabitEthernet1/0/1] qos wrr byte-count

[Sysname-GigabitEthernet1/0/1] qos wrr 4 group sp

[Sysname-GigabitEthernet1/0/1] qos wrr 5 group sp

[Sysname-GigabitEthernet1/0/1] qos wrr 6 group sp

[Sysname-GigabitEthernet1/0/1] qos wrr 7 group sp

[Sysname-GigabitEthernet1/0/1] qos wrr 0 group 1 byte-count 1

[Sysname-GigabitEthernet1/0/1] qos wrr 1 group 1 byte-count 2

[Sysname-GigabitEthernet1/0/1] qos wrr 2 group 1 byte-count 1

[Sysname-GigabitEthernet1/0/1] qos wrr 3 group 1 byte-count 3

Configuring SP+WFQ queuing

Configuration procedure

To configure SP+WFQ queuing:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Enter interface view. interface interface-type

interface-number

3. Enable byte-count or packet-based WFQ

[ byte-count | queuing. weight ]

N/A

The default queuing algorithm on an interface is WRR.

4. Assign a queue to the SP group.

qos wfq queue-id group sp

By default, all the queues of a

WFQ-enabled port are in WFQ group 1.

5. Assign a queue to a WFQ group, and set a scheduling

qos wfq queue-id group 1

{ weight | byte-count }

Select weight or byte-count according to the type (byte-count or

Step weight for the queue.

Command

schedule-value

Remarks packet-based) of WFQ you have enabled.

If you have enabled WFQ on the port, all the queues are in WFQ group 1 by default and the default scheduling weight is 1 for each queue.

6. (Optional.) Set the minimum guaranteed bandwidth for the queue. qos bandwidth queue

The default setting is 64 kbps for each

queue-id min queue in a WFQ group.

bandwidth-value

Configuration example

1. Network requirements



Configure SP+WFQ queuing on interface GigabitEthernet 1/0/1, and use packet-based

WFQ.

Assign queues 4 through 7 to the SP group.



Assign queues 0, 1, 2, and 3 to the WFQ group, with the weights being 1, 2, 1, and 3, respectively.



Set the minimum guaranteed bandwidth to 128 Mbps for each of the four queues.

2. Configuration procedure

# Enter system view.

<Sysname> system-view

# Configure SP+WFQ queuing on GigabitEthernet 1/0/1.

[Sysname] interface GigabitEthernet 1/0/1

[Sysname-GigabitEthernet1/0/1] qos wfq weight

[Sysname-GigabitEthernet1/0/1] qos wfq 4 group sp

[Sysname-GigabitEthernet1/0/1] qos wfq 5 group sp

[Sysname-GigabitEthernet1/0/1] qos wfq 6 group sp

[Sysname-GigabitEthernet1/0/1] qos wfq 7 group sp

[Sysname-GigabitEthernet1/0/1] qos wfq 0 group 1 weight 1

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 4 min 128000

[Sysname-GigabitEthernet1/0/1] qos wfq 1 group 1 weight 2

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 5 min 128000

[Sysname-GigabitEthernet1/0/1] qos wfq 2 group 1 weight 1

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 6 min 128000

[Sysname-GigabitEthernet1/0/1] qos wfq 3 group 1 weight 3

[Sysname-GigabitEthernet1/0/1] qos bandwidth queue 7 min 128000

Displaying and maintaining queuing

Execute display commands in any view.

Task

Display SP queuing configuration.

Display WRR queuing configuration.

Display WFQ queuing configuration.

Command display qos queue sp interface [ interface-type interface-number ] display qos queue wrr interface [ interface-type interface-number ] display qos queue wfq interface [ interface-type

Task Command interface-number ]

Display queue-based outbound traffic display qos queue-statistics interface [ interface-type statistics. interface-number ] outbound

Configuring queue scheduling profiles

In a queue scheduling profile, you can configure scheduling parameters for each queue. By applying the queue scheduling profile to an interface, you can implement congestion management on the interface.

Queue scheduling profiles support three queue scheduling methods: SP, WRR, and WFQ. In a queue scheduling profile, you can configure SP+WRR or SP+WFQ. When SP+WRR or SP+WFQ is configured, the scheduling priority is as follows:

•

The SP group has higher priority than WRR groups and WFQ groups.

•

Queues in the SP group are scheduled in descending order of queue IDs.

•

Queues in a WRR or WFQ group are scheduled based on their weights.

When SP and WRR groups are configured in a queue scheduling profile, Figure 16 shows the

scheduling order.

Figure 16 Queue scheduling profile configured with both SP and WRR

Q7 Q6 Q5 Q4 Q3 Q2 Q1 Q0

SP group WRR group 1

•

Queue 7 has the highest priority. Its packets are sent preferentially.

•

Queue 5 has the second highest priority. Packets in queue 5 are sent when queue 7 is empty.

•

When both queue 7 and queue 5 are empty, WRR group 1 is scheduled. Queues 0, 1, 2, 3, 4, and 6 in WRR group 1 are scheduled according to their weights.

Configuring a queue scheduling profile

You can modify the scheduling parameters in a queue scheduling profile already applied to an interface. The modification takes effect immediately.

To configure a queue scheduling profile:

Step

1. Enter system view.

Command system-view

2. Create a queue scheduling profile and enter queue scheduling profile view.

qos qmprofile profile-name

Remarks

N/A

By default, no queue scheduling profile exists.

Step Command Remarks

3. Configure queue scheduling parameters.

•

Configure a queue to use SP:

queue queue-id sp

•

Configure a queue to use

WRR:

queue queue-id wrr group 1

{ byte-count | weight }

schedule-value

•

Configure a queue to use

WFQ:

queue queue-id wfq group 1

{ byte-count | weight } schedule-value

bandwidth queue queue-id min bandwidth-value

By default, all queues use SP.

You can configure all queues to use one queuing method or different queuing methods

(WRR+WFQ is not allowed).

4. Return to system view.

quit N/A

5. Enter interface view.

interface

interface-number interface-type

N/A

6. Apply the queue scheduling profile to the interface.

qos apply qmprofile profile-name

Only one queue scheduling profile can be applied an interface.

Displaying and maintaining queue scheduling profiles

Execute display commands in any view.

Task Command

Display the configuration of queue scheduling profiles. display qos qmprofile configuration [ profile-name ] [ slot slot-number ]

Display the queue scheduling profiles applied to interfaces. display qos qmprofile interface [ interface-type interface-number ]

Queue scheduling profile configuration example

Network requirements

Configure a queue scheduling profile on interface GigabitEthernet 1/0/1 to meet the following requirements:

•

Queue 7 has the highest priority, and its packets are sent preferentially.

•

Queue 0 through queue 6 in WRR group 1 are scheduled according to their weights, which are

2, 1, 2, 4, 6, 8, and 10, respectively. When queue 7 is empty, WRR group 1 is scheduled.

Configuration procedure

# Enter system view.

<Sysname> system-view

# Create a queue scheduling profile named qm1 .

[Sysname] qos qmprofile qm1

[Sysname-qmprofile-qm1]

# Configure queue 7 to use SP queuing.

[Sysname-qmprofile-qm1] queue 7 sp

# Assign queue 0 through queue 6 to WRR group 1, with their weights as 2, 1, 2, 4, 6, 8, and 10, respectively.

[Sysname-qmprofile-qm1] queue 0 wrr group 1 weight 2

[Sysname-qmprofile-qm1] queue 1 wrr group 1 weight 1

[Sysname-qmprofile-qm1] queue 2 wrr group 1 weight 2

[Sysname-qmprofile-qm1] queue 3 wrr group 1 weight 4

[Sysname-qmprofile-qm1] queue 4 wrr group 1 weight 6

[Sysname-qmprofile-qm1] queue 5 wrr group 1 weight 8

[Sysname-qmprofile-qm1] queue 6 wrr group 1 weight 10

# Apply queue scheduling profile qm1 to GigabitEthernet 1/0/1.

[Sysname] interface GigabitEthernet 1/0/1

[Sysname-GigabitEthernet] qos apply qmprofile qm1

Configuring congestion avoidance

Overview

Avoiding congestion before it occurs is a proactive approach to improving network performance. As a flow control mechanism, congestion avoidance:

•

Actively monitors network resources (such as queues and memory buffers).

•

Drops packets when congestion is expected to occur or deteriorate.

When dropping packets from a source end, congestion avoidance cooperates with the flow control mechanism at the source end to regulate the network traffic size. The combination of the local packet drop policy and the source-end flow control mechanism helps maximize throughput and network use efficiency and minimize packet loss and delay.

Tail drop

Congestion management techniques drop all packets that are arriving at a full queue. This tail drop mechanism results in global TCP synchronization. If packets from multiple TCP connections are dropped, these TCP connections go into the state of congestion avoidance and slow start to reduce traffic, but traffic peak occurs later. Consequently, the network traffic jitters all the time.

RED and WRED

You can use Random Early Detection (RED) or Weighted Random Early Detection (WRED) to avoid global TCP synchronization.

Both RED and WRED avoid global TCP synchronization by randomly dropping packets. When the sending rates of some TCP sessions slow down after their packets are dropped, other TCP sessions remain at high sending rates. Link bandwidth is efficiently used, because TCP sessions at high sending rates always exist.

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

•

When the queue size is shorter than the lower limit, no packet is dropped.

•

When the queue size reaches the upper limit, all subsequent packets are dropped.

•

When the queue size is between the lower limit and the upper limit, the received packets are dropped based on the user-configured drop probability.

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

The average queue size reflects the queue size change trend but is not sensitive to burst queue size changes, and burst traffic can be fairly treated.

ECN

By dropping packets, WRED alleviates the influence of congestion on the network. However, the network resources for transmitting packets from the sender to the device which drops the packets are wasted. When congestion occurs, it is a better idea to inform the sender of the congestion status and have the sender proactively slow down the packet sending rate or decrease the window size of packets. This better utilizes the network resources.

RFC 2482 defined an end-to-end congestion notification mechanism named Explicit Congestion

Notification (ECN). ECN uses the DS field in the IP header to mark the congestion status along the packet transmission path. A ECN-capable terminal can determine whether congestion occurs on the transmission path according to the packet contents, and then adjusts the packet sending speed to avoid deteriorating congestion. ECN defines the last two bits (ECN field) in the DS field of the IP header as follows:

•

Bit 6 indicates whether the sending terminal device supports ECN, and is called the

"ECN-Capable Transport (ECT)" bit.

•

Bit 7 indicates whether the packet has experienced congestion along the transmission path, and is called the "Congestion Experienced (CE)" bit.

For more information about the DS field, see " Appendixes ."

In actual applications, the packets with ECT set to 1 and CE set to 0 and the packets with ECT set to

0 and CE set to 1 are considered as packets that an ECN-capable endpoint transmits.

After you enable ECN on a device, congestion management processes packets as follows:

•

When the average queue size is below the lower limit, no packet is dropped, and the ECN fields of packets are not identified or marked.

•

When the average queue size exceeds the lower limit and is below the upper limit, before the device drops a packet which should be dropped according to the drop probability, the device examines the ECN field of the packet.



If the ECN field shows that the packet is sent out of ECN-capable terminal, the device sets both the ECT bit and the CE bit to 1 and forwards the packet.

If the ECN field shows that the packet has experienced congestion along the transmission path (both the ECT bit and the CE bit are 1), the device forwards the packet without modifying the ECN field.

 If both the ECT bit and the CE bit are 0s, the device drops the packet.

•

When the average queue size exceeds the upper limit, the device drops the packet, regardless of whether the packet is sent out from an ECN-capable terminal.

ECN is enabled on a per-queue basis. You can configure the switch to identify and mark the ECN fields of packets for a specific queue.

Configuring and applying a WRED table

You can apply WRED tables to both Layer 2 and Layer 3 Ethernet interfaces. The term "interface" in this section collectively refers to these two types of interfaces. You can use the port link-mode command to configure an Ethernet port as a Layer 2 or Layer 3 interface (see Layer 2—LAN

Switching Configuration Guide ).

The switch supports the queue-based WRED table. You can configure separate drop parameters for different queues. When congestion occurs, packets of a queue are randomly dropped based on drop parameters of the queue.

Determine the following parameters before configuring WRED:

•

Upper limit and lower limit —When the average queue size is smaller than the lower limit, packets are not dropped. When the average queue size is between the lower limit and the upper limit, the packets are dropped based on the user-configured drop probability. When the average queue size exceeds the upper limit, subsequent packets are dropped.

•

Drop precedence —A parameter used for packet drop. The value 0 corresponds to green packets, the value 1 corresponds to yellow packets, and the value 2 corresponds to red packets. Red packets are dropped preferentially.

•

Exponent for average queue size calculation —The greater the exponent, the less sensitive the average queue size is to real-time queue size changes. The formula for calculating the

average queue size is average queue size = (previous average queue size x (1 – 2

–n

(current queue size x 2 ), where n is the exponent.

–n

)) +

•

Drop probability in percentage —The larger the value is, the greater the drop probability is.

Configuration procedure

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

To configure and apply a WRED table:

Step

1. Enter system view.

Command Remarks system-view

2. Create a WRED table and enter its view.

qos wred queue table table-name

3. (Optional.) Set the WRED exponent for average queue-id weighting-constant queue size calculation.

exponent

N/A

The default setting is 9.

4. (Optional.) Configure drop parameters.

queue queue-id [ drop-level drop-level ] low-limit low-limit high-limit high-limit

[ discard-probability discard-prob ]

By default, the low limit is 100, the high limit is 1000, and the drop probability is 10%.

5. (Optional.) Enable ECN for a queue. queue queue-id ecn

By default, ECN is not enabled on any queue.

6. Enter interface view. interface interface-number interface-type

N/A

7. Apply the WRED table to the interface.

qos wred apply [ table-name ]

By default, no WRED table is applied to an interface, and tail drop is used on an interface.

Configuration example

Network requirements

Apply a WRED table to interface GigabitEthernet 1/0/2, so that the packets are dropped as follows when congestion occurs:

•

For the interface to preferentially forward higher-priority traffic, set a lower drop probability for a queue with a greater queue ID. Set different drop parameters for queue 0, queue 3, and queue

•

Drop packets according to their colors.



In queue 0, set the drop probability to 25%, 50%, and 75% for green, yellow, and red packets, respectively.

In queue 3, set the drop probability to 5%, 10%, and 25% for green, yellow, and red packets, respectively.



In queue 7, set the drop probability to 1%, 5%, and 10% for green, yellow, and red packets, respectively.

•

Enable ECN for queue 7.

Configuration procedure

# Configure a queue-based WRED table, and set different drop parameters for packets with different drop levels in different queues.

<Sysname> system-view

[Sysname] qos wred queue table queue-table1

[Sysname-wred-table-queue-table1] queue 0 drop-level 0 low-limit 128 high-limit 512 discard-probability 25

[Sysname-wred-table-queue-table1] queue 0 drop-level 1 low-limit 128 high-limit 512 discard-probability 50

[Sysname-wred-table-queue-table1] queue 0 drop-level 2 low-limit 128 high-limit 512 discard-probability 75

[Sysname-wred-table-queue-table1] queue 3 drop-level 0 low-limit 256 high-limit 640 discard-probability 5

[Sysname-wred-table-queue-table1] queue 3 drop-level 1 low-limit 256 high-limit 640 discard-probability 10

[Sysname-wred-table-queue-table1] queue 3 drop-level 2 low-limit 256 high-limit 640 discard-probability 25

[Sysname-wred-table-queue-table1] queue 7 drop-level 0 low-limit 512 high-limit 1024 discard-probability 1

[Sysname-wred-table-queue-table1] queue 7 drop-level 1 low-limit 512 high-limit 1024 discard-probability 5

[Sysname-wred-table-queue-table1] queue 7 drop-level 2 low-limit 512 high-limit 1024 discard-probability 10

[Sysname-wred-table-queue-table1] queue 7 ecn

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

# Apply the queue-based WRED table to GigabitEthernet 1/0/2.

[Sysname] interface GigabitEthernet 1/0/2

[Sysname-GigabitEthernet1/0/2] qos wred apply queue-table1

Displaying and maintaining WRED

Execute display commands in any view.

Task

Display WRED configuration and statistics for interfaces.

Command display qos wred interface [ interface-type interface-number ]

Display the configuration of WRED tables. display qos wred table [ name table-name ] [ slot slot-number ]

Configuring traffic filtering

You can filter in or filter out traffic of a class by associating the class with a traffic filtering action. For example, you can filter packets sourced from an IP address according to network status.

Configuration procedure

To configure traffic filtering:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Create a traffic class and enter traffic class view. traffic classifier

[ operator { and | or } ] classifier-name By default, no traffic class exists.

3. Configure match criteria. if-match match-criteria

By default, no match criterion is configured.

4. Return to system view. quit

5. Create a traffic behavior and enter traffic behavior view.

traffic behavior behavior-name

N/A

By default, no traffic behavior exists.

6. Configure the traffic filtering action. filter { deny | permit }

By default, no traffic filtering action is configured.

If a traffic behavior has the filter deny action, all the other actions except for class-based accounting in the traffic behavior do not take effect.

7. Return to system view.

8. Create a QoS policy and enter QoS policy view. quit qos policy policy-name

N/A

By default, no QoS policy exists.

9. Associate the traffic class with the traffic behavior in the QoS policy. classifier classifier-name behavior behavior-name [

before-classifier-name ] insert-before

By default, a traffic class is not associated with a traffic behavior.

10.

11.

Return to system view.

Apply the QoS policy. quit N/A

•

•

As shown in Figure 17 , configure traffic filtering on GigabitEthernet 1/0/1 to deny the incoming

Choose one of the application destinations as needed.

By default, no QoS policy is applied.

12. (Optional.) Display the traffic filtering configuration.

[ behavior-name ]

Available in any view.

Configuration example

Network requirements

packets with port 21 as the source port.

Figure 17 Network diagram

Host

Switch

GE1/0/1

Configuration procedure

# Create advanced ACL 3000, and configure a rule to match packets whose source port number is

21.

<Switch> system-view

[Switch] acl number 3000

[Switch-acl-adv-3000] rule 0 permit tcp source-port eq 21

[Switch-acl-adv-3000] quit

# Create a traffic class named classifier_1 , and use ACL 3000 as the match criterion in the traffic class.

[Switch] traffic classifier classifier_1

[Switch-classifier-classifier_1] if-match acl 3000

[Switch-classifier-classifier_1] quit

# Create a traffic behavior named behavior_1 , and configure the traffic filtering action to drop packets.

[Switch] traffic behavior behavior_1

[Switch-behavior-behavior_1] filter deny

[Switch-behavior-behavior_1] quit

# Create a QoS policy named policy , and associate traffic class classifier_1 with traffic behavior behavior_1 in the QoS policy.

[Switch] qos policy policy

[Switch-qospolicy-policy] classifier classifier_1 behavior behavior_1

[Switch-qospolicy-policy] quit

# Apply QoS policy policy to the incoming traffic of GigabitEthernet 1/0/1.

[Switch] interface gigabitethernet 1/0/1

[Switch-GigabitEthernet1/0/1] qos apply policy policy inbound

Configuring priority marking

Overview

Priority marking sets the priority fields or flag bits of packets to modify the priority of packets. For example, you can use priority marking to set IP precedence or DSCP for a traffic class of IP packets to control the forwarding of these packets.

To configure priority marking to set the priority fields or flag bits for a class of packets, perform the following tasks:

1. Configure a traffic behavior with a priority marking action.

2. Associate the traffic class with the traffic behavior.

Priority marking can be used together with priority mapping. For more information, see " Configuring priority mapping ."

Color-based priority marking

Packet coloring methods

The color of a packet indicates the device's evaluation for the packet transmission priority. The device can color a packet by using either of the following methods:

•

Traffic policing

•

Mapping drop precedence

Traffic policing

Traffic policing is a common traffic control technology. Traffic policing uses the token bucket mechanism to evaluate the incoming or outgoing packets and colors the packets according to the evaluation result. By configuring different traffic control policies for packets in different colors, you can provide differentiated services for different traffic flows and use network resources efficiently.

The switch supports evaluating traffic by using two token buckets (bucket C and bucket E), and it colors a packet according to the number of tokens in the token buckets.

The switch supports coloring packets by using either of the following traffic policing functions: common CAR and aggregate CAR. For more information about coloring packets by using token

buckets and about common CAR and aggregate CAR, see " Configuring traffic policing, GTS, and rate limit

" and " Configuring aggregate CAR ."

Mapping drop precedence

Without traffic policing configured, a switch looks up the 802.1p priority of a packet in the

802.1p-to-drop priority mapping table, allocates the drop precedence value to the packet, and colors the packet according to the drop precedence value. Drop precedence value 0 denotes green packets, 1 denotes yellow packets, and 2 denotes red packets. For more information about priority

mapping tables, see " Configuring priority mapping ."

Configuring color-based priority marking

Configuring priority marking based on colors obtained through traffic policing

After traffic policing evaluates and colors packets, the switch can mark traffic with various priority values (including DSCP values, 802.1p priority values, and local precedence values) by color.

Configure priority marking by using either of the following methods:

•

Configuring the priority marking actions by color in the traffic policing action.

•

Configuring the priority marking actions by color in the behavior where the traffic policing action is configured.

You can use both methods to mark multiple priority values for packets in the same color. However, do not use the two methods to mark different values of the same priority type for packets. Otherwise, the

QoS policy configured with the behavior cannot be applied normally.

In a traffic behavior, an aggregate CAR action cannot be configured together with a priority marking action. Otherwise, the QoS policy configured with the behavior cannot be applied normally.

The switch implements both common CAR and aggregate CAR by using a QoS policy. For more

information about configuring classes and behaviors in a QoS policy, see " Configuring traffic policing, GTS, and rate limit

" and " Configuring aggregate CAR ."

Configuring priority marking based on colors obtained through mapping drop precedence

When packets are colored based on drop precedence values, you can create priority marking actions for packets in different colors in a traffic behavior and mark DSCP values, 802.1p priority values, and local precedence values for packets.

Configuration procedure

To configure priority marking:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Create a traffic class and enter traffic class view. traffic classifier classifier-name [ operator

{ and | or } ]

By default, no traffic class exists.

3. Configure match criteria. if-match match-criteria

By default, no match criterion is configured.

For more information about the if-match command, see ACL and

QoS Command

Reference .

4. Return to system view. quit N/A

5. Create a traffic behavior and enter traffic behavior view.

traffic behavior behavior-name

By default, no traffic behavior exists.

•

Set the DSCP value for packets: remark [ green | red | yellow ] dscp dscp-value

•

Set the 802.1p priority for packets or configure the inner-to-outer tag priority copying function: remark [ green | red | yellow ] dot1p

6. Configure a priority marking action. dot1p-value remark dot1p customer-dot1p-trust

•

Set the drop priority for packets: remark drop-precedence

drop-precedence-value

•

Set the IP precedence for packets: remark ip-precedence ip-precedence-value

•

Set the local precedence for packets: remark [ green | red | yellow ]

By default, no priority marking action is configured.

The switch supports local QoS IDs in the range of 1 to 3999.

The and remark local-precedence remark qos-local-id remark drop-precedence

, commands apply only to the incoming traffic.

The customer VLAN

(CVLAN) is the private network VLAN of the customer, and the

Step Command local-precedence

local-precedence-value

•

Set the local QoS ID for packets:

remark qos-local-id local-id-value

•

Set the CVLAN for packets: remark customer-vlan-id vlan-id

•

Set the SVLAN for packets: remark service-vlan-id vlan-id

Remarks service provider VLAN

(SVLAN) is the public network VLAN assigned by the service provider to the customer. For more information about the

CVLAN and SVLAN, see

Layer 2—LAN Switching

Configuration Guide .

7. Return to system view. quit N/A

8. Create a QoS policy and enter QoS policy view. qos policy policy-name

By default, no QoS policy exists.

9. Associate the traffic class with the traffic behavior in the QoS policy. classifier behavior-name classifier-name

[ behavior insert-before

before-classifier-name ]

By default, a traffic class is not associated with a traffic behavior.

10.

11.

Return to system view.

Apply the QoS policy. quit

•

•

•

As shown in Figure 18 , configure priority marking on the switch to meet the following requirements:

12. (Optional.) Display the priority marking user-defined configuration.

[ behavior-name ]

N/A

Choose one of the application destinations as needed.

By default, no QoS policy is applied.

Available in any view.

Priority marking configuration examples

Local precedence marking configuration example

Network requirements

Traffic source

Host A, B

Destination

Data server

Mail server

File server

Processing priority

High

Medium

Low

Figure 18 Network diagram

Internet

Host A Data server

192.168.0.1/24

GE1/0/1 GE1/0/2 Mail server

192.168.0.2/24

Host B

Switch

File server

192.168.0.3/24

Configuration procedure

# Create advanced ACL 3000, and configure a rule to match packets with destination IP address

192.168.0.1.

<Switch> system-view

[Switch] acl number 3000

[Switch-acl-adv-3000] rule permit ip destination 192.168.0.1 0

[Switch-acl-adv-3000] quit

# Create advanced ACL 3001, and configure a rule to match packets with destination IP address

192.168.0.2.

[Switch] acl number 3001

[Switch-acl-adv-3001] rule permit ip destination 192.168.0.2 0

[Switch-acl-adv-3001] quit

# Create advanced ACL 3002, and configure a rule to match packets with destination IP address

192.168.0.3.

[Switch] acl number 3002

[Switch-acl-adv-3002] rule permit ip destination 192.168.0.3 0

[Switch-acl-adv-3002] quit

# Create a traffic class named classifier_dbserver , and use ACL 3000 as the match criterion in the traffic class.

[Switch] traffic classifier classifier_dbserver

[Switch-classifier-classifier_dbserver] if-match acl 3000

[Switch-classifier-classifier_dbserver] quit

# Create a traffic class named classifier_mserver , and use ACL 3001 as the match criterion in the traffic class.

[Switch] traffic classifier classifier_mserver

[Switch-classifier-classifier_mserver] if-match acl 3001

[Switch-classifier-classifier_mserver] quit

# Create a traffic class named classifier_fserver , and use ACL 3002 as the match criterion in the traffic class.

[Switch] traffic classifier classifier_fserver

[Switch-classifier-classifier_fserver] if-match acl 3002

[Switch-classifier-classifier_fserver] quit

# Create a traffic behavior named behavior_dbserver , and configure the action of setting the local precedence value to 4.

[Switch] traffic behavior behavior_dbserver

[Switch-behavior-behavior_dbserver] remark local-precedence 4

[Switch-behavior-behavior_dbserver] quit

# Create a traffic behavior named behavior_mserver , and configure the action of setting the local precedence value to 3.

[Switch] traffic behavior behavior_mserver

[Switch-behavior-behavior_mserver] remark local-precedence 3

[Switch-behavior-behavior_mserver] quit

# Create a traffic behavior named behavior_fserver , and configure the action of setting the local precedence value to 2.

[Switch] traffic behavior behavior_fserver

[Switch-behavior-behavior_fserver] remark local-precedence 2

[Switch-behavior-behavior_fserver] quit

# Create a QoS policy named policy_server , and associate traffic classes with traffic behaviors in the QoS policy.

[Switch] qos policy policy_server

[Switch-qospolicy-policy_server] classifier classifier_dbserver behavior behavior_dbserver

[Switch-qospolicy-policy_server] classifier classifier_mserver behavior behavior_mserver

[Switch-qospolicy-policy_server] classifier classifier_fserver behavior behavior_fserver

[Switch-qospolicy-policy_server] quit

# Apply QoS policy policy_server to the incoming traffic of GigabitEthernet 1/0/1.

[Switch] interface GigabitEthernet 1/0/1

[Switch-GigabitEthernet1/0/1] qos apply policy policy_server inbound

[Switch-GigabitEthernet1/0/1] quit

Local QoS ID marking configuration example

Local QoS ID marking allows you to mark the same local QoS ID for packets of multiple classes and configure a new class to match the local QoS ID to group these packets into the new class. With this feature, you can perform QoS actions for the old classes respectively and perform other QoS actions for the new class. In this way, you can perform layers of QoS actions for the specific packets.

Network requirements

As shown in Figure 19 , configure local QoS ID marking and traffic policing to limit the outgoing traffic

of the Management department and the R&D department to 102400 kbps, respectively, and limit the outgoing traffic of the Marketing department (containing two sub-departments) to 204800 kbps.

Figure 19 Network diagram

IP network

GE1/0/1

Switch A

Management department

192.168.1.0/24

R&D department

192.168.2.0/24

Marketing department 1

192.168.3.0/24

Marketing department 2

192.168.4.0/24

Configuration considerations

•

Configure two classes to match the traffic from the Management department and the R&D department, respectively, and then configure traffic policing behaviors for the two classes.

•

Mark the same local QoS ID for the traffic from the two sub-departments of the Marketing department, configure a class to match packets with the local QoS ID, and then configure a traffic policing behavior for the class to limit the outgoing traffic of the two sub-departments.

Configuration procedure

1. Limit the upstream traffic of the Management department and R&D department:

# Configure IPv4 basic ACL 2001 to match the outgoing traffic of the Management department.

<SwitchA> system-view

[SwitchA] acl number 2001

[SwitchA-acl-basic-2001] rule permit source 192.168.1.0 0.0.0.255

[SwitchA-acl-basic-2001] quit

# Configure IPv4 basic ACL 2002 to match the outgoing traffic of the R&D department.

[SwitchA] acl number 2002

[SwitchA-acl-basic-2002] rule permit source 192.168.2.0 0.0.0.255

[SwitchA-acl-basic-2002] quit

# Create a class named admin , and use ACL 2001 as the match criterion.

[SwitchA] traffic classifier admin

[SwitchA-classifier-admin] if-match acl 2001

[SwitchA-classifier-admin] quit

# Create a class named rd , and use ACL 2002 as the match criterion.

[SwitchA] traffic classifier rd

[SwitchA-classifier-rd] if-match acl 2002

[SwitchA-classifier-rd] quit

# Create a traffic behavior named car_admin_rd , and configure traffic policing to limit the traffic rate to 102400 kbps.

[SwitchA] traffic behavior car_admin_rd

[SwitchA-behavior-car_admin_rd] car cir 102400

[SwitchA-behavior-car_admin_rd] quit

# Create a QoS policy named car , and associate classes admin and rd with behavior car_admin_rd .

[SwitchA] qos policy car

[SwitchA-qospolicy-car] classifier admin behavior car_admin_rd

[SwitchA-qospolicy-car] classifier rd behavior car_admin_rd

[SwitchA-qospolicy-car] quit

2. Limit the upstream traffic of the marketing department:

# Configure IPv4 basic ACL 2003 to match the outgoing traffic of the sub-department 1 of the marketing department.

[SwitchA] acl number 2003

[SwitchA-acl-basic-2003] rule permit source 192.168.3.0 0.0.0.255

[SwitchA-acl-basic-2003] quit

# Configure IPv4 basic ACL 2004 to match the outgoing traffic of the sub-department 2 of the

Marketing department.

[SwitchA] acl number 2004

[SwitchA-acl-basic-2004] rule permit source 192.168.4.0 0.0.0.255

[SwitchA-acl-basic-2004] quit

# Configure class marketing to match the outgoing traffic of the two sub-departments of the marketing department.

[SwitchA] traffic classifier marketing operator or

[SwitchA-classifier-marketing] if-match acl 2003

[SwitchA-classifier-marketing] if-match acl 2004

[SwitchA-classifier-marketing] quit

# Configure behavior remark_local_id to mark traffic with local QoS ID 100.

[SwitchA] traffic behavior remark_local_id

[SwitchA-behavior-remark_local_id] remark qos-local-id 100

[SwitchA-behavior-remark_local_id] quit

# Configure class marketing_car to match the outgoing traffic of the two sub-departments of the Marketing department.

[SwitchA] traffic classifier marketing_car

[SwitchA-classifier-marketing_car] if-match qos-local-id 100

[SwitchA-classifier-marketing_car] quit

# Create a behavior named marketing_car , and configure traffic policing to limit the traffic rate to 204800 kbps.

[SwitchA] traffic behavior marketing_car

[SwitchA-behavior-marketing_car] car cir 204800

[SwitchA-behavior-marketing_car] quit

# In QoS policy car , associate class marketing with behavior remark_local_id to mark the outgoing traffic of the Marketing department with local QoS ID 100.

[SwitchA] qos policy car

[SwitchA-qospolicy-car] classifier marketing behavior remark_local_id

# In QoS policy car , associate class marketing_car with behavior marketing_car to limit the traffic rate of traffic with local QoS ID 100.

[SwitchA-qospolicy-car] classifier marketing_car behavior marketing_car

[SwitchA-qospolicy-car] quit

# Apply QoS policy car to the incoming traffic of GigabitEthernet1/0/1.

[SwitchA] interface gigabitethernet 1/0/1

[SwitchA-GigabitEthernet1/0/1] qos apply policy car inbound

Configuring nesting

Nesting adds a VLAN tag to the matching packets to allow the VLAN-tagged packets to pass through the corresponding VLAN. For example, you can add an outer VLAN tag to packets from a customer network to a service provider network. This allows the packets to pass through the service provider network by carrying a VLAN tag assigned by the service provider.

Configuration procedure

To configure nesting:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Create a traffic class and enter traffic class view. traffic classifier classifier-name [ operator

{ and | or } ]

By default, no traffic class exists.

3. Configure match criteria. if-match match-criteria

By default, no match criterion is configured for a traffic class.

For more information about the match criteria, see the if-match command in ACL and

QoS Command

Reference .

N/A 4. Return to system view. quit

5. Create a traffic behavior and enter traffic behavior view.

traffic behavior behavior-name

By default, no traffic behavior exists.

Configure a VLAN tag adding action.

Return to system view.

nest top-most vlan vlan-id quit

8. Create a QoS policy and enter QoS policy view. qos policy policy-name

By default, no VLAN tag adding action is configured for a traffic behavior.

N/A

By default, no QoS policy exists.

9. Associate the traffic class with the traffic behavior in the QoS policy. classifier behavior-name classifier-name

[

before-classifier-name ] behavior insert-before

By default, no class-behavior association is configured for a QoS policy.

10. Return to system view. quit N/A

11. Apply the QoS policy.

•

As shown in Figure 20 , Site 1 and Site 2 in VPN A are two branches of a company, and they use

Choose one of the application destinations as needed.

By default, a QoS policy is not applied.

Configuration example

Network requirements

VLAN 5 to transmit traffic. Because Site 1 and Site 2 are located in different areas, the two sites use the VPN access service of a service provider. The service provider assigns VLAN 100 to the two sites.

Configure nesting, so that the two branches can communicate through the service provider network.

Figure 20 Network diagram

PE 1

GE1/0/1

Public network

GE1/0/2

VLAN 100 VLAN 5 Data

IP network

GE1/0/2

VLAN 100 VLAN 5 Data

PE 2

GE1/0/1

VLAN 5 Data VLAN 5 Data

CE 1

VLAN 5

VPN A

Site 1

VPN A

Site 2

CE 2

Configuration procedure

Configuring PE 1

# Create a class named test to match packets with VLAN ID 5.

<PE1> system-view

[PE1] traffic classifier test

[PE1-classifier-test] if-match service-vlan-id 5

[PE1-classifier-test] quit

# Configure an action to add outer VLAN tag 100 in traffic behavior test .

[PE1] traffic behavior test

[PE1-behavior-test] nest top-most vlan 100

[PE1-behavior-test] quit

# Create a QoS policy named test , and associate class test with behavior test in the QoS policy.

[PE1] qos policy test

[PE1-qospolicy-test] classifier test behavior test

[PE1-qospolicy-test] quit

# Configure the downlink port (GigabitEthernet 1/0/1) as a hybrid port, and assign the port to VLAN

100 as an untagged member.

[PE1] interface GigabitEthernet 1/0/1

[PE1-GigabitEthernet1/0/1] port link-type hybrid

[PE1-GigabitEthernet1/0/1] port hybrid vlan 100 untagged

# Apply QoS policy test to the incoming traffic of GigabitEthernet 1/0/1.

[PE1-GigabitEthernet1/0/1] qos apply policy test inbound

[PE1-GigabitEthernet1/0/1] quit

# Configure the uplink port (GigabitEthernet 1/0/2) as a trunk port, and assign it to VLAN 100.

[PE1] interface GigabitEthernet 1/0/2

[PE1-GigabitEthernet1/0/2] port link-type trunk

[PE1-GigabitEthernet1/0/2] port trunk permit vlan 100

[PE1-GigabitEthernet1/0/2] quit

Configuring PE 2

Configure PE 2 in the same way PE 1 is configured.

Configuring traffic redirecting

Traffic redirecting redirects packets matching the specified match criteria to a location for processing.

The following redirect actions are supported:

•

Redirecting traffic to the CPU —Redirects packets that require processing by the CPU to the

CPU.

•

Redirecting traffic to an interface —Redirects packets that require processing by an interface to the interface. This action applies only to Layer 2 packets, and the target interface must be a

Layer 2 interface.

Configuration procedure

To configure traffic redirecting:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Create a traffic class and enter traffic class view. traffic classifier classifier-name [ operator

{ and | or } ]

By default, no traffic class exists.

3. Configure match criteria. if-match match-criteria

By default, no match criterion is configured for a traffic class.

For more information about the match criteria, see the if-match command in ACL and

QoS Command

Reference .

N/A 4. Return to system view. quit

5. Create a traffic behavior and enter traffic behavior view.

traffic behavior behavior-name

By default, no traffic behavior exists.

6. Configure a traffic { cpu | interface interface-type redirecting action. interface-number }

By default, no traffic redirecting action is configured for a traffic behavior.

The actions of redirecting traffic to the

CPU and redirecting traffic to an interface are mutually exclusive with each other in the same traffic behavior. The last redirecting action configured takes effect.

7. Return to system view. quit N/A

8. Create a QoS policy and enter QoS policy view. qos policy policy-name

By default, no QoS policy exists.

9. Associate the traffic class with the traffic behavior in the QoS policy. classifier classifier-name behavior-name [

before-classifier-name ] behavior insert-before

By default, no class-behavior association is configured for a QoS policy.

Step

10. Return to system view.

11. Apply the QoS policy.

Command quit

•

•

•

" Configuring traffic policing,

Remarks

N/A

Choose one of the application destinations as needed.

By default, a QoS policy is not applied.

12. (Optional.) Display traffic redirecting configuration. display traffic behavior user-defined

[ behavior-name ]

Available in any view.

Configuration example

Network requirements

As shown in

�:

•

Switch A is connected to Switch B through two links. Switch A and Switch B are each connected to other devices.

•

GigabitEthernet 1/0/2 of Switch A and GigabitEthernet 1/0/2 of Switch B belong to VLAN 200.

•

GigabitEthernet 1/0/3 of Switch A and GigabitEthernet 1/0/3 of Switch B belong to VLAN 201.

•

On Switch A, the IP address of VLAN-interface 200 is 200.1.1.1/24, and that of VLAN-interface

201 is 201.1.1.1/24.

•

On Switch B, the IP address of VLAN-interface 200 is 200.1.1.2/24, and that of VLAN-interface

201 is 201.1.1.2/24.

Configure the actions of redirecting traffic to an interface to meet the following requirements:

•

Packets with source IP address 2.1.1.1 received on GigabitEthernet 1/0/1 of Switch A are forwarded to GigabitEthernet 1/0/2.

•

Packets with source IP address 2.1.1.2 received on GigabitEthernet 1/0/1 of Switch A are forwarded to GigabitEthernet 1/0/3.

•

Other packets received on GigabitEthernet 1/0/1 of Switch A are forwarded according to the routing table.

Figure 21 Network diagram

GE1/0/2

VLAN 200

Vlan-int200

200.1.1.1/24

GE1/0/2

VLAN 200

Vlan-int200

200.1.1.2/24

GE1/0/1 FGE1/0/1

Switch A

GE1/0/3

VLAN 201

Vlan-int201

201.1.1.1/24

GE1/0/3

VLAN 201

Vlan-int201

201.1.1.2/24

Switch B

Configuration procedure

# Create basic ACL 2000, and configure a rule to match packets with source IP address 2.1.1.1.

<SwitchA> system-view

[SwitchA] acl number 2000

[SwitchA-acl-basic-2000] rule permit source 2.1.1.1 0

[SwitchA-acl-basic-2000] quit

# Create basic ACL 2001, and configure a rule to match packets with source IP address 2.1.1.2.

[SwitchA] acl number 2001

[SwitchA-acl-basic-2001] rule permit source 2.1.1.2 0

[SwitchA-acl-basic-2001] quit

# Create a traffic class named classifier_1 , and use ACL 2000 as the match criterion in the traffic class.

[SwitchA] traffic classifier classifier_1

[SwitchA-classifier-classifier_1] if-match acl 2000

[SwitchA-classifier-classifier_1] quit

# Create a traffic class named classifier_2 , and use ACL 2001 as the match criterion in the traffic class.

[SwitchA] traffic classifier classifier_2

[SwitchA-classifier-classifier_2] if-match acl 2001

[SwitchA-classifier-classifier_2] quit

# Create a traffic behavior named behavior_1 , and configure the action of redirecting traffic to

GigabitEthernet 1/0/2.

[SwitchA] traffic behavior behavior_1

[SwitchA-behavior-behavior_1] redirect interface gigabitethernet 1/0/2

[SwitchA-behavior-behavior_1] quit

# Create a traffic behavior named behavior_2 , and configure the action of redirecting traffic to

GigabitEthernet 1/0/3.

[SwitchA] traffic behavior behavior_2

[SwitchA-behavior-behavior_2] redirect interface gigabitethernet 1/0/3

[SwitchA-behavior-behavior_2] quit

# Create a QoS policy named policy , associate traffic class classifier_1 with traffic behavior behavior_1 , and associate traffic class classifier_2 with traffic behavior behavior_2 in the QoS policy.

[SwitchA] qos policy policy

[SwitchA-qospolicy-policy] classifier classifier_1 behavior behavior_1

[SwitchA-qospolicy-policy] classifier classifier_2 behavior behavior_2

[SwitchA-qospolicy-policy] quit

# Apply QoS policy policy to the incoming traffic of GigabitEthernet 1/0/1.

[SwitchA] interface gigabitethernet 1/0/1

[SwitchA-GigabitEthernet1/0/1] qos apply policy policy inbound

Configuring global CAR

Overview

Global committed access rate (CAR) is an approach to policing traffic flows globally. It adds flexibility to common CAR where traffic policing is performed only on a per-traffic class or per-interface basis.

In this approach, CAR actions are created in system view and each can be used to police multiple traffic flows as a whole.

Global CAR provides the following CAR actions: aggregate CAR and hierarchical CAR.

Aggregate CAR

An aggregate CAR action is created globally. It can be directly applied to interfaces or used in the traffic behaviors associated with different traffic classes to police multiple traffic flows as a whole.

The total rate of the traffic flows must conform to the traffic policing specifications set in the aggregate CAR action.

Hierarchical CAR

A hierarchical CAR action is created globally. It must be used in conjunction with a common CAR or aggregate CAR action. With a hierarchical CAR action, you can limit the total traffic of multiple traffic classes.

A hierarchical CAR action can be used in the common or aggregate CAR action for a traffic class in either AND mode or OR mode.

•

In AND mode, the rate of the traffic class is strictly limited under the common or aggregate CAR.

This mode applies to flows that must be strictly rate limited.

•

In OR mode, the traffic class can use idle bandwidth of other traffic classes associated with the hierarchical CAR. This mode applies to high priority, bursty traffic like video.

By using the two modes appropriately, you can improve bandwidth efficiency.

For example, suppose two flows exist: a low priority data flow and a high priority, bursty video flow.

Their total traffic rate cannot exceed 4096 kbps and the video flow must be assured of at least 2048 kbps bandwidth. You can perform the following tasks:

•

Configure common CAR actions to set the traffic rate to 2048 kbps for the two flows.

•

Configure a hierarchical CAR action to limit their total traffic rate to 4096 kbps.

•

Use the action in AND mode in the common CAR action for the data flow, and in OR mode in the common CAR action for the video flow.

The video flow is assured of 2048 kbps bandwidth and can use idle bandwidth of the data flow.

In a bandwidth oversubscription scenario, the uplink port bandwidth is lower than the total downlink port traffic rate. You can use hierarchical CAR to meet the following requirements:

•

Limit the total rate of the downlink port traffic.

•

Allow each downlink port to forward traffic at the maximum rate when the other ports are idle.

For example, you can perform the following tasks:

•

Use common CAR actions to limit the rates of both Internet access flow 1 and flow 2 to 128 kbps.

•

Use a hierarchical CAR action to limit their total traffic rate to 192 kbps.

•

Use the hierarchical CAR action for both flow 1 and flow 2 in AND mode.

When flow 1 is not present, flow 2 is transmitted at the maximum rate, 128 kbps. When both flows are present, the traffic rate of flow 2 might drop below this rate, because the total rate of the two flows cannot exceed 192 kbps.

Configuring aggregate CAR

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Configure an aggregate

CAR action. qos car car-name aggregative cir

committed-information-rate

committed-burst-size [

[ cbs ebs excess-burst-size ] ] [ green action | red action | yellow action ] *

Use either of the commands.

qos car car-name aggregative cir

By default, no aggregate

committed-information-rate [ cbs

CAR action is configured. committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ green action | red action | yellow action ] *

3. Enter traffic behavior view. traffic behavior behavior-name N/A

4. Use the aggregate CAR in the traffic behavior.

car name agg-car-name N/A

Configuring hierarchical CAR

Step

1. Enter system view.

Command system-view

Remarks

N/A

qos car hierarchy-car-name hierarchy

cir committed-information-rate [ cbs

committed-burst-size [ ebs

2. Configure a hierarchical excess-burst-size ] ]

CAR action.

qos car hierarchy-car-name hierarchy

cir committed-information-rate [ cbs committed-burst-size ] pir

peak-information-rate excess-burst-size ]

[ ebs

Use either of the commands.

By default, no hierarchical

CAR action is configured.

3. Enter traffic behavior view. traffic behavior behavior-name

•

Aggregate CAR:

car name agg-car-name hierarchy-car hierarchy-car-name

[ mode { and | or } ]

4. Use the hierarchical CAR action in the traffic behavior to cooperate with an aggregate CAR action or

•

Common CAR:

car cir committed-information-rate

[ cbs committed-burst-size [ ebs excess-burst-size red action |

] ] [ green yellow action action

] * common CAR action.

[ hierarchy-car hierarchy-car-name [ mode { and | or } ] ]

car cir committed-information-rate

[ cbs committed-burst-size ] pir peak-information-rate [ ebs

N/A

Use any of the commands.

By default, no hierarchical

CAR action is used in a traffic behavior.

For more information about common CAR actions, see

GTS, and rate limit ."

Step Command excess-burst-size ] [ green action | red action | yellow action ] *

[ hierarchy-car hierarchy-car-name [ mode { and | or } ] ]

Remarks

Displaying and maintaining global CAR

Execute display commands in any view and reset commands in user view.

Task

Display statistics for global CAR actions.

Clear statistics for global CAR actions.

Command display qos car name [ car-name ] reset qos car name [ car-name ]

Aggregate CAR configuration example

Network requirements

As shown in Figure 22 , configure an aggregate CAR to rate-limit the traffic of VLAN 10 and VLAN

100 received on GigabitEthernet 1/0/1 by using these parameters: CIR is 2560 kbps, CBS is 20480 bytes, and the action for red packets is discard .

Figure 22 Network diagram

Internet

GE1/0/1

Switch

VLAN 10 VLAN 100

Configuration procedure

# Configure an aggregate CAR action named aggcar-1 according to the rate limit requirements.

<Switch> system-view

[Switch] qos car aggcar-1 aggregative cir 2560 cbs 20480 red discard

# Create class 1 to match traffic of VLAN 10. Create behavior 1 and use aggregate CAR action aggcar-1 in the behavior.

[Switch] traffic classifier 1

[Switch-classifier-1] if-match customer-vlan-id 10

[Switch-classifier-1] quit

[Switch] traffic behavior 1

[Switch-behavior-1] car name aggcar-1

[Switch-behavior-1] quit

# Create class 2 to match traffic of VLAN 100. Create behavior 2 and use aggregate CAR action aggcar-1 in the behavior.

[Switch] traffic classifier 2

[Switch-classifier-2] if-match customer-vlan-id 100

[Switch-classifier-2] quit

[Switch] traffic behavior 2

[Switch-behavior-2] car name aggcar-1

[Switch-behavior-2] quit

# Create a QoS policy named car , associate class 1 with behavior 1, and associate class 2 with behavior 2.

[Switch] qos policy car

[Switch-qospolicy-car] classifier 1 behavior 1

[Switch-qospolicy-car] classifier 2 behavior 2

[Switch-qospolicy-car] quit

# Apply QoS policy car to the incoming traffic of GigabitEthernet 1/0/1.

[Switch] interface gigabitethernet 1/0/1

[Switch-GigabitEthernet1/0/1]qos apply policy car inbound

Hierarchical CAR configuration examples

AND-mode hierarchical CAR configuration example

Network requirements

As shown in Figure 23 :

•

Configure rate limiting for HTTP traffic received on GigabitEthernet 1/0/1 and GigabitEthernet

1/0/2 to limit the rate of HTTP traffic received on each port to 240 kbps.

•

Configure hierarchical CAR to limit the rate of HTTP traffic received on the two ports to 320 kbps and drop the exceeding packets.

Figure 23 Network diagram

Internet

GE1/0/1

Switch

GE1/0/2

Configuration procedure

# Configure a hierarchical CAR action named http according to the rate limit requirements.

<Switch> system-view

[Switch] qos car http hierarchy cir 320

# Configure ACL 3000 to match HTTP packets.

[Switch] acl number 3000

[Switch-acl-adv-3000] rule permit tcp destination-port eq 80

[Switch-acl-adv-3000] quit

# Create traffic class 1, and use ACL 3000 as the match criterion in the traffic class.

[Switch] traffic classifier 1

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

[Switch-classifier-1] quit

# Configure a common CAR action in traffic behavior 1, and use hierarchical CAR action http , with the collaborating mode being AND.

[Switch] traffic behavior 1

[Switch-behavior-1] car cir 240 hierarchy-car http mode and

[Switch-behavior-1] quit

# Create a QoS policy named http , and associate traffic class 1 with traffic behavior 1 in the QoS policy.

[Switch] qos policy http

[Switch-qospolicy-http] classifier 1 behavior 1

[Switch-qospolicy-http] quit

# Apply QoS policy http to the incoming traffic of GigabitEthernet 1/0/1 and GigabitEthernet 1/0/2.

[Switch] interface gigabitethernet 1/0/1

[Switch-GigabitEthernet1/0/1] qos apply policy http inbound

[Switch-GigabitEthernet1/0/1] quit

[Switch] interface gigabitethernet 1/0/2

[Switch-GigabitEthernet1/0/2] qos apply policy http inbound

OR-mode hierarchical CAR configuration example

Network requirements

As shown in Figure 24 , configure rate limiting on GigabitEthernet 1/0/1 for video traffic received from

192.168.0.2 and 192.168.0.3. Set the CIR to 240 kbps for each of the video streams according to their regular average rates. To guarantee that occasional large bursts can pass through, configure hierarchical CAR to limit total rate of the two video streams to 640 kbps, and drop the exceeding traffic.

Figure 24 Network diagram

Switch

GE1/0/1

192.168.0.2

192.168.0.3

Configuration procedure

# Configure a hierarchical CAR action named video according to the rate limit requirements.

<Switch> system-view

[Switch] qos car video hierarchy cir 640

# Create traffic class 1, and use ACL 2000 as the match criterion in the traffic class to match packets sourced from 192.168.0.2.

[Switch] acl number 2000

[Switch-acl-basic-2000] rule permit source 192.168.0.2 0.0.0.0

[Switch-acl-basic-2000] quit

# Create traffic behavior 1, configure a common CAR action, and use hierarchical CAR action video , with the collaborating mode being OR.

[Switch] traffic classifier 1

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

[Switch-classifier-1] quit

[Switch] traffic behavior 1

[Switch-behavior-1] car cir 240 hierarchy-car video mode or

[Switch-behavior-1] quit

# Create traffic class 2, and use ACL 2001 as the match criterion in the traffic class to match packets sourced from 192.168.0.3.

[Switch] acl number 2001

[Switch-acl-basic-2001] rule permit source 192.168.0.3 0.0.0.0

[Switch-acl-basic-2001] quit

# Create traffic behavior 2, configure a common CAR action, and use hierarchical CAR action video , with the collaborating mode being OR.

[Switch] traffic classifier 2

[Switch-classifier-2] if-match acl 2001

[Switch-classifier-2] quit

[Switch] traffic behavior 2

[Switch-behavior-2] car cir 240 hierarchy-car video mode or

[Switch-behavior-2] quit

# Create a QoS policy named video , and associate traffic classes 1 and 2 with traffic behaviors 1 and

2 in the QoS policy, respectively.

[Switch] qos policy video

[Switch-qospolicy-video] classifier 1 behavior 1

[Switch-qospolicy-video] classifier 2 behavior 2

[Switch-qospolicy-video] quit

# Apply QoS policy video to the incoming traffic of GigabitEthernet 1/0/1.

[Switch] interface gigabitethernet 1/0/1

[Switch-GigabitEthernet1/0/1] qos apply policy video inbound

Configuring class-based accounting

Class-based accounting collects statistics (in packets or bytes) on a per-traffic class basis. For example, you can define the action to collect statistics for traffic sourced from a certain IP address.

By analyzing the statistics, you can determine whether anomalies have occurred and what action to take.

Configuration procedure

To configure class-based accounting:

Step

1. Enter system view.

Command system-view

Remarks

N/A

2. Create a traffic class and enter traffic class view. traffic classifier classifier-name

[ operator { and | or } ]

By default, no traffic class exists.

3. Configure match criteria. if-match match-criteria

By default, no match criterion is configured.

For more information about the if-match command, see

ACL and QoS Command

Reference .

N/A 4. Return to system view. quit

5. Create a traffic behavior and enter traffic behavior view.

traffic behavior behavior-name

By default, no traffic behavior exists.

6. Configure an accounting action. accounting { byte | packet }

By default, no traffic accounting action is configured.

A QoS policy that contains an accounting action cannot be applied globally.

7. Return to system view. quit N/A

10. Return to system view.

11.

Create a QoS policy and enter QoS policy view.

Apply the QoS policy. qos policy policy-name

By default, no QoS policy exists.

9. Associate the traffic class with the traffic behavior in the QoS policy. classifier classifier-name behavior behavior-name [ insert-before

before-classifier-name ]

By default, a traffic class is not associated with a traffic behavior. quit N/A

•