cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1110
Views
2
Helpful
8
Replies

QOS Config

eandrcisco007
Level 1
Level 1

Gents,

I need a fresh pair of eyes to check below configuration and offer recommendation if any...

Frankly speaking, I just don’t like the bandwidth remaining percent configuration specially upon having congestion on the interface/network and i think there would be a better way to reconfigure it,  

FYI. The phone has the highest priority and the Critical Data would get the next versus default that gets the last on the list.

policy-map qos_pmap
 class g_classmap
  priority percent 15
  set ip dscp cs5
 class s_classmap
  bandwidth remaining percent 55
  set ip dscp af31
 class b_classmap
  set ip dscp af21
  bandwidth remaining percent 30
 class g_classmap_phones
  priority percent 20
  set ip dscp ef
 class QOS-CRITICAL-DATA-CLASS
  set dscp cs3
  bandwidth remaining percent 15
 class class-default
 
 

Appreciate any feedback.

Thank you.

1 Accepted Solution

Accepted Solutions

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

Correct, the non-LLQ priority statement doesn't police or set a cap.

If a class were set with remaining percent 49, it could still use 100%.

If a class were set with remaining percent 49, and LLQ was set with 30, the LLQ class could have up to 30% (because there's an implicit policer with LLQ) and the 49% class could have up to 70%.

If there were other non-LLQ classes, but all aren't using all their guaranteed bandwidth, active non-LLQ normally proportion actual bandwidth based on their ratios between classes.  For example, if you there was only your 49% and a 10% class active, bandwidth would be split 49:10.  (NB: I understand ASR 1Ks split unused bandwidth differently.)

PS:

Regarding class-default not having a bandwidth allocation, that's likely from pre-HQF documentation.

View solution in original post

8 Replies 8

Hello.

You have no shaper, so I assume contracted bandwidth is equal to line-speed of the interface( if not, then you are in trouble). Also behaviour of the configuration depends on the IOS release (pre-HQF, IOS-XE and etc.) and interface speed.

For example, you are using default queue-size per class that could be not enough for 10M+ links on IOS, but it could be fine for IOS-XE.

 

What is your concern about "bandwidth remaining"? It's a method to assign weight per class (for scheduler).

So, for further discussion please provide "show ver" + "show polic-map int ..." + "show interface ..." + what is contracted WAN bandwidth.

Have a nice day.

Hi and thank you, 

The IOS ver. are all 15.1(4) M6 with 4.5 mbps & 15.2 (4) with 200 mbps as Bandwidth and yes the contracted Bandwidth is equal to line speed,

Well... My concern is about the way bandwidth remaining is configured and is not about using bandwidth remaining and even though i am not qos expert but I could tell it is not configured properly.

I am trying to find an optimal configuration to get the best out of available bandwidth ...to me when i see Priority command it means we are completely restricting traffic and by the same token when i see bandwidth remaining , it means , it is only gona provide the minumum bandwidth based on whatever has left for other class ... so why not hard coding the qos based on max. bandwidth per class and so forth,..

Below is the sh police-map int... (for 200mbps)

 Class-map: g-classmap (match-any)
      172706482 packets, 54439283596 bytes
      30 second offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name g_acl
        172706482 packets, 54439283009 bytes
        30 second rate 0 bps
      Priority: 15% (30000 kbps), burst bytes 750000, b/w exceed drops: 0

      QoS Set
        dscp cs5
          Packets marked 172706487

    Class-map: s_classmap (match-any)
      34792385 packets, 10288036444 bytes
      30 second offered rate 22000 bps, drop rate 0000 bps
      Match: access-group name s_acl
        34792385 packets, 10288036444 bytes
        30 second rate 22000 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 34792384/10288037102
      bandwidth remaining 50%
      QoS Set
        dscp af31
          Packets marked 34792385

    Class-map: b_classmap (match-any)
      46151679 packets, 15552705599 bytes
      30 second offered rate 57000 bps, drop rate 0000 bps
      Match: access-group name b_acl
        46151679 packets, 15552705599 bytes
        30 second rate 57000 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 46151679/15552705599
      bandwidth remaining 35%
      QoS Set
        dscp af21
          Packets marked 46151679

    Class-map: g_classmap_phones (match-any)
      73995750 packets, 8867265619 bytes
      30 second offered rate 200000 bps, drop rate 0000 bps
      Match: access-group name g_acl_phones
        73995750 packets, 8867265619 bytes
        30 second rate 200000 bps
      Priority: 20% (40000 kbps), burst bytes 1000000, b/w exceed drops: 0

      QoS Set
        dscp ef
          Packets marked 73995752

    Class-map: QOS-CRITICAL-DATA-CLASS (match-any)
      11503210 packets, 1418015810 bytes
      30 second offered rate 5000 bps, drop rate 0000 bps
      Match: access-group name QOS-CRITICAL-DATA
        11503208 packets, 1418015810 bytes
        30 second rate 5000 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 11503046/1417988741
      QoS Set
        dscp cs3
          Packets marked 11503210
      bandwidth remaining 15%

    Class-map: class-default (match-any)
      65814036085 packets, 61741312746198 bytes
      30 second offered rate 200718000 bps, drop rate 0000 bps
      Match: any

      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 65854701465/61802672581821
      QoS Set
        dscp af11
          Packets marked 65813337295

 

Below is the 2nd location with its qos config. for (4.5 mbps)

policy-map qos_policymap
 class g_classmap
  priority percent 15
  set ip dscp cs5
 class s_classmap
  bandwidth remaining percent 49
  set ip dscp af31
 class b_classmap
  set ip dscp af21
  bandwidth remaining percent 35
 class g_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
 

sh police-map int ....

 

    Class-map: g_classmap (match-any)
      41791741 packets, 14913875903 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: access-group name g_acl
        41791746 packets, 14913875690 bytes
        30 second rate 0 bps
      Priority: 15% (691 kbps), burst bytes 17250, b/w exceed drops: 11409

      QoS Set
        dscp cs5
          Packets marked 41791748

    Class-map: s_classmap (match-any)
      692506 packets, 97752071 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: access-group name s_acl
        692506 packets, 97752071 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) 692506/97752071
      bandwidth remaining 49% (1468 kbps)
      QoS Set
        dscp af31
          Packets marked 692506

    Class-map: b_classmap (match-any)
      1081771 packets, 394419846 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: access-group name b_acl
        1081771 packets, 394419846 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) 162942/57647033
      QoS Set
        dscp af21
          Packets marked 1081771
      bandwidth remaining 35% (1048 kbps)

    Class-map: g_classmap_phones (match-any)
      12771244 packets, 2979333068 bytes
      30 second offered rate 63000 bps, drop rate 0 bps
      Match: access-group name g_acl_phones
        12336996 packets, 2658170806 bytes
        30 second rate 63000 bps
      Priority: 20% (921 kbps), burst bytes 23000, b/w exceed drops: 29652

      QoS Set
        dscp ef
          Packets marked 12771243

    Class-map: QOS-CRITICAL-DATA-CLASS (match-any)
      4733999 packets, 247139639 bytes
      30 second offered rate 9000 bps, drop rate 0 bps
      Match: access-group name QOS-CRITICAL-DATA
        4733999 packets, 247139639 bytes
        30 second rate 9000 bps
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 4733999/247139639
      QoS Set
        dscp cs3
          Packets marked 4733999
      bandwidth remaining 15% (449 kbps)

    Class-map: class-default (match-any)
      4284870070 packets, 1175290167321 bytes
      30 second offered rate 531000 bps, drop rate 0 bps
      Match: any

      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/3458095/0
      (pkts output/bytes output) 36392724/1245434771129
      QoS Set
        dscp af11
          Packets marked 4273160437

 

 

