QoS Queue Group Template Command Reference

This command creates a text description stored in the configuration file for a configuration context. The description command associates a text string with a configuration context to help identify the content in the configuration file.

The no form of this command removes the string from the configuration.

This command enables the context to define ingress and egress queue group templates.

This command enables the context to create ingress queue group templates. Ingress queue group templates can be applied to ingress ports to create an ingress queue group of the same name.

An ingress template must be created for a group-name prior to creating a queue group with the same name on an ingress port.

This command creates a queue group template. The system does not maintain default queue groups or queue group templates. Each queue group template used in the system must be explicitly created.

The queue-group-name parameter is required when executing the queue-group command and identifies the name of the template to be either created or edited. Each ingress queue group template must be uniquely named within the system. Multiple ingress queue group templates may not share the same name. An ingress and egress queue group template may share the same name.

The no form of the command removes the specified queue group template from the system. If the queue group template is currently in use by an ingress port, the command will fail. If queue-group-name does not exist, the command has no effect and does not return an error.

This command is used in ingress and egress queue-group templates to create, modify, or delete a policer.

Policers are created and used in a similar manner to queues. The policer ID space is separate from the queue ID space, allowing both a queue and a policer to share the same ID. The ingress queue-group template may have up to 32 policers (numbered 1 through 32) and may be defined, while the egress queue-group template supports a maximum of 8 (numbered 1 through 8). While a policer may be defined in a queue-group template, it is not actually created until the queue-group template is instantiated on the ingress context of a forwarding plane or on the egress context of a port.

Once a policer is created, the policer's metering rate and profiling rates may be defined, as well as the policer's maximum and committed burst sizes (MBS and CBS respectively). Unlike queues that have dedicated counters, policers allow various stat-mode settings that define the counters that will be associated with the policer. Another supported feature—packet-byte-offset—provides a policer with the ability to modify the size of each packet-based on a defined number of bytes.

Once a policer is created, it cannot be deleted from the queue-group template unless any forwarding classes that are redirected to the policer are first removed.

The no version of this command deletes the policer.

This command defines the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.

The no form of the command removes any explicitly defined constraints used to derive the operational CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

This command specifies the name of the advanced configuration policy to be applied with this policer.

The cbs command is used to define the default committed buffer size for the template queue or the CBS for the template policer. Overall, the cbs command follows the same behavior and provisioning characteristics as the cbs command in the SAP ingress and egress QoS policy.

The no form of this command restores the default CBS size to the template policer.

This command is used to configure the percentage of the policer’s PIR leaky bucket's MBS (maximum burst size) that is reserved for high priority traffic. While the mbs value defines the policer’s high priority violate threshold, the percentage value defined is applied to the mbs value to derive the bucket’s low priority violate threshold. See the mbs command details for information on which types of traffic is associated with each violate threshold.

This command specifies the default maximum buffer size for the template queue in bytes or kilobytes.

The MBS value is used by a queue to determine whether it has exhausted all of its buffers while enqueuing packets. Once the queue has exceeded the amount of buffers allowed by MBS, all packets are discarded until packets have been drained from the queue.

The port>ethernet>access>ingress>queue-group and port>ethernet>access>egress>queue-group contexts for mbs provides a mechanism for overriding the default maximum size for the queue.

The sum of the MBS for all queues on an ingress access port can oversubscribe the total amount of buffering available. When congestion occurs and buffers become scarce, access to buffers is controlled by the RED slope that a packet is associated with. A queue that has not exceeded its MBS size is not guaranteed that a buffer will be available when needed or that the packet’s RED slope will not force the discard of the packet. Setting proper CBS parameters and controlling CBS oversubscription is one major safeguard to queue starvation (when a queue does not receive its fair share of buffers). Another is properly setting the RED slope parameters for the needs of services on this port or channel.

When configured on an egress queue group queue, this command and the queue-delay command are mutually exclusive. In order to change between the mbs and queue-delay parameters, the current parameter must be removed before adding the new parameter, that is, changing from mbs to queue-delay requires a no mbs before the queue-delay is configured and changing from queue-delay to mbs requires a no queue-delay before the mbs is configured. If queue-delay is configured for an egress queue group queue, it is not possible to override the MBS for that queue.

