Traffic exceeding the specified bandwidth is dropped if congestion exists otherwise policy is not used

When you specify the priority command for a class, it takes a bandwidth argument that gives maximum bandwidth in kbps. You use this parameter to specify the maximum amount of bandwidth allocated for packets belonging to the class configured with the priority command. The bandwidth parameter both guarantees bandwidth to the priority class and restrains the flow of packets from the priority class.

priority {bandwidth-kbps | percent percentage} [burst]




Guaranteed allowed bandwidth, in kbps, for the priority traffic. The amount of guaranteed bandwidth varies according to the interface and platform in use. Beyond the guaranteed bandwidth, the priority traffic will be dropped in the event of congestion to ensure that the nonpriority traffic is not starved.


Specifies that the amount of guaranteed bandwidth will be specified by the percent of available bandwidth.


Used in conjunction with the percent keyword; specifies the percentage of the total available bandwidth to be set aside for the priority class. The percentage can be a number from 1 to 100. (By default, only 75 percent can be reserved.)


(Optional) Specifies the burst size, in bytes. The range of the burst is 32 to 2,000,000 bytes. The burst size allows temporary bursting of traffic above the maximum limit after a period of inactivity. The default burst value is computed as 200 ms of traffic at the configured bandwidth rate.

In the event of congestion, if the priority class traffic exceeds the bandwidth guarantee, a congestion-aware policer is used to drop the exceeding packets. Voice traffic enqueued to the priority queue is UDP-based and therefore not adaptive to the early packet-drop characteristic of WRED. Because WRED is ineffective, you cannot use the WRED random-detect command with the priority command. In addition, because policing is used to drop packets and a queue limit is not imposed, the queue-limit command cannot be used with the priority command.

When congestion occurs, traffic destined for the priority queue is metered to ensure that the bandwidth allocation configured for the class to which the traffic belongs is not exceeded.

Priority traffic metering has these qualities:

■ It is much like committed access rate (CAR), except that priority traffic metering is only performed under conditions of congestion. When the device is not congested, the priority-class traffic is allowed to exceed its allocated bandwidth. When the device is congested, the priority-class traffic above the allocated bandwidth is discarded.

■ Metering performed on a per-packet basis, and tokens, are replenished as packets are sent. If not enough tokens are available to send the packet, the packet is dropped.

■ It restrains priority traffic to its allocated bandwidth to ensure that nonpriority traffic, such as routing packets and other data, is not starved.

With metering, the classes are policed and rate-limited individually. That is, although a single policy map might contain four priority classes, all of which are enqueued in a single priority queue, they are each treated as separate flows with separate bandwidth allocations and constraints.

Note It is important to note that because bandwidth for the priority class is specified as a parameter to the priority command, you cannot also configure the bandwidth command for a priority class. To do so is a configuration violation that would only introduce confusion in relation to the amount of bandwidth to allocate.

Keep these guidelines in mind when using the priority command:

■ You account for Layer 2 encapsulations in the amount of bandwidth that you specify with the priority command. However, ensure that you configure a bandwidth with room for the cell-tax overhead.

■ Use the priority command for Voice over IP (VoIP) on serial links and ATM permanent virtual circuits (PVCs).

Example: Calculating LLQ Bandwidth Required for VoIP

The bandwidth consumed by VoIP streams is calculated by adding the packet payload and all the headers, then multiplying that total number by the per-second packet rate.

The example shows how to calculate the VoIP bearer bandwidth requirement for a single VoIP call using a G.711 codec:

G.711 = 160 bytes payload size

Packet size = payload size + IP/UDP/RTP headers

= 160 bytes + 20 bytes + 8 bytes + 12 bytes = 200 bytes

Sampling Rate = 20 msec per sample = 50 samples per second

Bandwidth (bytes/sec) without Layer 2 overhead = 200 bytes/packet x 50 packets/second = 10000 bytes/second

Bandwidth (bits/sec) without Layer 2 overhead = 10000 bytes/second * 8 bits/byte = 80000 bits/second (80 kbps)

Bandwidth (bits/sec) with Layer 2 overhead

= 80000 bits/second + L2 overhead bytes/second

The figure shows a configuration example in which the VoIP traffic class, classified by the IP Precedence of 5, is queued in a LLQ within the CBWFQ system. The VoIP class receives guaranteed priority scheduling over the other classes but is limited to 10 percent of the bandwidth.


show policy-map interface interface

• Displays the packet statistics of all classes that are configured for all service policies either on the specified interface or subinterface router>show policy-map interface fastethernet 0/0 FastEthernet0/0

Service-policy output: LLQ

Class-map: LLQ (match-any) 0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: any

Weighted Fair Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 1000 (kbps) Burst 25000 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0

Class-map: class-default (match-any) 0 packets, 0 bytes

5 minute offered rate 0 bps, drop rate 0 bps Match: any

The show policy-map interface command displays the packet statistics of all classes that are configured for all service policies on the specified interface. Some of the key fields in the command output are described as follows:


Descri ption


Class of traffic being displayed. Output is displayed for each configured class in the policy.

offered rate

Rate, in kbps, of packets coming in to the class.

drop rate

Rate, in kbps, at which packets are dropped from the class. The drop rate is calculated by subtracting the number of successfully transmitted packets from the offered rate.


Match criteria specified for the class of traffic.

pkts matched/bytes matched

Number of packets (also shown in bytes) matching this class that were placed in the queue.

depth/total drops/no-buffer drops

Number of packets discarded for this class. No-buffer indicates that no memory buffer exists to service the packet.

Was this article helpful?

0 0

Post a comment