Differnet QoS configs and their outputs

[Patrick McHenry]

Hi,

I have 2 routers with 2 different QoS configs

on the first router the class-map CENTURY-LINK_P4 is defined, but not used in the PRIORITIZE policy-map.

on the second router the class-map CENTURY-LINK_P4 is defined and used in the PRIORITIZE policy-map.

On the the first router, the "show policy-map interface" output of the Class-map: class-default is showing drops (which I believe is somewhat normal as this is dropping scavenger (0 1) traffic first when there is contention.

On the second router, the "show policy-map interface" output of the Class-map: CENTURY-LINK_P4 is showing drops and the Class-map: class-default is not showing any drops...although it looks like a couple of packets have been getting through

Is the second router recognizing that there are 2 class-maps with the same IPP mapping and using the CENTURY-LINK_P4 first as it is listed in the PRIORITIZE policy-map?

Could this be causing any issues?

What is the better config?

Thank you

First router config:

class-map match-any CENTURY-LINK_P1
  description REAL-TIME VOICE
 match precedence 5
class-map match-any CENTURY-LINK_P2
  description STREAMING VIDEO
 match precedence 4  6  7
class-map match-any CENTURY-LINK_P3
  description CALL SIGNALLING
 match precedence 2  3
class-map match-any CENTURY-LINK_P4
  description SCAVENGER
 match precedence 0  1
!
policy-map PRIORITIZE
 class CENTURY-LINK_P1
  priority 600
 class CENTURY-LINK_P2
  bandwidth 1500
 class CENTURY-LINK_P3
  bandwidth 40
 class class-default
  fair-queue
policy-map OUTBOUND
 class class-default
  shape average 20000000
   service-policy PRIORITIZE
!

First router show output:

Service-policy output: OUTBOUND

    Class-map: class-default (match-any)
      1004718767 packets, 300283823548 bytes
      5 minute offered rate 603000 bps, drop rate 0000 bps
      Match: any
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/3796769/0
      (pkts output/bytes output) 1003952816/300969035300
      shape (average) cir 20000000, bc 80000, be 80000
      target shape rate 20000000

      Service-policy : PRIORITIZE

        queue stats for all priority classes:
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 825834/61120516

        Class-map: CENTURY-LINK_P1 (match-any)
          825834 packets, 61120516 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match:  precedence 5
            825834 packets, 61120516 bytes
            5 minute rate 0 bps
          Priority: 600 kbps, burst bytes 15000, b/w exceed drops: 0


        Class-map: CENTURY-LINK_P2 (match-any)
          1964215 packets, 315964520 bytes
          5 minute offered rate 3000 bps, drop rate 0000 bps
          Match:  precedence 4  6  7
            1964215 packets, 315964520 bytes
            5 minute rate 3000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 1964215/315964520
          bandwidth 1500 kbps

        Class-map: CENTURY-LINK_P3 (match-any)
          8360028 packets, 548243302 bytes
          5 minute offered rate 1000 bps, drop rate 0000 bps
          Match:  precedence 2  3
            8360028 packets, 548243302 bytes
            5 minute rate 1000 bps
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 8360028/548243302
          bandwidth 40 kbps

        Class-map: class-default (match-any)
          993568687 packets, 299358495998 bytes
          5 minute offered rate 598000 bps, drop rate 0000 bps
          Match: any
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops/flowdrops) 0/3796769/0/379
          (pkts output/bytes output) 992802738/300043706882
          Fair-queue: per-flow queue limit 16 packets

Second router config:

class-map match-any CENTURY-LINK_P1
  description REAL-TIME VOICE
 match precedence 5
class-map match-any CENTURY-LINK_P2
  description STREAMING VIDEO
 match precedence 4  6  7
class-map match-any CENTURY-LINK_P3
  description CALL SIGNALLING
 match precedence 2  3
class-map match-any CENTURY-LINK_P4
  description SCAVENGER
 match precedence 0  1
!
policy-map PRIORITIZE
 class CENTURY-LINK_P1
  priority percent 20
 class CENTURY-LINK_P2
  bandwidth percent 20
 class CENTURY-LINK_P3
  bandwidth percent 20
 class CENTURY-LINK_P4
  bandwidth percent 40
policy-map OUTBOUND
 class class-default
  shape average 20000000
   service-policy PRIORITIZE
!

Second router show output:

