Named Pools QoS Policy Command Reference

This commands creates a template that may be applied at the XMA, MDA, or port level to create named buffer pools. The policy may be applied at either the ingress or egress context for the port, XMA, or MDA. Policies applied on the MDA will take effect only after the named pool mode is set on the IOM. Setting the IOM named pool on will reboot the card.

Within the policy, named pools may be defined in the q1-pools context indicating that the provisioned pools will be used on Q1 based hardware. When the policy is associated at the XMA or MDA level, named pools defined in the policy allow queues from any port to be associated. When the policy is associated at the port level, the named pools created are only available to queues associated with the port. Each pool defined allows the slope-policy, resv-cbs, access-allocation-weight and network-allocation-weight parameters to be configured for the pool. The policy also manages the port-allocation-weights used to divide the buffers managed by the port between named pools local to the port, named pools on the ports XMA or MDA and the default pools. The allocation weights for a given port are derived in the following way (lowest to highest preference):

Pools in the policy may be added or removed at anytime. If the policy is currently associated with an XMA, MDA, or port, the system will first check to ensure necessary resources exist on the port, XMA, or MDA before allowing the pool creation within the policy to proceed. If the pool cannot be added, the pool pool-name command will fail. When a new pool is created, the system will scan all pool orphaned queues for queues associated with the new pool name wherever the policy is currently applied. (A queue with a defined pool name that does not exist is placed on its appropriate default pool until the pool comes into existence).

The no form of the command removes a specific named pool policy from the system. If the named pool policy is currently associated with an ingress or egress XMA, MDA, or port, the command will fail. If the named pool policy does not exist, the command has no effect and does not return an error.

The description command is used to define an informational ASCII string for the named pool policy. The string value may be defined or changed at anytime.

The no form of the command removes an explicit description string from the named pool policy.

The q1-pools command is used to enter the configuration node for Q1 oriented named buffer pools. The named pool policy will support contexts for configuring pools of other types when other pool types exist.

The port-allocation-weights command is used to define the weights used to divide the buffers managed by a port into three categories: default, XMA, MDA and port. The default category is given to the default pools, the XMA or MDA category is given to the XMA or MDA named pools and the port category is used by the local port named pools. When the IOM is placed in named-pool-mode, each port has an inherent set of weights that places all port managed buffers into the default category (default = 100, XMA or MDA = 0, port = 0). The policy port-allocation-weights command is used to override this port inherent behavior. When the policy is applied to the XMA or MDA, the defined port-allocation-weights parameter values override the inherent values for all ports on the XMA or MDA. When the policy is applied to the port level, the defined port-allocation-weights override both the local ports inherent weights and the XMA or MDA level named pool policy weights (if existing).

The no form of the command resets all values to the default value.

The pool command is used to create a new or edit an existing named pool within the policy. A CLI node is created for the named pool which contains the slope-policy and resv-cbs commands. A named pool created within the q1-pools context may be used by queues on any physical port, XMA or MDA where the policy is applied that has Q1 based buffer pools. Once the policy is applied on an XMA, MDA, or port, creating a new pool will fail if a pool resource is not available for the port, XMA, or MDA.

When creating a pool, the defined name must be unique within the policy. No other named pool may share the same name.

Once the pool is created, any queues currently on a default pool with a specified pool name the same as the new pool will be moved from the default pool to the new pool.

The no form of the command removes a specific named pool from the policy. If an instance of the named pool is currently associated with a created queue, the queue will be moved to the appropriate default pool. Once the pool is deleted, the pool is removed from both the policy and any instance of the pool on an XMA, MDA, or port is removed. The pool buffers are freed and may be available other named pools.

This command configures the threshold for the amber alarm on the over-subscription allowed.

Users can selectively enable amber or red alarm thresholds. But if both are enabled (non-zero) then the red alarm threshold must be greater than the amber alarm threshold.

The no form of the command reverts to the default value.

This command configures the threshold for the red alarm on the over-subscription allowed.

