QOS - the need for it and verifying it

[SJ K]

Hi all,

Just some very straight forward questions,  hope gurus here can shed some light

1) show int - output queue -> this is the hardware queue (tx-ring)  or this is the software queue ?

if I see drop, this means it is definitely congested ?

2) QOS classification -> using MCQ, it is said that we can classify at inbound and queue at outbound. But it seems to me, no matter what, classification is still needed when defining and egress policy. 

e.g.

( service-policy test
 class test-class  <---  isn't this already some-how a classification ?
)

So why bother to class at ingress ?

3) Just a silly question - Is there anyway we can "determine"  if a particular traffic is ingressing from a LLQ/PQ of its uplink ?
I think my MPLS provider is not sending my voice traffic to me on its' router's priority queue.  Anyway to verify that ?  or the only way is to ask the provider to show me its policy-map ?

Regards,

Noob

[Joseph W. Doherty · Accepted solution]

#1 "show int - output queue -> this is the hardware queue (tx-ring) or this is the software queue ?"
Probably the software queue. Platforms can differ.

"if I see drop, this means it is definitely congested ?"

Depends how you define congestion. All it really tells you is the queue overflowed.

Personally, I define congestion anytime you need to queue. I.e. anytime you cannot transmit immediately. However, such congestion doesn't mean it's automatically detrimental to your applications.

#2 Classification might be done at ingress. (I.e. I received a VoIP packet.)
Classification is often used at egress. (I.e. dequeue VoIP and/or ToS DSCP EF packets first.)
Do you see the difference?

#3 Actually not a silly question. Hmm, I don't think you can really figure that out at 100% assurance. However, you could probably tell QoS isn't being done somewhere upstream. For example, VoIP jitter would generally be due to somewhere upstream VoIP is not being provided priority over other traffic.

I don't think your provider just showing you their policy-map would answer your question. You would need to see more, possible much more. You would need to see all QoS related configuration and operational stats for all provider devices your traffic transits.

It's also possible your MPLS provider isn't doing QoS "right". They too are human, and make mistakes, both operationally and sometimes in concept. For instance, even if they have the "optimal" QoS service policies applied, does their QoS architecture account for things like interface tx-ring FIFO buffers?

[SJ K]

Hi Joseph,
Thanks for your reply!

#2 Classification might be done at ingress. (I.e. I received a VoIP packet.)
Classification is often used at egress. (I.e. dequeue VoIP and/or ToS DSCP EF packets first.)
Do you see the difference?

Sorry,  could you elaborate further ?

Since classification is always needed to dequeue packets accordingly (e.g. expedite queue for voice), then what's the point of classifying during "Ingress" ?

However, in setting up QOS for my 3850, it do seems that packets must already be classified and marked properly during "ingress" , and the classification done during "egress" is just for putting the right class to the right queue .

Is that what you mean ?

P.S.

-- if we have done only the classification during egress, we will get this error -> "
"% Queuing actions supported only with dscp/cos/qos-group/precedence based classification!!!"

Regards,

Noob

[Joseph W. Doherty]

What the issue might be, on your 3850 vs., for example, an ISR, the former's QoS architecture might only expect to use a QoS tag during egress.

If you had a device that can inspect a packet during egress as well as it could for ingress, then there might not be any advantage of doing classification during ingress.

That said, "by the book", (full) packet inspection classification is often done as early as possible, just once. The results of such classification generally reflected in some ToS tag in the frame or packet. In fact, the source might "classify".

The advantage of using tags, for later usage, it generally uses less device resources.

[SJ K]

Hey Joseph,

Thanks for your elaboration !

Just to share with you something interesting (or confusing to me).

I am using MCQ on my 3850 and seems to be CBWFQ is the queuing mechanism in use.

My high-level understanding is that CBWFQ priorities queuing based on bandwidth weights. (so probably a class with higher-bandwidth would have a higher priority - pls correct me if i am wrong ?)