Service-policy output: OUTBOUND

    Class-map: class-default (match-any)
      252363025 packets, 220164974032 bytes
      5 minute offered rate 694000 bps, drop rate 0000 bps
      Match: any
      Queueing
      queue limit 83 packets
      (queue depth/total drops/no-buffer drops) 0/110314/0
      (pkts output/bytes output) 252252711/220021542823
      shape (average) cir 20000000, bc 80000, be 80000
      target shape rate 20000000

      Service-policy : PRIORITIZE

        queue stats for all priority classes:
          Queueing
          queue limit 512 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: CENTURY-LINK_P1 (match-any)
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match:  precedence 5
          Priority: 20% (4000 kbps), burst bytes


        Class-map: CENTURY-LINK_P2 (match-any)
          225069 packets, 17367078 bytes
          5 minute offered rate 1000 bps, drop ra
          Match:  precedence 4  6  7
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drop
          (pkts output/bytes output) 225069/17367
          bandwidth 20% (4000 kbps)

        Class-map: CENTURY-LINK_P3 (match-any)
          163 packets, 28954 bytes
          5 minute offered rate 0000 bps, drop ra
          Match:  precedence 2  3
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drop
          (pkts output/bytes output) 163/28954
          bandwidth 20% (4000 kbps)

        Class-map: CENTURY-LINK_P4 (match-any)
          252137748 packets, 220147575300 bytes
          5 minute offered rate 694000 bps, drop
          Match:  precedence 0  1
          Queueing
          queue limit 64 packets
          (queue depth/total drops/no-buffer drop
          (pkts output/bytes output) 252027434/22
          bandwidth 40% (8000 kbps)

        Class-map: class-default (match-any)
          45 packets, 2700 bytes
          5 minute offered rate 0000 bps, drop ra
          Match: any

          queue limit 83 packets
          (queue depth/total drops/no-buffer drop
          (pkts output/bytes output) 45/2700

[Joseph W. Doherty]

What's the platform and IOS version?

Do these links on a "cloud" that supports any QoS?

[Patrick McHenry]

The first router is a 2911/K9 running 15.2(4)M6a

The second router is a ISR4331/K9 running 15.5(2)S

The routers connect to an MPLS cloud provider. We have opted for the 4 Queues 20/20/20/40 method. We were told we should match those percentages when creating our queues.

Not sure if that answers your questions....

Thank you

[Joseph W. Doherty]

Not sure if that answers your questions....

It helps.

Is the second router recognizing that there are 2 class-maps with the same IPP mapping and using the CENTURY-LINK_P4 first as it is listed in the PRIORITIZE policy-map?

Could this be causing any issues?

What is the better config?

First understand, different routers often have different traffic flows, so comparing one to another could be like comparing apples to oranges.  Conversely, maybe not too.

I could also say your different policy configurations might be causing issues, but they might not too.

Sorry, but not knowing your traffic, or your QoS policy objectives, cannot say whether another policy would be better.  I will say, your routers with their IOS versions, are about as good as it gets with Cisco equipment.

That said, your default queue limits might be too small for the BDP.

We were told we should match those percentages when creating our queues.

Yes, that's not uncommon, but you don't always have to do that.  You could have a more elaborate QoS policy on your egress to MPLS, while still taking advantage of the MPLS QoS policy.  Depending on your QoS objectives, you might not have an optimal MPLS QoS policy too.

If you only had two routers running across a MPLS cloud, you likely would be better served by not having any MPLS QoS.  If you have more than two routers, and multi-point traffic flows, then MPLS QoS is very helpful.  (If you have more than two routers, but your data flows are hub-and-spoke, again, MPLS QoS might not be beneficial.)

In general, I recommend a policy like:

policy-map Sample
class LLQ
 priority percent 33
class foreground
 bandwidth remaining percent 81
 fair-queue
class background
 bandwidth remaining percent 1
 fair-queue
class class-default
 bandwidth remaining percent 9
 fair-queue

In usage, foreground and background classes should almost be inverse of their bandwidth allocations.  Additionally, most traffic should be in class-default, unless there's a need to treat the traffic differently.  (The "secret" to the above policy, is FQ, which generally keeps a few heavy usage flows from being adverse to other light usage flows.  FQ also tends to drops packets from heavy usage flows first.)

[Patrick McHenry]

Thanks for your response - I think I need to hit the books on QoS...started reading the new End to End Qos book.

QoS is tricky and seems counter-intuitive...

So are you saying it is OK to not match the percentages that our provider has allocated for the 4 queues - 20/20/20/40?

In your example class LLQ is for priority IPP 5, the class foreground is for IPP 4 6 7 and so on..?

Why such a high percentage for Foreground?

Thank you

[Joseph W. Doherty]

QoS is tricky and seems counter-intuitive...

It often seems that way, but I think that has a lot to do with the way it's generally taught/explained.

So are you saying it is OK to not match the percentages that our provider has allocated for the 4 queues - 20/20/20/40?

Yes, although I had more in mind more elaborate QoS.  For example, your actual egress policy could have multiple classes that logically subdivide a MPLS class, although generally the sum of those classes bandwidth would equal the MPLS class bandwidth.

In your example class LLQ is for priority IPP 5, the class foreground is for IPP 4 6 7 and so on..?

Correct.

Why such a high percentage for Foreground?

Because I find QoS is often simpler to deal with if you think of dequeuing ratios rather that bandwidth reservations.

The purpose of Foreground's high bandwidth percentage is to insure it's almost treated like LLQ, relative to class default.  Or to think of it like the old router PQ except it won't totally starve lower classes of bandwidth.  (Likewise, class-default is almost treated like LLQ relative to the Background class.)