QOS Configuration & Bandwidth Guarantee

[eandrcisco007]

Gentlemen,

We have configured priority for Voice/Video as 35% bandwidth guarantee out of 100 % and in fact that was the main reason we put our delay-sensitive traffic on a guarantee queue so that no other traffic supersede VOIP. (Below is the full QOS Policy-map Config.)

policy-map qos_policymap

 class gold_classmap

  priority percent 15

  set ip dscp cs5

 class silver_classmap

  bandwidth remaining percent 49

  set ip dscp af31

 class bronze_classmap

  set ip dscp af21

  bandwidth remaining percent 35

 class gold_classmap_phones

  priority percent 20

  set ip dscp ef

 class QOS-CRITICAL-DATA-CLASS

  set dscp cs3

  bandwidth remaining percent 15

 class class-default

  set ip dscp af11

Having said that, we have congested the line and consequently the entire voice calls went down and we end up re-starting the router to bring it all back up to normal!! (Not a pleasant experience at all)

I have checked the VOIP traffic and apparently they marked correctly but I am not sure why configured QOS did not allocate 35% bandwidth strictly for VOIP as priority , and why the VOIP traffic didn’t get protected as intended according to their classifications!!

Attach is the show policy-map int…. result, and as you could see we have traffic marked as gold and packets are matching based on their classes.

Class-map: gold_classmap (match-any)

      202979 packets, 16577412 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: access-group name gold01_acl

        202979 packets, 16577412 bytes

        30 second rate 0 bps

      Priority: 15% (691 kbps), burst bytes 17250, b/w exceed drops: 0

      QoS Set

        dscp cs5

          Packets marked 202979

    Class-map: silver_classmap (match-any)

      9445 packets, 2379650 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: access-group name silver01_acl

        9445 packets, 2379650 bytes

        30 second rate 0 bps

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 9445/2379650

      bandwidth remaining 49% (1468 kbps)

      QoS Set

        dscp af31

          Packets marked 9445

    Class-map: bronze_classmap (match-any)

      23731 packets, 8393892 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: access-group name bronze01_acl

        23731 packets, 8393892 bytes

        30 second rate 0 bps

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 23731/8393922

      QoS Set

        dscp af21

          Packets marked 23731

      bandwidth remaining 35% (1048 kbps)

    Class-map: gold_classmap_phones (match-any)

      8903292 packets, 1092829561 bytes

      30 second offered rate 6000 bps, drop rate 0 bps

      Match: access-group name gold01_acl_phone

        8903292 packets, 1092829561 bytes

        30 second rate 6000 bps

      Priority: 20% (921 kbps), burst bytes 23000, b/w exceed drops: 3484

      QoS Set

        dscp ef

          Packets marked 8903292

    Class-map: QOS-CRITICAL-DATA-CLASS (match-any)

      1692456 packets, 92593303 bytes

      30 second offered rate 0 bps, drop rate 0 bps

      Match: access-group name QOS01-IMPORTANTDATA

        1692456 packets, 92593303 bytes

        30 second rate 0 bps

      Queueing

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/0/0

      (pkts output/bytes output) 1692456/92593207

      QoS Set

        dscp cs3

          Packets marked 1692456

      bandwidth remaining 15% (449 kbps)

    Class-map: class-default (match-any)

      84491805 packets, 20552506078 bytes

      30 second offered rate 397000 bps, drop rate 0 bps

      Match: any

      queue limit 64 packets

      (queue depth/total drops/no-buffer drops) 0/23918/0

      (pkts output/bytes output) 84913873/21181652594

      QoS Set

        dscp af11

          Packets marked 84267059

In addition, I have noticed drops on gold classmap phones and default class maps.

I would like to know what triggering this behavior and how I can fix it to let QOS operates as expected.

I would appreciate any comments/feedbacks in this regard

Best Regards

R