For policers, this command is used to configure the policer’s PIR leaky bucket’s high priority violate threshold. The high-prio-only command is applied to the MBS value to derive the bucket’s low priority violate threshold.

At ingress, trusted in-profile packets and untrusted high priority packets use the policer’s high priority violate threshold while trusted out-of-profile and untrusted low priority packets use the policer's low priority violate threshold.

At egress, inplus-profile and in-profile packets use the policer’s high priority violate threshold and out-of-profile packets use the policer's low priority violate threshold. exceed-profile packets are discarded unless enable-exceed-pir is configured, in which case they are forwarded.

The PIR bucket’s violate threshold represent the maximum burst tolerance allowed by the policer. If the policer's offered rate is equal to or less than the policer's defined rate, the PIR bucket depth hovers around the 0 depth with spikes up to the maximum packet size in the offered load. If the offered rate increases beyond the metering rate, the amount of data allowed above the rate is capped by the threshold. The low priority violate threshold provides a smaller burst size for the lower priority traffic associated with the policer. Since all lower priority traffic is discarded at the lower burst tolerance size, the remaining burst tolerance defined by high-prio-only is available for the higher priority traffic.

The policer’s mbs size defined in the QoS policy may be overridden on an SLA profile or SAP where the policy is applied.

The no form of this command returns the MBS size assigned to the queue to the value.

This command configures a packet byte offset for the QoS ingress queue-group policer.

This command is used to create a child to parent mapping between each instance of the policer and either the root arbiter or a specific tiered arbiter on the object where the policy is applied. Defining a parent association for the policer causes the policer to compete for the parent policer’s available bandwidth with other child policers mapped to the policer control hierarchy.

Policer control hierarchies may be created on SAPs or on a subscriber or multiservice site context. To create a policer control hierarchy on an ingress or egress SAP context, a policer-control-policy must be applied to the SAP. Once applied, the system will create a parent policer that is bandwidth limited by the policy’s max-rate value under the root arbiter. The root arbiter in the policy also provides the information used to determine the various priority level discard-unfair and discard-all thresholds. Besides the root arbiter, the policy may also contain user defined tiered arbiters that provide arbitrary bandwidth control for subsets of child policers that are either directly or indirectly parented by the arbiter.

When the QoS policy containing the policer with a parent mapping to an arbiter name exists on the SAP, the system will scan the available arbiters on the SAP. If an arbiter exists with the appropriate name, the policer to arbiter association is created. If the specified arbiter does not exist either because a policer-control-policy is not currently applied to the SAP or the arbiter name does not exist within the applied policy, the policer is placed in an orphan state. Orphan policers operate as if they are not parented and are not subject to any bandwidth constraints other than their own PIR. When a policer enters the orphan state, it is flagged as operationally degraded due to the fact that it is not operating as intended and a trap is generated. Whenever a policer-control-policy is added to the SAP or the existing policy is modified, the SAP's policer's parenting configurations must be reevaluated. If an orphan policer becomes parented, the degraded flag should be cleared and a resulting trap should be generated.

For subscribers, the policer control hierarchy is created through the policer-control-policy applied to the sub-profile used by the subscriber. A unique policer control hierarchy is created for each subscriber associated with the sub-profile. The QoS policy containing the policer with the parenting command comes into play through the subscriber sla-profile that references the QoS policy. The combining of the sub-profile and the sla-profile at the subscriber level provides the system with the proper information to create the policer control hierarchy instance for the subscriber. This functionality is available only for the 7450 ESS and 7750 SR.

Executing the parent command will fail if:

A policer with a parent command applied cannot be configured with stat-mode no-stats in either the QoS policy or as an override on an instance of the policer

Once a policer is successfully parented to an arbiter, the parent commands level and weight parameters are used to determine at what priority level and at which weight in the priority level that the child policer competes with other children (policers or other arbiters) for bandwidth.

The no form of this command is used to remove the parent association from all instances of the policer.

This command enables a limit on the profile.