On that, please look at the my policy-map below ->

  Policy Map MPLSPOLICY
    Class VOIPCLASS
      priority level 1 350 (kbps)
    Class HTTP
      bandwidth remaining ratio 50
    Class class-default
      bandwidth remaining ratio 100

I would expect the class-default to have a higher priority then Class HTTP since it has a larger bandwidth ratio allocated .

=========

However, on the below, i am seeing the default-class is using QUEUE2 and the HTTP class is using QUEUE1

show policy-map interface 's "bytes output" is reflecting the same bytes for the respective classes.

show platform qos queue stats gigabitEthernet 1/0/48
DATA Port:26 Enqueue Counters
-------------------------------
Queue Buffers Enqueue-TH0 Enqueue-TH1 Enqueue-TH2
----- ------- ----------- ----------- -----------
    0       0           0           0       17132
    1       0           0           0        1040 << HTTP class
    2       0           0           0      952750 << class-default
    3       0           0           0           0
    4       0           0           0           0
    5       0           0           0           0
    6       0           0           0           0
    7       0           0           0           0

Q1-> Isn't the CLASS-DEFAULT (who has a higher bandwidth supposed to be using a lower queue number (e.g. queue 1) ?
Does lower-queue number = higher priority ?

But again, if you look at the show qos queue config below (on the priority part)

show platform qos queue config gigabitEthernet 1/0/48
DATA Port:26 GPN:48 AFD:Disabled QoSMap:1 HW Queues: 208 - 215
  DrainFast:Disabled PortSoftStart:2 - 612
----------------------------------------------------------
  DTS Hardmax   Softmax  PortSMin GlblSMin  PortStEnd
  --- --------  -------- -------- --------- ---------
 0   1  6   102  8   408  7   272   0     0   2   816
 1   1  4     0  9   396  8   264   3    99   2   816
 2   1  4     0  9   396  8   264   3    99   2   816
 3   1  4     0  5     0  5     0   0     0   2   816
 4   1  4     0  5     0  5     0   0     0   2   816
 5   1  4     0  5     0  5     0   0     0   2   816
 6   1  4     0  5     0  5     0   0     0   2   816
 7   1  4     0  5     0  5     0   0     0   2   816
 Priority   Shaped/shared   weight  shaping_step
 --------   ------------   ------  ------------
 0      1     Shaped         65535          22
 1      7     Shared           100           0  >> weight 100 = default-class
 2      7     Shared            50           0  >> weight 50 = HTTP class
 3      0     Shared         10000           0
 4      0     Shared         10000         144
 5      0     Shared         10000           0
 6      0     Shared         10000         128
 7      0     Shared         10000           0

Both queue 1 and 2 has the same priority (7) and queue1 has a 100 weight

But on the queue stats output shown earlier - queue1 is used by HTTP (weight 50)

So why the discrepancy ?

show platform qos queue stats - showing queue1 is HTTP class (which weight = 50)

show platform qos queue config - showing queue1 is (weight 100 - which is class-default)

Regards,

Noob

[Joseph W. Doherty · Accepted solution]

I've haven't any direct experience with the 3650/3850, so unable to comment on its operations.

Hmm, except for LLQ/PQ it's not so much bandwidth weight set priorities, they set bandwidth dequeuing ratios. Your class-default should be guaranteed twice the bandwidth of your HTTP although the fact your percentages are over 100, make me wonder how it might operate.

"Does lower-queue number = higher priority ?"

Again, being unfamiliar with the 3650/3850, I'm not sure, but I would expect it's just queue number.

As to your different classes using different queues, indeed, that's how CBWFQ often manages classes, and in fact, on switches, those queues are hardware based.

[SJ K]

Hey Joseph,

Thanks for your insights and sorry for the late reply.

Is there anyway we can pro-actively monitor a CBFWQ's class bandwidth usage and packet drop  (via for e.g. SNMP) ?

Search through the doc on QOS but can't find any.. except for a command "netflow sampler" inside policy-map class.

Regards,

Alan

[Joseph W. Doherty]

I believe Cisco does provide those stats in their MIB (but off-hand, I don't have any OIDs I could suggest).