Users can selectively enable amber or red alarm thresholds. But if both are enabled (non-zero) then the red alarm threshold must be greater than the amber alarm threshold.

The no form of the command reverts to the default value.

The application-weights CLI node context contains the network and access allocation weights. The network and access application weights are used to divide the network and access buffer space available to the pools between each named pool. When the policy is applied at the XMA or MDA level, the network and access application weights are applied to the network and access buffer space given to the XMA or MDA named pools by the ingress or egress ports. When the policy is applied at the port level, the network and access application weights are applied to the local port network and access buffer space.

The network-allocation-weight command is used to define the weight used when dividing network associated buffer space between the named pools. When the named pool is created on an XMA or MDA, the network associated buffer space is summed from all ports. The pool’s network allocation weight is divided by the total network allocation weights from all named pools on the XMA or MDA. The resulting factor is multiplied by the summed port network associated buffer space to derive the amount of network buffers applied to the pool. When the named pool is created on a port, the weight is applied against the local ports network associated buffer space to derive the network buffers applied to the pool. A similar process is done for with the access-allocation-weight. The total buffers applied to the pool are the sum of the access and network buffers given to the pool.

Changing the weight does not change the total buffers allocated to the pools, just the ratio of distribution between the pools.

A weight of ‘0’ indicates that the pool will not receive any network associated buffers. If all pools on the port, XMA, or MDA have a network-allocation-weight equal to 0, the network associated buffer will not be used at that level.

The no form of the command returns the pools network allocation weight to the default value of 50.

The access-allocation-weight command is used to define the weight used when dividing access associated buffer space between the named pools. When the named pool is created on an XMA or MDA, the access associated buffer space is summed from all ports. The pool’s access allocation weight is divided by the total access allocation weights from all named pools on the XMA or MDA. The resulting factor is multiplied by the summed port access associated buffer space to derive the amount of access buffers applied to the pool. When the named pool is created on a port, the weight is applied against the local ports access associated buffer space to derive the access buffers applied to the pool. A similar process is done for with the network-allocation-weight. The total buffers applied to the pool are the sum of the access and network buffers given to the pool.

Changing the weight does not change the total buffers allocated to the pools, just the ratio of distribution between the pools.

A weight of ‘0’ indicates that the pool will not receive any access associated buffers. If all pools on the port, XMA, or MDA have a access-allocation-weight equal to 0, the access associated buffer will not be used at that level.

The slope-policy command is used to override the default slope-policy configuration for the named buffer pool. The specified slope-policy-name must exist as a current slope policy name. If the slope policy does not exist, the slope-policy command will fail. If a slope policy is currently associated with a named pool within a named pool policy, the slope policy cannot be removed from the system.

The slope policy contains the High and Low WRED slope definitions that will be used by the pool on each XMA or MDA on which the pool is created. If the slope-policy command is not executed or the no slope-policy command is executed, the default slope policy will be associated with the pool.

The no form of the command restores the default slope policy to the named pool.

The resv-cbs command is used to override the default reserved CBS size of the pool. The reserved CBS size defines the amount of buffer space within the pool that is not considered shared. When queues request buffers from the pool, they will be either ‘within-CBS’ or ‘above-CBS’. If the queue is ‘within-CBS’ based on the current queue depth and the configured CBS value for the queue, the requested buffer is taken from the reserved portion of the buffer pool. After the queues depth is beyond its configured CBS, the buffer will be taken from the pools shared space. Shared space buffers are subject to the WRED slope function within the buffer pool. If the WRED slopes are enabled, the buffer request may be denied based on WRED drop probability.

The default reserved CBS size of the pool is 30%.

The no form of the command restores the default reserved CBS size of 30%.

This command enables the context to modify the QoS default shared-queue policy.

This command creates the context to configure a shared queue QoS policy queue.