This command defines the administrative Peak Information Rate (PIR) and the administrative Committed Information Rate (CIR) parameters for the queue or policer. The PIR defines the maximum rate that the queue or policer can transmit packets out an egress interface (for SAP egress queues or policer). Defining a PIR does not necessarily guarantee that the queue can transmit at the intended rate. The actual rate sustained by the queue or policer can be limited by oversubscription factors or available egress bandwidth.

The CIR defines the rate at which the system prioritizes the queue or policer over other queues or policer competing for the same bandwidth. In-profile then out-of-profile packets are preferentially queued by the system at egress and at subsequent next hop nodes where the packet can traverse. To be properly handled throughout the network, the packets must be marked accordingly for profiling at each hop.

The CIR can be used by the queue or policer’s parent commands cir-level and cir-weight parameters to define the amount of bandwidth considered to be committed for the child queue during bandwidth allocation by the parent scheduler.

The rate command can be executed at anytime, altering the PIR and CIR rates for all queues created through the association of the SAP egress QoS policy with the queue-id or policer-id.

The no form of the command returns all queues or policer created with the queue-id or policer-id by association with the QoS policy to the default PIR and CIR parameters (max, 0).

This command is used to configure the forwarding plane counters that allow offered, forwarded and dropped accounting to occur for the policer. An ingress policer has multiple types of offered packets (explicit in-profile, explicit out-of-profile, uncolored, high priority or low priority) and each of these offered types is interacting with the policer’s metering and profiling functions resulting in colored output packets (green, yellow and red). Due to the large number of policers, it is not economical to allocate counters in the forwarding plane for all possible offered packet types and output conditions. Many policers, for example, will not be configured with a CIR profiling rate and not all policers will receive explicitly profiled offered packets. The stat-mode command allows provisioning of the number of counters each policer requires and how the offered packet types and output conditions should be mapped to the counters.

While a no-stats mode is supported that prevents any packet accounting, the use of the policer’s parent command requires that the policer's stat-mode to be set at least to the minimal setting so that offered stats are available for the policer's Fair Information Rate (FIR) to be calculated. Once a policer has been made a child to a parent policer, the stat-mode cannot be changed to no-stats unless the policer parenting is first removed.

Each time the policer’s stat-mode is changed, any previous counter values are lost and any new counters are set to zero.

Each mode uses a certain number of counters per policer instance that are allocated from the forwarding plane’s policer counter resources. The total/allocated/free stats can be viewed by using the tools dump resource-usage card fp command. If insufficient counters exist to implement a mode on any policer instance, the stat-mode change will fail and the previous mode will continue unaffected for all instances of the policer.

The stat-modes are summarized in Table 53.

The default stat-mode when a policer is created within the policy is minimal.

The stat-mode setting defined for the policer in the QoS policy may be overridden on an sla-profile or SAP where the policy is applied. If insufficient policer counter resources exist to implement the override, the stat-mode override command will fail. The previous stat-mode setting active for the policer will continue to be used by the policer.

The no form of this command attempts to return the policer’s stat-mode setting to minimal. The command will fail if insufficient policer counter resources exist to implement minimal where the QoS policer is currently applied and has a forwarding class mapping.

This command creates a queue for use in a queue group template. Once created, the defined queue-id acts as a repository for the default parameters for the queue. The template queue is created on each queue-group object that is created with the queue group template name. Each queue is identified within the template by a queue-id number. The template ensures that all queue groups created with the template name will have the same queue-ids providing a uniform structure for the forwarding class redirection commands in the SAP ingress QoS policies. The parameters within the template queue will be used as the default settings for each queue in the actual queue group. The queue parameters may be individually changed for each queue in each queue group using per queue overrides.

Once a queue within a template is mapped by a forwarding class on any object, the queue may be edited, but not deleted.

The no form of the command removes a template queue from the queue group template. If the queue is specified as a forwarding class redirection target in any SAP ingress QoS policy, the command will fail.

The queue burst-limit command is used to define an explicit shaping burst size for a queue. The configured size defines the shaping leaky bucket threshold level that indicates the maximum burst over the queue’s shaping rate.

