04-17-2015 11:20 AM - edited 03-05-2019 01:16 AM
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.
Solved! Go to Solution.
04-21-2015 02:38 AM
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.
04-19-2015 09:30 AM
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.
04-20-2015 08:30 AM
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.
04-20-2015 09:50 AM
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.
04-20-2015 11:15 AM
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.
04-21-2015 02:38 AM
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.
04-21-2015 08:11 AM
Thank you so very much Joseph.
This is exactly what i was looking and trying to underatnd.
04-20-2015 07:24 AM
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.
04-20-2015 08:40 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide