Bandwidth vs Bandwidth Remaining

This topic is to discuss the following lesson:

Hi Rene, for BW remaining percentage config, if other classes such AF11, AF21 and AF31 are not in use, then can the Default class take the unused BW from these 3 classes OR will BW remaining percentage for AF11(8 Mbps) , AF21(16 Mbps) or AF31(24 Mbps) will always be reserved for them and cant be used by Default or any other class?

Hello Sandeep

Remember, that these values are referring to bandwidth guarantees that exist during congestion. In other words, this is reserved bandwidth for that particular type of traffic.

Now if there is no AF11, AF21, and AF31 traffic at a particular time, then all other configured traffic types (EF and class-default) will share the full bandwidth of the interface as needed. But such traffic will be served in a best-effort manner, no guaranteed bandwidth is provided beyond what has been configured.

So if you were to examine the results of such a situation in the lab, you would see that any additional bandwidth available would show up under the class-default.

But be aware that this is not guaranteed bandwidth that you are seeing, but best effort.

I hope this has been helpful!

Laz

Remember, when configuring these values (whether percentage or percentage remaining) they define the minimum guaranteed bandwidth

1 Like

Hi,
First at all, thank you with the great work you’re doing with NetworkLessons. After reading this lessons I have one doubt. If I understood it correctly from the “Introduction to Qos” lesson, QoS can only be applied to trunks interfaces or to routed interfaces according to the folowing words from Lazaros in that section’s forum:

“QoS functions at Layer 3 and Layer 2. Layer 3 QoS will operate when routing packets, as the QoS information is found within the header of the IP packet. At layer 2, QoS information is found within the 802.1Q tag, or the VLAN tag. This VLAN tag exists only on frames that traverse trunk ports. Since frames that enter and exit an access port do not have VLAN tags which contain the tagging information, QoS based on markings cannot be implemented at access ports. There is an exception to this rule, which is access ports that are configured with an additional voice VLAN. This is because voice VLAN frames do have a VLAN tag and can be handled differently than other frames”

However, in the current lesson it’s being applied to non-routed non-trunk interfaces. Did I miss something? The interfaces used in this lessons are configured as follow:

interface GigabitEthernet1/0/27
!
interface GigabitEthernet1/0/48
 service-policy output BANDWIDTH-REMAINING

So there is no switchport mode trunk to convert them to trunks nor they have IP addresses making them routed interfaces.

Another question: what’s the difference between the priority command used in the previous lesson and the police rate command used in the previous. Both assign the traffic to a LLQ up to a certain maximum per second, don’t they?

Additionally, I’d like to point out 2 that I’ve detected a minor error: The sum “10 + 20 + 30 = 70 Mbps” is wrong. Those values sum 60, not 70.

Hello José

Yes, I see the confusion. Let me clarify my statement. QoS mechanisms that use DSCP and CoS values to make their decisions require that the DSCP and CoS information exists. For Layer 2 QoS, only tagged frames can participate in QoS because the CoS value exists within the tag. Therefore, only trunk ports (which use tagged frames) can apply Layer 2 QoS policies. For Layer 3 QoS where DSCP values are used, using a policy map as in this lesson, it is possible to queue packets with a particular priority based on the DSCP values found in the IP header. Typically, a Layer 2 port will not be able to “read” information in the Layer 3 header, however, there are switch models with the appropriate IOS that are able to read those Layer 3 DSCP values and queue accordingly.

The priority command in the QoS LLQ lesson is used to define the priority queue within the LLQ scheme. Using that keyword makes all packets that match bypass the CBWFQ scheduler. The police rate command here is simply defining a rate at which to police traffic. However, the important thing here is that it is put under a priority level command. As shown below, the priority level command enables you to configure multiple priority queues. In this case, Rene has only created one, but it is essentially the same as using the priority command in the LLQ lesson.
https://www.cisco.com/c/en/us/td/docs/ios/qos/command/reference/qos_book/qos_n1.html#wp1049085

Yes, thanks for that, I’ll let Rene know to make the correction.

I hope this has been helpful!

Laz

1 Like