The burst-limit command is supported under the sap-ingress and sap-egress QoS policy queues. The command is also supported under the ingress and egress queue-group-templates queues.

The no form of this command is used to restore the default burst limit to the specified queue. This is equivalent to specifying burst-limit default within the QoS policies or queue group templates. When specified within a queue-override queue context, any current burst limit override for the queue will be removed and the queue’s burst limit will be controlled by its defining policy or template.

The high-prio-only command configures the percentage of buffer space for the queue, used exclusively by high priority packets. The specified value overrides the default value for the context.

The priority of a packet can only be set in the SAP ingress QoS policy and is only applicable on the ingress queues for a SAP. At SAP egress, the priority of a packet is based on its profile state.

The no form of this command restores the default high priority reserved size.

This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the ingress scheduling and profiling is changed. The packet-byte-offset command is meant to be an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the scheduling and profiling throughput is affected by the offset as well as the stats (accounting) associated with the queue. The packet-byte-offset does not apply to drop statistics, received valid statistics, or the offered managed and unmanaged statistics used by Ingress Multicast Path Management.

The no version of this command is used to remove per packet size modifications from the queue.

This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers, policers (at egress only), and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.

Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multiservice customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The SAP that the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.

The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state mentioned above and automatically return to normal operation when the parent scheduler is available again.

When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.

The no form of the command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. Once a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.

This command allows the queue to receive buffers from an explicit buffer pool instead of the default buffer pool. The specified pool-name must have been explicitly created in a named pool policy and the policy must have been applied to the MDA or port on which the queue resides. Named pools are not supported on the 7950 XSR, 7750 SRc4/12, 7750 SR-a4/a8 or 7750 SR-1e/2e/3e.

If the specified pool-name does not exist on the MDA, the queue will be treated as pool orphaned and will be mapped to the appropriate default pool. Once the pool comes into existence on the MDA or port, the queue will be mapped to the new pool.

Once the queue is created within the policy, the pool command may be used to either remove the queue from the pool or specify a new pool name association for the queue. The pool command does not appear in save or show command output. Instead, the current pool name for the queue will appear on the queue command output using the pool keyword if it is configured.

The no form of the command removes the pool name from the configuration.

This command defines the administrative Peak Information Rate (PIR) and the administrative Committed Information Rate (CIR) parameters for the queue. The PIR defines the maximum rate that the queue can transmit packets through the switch fabric (for SAP ingress queues). Defining a PIR does not necessarily guarantee that the queue can transmit at the intended rate. The actual rate sustained by the queue can be limited by oversubscription factors or available egress bandwidth.

The CIR defines the rate at which the system prioritizes the queue over other queues competing for the same bandwidth. For SAP ingress, the CIR also defines the rate that packets are considered in-profile by the system. In-profile then out-of-profile packets are preferentially queued by the system at egress and at subsequent next hop nodes where the packet can traverse. To be properly handled throughout the network, the packets must be marked accordingly for profiling at each hop.

The CIR can be used by the queue’s parent commands cir-level and cir-weight parameters to define the amount of bandwidth considered to be committed for the child queue during bandwidth allocation by the parent scheduler.

The rate command can be executed at anytime, altering the PIR and CIR rates for all queues created through the association of the SAP ingress or SAP egress QoS policy with the queue-id.

The no form of the command returns all queues created with the queue-id by association with the QoS policy to the default PIR and CIR parameters (max, 0).

This command enables the context to configure QoS egress queue groups. Egress queue group templates can be applied to egress Ethernet ports to create an egress queue group.

The fc command is used to enter the forwarding class mapping context for the given fc-name. Each forwarding class has a default mapping depending on the egress queue group template. The system created policer-output-queue template contains queues 1 and 2 by default with queue 1 being best-effort and queue 2 expedited. Forwarding classes be, l1, af and l2 all map to queue 1 by default. Forwarding classes h1, ef, h2 and nc all map to queue 2 by default. More queues may be created within the policer-output-queues template and the default forwarding classes may be changed to any defined queue within the template.

When all other user defined egress queue group templates are created, only queue 1 (best-effort) exists and all forwarding classes are mapped to that queue. Other queues may be created and the forwarding classes may be changed to any defined queue within the template.

