cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1206
Views
0
Helpful
2
Replies

QoS Child Policy Bandwidth Allocation

philclemens1835
Level 1
Level 1

I know this has been covered in multiple community threads, as well as YouTube videos, etc.  In fact, if anybody has a very good, basic reference for this concept, please share.

 

What is not clearly defined is the concept of bandwidth remaining versus bandwidth, and how it affects the default class.

 

I understand overall available bandwidth varies by method of allocation, but I'm primarily interested in the logical differences between "bandwidth percent" and "bandwidth remaining percent".

 

In this basic example

policy-map child

class 1

 priority level 1

 police rate percent 50

 exceed action drop

class 2

 bandwidth remaining percent 50

or

class 2

 bandwidth percent 50

class class-default

end policy-map

 

Class 1 can use up to 50% of the bandwidth, and any excess packets are dropped.

If Class 2 is "bandwidth remaining percent" it actually only gets 25% of the overall bandwidth.  In this case, there would be 25% for class default.

If Class 2 is "bandwidth percent" it gets up to the other 50% available.  In this case there is 0% for class default in a congested situation.

What is correct and incorrect about my statements?

 

The "bandwidth percent" seems to provide more definition.  I want 50% for priority traffic, and then I can allocate the other 50% among the other classes.  However, I've read that the total can be greater than 100%, which does not make logical sense to me.  Then I could have five classes each allocated 50%, which results in each actually getting 20%.

 

"Bandwidth remaining percent" seems infinite.  I could continue every class as remaining percent 50, and it just keeps taking half of the remaining bandwidth.  Then, it also then appears to require the sum of the values to equal 100, which doesn't line up with "remaining percent".  Does that mean that, even though we're saying "remaining percent" it's actually an explicit percent of the overall bandwidth, rather than a percent of the remaining bandwidth?

 

 

2 Replies 2

smilstea
Cisco Employee
Cisco Employee

I'll define the 3 different queueing actions we have:

  • Shape: Maximum rate a node in the policy-map hierarchy can receive. The shape parameter can associated to a queue or a parent/grandparent node in the hierarchy.
  • Bandwidth: Guaranteed minimum bandwidth assigned to a node in the policy-map hierarchy. The bandwidth parameter can be associated to a queue or a parent/grandparent node in the hierarchy. Note in cases where the sum of bandwidth statements for a port and all its subinterfaces oversubscribes the link rate, then there is no guarantee of minimum bandwidth. However the defined behavior is for oversubscribed streams to back off in proportion to the configured oversubscribed minimum rates.
  • Bandwidth remaining: This attribute is used to allocate excess bandwidth to nodes in a policy-map after priority and bandwidth traffic have all met their guarantee.

 

 

 

Sam

jawicks
Cisco Employee
Cisco Employee

 It's kind of neither of the two scenarios you give, probably ends up being closer to the second option.............the "bandwidth remaining percent" configuration tells the scheduler the amount of bandwidth to allocate to that queue after all the priority classes have been serviced, but it's acting more like a weighted ratio.  The PQ policer command in your policy is not calculated in these ratios (only "bandwidth" commands are used to define a weight on a given queue) but because PQ always gets services first then "bandwidth remaining percent" ends up being a weighted ratio of available bandwidth of the parent shaper, AFTER all the PQ traffic has been deducted.

 

In fact, even when using just the "bandwidth percent" command then under congestion at the parent level if the bandwidths configured for the non-PQ child-classes cannot be allocated for each class then these "bandwidth percent" configurations just end up being weight used by the sceduler to allocate available bandwidth between the queue.   The concept of the "bandwidth percent" command being used to configure minimum guaranteed bandwidth for the queue flys out of the window if that configured minimum-bandwidth at the child level has already been gobbled up by the strict priority-queue(s).

 

Using percentage values you should not be able to oversubscribe the total bandwidth by more than 100% (should result in an errror when the commit takes place) see an example below running XR6.4.2.....................note that the 50% policer in the PQ is NOT included in calculating percentages for bandwidth allocation (the strict "priority" keyword in the config takes care of that), so the resulting policy ends up with three classes allocated 50% but only the non-PQ classes count in the maths.

 

RP/0/RSP0/CPU0:ASR9001-BNG(config)#policy-map test
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap)#class ef
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#priority level 1
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#police rate percent 50
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c-police)#exit
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#exit
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap)#class one
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#R
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#bandwidth remaining percent 50
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#exit
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap)#class two
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#bandwidth remaining percent 50
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#exit
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap)#class three
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#bandwidth remaining percent 50
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap-c)#exit
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap)#exit
RP/0/RSP0/CPU0:ASR9001-BNG(config)#
Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:yes

% Failed to commit one or more configuration items during a pseudo-atomic operation. All changes made have been reverted. Please issue 'show configuration failed [inheritance]' from this session to view the errors
RP/0/RSP0/CPU0:ASR9001-BNG(config)#show config fail
Mon Nov 30 11:03:51.964 GMT
!! SEMANTIC ERRORS: This configuration was rejected by
!! the system due to semantic errors. The individual
!! errors with each failed configuration command can be
!! found below.
!
policy-map test
 class ef
  priority level 1
  police rate percent 50
!
class one
  bandwidth remaining percent 50
!
class two
  bandwidth remaining percent 50
!
class three
  bandwidth remaining percent 50
!
class class-default
!
end-policy-map
!
!!% Qos verification failed for policy-map.: Policy-map test class three failed.total bandwidth remaining percent > 100 %
end

RP/0/RSP0/CPU0:ASR9001-BNG(config)#policy-map test
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap)#no class three       <-- remove the third class asking for 50% bandwidth
RP/0/RSP0/CPU0:ASR9001-BNG(config-pmap)#
Uncommitted changes found, commit them before exiting(yes/no/cancel)? [cancel]:yes
RP/0/RSP0/CPU0:Nov 30 11:05:39.273 GMT: config[65920]: %MGBL-CONFIG-6-DB_COMMIT : Configuration committed by user 'cisco'. Use 'show configuration commit changes 1000000227' to view the changes.
RP/0/RSP0/CPU0:Nov 30 11:05:39.302 GMT: config[65920]: %MGBL-SYS-5-CONFIG_I : Configured from console by cisco
RP/0/RSP0/CPU0:ASR9001-BNG#
RP/0/RSP0/CPU0:ASR9001-BNG#show run policy-map test
Mon Nov 30 11:05:58.072 GMT
policy-map test
 class ef
  priority level 1
  police rate percent 50
!
class one
  bandwidth remaining percent 50
!
class two
  bandwidth remaining percent 50
!
class class-default
!
end-policy-map

 

As I mentioned before, the "bandwidth remaining percent" ends up being acted upon by the scheduler as just a weighted ratio (that as we see above, cannot exceed 100%) so this can be a little clunky so I believe that a better option when you have a mix of PQ and class-based queues is to use the "bandwidth remaining ratio", for a couple of reasons. Firstly the syntax of the command indicates more accurately what is happening under the hood with the scheduler.  Secondly the available range for the "ratio" is between 1-1000 and so you are able to be more granular with your bandwidth allocations than when specifying a percentage which is obviously only between 1-100 plus you don't run into the problem of exceeding 100% in your allocations.

 

Rgds, Jim.W.