Account
Account is not an independent command but rather an extension to scheduling commands that allows a user to specify overhead accounting for that command. Account is presented here to avoid replication in each of the scheduling commands.
Syntax description:
To configure a user defined number of bytes to be added to or subtracted from the scheduling length:
[no] shape | bandwidth
rate
account user-defined
value [atm]
To specify encapsulation of a downstream device and automatically calculate the overhead accounting adjustment:
[no] shape | bandwidth
rate
account dot1q | qing
encapsulation
Command Default:
By default Layer 3 Datagram and Layer 2 headers are included in scheduling calculations.
Usage Guidelines:
If the account option is used in one class containing scheduling actions in a policy-map, the account command with same values must be used in all classes containing scheduling actions. Similarly in a hierarchical policy-map the same account options must be configured in each level of the policy.
Bandwidth
The bandwidth command is used to guarantee a minimum service rate to a class.
Syntax description:
To configure in Kbps:
[no] bandwidth
rate [account
account options]
To configure as a percentage of visible bandwidth:
[no] bandwidth
percent
value [account
account options]
Command Default:
By default there is no minimum bandwidth value configured in the schedule entry for a queue. Note that the default excess weight does guarantee some minimum service.
Usage Guidelines:
The bandwidth command may be useful if you have an application for which you know the minimum bandwidth requirements.
Bandwidth rates can be configured in 8Kbps increments and the ASR1K has been tested to achieve accuracy within 1% of those rates.
The bandwidth command is only supported in leaf schedules (class layer schedules). If you wish to apportion bandwidth in a parent policy you may use the bandwidth remaining command.
If you wish to replicate scheduling behavior of an IOS Classic platform (2 parameter scheduler) you may want to replace all bandwidth percent
value commands in your configuration with bandwidth remaining percent
value command.
Bandwidth remaining
The bandwidth remaining command is used to apportion excess bandwidth between classes. It may be configured as a simple weight or as a percentage of available bandwidth.
Syntax Description:
To configure as a simple weight:
[no] bandwidth remaining ratio
value [account
account options]
To configure as a percentage:
[no] bandwidth remaining percent
value [account
account options]
Command Default:
By default every bandwidth schedule entry, whether in leaf schedule or a parent schedule, is configured with an excess weight of 1. This is equivalent to bandwidth remaining ratio
1 being configured in that class.
Usage Guidelines:
Configuring bandwidth remaining as a weight supports values of 1 to 1000. This can allow more granular excess sharing than using the percent option.
Configuring bandwidth remaining percent
value yields behavior similar to IOS classic which used a 2 parameter scheduler.
With a shape on parent / queue on child policy (parent has only class default) bandwidth remaining ratio
value should be used to apportion bandwidth between logical interfaces where parent polices are attached
Fair-Queue
The fair-queue command is used to configure flow based fair-queuing in a class configured as a bandwidth queue.
Syntax Description:
fair-queue
Command Default:
By default a single fifo queue is configured for each bandwidth class.
Usage Guidelines:
Flow based fair-queuing is used to ensure a single greedy flow can’t consume all the bandwidth allocated to a class.
All packets from any given flow are hashed into the same flow queue.
Flow-queuing should not be configured in a policy attached to a tunnel interface. Since all packets have the same outer header all packets are hashed to the same flow queue thus rendering the feature ineffective.
Priority
The priority command is used to give low latency and low jitter treatment to a class of traffic.
Syntax Description:
To configure an absolute priority queue (note should be used with explicit policer)
[no] priority
To configure an absolute priority queue with multi-level priority queuing (note this should be used with an explicit policer)
[no] priority level
1 | 2
To configure a priority queue with conditional policer
[no] priority
rate in kbps [burst in bytes]
or
[no] priority percent
rate [burst in bytes]
To configure multilevel priority queueing with conditional policer
[no] priority level
1 | 2rate in kpbs [burst in bytes]
or
[no] priority level
1 | 2
percentrate [burst in bytes]
Command Default:
By default queues are not configured with priority treatment.
Usage Guidelines:
Priority queues should be used with some form of queue admission control (explicit policer or conditional policer) to avoid chance of starving other classes of service.
The policer conforming burst should be configured to an appropriate value for the application in the queue. The following is a configuration example
policy-map always_on_policer_burst_example
class voice
priority
police cir 2000000 1250
It is not necessary to configure priority in the parent of a hierarchical policy as priority propagation will ensure packets marked as priority by a leaf schedule will receive priority treatment throughout the scheduling hierarchy.
Shape
Use the shape command to configure the maximum rate at which a queue may be serviced. Configuring a shaper does not guarantee throughput to a class, it simply puts an upper bound on the rate at which that class may be serviced.
Syntax Description:
[no] shape average
rate [unit] [confirming burst] [excess burst] [account
options]
or
[no] shape average percent
rate [confirming burst] [excess burst] [account
options]
Command Default:
By default there is no maximum rate configured in the schedule entry for a bandwidth queue.
Usage Guidelines:
The shape command is most commonly used in a parent policy to limit the rate at which traffic is sent to a remote site.
When used in a parent policy the shape rate will be enforced for all traffic - priority and bandwidth.
The shape command has options for conforming and excess burst sizes but these values have no effect on XE platforms. Hardware scheduling on the ASR1K platform obviates the need to optimize burst parameters.
The shape command enforces a maximum rate at which a class may be serviced but does not in itself guarantee any throughput to that class. The bandwidth remaining command may be used along with the shape command to guarantee throughput.