Besides the default mappings within the templates, the egress queue group template forwarding class queue mappings operate the same as the forwarding class mappings in a sap-egress QoS policy.

The template forwarding class mappings are the default mechanism for mapping egress policed traffic to a queue within an egress port queue group associated with the template. If a queue-id is explicitly specified in the QoS policy forwarding class policer mapping, and that queue exists within the queue group, the template forwarding class mapping is ignored.

On the 7450 ESS and 7750 SR, egress policed subscriber traffic works in a slightly different way. The subscriber and subscriber host support destination and organization strings are used to identify the egress port queue group. In this instance, the forwarding class mappings are always used and any queue overrides in the QoS policy are ignored. If neither string exists for the subscriber host, the egress queue group queue-id can be derived from either the QoS policy policer mapping or the template forwarding class queue mappings.

The no form of this command is used to return the specified forwarding class to its default template queue mapping.

This command is used to map the forwarding class to the specified queue-id. The specified queue-id must exist within the egress queue group template. Once a queue is defined in a forwarding class mapping, that queue cannot be deleted unless the forwarding class mapping is moved to another queue within the template. Other criteria may also exist preventing the queue from being deleted from the template such as an applied SAP egress QoS policy mapping to the queue.

This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed.

The packet-byte-offset command is meant to be an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers.

When a packet-byte-offset value is applied to a queue or policer instance, it adjusts the immediate packet size. This means that the queue rates (i.e., operational PIR and CIR) and policer or queue bucket updates use the adjusted packet size. In addition, the statistics will also reflect the adjusted packet size. Scheduler policy rates, which are data rates, will use the adjusted packet size.

The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, are always on-the-wire rates and thus use the actual frame size. The same goes for the agg-rate-limit on a SAP, a subscriber, or a Multiservice Site (MSS) when the queue is port-parented.

When the user enables frame-based-accounting in a scheduler policy or queue-frame-based-accounting with agg-rate-limit in a port scheduler policy, the policer or queue rate will be capped to a user configured on-the-wire rate and the packet-byte-offset is not included, however the offsets are applied to the statistics. This command is ignored on FP1 hardware.

The no version of this command is used to remove per packet size modifications from the queue.

This command configures a QoS egress queue-group policer.

This command enables the forwarding of traffic exceeding the PIR for a SAP egress or a network egress queue group (configured in the egress queue group template) policer. This traffic is forwarded as exceed-profile instead of being dropped.

The sap-egress QoS policy's policer stat-mode command is used to configure the forwarding plane counters that allow offered, forwarded and dropped accounting to occur for the policer. An egress policer has multiple types of offered packets (soft in-profile and out-of-profile from ingress and hard in-profile, out-of-profile, and exceed-profile due to egress profile overrides) and each of these offered types is interacting with the policer’s metering and profiling functions resulting in colored output packets (green, yellow and red). Due to the potential large number of egress policers, it is not economical to allocate counters in the forwarding plane for all possible offered packet types and output conditions. Many policers, for example, will not be configured with a CIR profiling rate and not all policers will receive explicitly re-profiled offered packets. The stat-mode command allows provisioning of the number of counters each policer requires and how the offered packet types and output conditions should be mapped to the counters.

While a no-stats mode is supported that prevents any packet accounting, the use of the policer's parent command requires that the policer’s stat-mode to be set at least to the minimal setting so that offered stats are available for the policer’s Fair Information Rate (FIR) to be calculated. Once a policer has been made a child to a parent policer, the stat-mode cannot be changed to no-stats unless the policer parenting is first removed.

Each time the policer's stat-mode is changed, any previous counter values are lost and any new counters are set to zero.

Each mode uses a certain number of counters per policer instance that are allocated from the forwarding plane's policer counter resources. The total/allocated/free stats can be viewed by using the tools dump resource-usage card fp command. If insufficient counters exist to implement a mode on any policer instance, the stat-mode change will fail and the previous mode will continue unaffected for all instances of the policer.

The ingress policer stat-modes are summarized in Table 63.

The default stat-mode when a policer is created within the policy is minimal.

