Shared-Queue QoS Policy 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 context in the configuration file.

The no form of this command removes any description string from the context.

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

This command specifies the forwarding class name. The forwarding class name represents an egress queue. The fc fc-name represents a CLI parent node that contains sub-commands or parameters describing the egress characteristics of the queue and the marking criteria of packets flowing through it. The fc command overrides the default parameters for that forwarding class defined in the network default policy policy-id 1.

This command configures the broadcast forwarding type queue mapping for fc fc-name. The specified queue-id must exist within the policy as a multipoint queue before the mapping can be made. Once the forwarding class mapping is executed, all broadcast traffic on a SAP using this policy will be forwarded using the queue-id.

The broadcast forwarding type usually tracks the multicast forwarding type definition. This command overrides that default behavior.

The no form of the command sets the broadcast forwarding type queue-id back to the default of tracking the multicast forwarding type queue mapping.

This command configures the multicast forwarding type queue mapping for fc fc-name. The specified queue-id must exist within the policy as a multipoint queue before the mapping can be made. Once the forwarding class mapping is executed, all multicast traffic on a SAP using this policy is forwarded using the queue-id.

The multicast forwarding type includes the unknown unicast forwarding type and the broadcast forwarding type unless each is explicitly defined to a different multipoint queue. When the unknown and broadcast forwarding types are left as default, they will track the defined queue for the multicast forwarding type.

The no form of the command sets the multicast forwarding type queue-id back to the default queue for the forwarding class. If the broadcast and unknown forwarding types were not explicitly defined to a multipoint queue, they will also be set back to the default multipoint queue (queue 11).

This command overrides the default unicast forwarding type queue mapping for fc fc-name. The specified queue-id must exist within the policy as a non-multipoint queue before the mapping can be made. Once the forwarding class mapping is executed, all unicast traffic (this includes all traffic, even broadcast and multicast for services) on a SAP using this policy is forwarded using the queue-id.

The no form of this command sets the unicast (point-to-point) queue-id back to the default queue for the forwarding class (queue 1).

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. 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 or 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.

This command configures the unknown unicast forwarding type queue mapping for fc fc-name. The specified queue-id must exist within the policy as a multipoint queue before the mapping can be made. Once the forwarding class mapping is executed, all unknown traffic on a SAP using this policy is forwarded using the queue-id.

The unknown forwarding type usually tracks the multicast forwarding type definition. This command overrides that default behavior.

The no form of this command sets the unknown forwarding type queue-id back to the default of tracking the multicast forwarding type queue mapping.

The Committed Burst Size (cbs) command specifies the relative amount of reserved buffers for a specific ingress network XMA or MDA forwarding class queue or egress network port forwarding class queue. The value is entered as a percentage.

The CBS for a queue is used to determine whether it has exhausted its reserved buffers while enqueuing packets. Once the queue has exceeded the amount of buffers considered in reserve for this queue, it must contend with other queues for the available shared buffer space within the buffer pool. Access to this shared pool space is controlled through Random Early Detection (RED) slope application.

Two RED slopes are maintained in each buffer pool. A high priority slope is used by in-profile packets. A low priority slope is used by out-of-profile packets. All Network-Control and Management packets are considered in-profile. Assured packets are handled by their in-profile and out-of-profile markings. All Best-Effort packets are considered out-of-profile. Premium queues should be configured such that the CBS percent is sufficient to prevent shared buffering of packets. This is generally taken care of by the CIR scheduling of Premium queues and the overall small amount of traffic on the class. Premium queues in a properly designed system will drain before all others, limiting their buffer utilization.

The RED slopes will detect congestion conditions and work to discard packets and slow down random TCP session flows through the queue. The RED slope definitions can be defined, modified or disabled through the network-queue policy assigned to the XMA or MDA for the network ingress buffer pool or assigned to the network port for network egress buffer pools.

The resultant CBS size can be larger than the MBS. This will result in a portion of the CBS for the queue to be unused and should be avoided.

The high-prio-only command allows the reservation of queue buffers for use exclusively by high priority packets as a default condition for access buffer queues for this shared queue policy.

The difference between the MBS size for the queue and the high priority reserve defines the threshold where low priority traffic will be discarded. The result is used on the queue to define a threshold where low priority packets are discarded, leaving the rest of the default MBS size for high priority packets only. If the current MBS for the queue is 10MBytes, a value of 5 will result in a high priority reserve on the queue of 500KBytes. A value of 0 specifies that none of the MBS of the queue will be reserved for high priority traffic. This does not affect RED slope operation for packets attempting to be queued.

Modifying the current MBS for the queue through the mbs command will cause the default high-prio-only function to be recalculated and applied to the queue. The high-prio-only command as defined for the specific queue can be used to override the default high-prio-only setting as defined in the network queue policy. This prevents the high-prio-only command for the shared queue policy from having an affect on the queue.

This command specifies the relative amount of the buffer pool space for the maximum buffers for a specific ingress network XMA or MDA forwarding class queue or egress network port forwarding class queue.

The MBS value is used to by a queue to determine whether it has exhausted its total allowed buffers while enqueuing packets. Once the queue has exceeded its maximum amount of buffers, all packets are discarded until the queue transmits a packet. 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 the network queues.

The MBS size can sometimes be smaller than the CBS. This will result in a portion of the CBS for the queue to be unused and should be avoided.

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 pool command is used to remove 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 defines the administrative Peak Information Rate (PIR) and the administrative Committed Information Rate (CIR) parameters for the queue. The PIR defines the percentage that the queue can transmit packets through the switch fabric (for SAP ingress queues) or out an egress interface (for SAP egress 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 over-subscription factors or available egress bandwidth.

The CIR defines the percentage 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 packets are preferentially queued by the system at egress and at subsequent next hop nodes where the packet can traverse. To be properly handled as in- or out-of-profile 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.