QoS - nested policies and shaping

[Thomas Schmitt]

Hello,

I know, there are thousands discussion about nested QoS policies and shaping, but still I didn't found an answer for my question. Please explain again how it works (in this example it is 6880)

So I have simple nested policy:

policy-map type lan-queuing CHILD
  class VOICE-AUDIO
    priority
 class CONTROL
    bandwidth remaining percent 10
  class class-default
    random-detect dscp-based

policy-map type lan-queuing SHAPER-100M
  class class-default
    shape average 100000000
   service-policy CHILD

I'm using transmit queue type = 1p7q4t and have regular DSCP to queue and threshold-number mapping, WRED  and so on, just like without shaper. There are no questions so far.

But what happens by congestion in case of a configured shaper? -All 8 queues send their traffic to the shaper, the shaper is applied to 10Gig interface and has huge amount of buffers, so i could observe delays from few seconds.

Do I understand it right, that packets from priority queue just wait in shaper buffer together with packets of class CONTROL and class-default, for seconds in case of congestion? Take a look on this picture, what happens to the second LLQ packet?

Thank you in advance

[Joseph W. Doherty]

Ah, you're gone down the "rabbit hole" of how an instance of Cisco's QoS works.

In my experience, it's very difficult to find Cisco documentation, or for Cisco to tell you, how any particular instance of QoS actually works.

Logically, a shaper should push over rate packets into the defined CBWFQ queues, and release them based on the expected dequeuing between the class queues.

For example, in your diagram, if you had those four packets queued, I would expect the two LLQ packets to be dequeued first. However, it's certainly possible (and I suspect its likely) the shaper defines its own queues, separate from the CBWFQ queues. (Much like an interface often has its own tx-ring FIFO queue.)

If it does, it would be difficult to predict, again without specific technical information from Cisco, what will happen. That said, if you actually see a second LLQ packet delayed by 3 seconds, it's time to complain to TAC, as I would consider it a bug.