Thank you.

 

 

 

 

 

 

 

 

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

I am trying to find an optimal configuration to get the best out of available bandwidth ...to me when i see Priority command it means we are completely restricting traffic and by the same token when i see bandwidth remaining , it means , it is only gona provide the minumum bandwidth based on whatever has left for other class ... so why not hard coding the qos based on max. bandwidth per class and so forth,..

LLQ classes have implicit policers, I suspect, because any such class can starve all other traffic.  On the other hand, as long as LLQ classes support defining an explicit policer (or shaper), Cisco could have not had an implicit policer, IMO; but it is what it is.

I'm unsure you understand what remaining bandwidth statement actually does.  It sets a minimum bandwidth guarantee, as configured, when all 100% has been allocated across the policy and when all other classes are actually using all their configured bandwidth.  It also sets proportional dequeuing.  For example, I believe the following polices will provide the same effective results:

policy sample1

class A

bandwidth percent 5

class B

bandwidth percent 5

policy sample2

class A

bandwidth percent 50

class B

bandwidth percent 50

policy sample3

class A

bandwidth 8000

class B

bandwidth 8000

As to "I am trying to find an optimal configuration to get the best out of available bandwidth", well that depends on what you're trying to accomplish especially while regarding the service needs of your traffic.

For starters, using FQ for all traffic, works generally well.  Light volume flows are not impacted by high volume flow's packet train bursts, and every flow gets its fair share of the bandwidth.