[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

It would be helpful if you would describe your environment.

In general, your LLQ phones drops appears to be from hitting the implicit policer and your class-default drops from insufficient bandwidth.

Regarding you VoIP issue, how is your call signally marked?

[eandrcisco007]

Thank you Joseph, 

To give you a brief insight, we have 4 T1 Lines that are bundled to a multilink interface with a max reserved bandwidth 85 connected to L3, we have configured different ACL's for each class. Voip and Video are configured as Gold vs Silver, Bronze and Best Effort(Default),  

Our call signalling marked as cs3 and voice packets are marked as ef. all qos configs are mentioned above.

Hope above description will meet your requirements.

Regards

[Joseph W. Doherty]

What's your router platform?  Your IOS version?

Your bundle is MLPPP?  If so, is fragmentation enabled or not?

Your egress QoS is applied to the bundle interface?

If Silver is video, what's in Gold (non-phones) class?

Have you modified the tx-ring-limit?

So you've max reserved 85% for the bundle interface, correct?

[eandrcisco007]

The platform is 2851 and the IOS is 15.1

Yes,the bundle is MLPPP.

Yes, the Egress Qos is applied to the Bundle Int.

below is the int confiug...

 load-interval 30
 delay 3000
 no peer neighbor-route
 ppp multilink
 ppp multilink group 2
 max-reserved-bandwidth 85

I assume the video should also be marked as Gold...

Below are in Gold class:

Per udp any any dscp ef

Per udp any any dscp cs5

Per udp any any range 16384 32767

I have not configured all above configurations... but i am trying to get all misconfigurations fixed/verified ... i gotta agree it is not the best config....and that is the reason i am trying to fix it....and in fact ...it could be the reason the all the interface got congested ...

[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

Ok, with 15.x IOS, max-reserved isn't used.  You should provide an explicit bandwidth allocation to class-default.

Whether video should be placed into LLQ first depends on whether it's real-time video, like video conferencing, or whether is streaming video.  The latter doesn't often need LLQ because it's usually buffered.  The former benefits from LLQ, but when mixed VoIP, video's generally larger packets might cause VoIP additional jitter, which might or might not, be a problem.

Going back to your OP's "Having said that, we have congested the line and consequently the entire voice calls went down and we end up re-starting the router to bring it all back up to normal!! (Not a pleasant experience at all)", QoS doesn't preclude congesting a line, but when it's congested, QoS allows you to manage the congestion.  (Even that doesn't always guarantee you'll get all the results you want; sometimes you just need additional bandwidth.)

The few drops you had in you phone class, might have been enough, to disrupt your VoIP calls.

I did ask, what other traffic was in the other Gold class, because there's actually only one LLQ.  The only purpose of multiple LLQ classes is to allow you to set different traffic limits.  So, if you really don't need those, you can just have one logical LLQ class that maps into the one and only physically LLQ class.  That might be sufficient to solve your issue as it appears you slightly overran your logical limit for the phone class.

I also asked about your tx-ring-limits, but later IOSs are supposed to better self adjust.  These are the hardware FIFO queues.  Only when they overflow, does your CBWFQ policy engage.  Sometimes there's benefit to decrease these queues so your priority traffic isn't queued in those FIFO queues.  If you wanted to adjust for your MLPPP, I believe you would adjust on each serial interface, not the multi-interface, but don't quote me on that.  (It's been many years since I worked with a serial MLPPP interface.)

[eandrcisco007]

Hi Joseph,

Thank you so mcuh,outstanding.

I thought Priority percent ... would reserve specific amount of Bandwidth for its COS so the line would never get congested at least for that amount..i.e. 35%...

Could you please elaborate on the last two parts of your comments? Great stuff and i would like to get deep into those subjects...

Thank you.

[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

Most CBWFQ commands do not actually reserve bandwidth, including the priority command.  However, you can "manually" set aside bandwidth by creative use of shapers or policers in other classes.  Or, you need to get involved with RSVP.

What did you want to know more about, tx-ring-limit?

[eandrcisco007]

I would like to know how effective would it be if we adjust the queues on each serial interface and how we can test/verify it and overall how we do it and stuff like that.

Thank you.

[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

Depends on what kind of effective you want.

The tx-ring is to insure the interface has packets ready to go, i.e. it insures the interface can run at 100% because it won't need to wait on a packet.

CBWFQ insures when there's congestion, you determine what goes next.

The two often are mutually exclusive.  I.e. if you don't don't keep the tx-ring filled, the interface might wait to pull a packet from a CBWFQ queue, but a full tx-ring doesn't sequence packets as you want.

For T1s, I would suggest a minimum tx-ring value, often it's 2 or 3.  This will insure your LLQ packets will generally go first.

For testing, you could run SLA tests with different markings (or see if VoIP phones continue to work well even when link is at 100% usage [if QoS is working correctly, that should be the case]).

[eandrcisco007]

Outstanding/thank you so much Joseph.