The stat-mode setting defined for the policer in the QoS policy may be overridden on an sla-profile or SAP where the policy is applied. If insufficient policer counter resources exist to implement the override, the stat-mode override command will fail. The previous stat-mode setting active for the policer will continue to be used by the policer.

The no form of this command attempts to return the policer’s stat-mode setting to minimal. The command will fail if insufficient policer counter resources exist to implement minimal where the QoS policer is currently applied and has a forwarding class mapping.

This command creates a queue for use in a queue group template. Once created, the defined queue-id acts as a repository for the default parameters for the queue. The template queue is created on each queue group object that is created with the queue group template name. Each queue is identified within the template by a queue ID. The template ensures that all queue groups created with the template name will have the same queue-ids providing a uniform structure for the forwarding class redirection commands in the SAP egress QoS policies. The parameters within the template queue will be used as the default settings for each queue in the actual queue group. The queue parameters may be individually changed for each queue in each queue group using per queue overrides.

This command enables support for dynamically modifying the MBS size of a queue using H-QoS in order to maintain the maximum latency for traffic in the queue based on the queue’s configured MBS and the ratio of its operational PIR to its administrative PIR. As the H-QoS algorithm updates the operational PIR, by reducing or increasing it, the MBS of the queue is adjusted accordingly.

The configuration of dynamic MBS and the configuration of queue depth monitoring (monitor-depth command) are mutually exclusive. Queue depth monitoring is an override on the queue where the queue group is applied.

The no form of this command disables dynamic MBS resizing.

The hi-low-prio-only command configures the percentage of buffer space for the queue, used exclusively by higher priority (in-profile and out-of-profile) packets. The specified value overrides the default value for the context. It is applicable to SAP egress QoS policy queues and egress queue group template queues.

The priority of a packet can only be set in the SAP ingress QoS policy and is only applicable on the ingress queues for a SAP. At SAP egress, the priority of a packet is based on its profile state. The no form of this command restores the default high priority reserved size.

The hi-low-prio-only drop tail exists also for egress network queues in a network queue policy, however, in these policies it is not configurable and has a default of an additional 10% of the MBS value on top of the high priority only.

The percent-rate command within the egress queue group template enables support for a queue’s PIR and CIR rate to be configured as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gigabit and a 10-Gigabit Ethernet port, the queue’s rates will be 10 times greater on the 10 Gigabit port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port based queue overrides to modify a queue’s rate to get the same relative performance from the queue.

If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.

The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at anytime.

The no form of this command returns the queue to its default shaping rate and CIR rate.

This command defines the port scheduling parameters used to control the queue’s behavior when a virtual egress port scheduling is enabled where the egress queue group template is applied. The port-parent command follows the same behavior and provisioning characteristics as the parent command in the SAP egress QoS policy. The port-parent command and the parent command are mutually exclusive.

The no form of the command removes the values from the configuration.

This command configures the target queue delay for packets forwarded through the queue. It is used to determine the related queue parameters based on the administrative PIR of the queue. This command and the mbs command are mutually exclusive.

In order to change between the mbs and queue-delay parameters, the current parameter must be removed before adding the new parameter, that is, changing from mbs to queue-delay requires a no mbs before the queue-delay is configured and changing from queue-delay to mbs requires a no queue-delay before the mbs is configured.

If queue-delay is configured for an egress queue group queue, it is not possible to override the MBS for that queue.

The no form of this command disables the determination of the queue parameters based on the queue delay.

This command allows the configuration of WRED per queue with the following options:

Native Hardware WRED

When the wred-queue mode native command is configured, the queue uses the WRED capabilities of the FP3. In this case the out and exceed-profile traffic map to the low and exceed WRED slopes specified within the slope policy, and the inplus and in-profile traffic uses the MBS drop tail; this requires the slope-usage to be configured as exceed-low. The instantaneous queue depth is compared against the low and exceed slopes so the time average factor in the slope policy is ignored.

When a policy is not explicitly defined, the default slope policy is used.

When native mode is enabled for a queue, the hi-low-prio-only and high-prio-only commands are ignored; traffic mapped to a slope that is shut down will use the MBS drop tail.