When you don't want to treat all flows with equal priority to bandwidth, you can prioritize their dequeuing priority by setting their bandwidth allocation.

For example, let's say you had lots of telnet flows and lots of bulk file copies, you might use a policy like:

policy SampleTwoTier

class foreground

bandwidth percent 99

class background

bandwidth percent 1

For the forgoing, you direct the telnet flows to the foreground class, and the bulk file copies to the background class.  Ideally, actual bandwidth consumption might be the inverse, but anytime the telnet traffic was queued concurrently with the bulk file copy traffic, it has a much higher chance of being dequeued first.

Also ideally, you would have FQ applied to each class, although unlikely to be needed much for the foreground class.  Also ideally, for the background class, you might have something like FRED or DBL.

My generic policy, that handles most anything is:

policy generic

class realtime

priority percent 33

class hiPriority

bandwidth remaining 81

fair-queue

class loPriority

bandwidth remaining 1

fair-queue

class class-default

bandwidth remaining 9

fair-queue

In the above, most traffic should be left in class-default, only "special" traffic, should be redirected to the other classes.  For example, VoIP bearer might be in realtime, terminal screen scraping might be in hiPriority and bulk data transfers might be in loPriority.

Thank you Joseph,

So according to your comments,  " Remaining Bandwidth sets a minimum bandwidth guarantee, as configured " it means it doesnt provide any type of policing so in view of that what would happen if the priority percent is 30 and bandwidth remaining perect is 49 and the bandwidth is fully congested ... it means all 49 perect is currently in use , and in additon we have few more classes with bandwidth remaining percet i.e. 15 and 35 ... so what is going to happen to default traffic...?

By the way, I have read in Cisco documenation that we normally dont define any bandwidth for class class default.

Appreciate for your input.

 

 

 

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

Correct, the non-LLQ priority statement doesn't police or set a cap.

If a class were set with remaining percent 49, it could still use 100%.

If a class were set with remaining percent 49, and LLQ was set with 30, the LLQ class could have up to 30% (because there's an implicit policer with LLQ) and the 49% class could have up to 70%.

If there were other non-LLQ classes, but all aren't using all their guaranteed bandwidth, active non-LLQ normally proportion actual bandwidth based on their ratios between classes.  For example, if you there was only your 49% and a 10% class active, bandwidth would be split 49:10.  (NB: I understand ASR 1Ks split unused bandwidth differently.)

PS:

Regarding class-default not having a bandwidth allocation, that's likely from pre-HQF documentation.

Thank you so very much Joseph.

This is exactly what i was looking and trying to underatnd.

Joseph W. Doherty
Hall of Fame
Hall of Fame

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

The advantage of "remaining" bandwidth, you avoid the need to re-juggle class bandwidths if you changed your LLQ bandwidth assignments.

You don't have any bandwidth defined for class-default?

You say you want your Critical Data to have highest priority after phone traffic, but your s_classmap and b_classmap both have higher bandwidth allocations.

 

Hi and thank you for your input,.

In fact, set ip dscp af11 is defined for class-default ,

Would you be kind check my comments that i have posted for Vasilii in reply to his comments and update? ( I have posted some results based on sh police-map command that could possibly provide better details to scrutinze..)

thank you.

 

 

 

Review Cisco Networking for a $25 gift card