Login
- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 02-QoS configuration | 376.51 KB |
Contents
QoS processing flow in a device
Restrictions and guidelines for applying a QoS policy
Applying the QoS policy to an interface
Applying the QoS policy globally
Applying the QoS policy to a control plane
Applying the QoS policy in control-plane management view
Setting the QoS policy-based traffic rate statistics collection period for an interface
Display and maintenance commands for QoS policies
Configuring traffic policing and rate limit
About traffic policing and rate limit
Traffic evaluation and token buckets
Traffic policing configuration approaches
Configuring traffic policing by using the MQC approach
Configuring CAR-list-based traffic policing
Configuring ACL-based traffic policing
Configuring traffic policing for all traffic
Configuring the rate limit for an interface
Display and maintenance commands for traffic policing and rate limit
Configuring congestion management
Cause, negative results, and countermeasure of congestion
Setting the FIFO queue size for an interface
Restrictions and guidelines for CBQ configuration
Configure AF and the minimum guaranteed bandwidth
Configuring EF and the maximum bandwidth
Setting the maximum available interface bandwidth
Setting the maximum reserved bandwidth as a percentage of available bandwidth for an interface
Displaying and maintaining congestion management
Restrictions and guidelines: Traffic filtering configuration
Configuring protocol packet rate limiting
About protocol packet rate limiting
Configuring traffic redirecting
Restrictions and guidelines: Traffic redirecting configuration
Configuring class-based accounting
Restrictions and guidelines: Class-based accounting configuration
Appendix B Introduction to packet precedence
QoS overview
In data communications, Quality of Service (QoS) provides differentiated service guarantees for diversified traffic in terms of bandwidth, delay, jitter, and drop rate, all of which can affect QoS.
QoS manages network resources and prioritizes traffic to balance system resources.
The following section describes typical QoS service models and widely used QoS techniques.
QoS service models
This section describes several typical QoS service models.
Best-effort service model
The best-effort model is a single-service model. The best-effort model is not as reliable as other models and does not guarantee delay-free delivery.
The best-effort service model is the default model for the Internet and applies to most network applications. It uses the First In First Out (FIFO) queuing mechanism.
IntServ model
The integrated service (IntServ) model is a multiple-service model that can accommodate diverse QoS requirements. This service model provides the most granularly differentiated QoS by identifying and guaranteeing definite QoS for each data flow.
In the IntServ model, an application must request service from the network before it sends data. IntServ signals the service request with the RSVP. All nodes receiving the request reserve resources as requested and maintain state information for the application flow.
The IntServ model demands high storage and processing capabilities because it requires all nodes along the transmission path to maintain resource state information for each flow. This model is suitable for small-sized or edge networks. However, it is not suitable for large-sized networks, for example, the core layer of the Internet, where billions of flows are present.
DiffServ model
The differentiated service (DiffServ) model is a multiple-service model that can meet diverse QoS requirements. It is easy to implement and extend. DiffServ does not signal the network to reserve resources before sending data, as IntServ does.
QoS techniques in a network
The QoS techniques include the following features:
· Traffic classification.
· Traffic policing.
The following section briefly introduces these QoS techniques.
All QoS techniques in this document are based on the DiffServ model.
Figure 1 Position of the QoS techniques in a network
As shown in Figure 1, traffic classification and traffic policing mainly implement the following functions:
· Traffic classification—Uses match criteria to assign packets with the same characteristics to a traffic class. Based on traffic classes, you can provide differentiated services.
· Traffic policing—Polices flows and imposes penalties to prevent aggressive use of network resources. You can apply traffic policing to both incoming and outgoing traffic of a port.
· Congestion management—Provides a resource scheduling policy to determine the packet forwarding sequence when congestion occurs. Congestion management usually applies to the outgoing traffic of a port.
QoS processing flow in a device
Figure 2 briefly describes how the QoS module processes traffic.
1. Traffic classifier identifies and classifies traffic for subsequent QoS actions.
2. The QoS module takes various QoS actions on classified traffic as configured, depending on the traffic processing phase and network status. For example, you can configure traffic policing for incoming traffic.
QoS configuration approaches
You can configure QoS by using the MQC approach or non-MQC approach.
In the modular QoS configuration (MQC) approach, you configure QoS service parameters by using QoS policies. A QoS policy defines QoS actions to take on different classes of traffic and can be applied to an object (such as an interface) to control traffic.
In the non-MQC approach, you configure QoS service parameters without using a QoS policy. For example, you can use the rate limit feature to set a rate limit on an interface without using a QoS policy.
Some features support both approaches, but some support only one.
Configuring a QoS policy
About QoS policies
A QoS policy has the following components:
· Traffic class—Defines criteria to match packets.
· Traffic behavior—Defines QoS actions to take on matching packets.
By associating a traffic class with a traffic behavior, a QoS policy can perform the QoS actions on matching packets.
A QoS policy can have multiple class-behavior associations.
QoS policy tasks at a glance
To configure a QoS policy, perform the following tasks:
2. Defining a traffic behavior
4. (Optional.) Configuring policy nesting
¡ Applying the QoS policy to an interface
¡ Applying the QoS policy globally
6. (Optional.) Setting the QoS policy-based traffic rate statistics collection period for an interface
Defining a traffic class
1. Enter system view.
system-view
2. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
3. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criterion is configured.
For more information, see the if-match command in ACL and QoS Command Reference.
Defining a traffic behavior
1. Enter system view.
system-view
2. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
3. Configure an action in the traffic behavior.
By default, no action is configured for a traffic behavior.
For more information about configuring an action, see the subsequent chapters for traffic policing, traffic filtering, priority marking, class-based accounting, and so on.
Defining a QoS policy
1. Enter system view.
system-view
2. Create a QoS policy and enter QoS policy view.
qos policy policy-name
3. Associate a traffic class with a traffic behavior to create a class-behavior association 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.
Repeat this step to create more class-behavior associations.
Configuring policy nesting
About this task
A QoS policy configuration can contain a parent policy and a child policy.
Policy nesting allows you to create a child policy in the view of a traffic behavior of the parent policy.
You can nest a QoS policy in a traffic behavior to reclassify the traffic class associated with the behavior. Then the system performs the actions defined in the QoS policy on the reclassified traffic. The QoS policy nested in the traffic behavior is called the child policy. The QoS policy that nests the behavior is called the parent policy.
Prerequisites
Before configuring policy nesting, define a child policy (see "Defining a QoS policy").
Procedure
1. Enter system view.
system-view
2. Define a traffic class for the parent policy.
a. Create a traffic class for the parent policy and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criterion is configured.
For more information about configuring match criteria, see ACL and QoS Command Reference.
c. Return to system view.
quit
3. Nest the child QoS policy in the traffic behavior of the parent policy.
a. Create a traffic behavior for the parent policy and enter traffic behavior view.
traffic behavior behavior-name
b. Nest the child QoS policy.
traffic-policy policy-name
By default, policy nesting is not configured.
c. Return to system view.
quit
4. Create the parent policy and enter parent policy view.
qos policy policy-name
5. Associate the class with the behavior in the parent policy.
classifier classifier-name behavior behavior-name
By default, a class is not associated with a behavior.
Applying the QoS policy
Application destinations
You can apply a QoS policy to the following destinations:
· Interface—The QoS policy takes effect on the traffic sent or received on the interface.
· Globally—The QoS policy takes effect on the traffic sent or received on all ports.
· Control plane—The QoS policy takes effect on the traffic received on the control plane.
· Management interface control plane—The QoS policy takes effect on the traffic sent from the management interface to the control plane.
Restrictions and guidelines for applying a QoS policy
You can modify traffic classes, traffic behaviors, and class-behavior associations in a QoS policy even after it is applied (except that it is applied to a user profile). If a traffic class uses an ACL for traffic classification, you can delete or modify the ACL.
Applying the QoS policy to an interface
Restrictions and guidelines
A QoS policy can be applied to multiple interfaces. However, only one QoS policy can be applied to one direction (inbound or outbound) of an interface.
The QoS policy applied to the outgoing traffic on an interface does not regulate local packets. Local packets refer to critical protocol packets sent by the local system for operation maintenance. The most common local packets include link maintenance, RIP, LDP, and SSH packets.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Apply the QoS policy to the interface.
qos apply policy policy-name { inbound [ enhancement | postposition ] | outbound [ enhancement ] }
By default, no QoS policy is applied to an interface.
Applying the QoS policy globally
About this task
You can apply a QoS policy globally to the inbound or outbound direction of all ports.
Restrictions and guidelines
When you apply a QoS policy globally, the QoS policy is applied on all interface cards. If the hardware resources of an interface card are insufficient, applying a QoS policy globally might fail on the interface card. The system does not automatically roll back the QoS policy configuration already applied to other interface cards. To ensure consistency, you must use the undo qos apply policy global command to manually remove the QoS policy configuration applied to them.
A QoS policy that contains an accounting action cannot be applied globally.
Procedure
1. Enter system view.
system-view
2. Apply the QoS policy globally.
qos apply policy policy-name global { inbound | outbound } enhancement
By default, no QoS policy is applied globally.
Applying the QoS policy to a control plane
About this task
A device provides the user plane and the control plane.
· User plane—The units at the user plane are responsible for receiving, transmitting, and switching (forwarding) packets, such as various dedicated forwarding chips. They deliver super processing speeds and throughput.
· Control plane—The units at the control plane are processing units running most routing and switching protocols. They are responsible for protocol packet resolution and calculation, such as CPUs. Compared with user plane units, the control plane units allow for great packet processing flexibility but have lower throughput.
When the user plane receives packets that it cannot recognize or process, it transmits them to the control plane. If the transmission rate exceeds the processing capability of the control plane, the control plane will be busy handling undesired packets. As a result, the control plane will fail to handle legitimate packets correctly or timely. As a result, protocol performance is affected.
To address this problem, apply a QoS policy to the control plane to take QoS actions, such as traffic filtering or traffic policing, on inbound traffic. This ensures that the control plane can correctly receive, transmit, and process packets.
A predefined control plane QoS policy uses the protocol type or protocol group type to identify the type of packets sent to the control plane. You can use protocol types or protocol group types in if-match commands in traffic class view for traffic classification. Then you can reconfigure traffic behaviors for these traffic classes as required. You can use the display qos policy control-plane pre-defined command to display predefined control plane QoS policies.
Procedure
1. Enter system view.
system-view
2. Enter control plane view.
In standalone mode:
control-plane slot slot-number [ cpu cpu-number ]
In IRF mode:
control-plane chassis chassis-number slot slot-number [ cpu cpu-number ]
3. Apply the QoS policy to the control plane.
qos apply policy policy-name inbound
By default, no QoS policy is applied to a control plane.
Applying the QoS policy in control-plane management view
About this task
If the rate of packets from the management interface to the control plane exceeds the processing capability, the control plane will fail to handle the packets correctly or timely. As a result, protocol performance is affected.
This feature allows you to rate limit the packets sent from the management interface to the control plane. This ensures that the control plane can correctly receive, transmit, and process packets from the management interface.
By default, a predefined QoS policy is applied in control-plane management view. To display the predefined QoS policy, use the display qos policy control-plane management pre-defined command. The predefined QoS policy uses the protocol type or protocol group type to identify the type of packets sent from the management interface to the control plane. You can use protocol types or protocol group types in if-match commands in traffic class view for traffic classification. Then, you can reconfigure traffic behaviors for these traffic classes as required.
Procedure
1. Enter system view.
system-view
2. Enter control-plane management view.
control-plane management
3. Apply the QoS policy.
qos apply policy policy-name inbound
By default, no QoS policy is applied in control-plane management view.
Setting the QoS policy-based traffic rate statistics collection period for an interface
About this task
You can enable collection of per-class traffic statistics over a period of time, including the average forwarding rate and drop rate. For example, if you set the statistics collection period to n minutes, the system performs the following operations:
· Collects traffic statistics for the most recent n minutes.
· Refreshes the statistics every n/5 minutes.
You can use the display qos policy interface command to view the collected traffic rate statistics.
A subinterface uses the statistics collection period configured on the main interface.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the traffic rate statistics collection period for the interface.
qos flow-interval interval
The default setting is 5 minutes.
Display and maintenance commands for QoS policies
Execute display commands in any view and reset commands in user view.
|
Task |
Command |
|
Display QoS policy configuration. |
In standalone mode: display qos policy { system-defined | user-defined } [ policy-name [ classifier classifier-name ] ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display qos policy { system-defined | user-defined } [ policy-name [ classifier classifier-name ] ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
|
Display information about QoS policies applied to the control plane. |
In standalone mode: display qos policy control-plane slot slot-number [ cpu cpu-number ] In IRF mode: display qos policy control-plane chassis chassis-number slot slot-number [ cpu cpu-number ] |
|
Display information about QoS policies applied in control-plane management view. |
display qos policy control-plane management |
|
Display information about the predefined QoS policy applied in control-plane management view. |
display qos policy control-plane management pre-defined |
|
Display information about the predefined QoS policy applied to the control plane. |
In standalone mode: display qos policy control-plane pre-defined [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display qos policy control-plane pre-defined [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
|
Display information about QoS policies applied globally. |
In standalone mode: display qos policy global [ slot slot-number [ cpu cpu-number ] ] [ inbound | outbound ] In IRF mode: display qos policy global [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] [ inbound | outbound ] |
|
Display information about QoS policies applied to interfaces. |
In standalone mode: display qos policy interface [ interface-type interface-number ] [ slot slot-number [ cpu cpu-number ] ] [ inbound | outbound ] In IRF mode: display qos policy interface [ interface-type interface-number ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] [ inbound | outbound ] |
|
Display traffic behavior configuration. |
In standalone mode: display traffic behavior { system-defined | user-defined } [ behavior-name ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display traffic behavior { system-defined | user-defined } [ behavior-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
|
Display traffic class configuration. |
In standalone mode: display traffic classifier { system-defined | user-defined } [ classifier-name ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display traffic classifier { system-defined | user-defined } [ classifier-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
|
Clear the statistics for the QoS policy applied to the control plane. |
In standalone mode: reset qos policy control-plane slot slot-number [ cpu cpu-number ] In IRF mode: reset qos policy control-plane chassis chassis-number slot slot-number [ cpu cpu-number ] |
|
Clear the statistics for a QoS policy applied globally. |
reset qos policy global [ inbound | outbound ] |
|
Clear the statistics of the QoS policy applied in a certain direction of a VLAN. |
reset qos vlan-policy [ vlan vlan-id ] [ inbound | outbound ] |
Configuring traffic policing and rate limit
About traffic policing and rate limit
Traffic limit helps assign network resources (including bandwidth) and increase network performance. For example, you can configure a flow to use only the resources committed to it in a certain time range. This avoids network congestion caused by burst traffic.
Traffic policing controls the traffic rate and resource usage according to traffic specifications. You can use token buckets for evaluating traffic specifications.
Traffic evaluation and token buckets
Token bucket features
A token bucket is analogous to a container that holds a certain number of tokens. Each token represents a certain forwarding capacity. The system puts tokens into the bucket at a constant rate. When the token bucket is full, the extra tokens cause the token bucket to overflow.
Evaluating traffic with the token bucket
A token bucket mechanism evaluates traffic by looking at the number of tokens in the bucket. If the number of tokens in the bucket is enough for forwarding the packets:
· The traffic conforms to the specification (called conforming traffic).
· The corresponding tokens are taken away from the bucket.
Otherwise, the traffic does not conform to the specification (called excess traffic).
A token bucket has the following configurable parameters:
· Mean rate at which tokens are put into the bucket, which is the permitted average rate of traffic. It is usually set to the committed information rate (CIR).
· Burst size or the capacity of the token bucket. It is the maximum traffic size permitted in each burst. It is usually set to the committed burst size (CBS). The set burst size must be greater than the maximum packet size.
Each arriving packet is evaluated.
Complicated evaluation
You can set two token buckets, bucket C and bucket E, to evaluate traffic in a more complicated environment and achieve more policing flexibility. The following are main mechanisms used for complicated evaluation:
· Single rate two color—Uses one token bucket and the following parameters:
¡ CIR—Rate at which tokens are put into bucket C. It sets the average packet transmission or forwarding rate allowed by bucket C.
¡ CBS—Size of bucket C, which specifies the transient burst of traffic that bucket C can forward.
When a packet arrives, the following rules apply:
¡ If bucket C has enough tokens to forward the packet, the packet is colored green.
¡ Otherwise, the packet is colored red.
· Single rate three color—Uses two token buckets and the following parameters:
¡ CIR—Rate at which tokens are put into bucket C. It sets the average packet transmission or forwarding rate allowed by bucket C.
¡ CBS—Size of bucket C, which specifies the transient burst of traffic that bucket C can forward.
¡ EBS—Size of bucket E minus size of bucket C, which specifies the transient burst of traffic that bucket E can forward. The EBS cannot be 0. The size of E bucket is the sum of the CBS and EBS.
When a packet arrives, the following rules apply:
¡ If bucket C has enough tokens, the packet is colored green.
¡ If bucket C does not have enough tokens but bucket E has enough tokens, the packet is colored yellow.
¡ If neither bucket C nor bucket E has sufficient tokens, the packet is colored red.
· Two rate three color—Uses two token buckets and the following parameters:
¡ CIR—Rate at which tokens are put into bucket C. It sets the average packet transmission or forwarding rate allowed by bucket C.
¡ CBS—Size of bucket C, which specifies the transient burst of traffic that bucket C can forward.
¡ PIR—Rate at which tokens are put into bucket E, which specifies the average packet transmission or forwarding rate allowed by bucket E.
¡ EBS—Size of bucket E, which specifies the transient burst of traffic that bucket E can forward.
When a packet arrives, the following rules apply:
¡ If bucket C has enough tokens, the packet is colored green.
¡ If bucket C does not have enough tokens but bucket E has enough tokens, the packet is colored yellow.
¡ If neither bucket C nor bucket E has sufficient tokens, the packet is colored red.
Traffic policing
Traffic policing supports policing the inbound traffic and the outbound traffic.
A typical application of traffic policing is to supervise the specification of traffic entering a network and limit it within a reasonable range. Another application is to "discipline" the extra traffic to prevent aggressive use of network resources by an application. For example, you can limit bandwidth for HTTP packets to less than 50% of the total. If the traffic of a session exceeds the limit, traffic policing can drop the packets or reset the IP precedence of the packets. Figure 3 shows an example of policing outbound traffic on an interface.
Traffic policing is widely used in policing traffic entering the ISP networks. It can classify the policed traffic and take predefined policing actions on each packet depending on the evaluation result:
· Forwarding the packet if the evaluation result is "conforming."
· Dropping the packet if the evaluation result is "excess."
· Forwarding the packet with its precedence re-marked if the evaluation result is "conforming."
· Delivering the packet to next-level traffic policing with its precedence re-marked if the evaluation result is "conforming."
Rate limit
Rate limit controls the rate of inbound and outbound traffic. The outbound traffic is taken for example.
The rate limit of an interface or PW specifies the maximum rate for forwarding packets (excluding critical packets).
Rate limit also uses token buckets for traffic control. When rate limit is configured on an interface, a token bucket handles all packets to be sent through the interface for rate limiting. If enough tokens are in the token bucket, packets can be forwarded. Otherwise, packets are put into QoS queues for congestion management. In this way, the traffic passing the interface is controlled.
Figure 4 Rate limit implementation
The token bucket mechanism limits traffic rate when accommodating bursts. It allows bursty traffic to be transmitted if enough tokens are available. If tokens are scarce, packets cannot be transmitted until efficient tokens are generated in the token bucket. It restricts the traffic rate to the rate for generating tokens.
Rate limit controls the total rate of all packets on an interface. It is easier to use than traffic policing in controlling the total traffic rate.
Configuring traffic policing
Traffic policing configuration approaches
You can configure traffic policing by using the MQC approach or the non-MQC approach. If both approaches are used, the MQC configuration takes effect.
You can configure the following types of traffic policing by using the non-MQC approach:
· CAR-list-based traffic policing.
· ACL-based traffic policing.
· Traffic policing for all traffic.
If traffic policing is configured by using both the MQC approach and non-MQC approach, the configuration in MQC approach takes effect.
Configuring traffic policing by using the MQC approach
Restrictions and guidelines
The device supports the following application destinations for traffic policing:
· Interface.
· Globally.
· Control plane.
· Control-plane management view.
Procedure
1. Enter system view.
system-view
2. Define a traffic class.
a. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criterion is configured.
For more information about the if-match command, see ACL and QoS Command Reference.
c. Return to system view.
quit
3. Define a traffic behavior.
a. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
b. Configure a traffic policing action.
car cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ green action | red action | yellow action ] *
car cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ green action | red action | yellow action ] *
By default, no traffic policing action is configured.
c. Return to system view.
quit
4. Define a QoS policy.
a. Create a QoS policy and enter QoS policy view.
qos policy policy-name
b. Associate the traffic class with the traffic behavior in the QoS policy.
classifier classifier-name behavior behavior-name
By default, a traffic class is not associated with a traffic behavior.
c. Return to system view.
quit
5. Apply the QoS policy.
For more information, see "Applying the QoS policy."
By default, no QoS policy is applied.
Configuring CAR-list-based traffic policing
1. Enter system view.
system-view
2. Configure a CAR list.
qos carl carl-index { dscp dscp-list | mac mac-address | mpls-exp mpls-exp-value | precedence precedence-value | { destination-ip-address | source-ip-address } { range start-ip-address to end-ip-address | subnet ip-address mask-length } [ per-address [ shared-bandwidth ] ] }
3. Enter interface view.
interface interface-type interface-number
4. Apply a CAR-list-based CAR policy to the interface.
qos car { inbound | outbound } carl carl-index cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ green action | red action | yellow action ] *
qos car { inbound | outbound } carl carl-index cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ green action | red action | yellow action ] *
By default, no CAR policy is applied to an interface.
Configuring ACL-based traffic policing
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure an ACL-based CAR policy on the interface.
qos car { inbound | outbound } acl [ ipv6 ] acl-number cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ green action | red action | yellow action ] *
qos car { inbound | outbound } acl [ ipv6 ] acl-number cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ green action | red action | yellow action ] *
By default, no CAR policy is configured on an interface.
Configuring traffic policing for all traffic
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure a CAR policy for all traffic on the interface.
qos car { inbound | outbound } any cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ] [ green action | red action | yellow action ] *
qos car { inbound | outbound } any cir committed-information-rate [ cbs committed-burst-size ] pir peak-information-rate [ ebs excess-burst-size ] [ green action | red action | yellow action ] *
By default, no CAR policy is configured on an interface.
Configuring the rate limit
Configuring the rate limit for an interface
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Configure the rate limit for the interface.
¡ In absolute value:
qos lr outbound cir committed-information-rate [ cbs committed-burst-size [ ebs excess-burst-size ] ]
By default, no rate limit is configured on an interface.
Display and maintenance commands for traffic policing and rate limit
Execute display commands in any view.
|
Task |
Command |
|
Display CAR configuration and statistics on an interface. |
display qos car interface [ interface-type interface-number ] |
|
Display CAR list information. |
In standalone mode: display qos carl [ carl-index ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display qos carl [ carl-index ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
|
Display rate limit configuration and statistics. |
display qos lr interface [ interface-type interface-number ] |
|
Display traffic behavior configuration. |
In standalone mode: display traffic behavior user-defined [ behavior-name ] [ slot slot-number [ cpu cpu-number ] ] In IRF mode: display traffic behavior user-defined [ behavior-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ] |
Configuring congestion management
About congestion management
Cause, negative results, and countermeasure of congestion
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 5 shows common congestion scenarios.
Figure 5 Traffic congestion causes
Congestion can introduce 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 system breakdown.
Congestion is unavoidable in switched networks or multiuser application environments. To improve the service performance of your network, implement congestion management policies.
For example, congestion management defines a resource dispatching policy to prioritize packets for forwarding when congestion occurs.
Congestion management methods
Congestion management involves queue creating, traffic classification, packet enqueuing, and queue scheduling.
Queuing is a common congestion management technique. It classifies traffic into queues and picks out packets from each queue by using an algorithm. Various queuing algorithms are available, and each addresses a particular network traffic problem. Your choice of algorithm significantly affects bandwidth assignment, delay, and jitter.
The device supports the following queuing mechanisms:
· FIFO.
· CBQ.
FIFO
As shown in Figure 6, the first in first out (FIFO) uses a single queue and does not classify traffic or schedule queues. FIFO delivers packets in their arrival order. The packet that arrives earlier is scheduled first. The only concern of FIFO is queue length, which affects delay and packet loss rate. On a device, resources are assigned to packets depending on their arrival order and load status of the device. The best-effort service model uses FIFO queuing.
FIFO does not address congestion problems. If only one FIFO output/input queue exists on a port, you cannot ensure timely delivery of mission-critical or delay-sensitive traffic or smooth traffic jitter. If malicious traffic occupies bandwidth aggressively, the problems increase. To control congestion and prioritize forwarding of critical traffic, use other queue scheduling mechanisms, where multiple queues can be configured. Within each queue, FIFO is still used.
CBQ
Figure 7 CBQ
Class-based queuing (CBQ) extends WFQ by supporting user-defined classes. When network congestion occurs, CBQ uses user-defined traffic match criteria to enqueue packets. Before packets are enqueued, congestion avoidance actions, such as tail drop or WRED and bandwidth restriction check, are performed. When being dequeued, packets are scheduled by WFQ.
CBQ provides the following queues:
· Emergency queue—Enqueues emergent packets. The emergency queue is a FIFO queue without bandwidth restriction.
· Strict priority (SP) queuing—SP queuing is designed for mission-critical applications. Mission-critical applications require preferential treatment to reduce the response delay when congestion occurs. With SP queuing, CBQ can provide strict priority service. A maximum of 64 SP queues are supported.
· Low Latency Queuing (LLQ)—An EF queue. Because packets are fairly treated in CBQ, delay-sensitive flows like video and voice packets might not be transmitted timely. To solve this problem, LLQ combines PQ and CBQ to preferentially transmit delay-sensitive flows like voice packets. When defining traffic classes for LLQ, you can configure a class of packets to be preferentially transmitted. The packets of all priority classes are assigned to the same priority queue. Bandwidth restriction on each class of packets is checked before the packets are enqueued. During the dequeuing operation, packets in the priority queue are transmitted first. To reduce the delay of the other queues except the priority queue, LLQ assigns the maximum available bandwidth to each priority class. The bandwidth value polices traffic during congestion. When no congestion is present, a priority class can use more than the bandwidth assigned to it. During congestion, the packets of each priority class exceeding the assigned bandwidth are discarded.
· Bandwidth queuing (BQ)—An AF queue. The BQ provides guaranteed bandwidth for AF traffic, and schedules the AF classes proportionally. The system supports up to 64 AF queues.
· Default queue—A WFQ queue. The default queue transmits the BE traffic by using the remaining interface bandwidth.
The system matches packets with classification rules in the following order:
· Match packets with priority classes and then the other classes.
· Match packets with priority classes in the configuration order.
· Match packets with other classes in the configuration order.
· Match packets with classification rules in a class in the configuration order.
Setting the FIFO queue size
Setting the FIFO queue size for an interface
Restrictions and guidelines
For the FIFO queuing feature to take effect on a subinterface, you must configure the rate limit on the subinterface.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the FIFO queue size for the interface.
qos fifo queue-length queue-length
The default setting is 75.
If the burst traffic is too heavy, increase the queue length to make queue scheduling more accurate.
Configuring CBQ
About CBQ
The system predefines the following classes, traffic behaviors, and policies:
Predefined classes
The system predefines some classes and defines general rules for the classes. You can use the following predefined classes when defining a policy:
· default-class—Matches the default traffic.
· ef, af1, af2, af3, af4—Matches IP DSCP value ef, af1, af2, af3, af4, respectively.
· ip-prec0, ip-prec1, …ip-prec7—Matches IP precedence value 0, 1, …7, respectively.
· mpls-exp0, mpls-exp1, …mpls-exp7—Matches MPLS EXP value 0, 1, …7, respectively.
Predefined traffic behaviors
The system predefines some traffic behaviors and defines QoS features for the behaviors.
· ef—Assigns a class of packets to the EF queue and assigns 20% of the available interface or PVC bandwidth to the class of packets.
· af—Assigns a class of packets to the AF queue and assigns 20% of the available interface or PVC bandwidth to the class of packets.
· be—Defines no features.
· be-flow-based—Assigns a class of packets to a WFQ queue and specifies the drop policy as WRED. By default, 256 WFQ queues exist, and WRED is an IP precedence-based drop policy.
Predefined QoS policy
The system predefines a QoS policy, specifies a predefined class for the policy and associates a predefined behavior with the class. The policy is named default, with the default CBQ action.
The policy default is defined as follows:
· Associates the predefined class ef with the predefined traffic behavior ef.
· Associates predefined classes af1 through af4 with the predefined traffic behavior af.
· Associates the predefined class default-class with the predefined traffic behavior be.
Restrictions and guidelines for CBQ configuration
When you configure CBQ, follow these restrictions and guidelines:
· Only one of the following queuing actions can be configured in the same behavior:
¡ AF.
¡ EF.
¡ SP.
¡ WFQ.
· To configure queue af for multiple classes of a policy, you must configure them in one of the following units:
¡ Bandwidth in kbps.
¡ Percentage of the available bandwidth.
¡ Percentage of the remaining bandwidth.
· In a QoS policy, if AF is configured in percentage of the remaining bandwidth, EF can be configured in absolute value or in percentage.
· In a QoS policy, if AF is configured in absolute value or in percentage, EF can be configured in absolute value or in percentage.
· You must configure the rate limit on a subinterface for the CBQ feature to take effect on the subinterface.
· The default class cannot be associated with a traffic behavior including EF or SP.
· You can associate the traffic behavior that contains a WFQ action only with the default class.
· RTPQ and CBQ are mutually exclusive. CBQ can use LLQ to provide priority service for real-time traffic.
Configure AF and the minimum guaranteed bandwidth
Restrictions and guidelines
· The undo queue af command also cancels the queue-length command configuration and all WRED-related settings.
· The wred and queue-length commands are mutually exclusive in a traffic behavior.
· The undo wred [ dscp | ip-precedence ] command also cancels all other WRED-related settings.
· A QoS policy that contains an AF action can only be applied to the outbound direction of an interface.
Procedure
1. Enter system view.
system-view
2. Define a traffic class.
a. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criterion is configured.
For more information about configuring match criteria, see ACL and QoS Command Reference.
c. Return to system view.
quit
3. Define a traffic behavior.
a. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
b. Configure AF and the minimum guaranteed bandwidth.
queue af bandwidth { bandwidth | pct percentage | remaining-pct remaining-percentage }
By default, AF is not configured.
c. (Optional.) Set the maximum queue size.
queue-length queue-length
The default setting is 64 packets.
If the burst traffic is too heavy, increase the queue length to make queue scheduling more accurate.
d. Enable WRED.
wred [ dscp | ip-precedence ]
By default, WRED is not enabled.
e. Set the exponent for WRED to calculate the average queue size.
wred weighting-constant exponent
The default setting is 9.
f. Set the lower limit, upper limit, and drop probability denominator for a DSCP value in WRED
wred dscp dscp-value low-limit low-limit high-limit high-limit [ discard-probability discard-prob ]
By default, the lower limit is 10, the upper limit is 30, and the drop probability denominator is 10.
You must enable DSCP-based WRED by using the wred dscp command before you configure this command.
g. Set the lower limit, upper limit, and drop probability denominator for an IP precedence in WRED.
wred ip-precedence precedence low-limit low-limit high-limit high-limit [ discard-probability discard-prob ]
By default, the lower limit is 10, the upper limit is 30, and the drop probability denominator is 10.
h. Return to system view.
quit
4. Define a QoS policy.
a. Create a QoS policy and enter QoS policy view.
qos policy policy-name
b. Associate a traffic behavior with a class in the policy.
classifier classifier-name behavior behavior-name
By default, a class is not associated with a behavior.
c. Return to system view.
quit
5. Apply the QoS policy.
For more information, see "Applying the QoS policy."
By default, no QoS policy is applied.
Configuring EF and the maximum bandwidth
Restrictions and guidelines
· A QoS policy that contains an EF action can only be applied to the outbound direction of an interface.
Procedure
1. Enter system view.
system-view
2. Define a traffic class.
a. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criterion is configured.
For more information about configuring match criteria, see ACL and QoS Command Reference.
c. Return to system view.
quit
3. Define a traffic behavior.
a. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
b. Configure EF and the maximum bandwidth.
queue ef bandwidth { bandwidth [ cbs burst ] | pct percentage [ cbs-ratio ratio] }
By default, EF is not configured.
c. (Optional.) Set the maximum queue size.
queue-length queue-length
The default setting is 64 packets.
If the burst traffic is too heavy, increase the queue length to make queue scheduling more accurate.
d. Return to system view.
quit
4. Define a QoS policy.
a. Create a QoS policy and enter QoS policy view.
qos policy policy-name
b. Associate a traffic behavior with a class in the policy.
classifier classifier-name behavior behavior-name
By default, a class is not associated with a behavior.
c. Return to system view.
quit
5. Apply the QoS policy.
For more information, see "Applying the QoS policy."
By default, no QoS policy is applied.
Configuring WFQ
Restrictions and guidelines
· The undo queue wfq command also cancels the queue-length command configuration and all WRED-related settings.
· The wred and queue-length commands are mutually exclusive in a traffic behavior.
· The undo wred [ dscp | ip-precedence ] command also cancels all other WRED-related settings.
· A QoS policy that contains a WFQ action can only be applied to the outbound direction of an interface.
Procedure
1. Enter system view.
system-view
2. Define a traffic class.
a. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criterion is configured.
For more information about configuring match criteria, see ACL and QoS Command Reference.
c. Return to system view.
quit
3. Define a traffic behavior.
a. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
b. Configure WFQ.
queue wfq [ queue-number total-queue-number ]
By default, WFQ is not configured.
c. Set the maximum queue size.
queue-length queue-length
The default setting is 64 packets.
If the burst traffic is too heavy, increase the queue length to make queue scheduling more accurate.
d. Enable WRED.
wred [ dscp | ip-precedence ]
By default, WRED is not enabled.
e. Set the exponent for WRED to calculate the average queue size
wred weighting-constant exponent
The default setting is 9.
f. Set the lower limit, upper limit, and drop probability denominator for a DSCP value in WRED
wred dscp dscp-value low-limit low-limit high-limit high-limit [ discard-probability discard-prob ]
By default, the lower limit is 10, the upper limit is 30, and the drop probability denominator is 10.
g. Set the lower limit, upper limit, and drop probability denominator for an IP precedence in WRED.
wred ip-precedence precedence low-limit low-limit high-limit high-limit [ discard-probability discard-prob ]
By default, the lower limit is 10, the upper limit is 30, and the drop probability denominator is 10.
h. Return to system view.
quit
4. Define a QoS policy.
a. Create a QoS policy and enter QoS policy view.
qos policy policy-name
b. Associate a traffic behavior with a class in the policy.
classifier classifier-name behavior behavior-name
By default, a class is not associated with a behavior.
c. Return to system view.
quit
5. Apply the QoS policy.
For more information, see "Applying the QoS policy."
By default, no QoS policy is applied.
Setting the maximum available interface bandwidth
Restrictions and guidelines
· The maximum available interface bandwidth refers to the maximum interface bandwidth used for bandwidth check when CBQ enqueues packets. It is not the actual bandwidth of the physical interface.
· As a best practice, set the maximum available interface bandwidth to be smaller than the actual available bandwidth of the physical interface or logical link.
· On subinterfaces, you must configure the bandwidth command to provide base bandwidth for CBQ calculation.
¡ If no maximum available bandwidth is set for an interface, the following bandwidth is used for CBQ calculation:
¡ The actual baud rate or rate if the interface is a physical one.
¡ 0 kbps if the interface is a virtual interface, tunnel interface or Layer 3 aggregate interface.
Procedure
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the maximum available bandwidth of the interface.
bandwidth bandwidth-value
For more information about this command, see Interface Command Reference.
Setting the maximum reserved bandwidth as a percentage of available bandwidth for an interface
1. Enter system view.
system-view
2. Enter interface view.
interface interface-type interface-number
3. Set the maximum reserved bandwidth as a percentage of available bandwidth.
qos reserved-bandwidth pct percent
The default setting is 80.
Typically, the maximum reserved bandwidth should not be greater than 80% of available bandwidth. As a best practice, use the default setting.
Displaying and maintaining congestion management
Execute display commands in any view and reset commands in user view.
|
Task |
Command |
|
Display QoS policy configuration. |
display qos policy { system-defined | user-defined } [ policy-name [ classifier classifier-name ] ] |
|
(In standalone mode.) Display information about QoS policies applied to interfaces or PVCs. |
display qos policy interface [ interface-type interface-number [ pvc { pvc-name | vpi/vci } ] ] [ slot slot-number ] [ inbound | outbound ] |
|
(In IRF mode.) Display information about QoS policies applied to interfaces. |
display qos policy interface [ interface-type interface-number ] [ chassis chassis-number slot slot-number ] [ inbound | outbound ] |
|
Display the CBQ configuration and statistics for interfaces. |
display qos queue cbq interface [ interface-type interface-number ] |
|
Display the FIFO configuration and statistics for interfaces. |
display qos queue fifo interface [ interface-type interface-number ] |
|
Display queuing configuration and statistics for interfaces. |
display qos queue interface [ interface-type interface-number ] |
|
Display traffic behavior configuration. |
display traffic behavior { system-defined | user-defined } [ behavior-name ] |
|
Display class configuration. |
display traffic classifier { system-defined | user-defined } [ classifier-name ] |
Configuring traffic filtering
About 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.
Restrictions and guidelines: Traffic filtering configuration
The device supports the following application destinations for traffic filtering:
· Interface.
· Globally.
· Control plane.
Procedure
1. Enter system view.
system-view
2. Define a traffic class.
a. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criterion is configured.
For more information about configuring match criteria, see ACL and QoS Command Reference.
c. Return to system view.
quit
3. Define a traffic behavior.
a. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
b. 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 other actions in the traffic behavior except class-based accounting do not take effect.
c. Return to system view.
quit
4. Define a QoS policy.
a. Create a QoS policy and enter QoS policy view.
qos policy policy-name
b. Associate the traffic class with the traffic behavior in the QoS policy.
classifier classifier-name behavior behavior-name
By default, a traffic class is not associated with a traffic behavior.
c. Return to system view.
quit
5. Apply the QoS policy.
For more information, see "Applying the QoS policy."
By default, no QoS policy is applied.
6. (Optional.) Display the traffic filtering configuration.
In standalone mode:
display traffic behavior user-defined [ behavior-name ] [ slot slot-number [ cpu cpu-number ] ]
In IRF mode:
display traffic behavior user-defined [ behavior-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
This command is available in any view.
Configuring protocol packet rate limiting
About protocol packet rate limiting
The protocol packet processing rate of a CPU is limited. When a large number of protocol packets are sent to the CPU, the CPU might be occupied by the protocol packets and cannot process other tasks. The protocol packet rate limiting feature limits the rate of protocol packets sent to the CPU, and it guarantees the normal operation of the CPU.
Procedure
1. Enter system view.
system-view
2. Define a traffic class.
a. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criteria are configured.
For more information, see the if-match command in ACL and QoS Command Reference.
c. Return to system view.
quit
3. Define a traffic behavior.
a. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
b. Configure protocol packet rate limiting.
packet-rate value
By default, protocol packet rate limiting is not configured.
c. Return to system view.
quit
4. Define a QoS policy.
a. Create a QoS policy and enter QoS policy view.
qos policy policy-name
b. Associate the class with the traffic behavior in the QoS policy.
classifier classifier-name behavior behavior-name
By default, a class is not associated with any behavior.
c. Return to system view.
quit
5. Apply the QoS policy to a control plane.
For more information, see "Applying the QoS policy to a control plane."
By default, no QoS policy is applied to a control plane.
6. (Optional.) Display the protocol packet rate limiting configuration.
In standalone mode:
display traffic behavior user-defined [ behavior-name ] [ slot slot-number [ cpu cpu-number ] ]
In IRF mode:
display traffic behavior user-defined [ behavior-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
This command is available in any view.
Configuring priority marking
About priority marking
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 class of IP packets to control the forwarding of these packets.
1. Configure a traffic behavior with a priority marking action.
2. Associate the traffic class with the traffic behavior.
Configuring priority marking
Restrictions and guidelines
The device supports the following application destinations for priority marking:
· Interface.
· Globally.
· Control plane.
Procedure
1. Enter system view.
system-view
2. Define a traffic class.
a. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criterion is configured.
For more information about the if-match command, see ACL and QoS Command Reference.
c. Return to system view.
quit
3. Define a traffic behavior.
a. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
b. Configure a priority marking action.
For configurable priority marking actions, see the remark commands in ACL and QoS Command Reference.
c. Return to system view.
quit
4. Define a QoS policy.
a. Create a QoS policy and enter QoS policy view.
qos policy policy-name
b. Associate the traffic class with the traffic behavior in the QoS policy.
classifier classifier-name behavior behavior-name
By default, a traffic class is not associated with a traffic behavior.
c. Return to system view.
quit
5. Apply the QoS policy.
For more information, see "Applying the QoS policy."
By default, no QoS policy is applied.
6. (Optional.) Display the priority marking configuration.
In standalone mode:
display traffic behavior user-defined [ behavior-name ] [ slot slot-number [ cpu cpu-number ] ]
In IRF mode:
display traffic behavior user-defined [ behavior-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
This command is available in any view.
Configuring traffic redirecting
About traffic redirecting
Traffic redirecting redirects packets matching the specified match criteria to a location for processing.
You can redirect packets to the following destinations:
· Interface. Packets can be redirected to only Blade interfaces and Blade aggregate interfaces.
· Failover group.
For information about failover groups, see Virtual Technologies Configuration Guide.
Restrictions and guidelines: Traffic redirecting configuration
The device supports the following application destinations for traffic redirecting:
· Interface.
· Globally.
· Control plane.
· If you execute the redirect command multiple times, the most recent configuration takes effect.
· For traffic redirecting to an Ethernet interface, the switch does not display the redirecting action after the interface module or interface expansion card that hosts the interface is removed. After the interface module or interface expansion card is reinserted, the switch can display the redirecting action.
Procedure
1. Enter system view.
system-view
2. Define a traffic class.
a. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] 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.
c. Return to system view.
quit
3. Define a traffic behavior.
a. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
b. Configure a traffic redirecting action.
In standalone mode:
redirect { failover-group group-name [ channel channel-id ] | interface interface-type interface-number slot slot-number }
In IRF mode:
redirect { failover-group group-name [ channel channel-id ] | interface interface-type interface-number | chassis chassis-number slot slot-number }
By default, no traffic redirecting action is configured for a traffic behavior.
c. Return to system view.
quit
4. Define a QoS policy.
a. Create a QoS policy and enter QoS policy view.
qos policy policy-name
b. Associate the traffic class with the traffic behavior in the QoS policy.
classifier classifier-name behavior behavior-name
By default, a traffic class is not associated with a traffic behavior.
c. Return to system view.
quit
5. Apply the QoS policy.
For more information, see "Applying the QoS policy."
By default, no QoS policy is applied.
6. (Optional.) Display traffic redirecting configuration.
In standalone mode:
display traffic behavior user-defined [ behavior-name ] [ slot slot-number [ cpu cpu-number ] ]
In IRF mode:
display traffic behavior user-defined [ behavior-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
This command is available in any view.
Configuring class-based accounting
About class-based accounting
Class-based accounting collects statistics 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.
Restrictions and guidelines: Class-based accounting configuration
The device supports the following application destinations for class-based accounting:
· Interface.
· Globally.
· Control plane.
Procedure
1. Enter system view.
system-view
2. Define a traffic class.
a. Create a traffic class and enter traffic class view.
traffic classifier classifier-name [ operator { and | or } ]
b. Configure a match criterion.
if-match [ not ] match-criteria
By default, no match criterion is configured.
For more information about the if-match command, see ACL and QoS Command Reference.
c. Return to system view.
quit
3. Define a traffic behavior.
a. Create a traffic behavior and enter traffic behavior view.
traffic behavior behavior-name
b. Configure an accounting action.
accounting [ byte | packet ]
By default, no traffic accounting action is configured.
c. Return to system view.
quit
4. Define a QoS policy.
a. Create a QoS policy and enter QoS policy view.
qos policy policy-name
b. Associate the traffic class with the traffic behavior in the QoS policy.
classifier classifier-name behavior behavior-name
By default, a traffic class is not associated with a traffic behavior.
c. Return to system view.
quit
5. Apply the QoS policy.
For more information, see "Applying the QoS policy."
By default, no QoS policy is applied.
6. (Optional.) Display the class-based accounting configuration.
In standalone mode:
display traffic behavior user-defined [ behavior-name ] [ slot slot-number [ cpu cpu-number ] ]
In IRF mode:
display traffic behavior user-defined [ behavior-name ] [ chassis chassis-number slot slot-number [ cpu cpu-number ] ]
Appendixes
Appendix A Acronyms
Table 1 Appendix A Acronyms
|
Acronym |
Full spelling |
|
AF |
Assured Forwarding |
|
BE |
Best Effort |
|
BQ |
Bandwidth Queuing |
|
CAR |
Committed Access Rate |
|
CBS |
Committed Burst Size |
|
CBQ |
Class Based Queuing |
|
CE |
Congestion Experienced |
|
CIR |
Committed Information Rate |
|
CQ |
Custom Queuing |
|
DCBX |
Data Center Bridging Exchange Protocol |
|
DiffServ |
Differentiated Service |
|
DSCP |
Differentiated Services Code Point |
|
EBS |
Excess Burst Size |
|
ECN |
Explicit Congestion Notification |
|
EF |
Expedited Forwarding |
|
FIFO |
First in First out |
|
FQ |
Fair Queuing |
|
GMB |
Guaranteed Minimum Bandwidth |
|
GTS |
Generic Traffic Shaping |
|
IntServ |
Integrated Service |
|
ISP |
Internet Service Provider |
|
LLQ |
Low Latency Queuing |
|
LSP |
Label Switched Path |
|
MPLS |
Multiprotocol Label Switching |
|
PE |
Provider Edge |
|
PIR |
Peak Information Rate |
|
PQ |
Priority Queuing |
|
PW |
Pseudowire |
|
QoS |
Quality of Service |
|
QPPB |
QoS Policy Propagation Through the Border Gateway Protocol |
|
RED |
Random Early Detection |
|
RSVP |
Resource Reservation Protocol |
|
RTP |
Real-Time Transport Protocol |
|
SP |
Strict Priority |
|
ToS |
Type of Service |
|
VoIP |
Voice over IP |
|
VPN |
Virtual Private Network |
|
WFQ |
Weighted Fair Queuing |
|
WRED |
Weighted Random Early Detection |
|
WRR |
Weighted Round Robin |
Appendix B Introduction to packet precedence
IP precedence and DSCP values
As shown in Figure 8, the ToS field in the IP header contains 8 bits. The first 3 bits (0 to 2) represent IP precedence from 0 to 7. According to RFC 2474, the ToS field is redefined as the differentiated services (DS) field. A DSCP value is represented by the first 6 bits (0 to 5) of the DS field and is in the range 0 to 63. The remaining 2 bits (6 and 7) are reserved.
Table 2 IP precedence
|
IP precedence (decimal) |
IP precedence (binary) |
Description |
|
0 |
000 |
Routine |
|
1 |
001 |
priority |
|
2 |
010 |
immediate |
|
3 |
011 |
flash |
|
4 |
100 |
flash-override |
|
5 |
101 |
critical |
|
6 |
110 |
internet |
|
7 |
111 |
network |
Table 3 DSCP values
|
DSCP value (decimal) |
DSCP value (binary) |
Description |
|
46 |
101110 |
ef |
|
10 |
001010 |
af11 |
|
12 |
001100 |
af12 |
|
14 |
001110 |
af13 |
|
18 |
010010 |
af21 |
|
20 |
010100 |
af22 |
|
22 |
010110 |
af23 |
|
26 |
011010 |
af31 |
|
28 |
011100 |
af32 |
|
30 |
011110 |
af33 |
|
34 |
100010 |
af41 |
|
36 |
100100 |
af42 |
|
38 |
100110 |
af43 |
|
8 |
001000 |
cs1 |
|
16 |
010000 |
cs2 |
|
24 |
011000 |
cs3 |
|
32 |
100000 |
cs4 |
|
40 |
101000 |
cs5 |
|
48 |
110000 |
cs6 |
|
56 |
111000 |
cs7 |
|
0 |
000000 |
be (default) |
802.1p priority
802.1p priority lies in the Layer 2 header. It applies to occasions where Layer 3 header analysis is not needed and QoS must be assured at Layer 2.
Figure 9 An Ethernet frame with an 802.1Q tag header
As shown in Figure 9, the 4-byte 802.1Q tag header contains the 2-byte tag protocol identifier (TPID) and the 2-byte tag control information (TCI). The value of the TPID is 0x8100. Figure 10 shows the format of the 802.1Q tag header. The Priority field in the 802.1Q tag header is called 802.1p priority, because its use is defined in IEEE 802.1p. Table 4 shows the values for 802.1p priority.
Table 4 Description on 802.1p priority
|
802.1p priority (decimal) |
802.1p priority (binary) |
Description |
|
0 |
000 |
best-effort |
|
1 |
001 |
background |
|
2 |
010 |
spare |
|
3 |
011 |
excellent-effort |
|
4 |
100 |
controlled-load |
|
5 |
101 |
video |
|
6 |
110 |
voice |
|
7 |
111 |
network-management |
