IP to ATM Class of Service (CoS) describes a set of features for coarse-grained mapping of Quality of Service (QoS) characteristics between IP and ATM. In some cases, these features are implemented differently on 7500 series platforms with distributed QoS than all other platforms, which includes the 7200 series and the 2600 and 3600 series.
One difference is the amount of bandwidth which cannot be allocated with a bandwidth statement for class-based weighted fair queueing (CBWFQ) or a priority statement for low latency queueing (LLQ) and which needs to be available for all other traffic. This document describes the implementation differences and how platforms other than the 7500 series routers use the max-reserved-bandwidth command in order to adjust the amount of bandwidth that must be left over.
There are no specific requirements for this document.
This document is not restricted to specific software and hardware versions.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
When you configure QoS service policies in order to support voice and video, you need to ensure that adequate bandwidth exists for all required applications. Add up the minimum bandwidth requirements for each major application, such as the voice media streams, video streams, voice control protocols, and all data traffic in order to start your configuration. This sum represents the minimum bandwidth requirement for any given link and should consume no more than 75 percent of the total bandwidth available on that link. This 75 percent rule leaves bandwidth for two types of overhead traffic:
Routing protocol updates and Layer 2 keepalives
Additional applications such as e-mail, HTTP traffic, and other data traffic that is not easily measured
In addition, the 75 percent rule reserves bandwidth for two sets of Layer 2 overhead:
Layer 2 overhead in traffic classes that you define. On ATM Permanent Virtual Circuits (PVCs), the bandwidth parameter specified in the bandwidth and priority commands do not count or include the padding in order to make the last cell an even multiple of 48 bytes or the five bytes of each cell header. Refer to What Bytes Are Counted by IP to ATM CoS Queueing?
Layer 2 overhead of packets that match to the class-default class in a QoS service policy
This illustration shows how routing updates and other bytes fill the capacity of your link.
The 75 percent rule is documented in the Congestion Management Overview chapter of the Cisco IOS® Quality of Service Solutions Configuration Guide. It is important to understand that this rule applies only to platforms other than the 7500 series with distributed QoS.
The bandwidth and priority commands support a bandwidth parameter specified in kbps or as a percent. The sum of the specified bandwidth parameters cannot exceed 75 percent of the available bandwidth. ATM PVCs use this definition of available bandwidth based on the ATM service category:
ATM Service Category | Available Bandwidth Definition |
---|---|
VBR-rt | Output sustained cell rate (SCR) |
VBR-nrt | Output sustained cell rate (SCR) |
ABR | Output minimum cell rate (MCR) |
UBR | N/A. UBR VCs do not support minimum bandwidth guarantees with either the bandwidth or the priority command. |
The 25 percent of bandwidth that remains is used for overhead. This includes Layer 2 overhead, routing traffic, and best-effort traffic.
If your particular traffic conditions and service policies can support to reserve more than 75 percent of the available bandwidth, you can override the 75 percent rule with the max-reserved-bandwidth command. Cisco IOS Software Releases 12.2(6)S, 12.2(6)T, 12.2(4)T2 and 12.2(3) introduce support for the max-reserved-bandwidth command on ATM PVCs on platforms other than the 7500 series. Refer to Cisco bug ID CSCdv06837 (registered customers only) .
By default, 75 percent of the interface bandwidth can be used for fancy queueing. If this percentage needs to be changed, the max-reserved-bandwidth command can be used in order to specify the amount of bandwidth that is allocated to fancy queueing. The max-reserved-bandwidth command can be applied on ATM physical interfaces but this does not have any effect on the available bandwidth output of the interface. This example shows how to configure the max-reserved-bandwidth command under the ATM physical interface
Rtr(config)#policy-map test class multimedia priority 128
Rtr(config)#interface atm 1/0 Rtr(config-if)#max-reserved-bandwidth 90 Rtr(config-if)#service-policy output test
Rtr#show queueing interface atm 1/0 Interface ATM1/0 Queueing strategy: weighted fair Output queue: 0/512/100/0 (size/max total/threshold/drops) Conversations 0/1/64 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 1034 kilobits/sec ...
The available bandwidth should be 1267 kilobits/sec as per the formula Available Bandwidth = (max reserved bandwidth * interface bandwidth) - (sum of priority classes) but the ouput is 1034 kilobits/sec. This means that max-reserved-bandwidth is still the 75 percent of the interface bandwidth (default percentage). It shows that the max-reserved-bandwidth command configured under the physical atm interface mode does not have any effect in the calculation of the available bandwidth.
The max-reserved-bandwidth command can also be configured under PVC. This example shows the configuration of the max-reserved-bandwidth command under PVC.
Rtr(config)#policy-map test class multimedia priority 128
Rtr(config)#interface atm 1/0 Rtr(config-if)#pvc 1/41 Rtr(config-if-atm-vc)#max-reserved-bandwidth 90 Rtr(config-if-atm-vc)# service-policy output test
Rtr#show queueing interface atm 1/0 Interface ATM1/0 VC 1/41 Queueing strategy: weighted fair Output queue: 0/512/100/0 (size/max total/threshold/drops) Conversations 0/1/64 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 1267 kilobits/sec ...
The available bandwidth is 1267 kilobits/sec as per the formula Available Bandwidth = (max reserved bandwidth * interface bandwidth) - (sum of priority classes). This means that the max-reserved-bandwidth command is 90 percent of the interface bandwidth which is configured under the PVC.
Note: The max-reserved-bandwidth command works only when configured under the PVC. It can also be configured under the ATM interface but the available bandwidth does not change as per the formula.
The formula in order to calculate the available bandwidth is:
Available Bandwidth = (max reserved bandwidth * interface bandwidth) - (sum of priority classes)
Note: The available bandwidth for fancy queueing is calculated based on the interface bandwidth like it is configured with the bandwidth [value in kilobits] interface configuration command, except when the service-policy is applied on a frame-relay PVC or an ATM PVC.
How this command affects bandwidth allocations varies slightly with the Cisco IOS Software release and platforms.
In Cisco IOS Software Releases 12.1T and 12.2, the percentages that you define in your classes are a percentage of the available bandwidth, rather than the full interface or VC bandwidth.
This output is an example that uses a T1 physical link. This policy-map is configured:
policy-map test122 class multimedia priority 128 class www bandwidth percent 30
This policy-map is applied on output on interface serial0:
Router#show policy interface serial0 Serial0 Service-policy output: test122 Class-map: multimedia (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0bps Match: access-group 101 Weighted Fair Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 128 (kbps) Burst 3200 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: www (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0bps Match: access-group 102 Weighted Fair Queueing Output Queue: Conversation 265 Bandwidth 30 (%) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0
The show interface command allows you to view the available bandwidth:
Router#show interface serial 0 Serial0 is up, line protocol is up Internet address is 1.1.1.1/30 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, ... Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/0/256 (active/max active/max total) Reserved Conversations 1/1 (allocated/max allocated) Available Bandwidth 1030 kilobits/sec ...
The available bandwidth is calculated as:
Available Bandwidth = (max reserved bandwidth * interface bandwidth) - (sum of priority classes)
When you fill in the numbers of this example, you get 1030 Kbit = (75% * 1544 Kbit) - 128 Kbit.
The bandwidth percent gets a percentage of the Available Bandwidth as calculated here. In this case it gets 30 percent from 1030 Kbit, being 309 Kbit. The output of the show policy interface command also provides a reference to a percentage rather than to an absolute value.
Note: In Cisco IOS Software Releases 12.1T and 12.2, the semantics of bandwidth percent are inconsistent among 7200 and earlier and the 7500 platform. In the 7200, the bandwidth percent is a relative percent number to the available bandwidth that remains and in the 7500, it is an absolute percent number in reference to the interface bandwidth.
Note: In Cisco IOS Software Releases 12.1T and 12.2, it is not possible to mix classes with bandwidth and classes with bandwidth percent in the same policy-map.
In Cisco IOS Software Releases 12.2T and 12.3, the bandwidth percent command is consistent among 7500 and 7200 and earlier. This means that now, the bandwidth percent command no longer refers to a percentage of the Available Bandwidth, but to a percentage of the interface bandwidth. A class with a bandwidth percent command in a policy-map now has a fix calculated amount of bandwidth allocated to it. The sum of all the bandwidth or bandwidth percent, priority and priority percent classes together has to respect the max reserved bandwidth rule.
The functionality of bandwidth percent as it is understood in Cisco IOS Software Releases 12.1T and 12.2 for the Cisco 7200 and earlier platforms is preserved in Cisco IOS Software Releases 12.2T and 12.3 with the introduction of the new command bandwidth remaining percent.
You can read more about these changes from Low Latency Queueing with Priority Percentage Support.
This is an example:
policy-map test123 class multimedia priority 128 class www bandwidth percent 20 class audiovideo priority percent 10
In the show policy interface output, calculated bandwidths are derived from a percentage of the interface bandwidth:
Router#show policy-map interface serial 0/0 Serial0/0 Service-policy output: test123 Class-map: multimedia (match-all) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: access-group 101 Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 128 (kbps) Burst 3200 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 Class-map: www (match-all) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: access-group 102 Queueing Output Queue: Conversation 265 Bandwidth 20 (%) ! 20% of 1544Kbit is rounded to 308Kbit Bandwidth 308 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 Class-map: audiovideo (match-all) 0 packets, 0 bytes 30 second offered rate 0 bps, drop rate 0 bps Match: access-group name AudioVideo Queueing Strict Priority Output Queue: Conversation 264 Bandwidth 10 (%) ! 10% of 1544Kbit is rounded to 154Kbit Bandwidth 154 (kbps) Burst 3850 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0
Note: For the bandwidth commands, it is not possible to mix classes with different units (bandwidth, bandwidth percent, bandwidth remaining percent) in the same policy map. You receive an error message like this:
Router(config-pmap-c)#bandwidth remaining percent 50 All classes with bandwidth should have consistent units
Admission of Resource Reservation Protocol (RSVP) flow is bounded by the ip rsvp bandwidth command that uses the maximum reserveable bandwidth, which is a function of the available WFQ bandwidth. Thus, the use of the max-reserved-bandwidth command in order to configure a value higher than the historic default of 75 percent makes more bandwidth available to RSVP. But the RSVP configuration still limits you to 75 percent for RSVP calls. As a workaround, use the bandwidth command in order to increase the interface bandwidth, apply the max-reserved-bandwidth command, and then reapply or reconfigure the ip RSVP bandwidth command. In other words, artificially inflate the interface bandwidth as seen by the Cisco IOS software processes.
Note: The drawbacks of this workaround include miscalculation of routing metrics and of SNMP-calculated link utilization values.
The max-reserved-bandwidth command has no effect on distributed, versatile interface processor (VIP)-based QoS features like distributed Class-Based Weighted Fair queueing (CBWFQ) and WFQ, except when Route Switch Processor (RSP)-based CBWFQ was previously supported. You can allocate up to 99 percent of your available bandwidth to the configured classes. The class-default needs only a one percent minimum. This is true for Cisco IOS Software Releases 12.0S, 12.1E, and 12.2 mainline releases.
The different default maximum reserveable bandwidth values on 7500 series and non-7500 series routers were chosen initially for backward compatibility with features that exist. The defaults are not specifically imposed by the Modular QoS CLI (MQC).
The difference is related to the handling of class-default itself.
On the 7500 series, class-default is given at least one percent bandwidth not specifically reserved in the configuration. The class-default flows compete as a class with other configured classes for access to the scheduler.
On the 7200 series, when configured with the fair-queue command, the class-default does not exist as such in terms of global scheduling. Instead, each of the flows from the class-default competes with other configured classes, as illustrated here.
Thus, you can limit the bandwidth of class-default on the 7500 to one percent because all flows are handled as a single class. On other platforms, you need to determine the amount of bandwidth used by all the individual flows.
Each flow in both the class-default and configured classes is assigned a weight, which in turn determines the bandwidth. You can calculate the equivalent weight which would correspond to all flows and compare that to the weight of other classes. In a worse-case scenario, you could exceed 25 percent of the bandwidth if you configure a high amount of precedence-7 flows in the class-default. For example:
weight = 32k/(1+prec) ==> 4k for flow prec 7
If you have 256 separate and distinguished hashed flows of this type, it gives a combined weight of 4 k/256 = 16. These 256 flows take an equivalent bandwidth that corresponds to class of weight 16. This example illustrates that you cannot limit the bandwidth used to one percent. The bandwidth can be in reality one percent, ten percent, 20 percent or even 30 percent in exceptional circumstances. In reality, bandwidth is typically very limited. Flows with a weight of 32 k are given limited bandwidth when there is congestion.
Refer to Measuring the Utilization of ATM PVCs for guidelines on how to estimate VC utilization and packet size.