Explicit definition of an ingress queue’s hardware scheduler status is supported. A single ingress queue allows support for multiple forwarding classes. The default behavior automatically chooses the expedited or non-expedited nature of the queue based on the forwarding classes mapped to it. As long as all forwarding classes mapped to the queue are expedited (nc, ef, h1 or h2), the queue is treated as an expedited queue by the hardware schedulers. When any non-expedited forwarding classes are mapped to the queue (be, af, l1 or l2), the queue is treated as best effort (be) by the hardware schedulers. On the 7950 XRS, the expedited hardware schedulers are used to enforce expedited access to internal switch fabric destinations.

On the 7450 ESS, the expedited hardware schedulers are used to enforce expedited access to internal switch fabric destinations. The hardware status of the queue must be defined at the time of queue creation within the policy.

The pool keyword is a create time parameter that 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 XMA, MDA, or port on which the queue resides.

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 XMA, 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 (or not appear) on the queue command output using the pool keyword.

This command is utilized 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 (or not appear) on the queue command output using the pool keyword.

The no form of the command removes a named pool association for the queue. When the pool name is removed, the queue will be placed on the appropriate default pool.

This command creates a context to configure a network queue policy. Network queue policies define the ingress network queuing at the XMA or MDA network node level and at the Ethernet port and SONET/SDH path level to define network egress queuing.

Network queue policies define ingress and egress network queues similar to a sap-ingress QoS policy.

This command creates the context to configure a QoS network-queue policy queue.

Explicit definition of an ingress queue’s hardware scheduler status is supported. A single ingress queue allows support for multiple forwarding classes. The default behavior automatically chooses the expedited or non-expedited nature of the queue based on the forwarding classes mapped to it. As long as all forwarding classes mapped to the queue are expedited (nc, ef, h1 or h2), the queue is treated as an expedited queue by the hardware schedulers. When any non-expedited forwarding classes are mapped to the queue (be, af, l1 or l2), the queue is treated as best effort (be) by the hardware schedulers. The expedited hardware schedulers are used to enforce expedited access to internal switch fabric destinations. The hardware status of the queue must be defined at the time of queue creation within the policy.

The queue command allows the creation of multipoint queues. Only multipoint queues can receive ingress packets that need flooding to multiple destinations. By separating the unicast for multipoint traffic at service ingress and handling the traffic on separate multipoint queues, special handling of the multipoint traffic is possible. Each queue acts as an accounting and (optionally) shaping device offering precise control over potentially expensive multicast, broadcast and unknown unicast traffic. Only the back-end support of multipoint traffic (between the forwarding class and the queue based on forwarding type) needs to be defined. The individual classification rules used to place traffic into forwarding classes are not affected. Queues must be defined as multipoint at the time of creation within the policy.

The multipoint queues are for multipoint-destined service traffic. Within non-multipoint services, such as Epipe services, all traffic is considered unicast due to the nature of the service type. Multicast and broadcast-destined traffic in an Epipe service will not be mapped to a multipoint service queue.

When a QoS policy with multipoint queues is applied to an Epipe or IES SAP, the multipoint queues are not created. Any billing or statistical queries about a multipoint queue on a non-multipoint service returns zero values. Any queue parameter information requested about a multipoint queue on a non-multipoint service returns the queue parameters in the policy. Buffers will not be allocated for multipoint queues on non-multipoint services. Buffer pool queries return zero values for actual buffers allocated and current buffer utilization.

The no form of this command removes the queue-id from the network-queue policy and from any existing SAPs using the policy. If any forwarding class forwarding types are mapped to the queue, they revert to their default queues. When a queue is removed, any pending accounting information for each SAP queue created due to the definition of the queue in the policy is discarded.

The pool keyword is a create time parameter that 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 XMA, MDA, or port on which the queue resides.

If the specified pool-name does not exist on the XMA or 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 XMA or 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 (or not appear) on the queue command output using the pool keyword.

The queue’s pool association may only be removed by either re-executing the queue command without the pool keyword or by executing the no pool command within the queue’s CLI context. When the pool name is removed, the queue will be placed on the appropriate default pool.

This command is utilized 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 (or not appear) on the queue command output using the pool keyword.

The no form of the command removes a named pool association for the queue. When the pool name is removed, the queue will be placed on the appropriate default pool.