Network Queue QoS Policy Command Reference
174 Quality of Service Guide
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 traffic.
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.
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, 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.
Parameters queue-id — The queue-id for the queue, expressed as an integer. The queue-id uniquely identifies
the queue within the policy. This is a required parameter each time the queue command is
executed.
Values 1 to 32
queue-type — The expedite, best-effort and auto-expedite queue types are mutually exclusive to
each other. Each defines the method that the system uses to service the queue from a hardware
perspective. While parental virtual schedulers can be defined for the queue, they only enforce
how the queue interacts for bandwidth with other queues associated with the same scheduler
hierarchy. An internal mechanism that provides access rules when the queue is vying for
bandwidth with queues in other virtual schedulers is also needed. A keyword must be
specified at the time the queue is created in the network-queue policy. If an attempt is made
to change the keyword after the queue is initially defined, an error is generated.
To Next Page
Loading...
