3750 QoS Questions

[Mark Bowyer]

  I have got a couple of questions.  If you do not have a CoS or Dscp marking specified in your maps, do they automatically get re-marked as 0?

Also, is it necessary for the egress side of things to do shaping or sharing or both? or is it only necessary when you see output drops?

My config is below, I have made multiple changes to the buffers and thresholds. I am giving voice, video and signaling priority, can anyone see anything wrong with it?

mls qos

mls qos map cos-dscp 0 8 16 26 32 46 48 56

mls qos srr-queue input bandwidth 85 15

mls qos srr-queue input threshold 1 8 16

mls qos srr-queue input threshold 2 50 85

mls qos srr-queue input buffers 67 33

mls qos srr-queue input cos-map queue 1 threshold 2  0 1

mls qos srr-queue input cos-map queue 2 threshold 2  2 4 6 7

mls qos srr-queue input cos-map queue 2 threshold 3  3 5

mls qos srr-queue input dscp-map queue 1 threshold 2  0

mls qos srr-queue input dscp-map queue 2 threshold 3  24 26 34 46

mls qos srr-queue output cos-map queue 1 threshold 3  3 5 6 7

mls qos srr-queue output cos-map queue 3 threshold 3  2 4

mls qos srr-queue output cos-map queue 4 threshold 2  0 1

mls qos srr-queue output dscp-map queue 1 threshold 3  24 26 34 46

mls qos srr-queue output dscp-map queue 4 threshold 2  0

mls qos queue-set output 1 threshold 1 20 85 100 138

mls qos queue-set output 1 threshold 2 138 138 92 400

mls qos queue-set output 1 threshold 3 36 77 100 318

mls qos queue-set output 1 threshold 4 20 85 100 400

mls qos queue-set output 2 threshold 1 149 149 100 149

mls qos queue-set output 2 threshold 2 118 118 100 235

mls qos queue-set output 2 threshold 3 41 68 100 272

mls qos queue-set output 2 threshold 4 42 72 100 242

mls qos queue-set output 1 buffers 10 1 1 88

mls qos queue-set output 2 buffers 18 1 1 80

class-map match-any voice

match ip dscp 46

class-map match-any video

match ip dscp 34

class-map match-any control

match ip dscp 24

class-map match-any control-VoIP

match ip dscp 26

policy-map vvc-map

class voice

trust dscp

class video

trust dscp

class control

trust dscp

class control-VoIP

trust dscp

******Interface Config*********

service-policy input vvc-map

priority-queue out

I have done multiple tests of the config, with varying results. On some video conferencing units that we have got, it reports that video and audio packets are being lost, but the counters are incrementing continuously, so could this just be put down to bursty traffic?

[Mark Bowyer]

I have fixed the packet loss issue by increasing the egress buffer size for queue 1, but if anybody can answer the other questions?

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

If you do not have a CoS or Dscp marking specified in your maps, do they automatically get re-marked as 0?

Depends upon ingress processing.  If QoS is enabled, marking will be reset by default (on many Cisco switches) unless you trust on the ingress interface (or have an ingress service policy).

Also, is it necessary for the egress side of things to do shaping or sharing or both? or is it only necessary when you see output drops?

What's "necessary" for egress, depends on what you're trying to accomplish.  (BTW, I very seldom shape, except for downstream bandwidth availability [when less than interface].)

Whether drops requires shaping or sharing, also depends on what you're trying to accomplish and the impact of those drops.  Drops aren't always bad as no drops might not always be good.

My config is below, I have made multiple changes to the buffers and thresholds. I am giving voice, video and signaling priority, can anyone see anything wrong with it?

Without knowing a lot more, can't really say.

I have done multiple tests of the config, with varying results. On some video conferencing units that we have got, it reports that video and audio packets are being lost, but the counters are incrementing continuously, so could this just be put down to bursty traffic?

For most real-time traffic, often the goal is to avoid drops and excessive latency.  Drops might be indicative of insufficient bandwidth, but if transient, might be caused by insufficient buffer resources (which seems to be the case from your 2nd posting).

[Mark Bowyer]

When you say drops arent always bad, what do you mean? Also, in what situations would you use sharing on egress?

Sent from Cisco Technical Support iPad App

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Drop aren't always bad because TCP can use them to manage its flow rate.

I use sharing on egress to control bandwidth proportions between different traffic.  For example, if I have some background data flow, like a server backup, I might have it share bandwidth with "normal" traffic, but give the latter a much larger bandwidth guarantee.

Specifically on a 3750, I might enable PQ for RT traffic, and set the 3 remaining queues to share bandwidth 1:9:81.  The lowest for background and the highest for really critical.  Most traffic would normally map into the middle bandwidth allocation, but as sharing doesn't limit a queue's bandwidth, if there's bandwidth available, you might see the the queues using bandwidth in reverse proportions to their bandwidth allocations.

[Mark Bowyer]

Thanks for all the good info. In our environment, I think its mainly at the edge of the network where we would use shaping, where the upstream bandwidth is less than the edge port bandwidth. Do you do shaping on every port? and which types of traffic? Do you just do shaping on your priority queues that your realtime traffic is using or do you limit all of the other queues too?

I have seen in some examples from Kevin Wallace, where he uses shaping and sharing on the same interface, but just uses shaping on 2 of the queues and sharing on the other 2.

Also, you have abviously got your edge ports and your outgoing interface for your WAN, would youuse the same shaping and sharing on your edge ports and your WAN port?

[Mark Bowyer]

Also, when you apply QoS in your network, in what stages do you deploy it? Do you have a base config with all of the maps/thresholds, class maps and policy maps which you deploy and then once that is applied and QoS is turned on, do you then go and tweak the buffers depending on if you see any packet loss?

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

How I prefer to deploy QoS is where it's most needed first.  I also try to use the minimal amount of QoS that does what's needed.

For example, on many LANs, there's often not much need for QoS as often whatever congestion there is, it's not adverse to the service needs of the traffic.  (In cases where LAN congestion is an issue, often bandwidth can be added to remediate.)

On many WANs, generally due to reduced bandwidth, congestion is quite common and QoS can be very beneficial.  If the device supports FQ or WFQ, often that alone will meet 90+% of QoS needs.  In the cases where FQ or WFQ aren't enough, I'll provide a custom QoS policy.

And yes, if there's packet loss, I may tweak buffers and/or queue depths and/or the dropping policy.  Goal being to obtain optimal "goodput".

[Joseph W. Doherty · Accepted solution]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Normally I only shape when I want to create artificial congestion, to mimic "downstream" bandwidth, where I'm unable to provide the QoS I desire at that downstream bottleneck.

For example, if I have a 100 Mbps LAN feeding to a 1.5 Mbps I'll "worry" about the 1.5 Mbps QoS at the physical 1.5 Mbps interface.  However, if I'm unable to do that, I'll shape (if possible) the 100 Mbps (at 1.5 Mbps) sending to the 1.5 Mbps path and manage QoS there.

When I shape, I shape for the capacity of the path (again where I'm unable to apply QoS at the bottlneck).  Often I'll apply traffic prioritzation to the shaped traffic (basically the same prioritization I would apply at the physical bottleneck).

[Mark Bowyer]

I have dropped you a PM.