This is only supported on FP3 hardware and is ignored on FP1 and FP2 hardware.

The no form of the command restores the queue default congestion control behavior to the queue.

Pool-per-queue WRED

When the wred-queue mode pool-per-queue command is defined and the queue ID is created on FP2 or higher based hardware, a buffer pool is created specifically for the queue and the queue obtains all buffers from that pool. The size of the pool is the same as the size of the queue. In this manner, the WRED slopes that operate based on the pool’s buffer utilization are also reacting to the congestion depth of the queue.

The size of the buffer pool is dictated by the queue’s mbs parameter. The size of the reserved CBS portion of the buffer pool is dictated by the queue’s cbs parameter. The provisioning characteristics of the mbs and cbs commands are not changed.

In the case where this is applied on FP2 or higher based hardware that has WRED queue support shutdown (config>card>fp>egress>wred-queue-control>shutdown) the queue will continue to map to either to its default pool or the pool defined in the pool command. If the no shutdown command is executed in the wred-queue-control context, the queue will be automatically moved to its own WRED pool.

Each pool created for a queue using the wred-queue command shares buffers with all other wred-queue enabled queues on the same forwarding plane. The WRED pool buffer management behavior is defined within the config>card>fp>egress>wred-queue-control CLI context.

The WRED slopes within the pool are defined by the slope policy associated with the queue. When a policy is not explicitly defined, the default slope policy is used. The slope policy enables, disables, and defines the relative geometry of the highplus, high, low, and exceed WRED slopes in the pool. The policy also specifies the time average factor used by the pool when calculating the weighted average pool depth.

As packets attempt to enter the egress queue, they are associated with the highplus, high, low, or exceed WRED slope based on the packet’s profile. If the packet is inplus-profile, the highplus slope is used. If the packet is in-profile, the high slope is used. If the packet is out-of-profile, the low slope is used, and if the packet is exceed-profile, then exceed slope is used. This mapping of packet profile to slope is enabled using the slope-usage default parameter. Each WRED slope performs a probability discard based on the current weighted average pool depth.

When wred-queue is enabled for an egress queue group queue on FP2 or higher based hardware, the queue pool hi-low-prio-only and hi-prio-only commands are ignored; traffic mapped to a slope that is shutdown will use the MBS drop tail.

The configuration of wred-queue mode pool-per-queue is ignored on FP1 hardware. The resource usage for the wred-queue pool-per-queue per forwarding plane can be seen in the tools dump resource-usage card [slot-num] fp [fp-number] output under Dynamic Q2 Wred Pools.

The no form of the command restores the generic buffer pool behavior to the queue. The WRED pool is removed from the system. The queue will be moved to either the default buffer pool or to a named pool if defined and the pool exists. The queue then uses the default congestion control behavior.

This command specifies that the queues within this egress queue group template are to be managed by the Hierarchical QoS (H-QoS) process when the template is applied to an Ethernet access egress or network egress context. It is applicable to all egress queue group templates, including the default policer-output-queues template.

The no queues-hqos-manageable command must be configured for access egress queue groups that are used for post-policer traffic in order to prevent H-QoS from measuring the traffic through a policer managed by H-QoS then again through a post-policer access egress queue group queue.

Avoid scenarios that result in traffic being either not being measured or being measured twice by H-QoS as they will cause the H-QoS result to be inaccurate; see Child Policer Hierarchical QoS Parenting for more information.

A template configured for no queues-hqos-manageable cannot be applied to an Ethernet network egress context. Any egress queue group templates applied to an Ethernet network egress context cannot be configured as no queues-hqos-manageable. The configuration of no queues-hqos-manageable and the configuration of policers and queue packet-byte-offset within the egress queue group template are mutually exclusive.

When a queue group template with no queues-hqos-manageable is configured under a port's Ethernet access egress context, the configuration of an aggregate rate or scheduler policy is not permitted under that context, nor are parent overrides for any of the queues in the queue group. If a port scheduler is configured on the port, the queue group queues are not parented to the port scheduler.

The no form of the command specifies that queues within this egress queue group are not managed by HQoS.