- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2020 03:49 AM
Hello everyone,
a colleague of mine ask me to transfer their old configuration to a new device.
However, I'm having trouble understanding the QoS/VoiP configuration that has been implemented by an external contractor.
This is the old configuration.
#Device
Catalyst 3750
OS: 15.0
#Global
mls qos srr-queue output dscp-map queue 2 threshold 1 34
mls qos srr-queue output dscp-map queue 4 threshold 1 0 1 2 3 4
mls qos
#Interface
srr-queue bandwidth share 1 1 3 95
srr-queue bandwidth shape 0 0 0 0
mls qos trust dscp
I don't get the values for the bandwidth share. Wouldn't the current settings mean, that queue 4 get's 95% of the bandwidth, if there is a congestion? This seems counter intuitive to me. After all it's the queue with the least important traffic. (Assuming that DSCP 46 is in queue 1 by default.)
Could somebody enlighten me?
Kind regards
Salocin
Solved! Go to Solution.
- Labels:
-
Catalyst 3000
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2020 08:47 AM
One schools provides the more bandwidth to more important traffic, insuring that traffic doesn't lack for bandwidth.
The second school presumes if more important is only allocated the bandwidth it needs, so less important traffic might have a much larger allocation, to reflect the bandwidth not needed by the more important traffic. (What you have is likely the second school approach.)
Of course, much also depends on your SLA needs and the capability of the equipment. With the good QoS features, you can sort of merge both schools (but often not on switches which have weaker QoS features).
For example, you might have something like (on a router):
policy-map Sample
class Important
bandwidth percent 99
fair-queue
shape average percent 10
class Not_Important
bandwidth percent 1
In the above, the Important class has the bulk of the bandwidth allocation, also insuring a high priority for dequeuing, but it's also limited to only using 10% of the bandwidth. I.e. some misbehaving application won't "starve" the Not_Important traffic (and further, the FQ in the class will keep one or perhaps a few such "bad" flows" from "starving" other flows in that class.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-28-2020 08:47 AM
One schools provides the more bandwidth to more important traffic, insuring that traffic doesn't lack for bandwidth.
The second school presumes if more important is only allocated the bandwidth it needs, so less important traffic might have a much larger allocation, to reflect the bandwidth not needed by the more important traffic. (What you have is likely the second school approach.)
Of course, much also depends on your SLA needs and the capability of the equipment. With the good QoS features, you can sort of merge both schools (but often not on switches which have weaker QoS features).
For example, you might have something like (on a router):
policy-map Sample
class Important
bandwidth percent 99
fair-queue
shape average percent 10
class Not_Important
bandwidth percent 1
In the above, the Important class has the bulk of the bandwidth allocation, also insuring a high priority for dequeuing, but it's also limited to only using 10% of the bandwidth. I.e. some misbehaving application won't "starve" the Not_Important traffic (and further, the FQ in the class will keep one or perhaps a few such "bad" flows" from "starving" other flows in that class.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-29-2020 04:12 AM
Thank you for the detailed answer.
I think I will take a closer look at the merged approach and try to implement it, if possible.
Have a nice weekend
Salocin
