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.
The copy command is a configuration level maintenance tool used to create new policies using existing policies. It also allows bulk modifications to an existing policy with the use of the
overwrite keyword.
Indicates that the source policy ID and the destination policy ID are network-queue policy IDs. Specify the source policy ID that the copy command will attempt to copy from and specify the destination policy ID to which the command will copy a duplicate of the policy.
SR7>config>qos# copy network-queue nq1 nq2
MINOR: CLI Destination "nq2" exists - use {overwrite}.
SR7>config>qos# copy network-queue nq1 nq2 overwrite
[no] network-queue policy-name
This command creates a context to configure a network queue policy. Network queue policies define the ingress network queuing at the MDA network node level and on the Ethernet port and SONET/SDH path level to define network egress queuing.
The fc context in the network-queue context provides a forwarding class queue context to the contained buffer control and queue rate commands.
The fc node contains the PIR, CIR, CBS and MBS commands used to control the buffer pool resources of each forwarding class queue on the ingress and egress pools that are associated with the network-queue policy.
The no form of this command
restores all PIR, CIR, CBS and MBS parameters for the forwarding class network queue to their default values.
This command overrides the default 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 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).
Resource Utilization :
When a multipoint queue is created and at least one forwarding class is mapped to the queue using the
multipoint-queue command, a single ingress multipoint hardware queue is created per instance of the applied network-queue policy using the queue-policy command at the ingress network MDA level. Multipoint queues are not created at egress and the multipoint queues defined in the network-queue policy are ignored when the policy is applied to an egress port.
The queue-id parameter specified must be an existing, multipoint queue defined in the
config>qos>network-queue>queue context.
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 no form of this command removes the queue-id from the network-queue policy and from any existing MDA or port 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 MDA or port queue created due to the definition of the queue in the policy is discarded.
Resource Utilization
When the network-queue policy is applied on a ingress MDA, each unicast queue is created multiple times - once for each switch fabric destination currently provisioned. Some IOM types represent one switch fabric destinations while others may represent two. At egress, a single queue is created since the policy is applied at the port level. Queues are only created when at least one forwarding class is mapped to the queue using the queue command within the forwarding class context.
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.
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 to change the keyword after the queue is initially defined, an error is generated.
This keyword specifies that this queue-id is for multipoint forwarded traffic only. This queue-id can only be explicitly mapped to the forwarding class multicast, broadcast, or unknown unicast ingress traffic. If you attempt to map forwarding class unicast traffic to a multipoint queue, an error is generated and no changes are made to the current unicast traffic queue mapping.
A queue must be created as multipoint. The multipoint designator cannot be defined after the queue is created. If an attempt is made to modify the command to include the multipoint keyword, an error is generated and the command will not execute.
The multipoint keyword can be entered in the command line on a pre-existing multipoint queue to edit queue-id parameters.
This command is a container for the configuration parameters controlling the behavior of an HSMDA queue. Unlike the standard QoS policy queue command, this command is not used to actually create or dynamically assign the queue to the object which the policy is applied. The queue identified by queue-id always exists whether the command is executed or not. In the case of HSMDA SAPs and subscribers, all eight queues exist at the moment the system allocates an HSMDA queue group to the object.
With standard service queues, the scheduling behavior relative to other queues is based on two items, the queues Best-Effort or Expedited nature and the dynamic rate of the queue relative to the defined CIR. HSMDA queues are handled differently. The create time auto-expedite and explicit expedite and best-effort qualifiers have been eliminated and instead the scheduling behavior is based solely on the queues identifier. Queues with a queue-id equal to 1 are placed in scheduling class 1. Queues with queue-id 2 are placed in scheduling class 2. And so on up to scheduling class 8. Each scheduling class is either mapped directly to a strict scheduling priority level based on the class ID, or the class may be placed into a weighted scheduling class group providing byte fair weighted round robin scheduling between the members of the group. Two weighted groups are supported and each may contain up to three consecutive scheduling classes. The weighed group assumes its highest member class’s inherent strict scheduling level for scheduling purposes. Strict priority level 8 has the highest priority while strict level 1 has the lowest. When grouping of scheduling classes is defined, some of the strict levels will not be in use.
The no form of the command restores the defined queue-id to its default parameters. All HSMDA queues having the queue-id and associated with the QoS policy are re-initialized to default parameters.
This command adds or subtracts the specified number of bytes to the accounting function for each packet handled by the HSMDA queue. Normally, the accounting and leaky bucket functions are based on the Ethernet DLC header, payload and the 4 byte CRC (everything except the preamble and inter-frame gap). As an example, the packet-byte-offset command can be used to add the frame encapsulation overhead (20 bytes) to the queues accounting functions.
The secondary shaper leaky bucket, scheduler priority level leaky bucket and the port maximum rate updates are not affected by the configured packet-byte-offset. Each of these accounting functions are frame based and always include the preamble, DLC header, payload and the CRC regardless of the configured byte offset.
The packet-byte-offset command accepts either add or subtract as valid keywords which define whether bytes are being added or removed from each packet traversing the queue. Up to 20 bytes may be added to the packet and up to 43 bytes may be removed from the packet. An example use case for subtracting bytes from each packet is an IP based accounting function. Given a Dot1Q encapsulation, the command packet-byte-offset subtract 14 would remove the DLC header and the Dot1Q header from the size of each packet for accounting functions only. The 14 bytes are not actually removed from the packet, only the accounting size of the packet is affected.
As inferred above, the variable accounting size offered by the packet-byte-offset command is targeted at the queue and queue group level. When the queue group represents the last-mile bandwidth constraints for a subscriber, the offset allows the HSMDA queue group to provide an accurate accounting to prevent overrun and underrun conditions for the subscriber. The accounting size of the packet is ignored by the secondary shapers, the scheduling priority level shapers and the scheduler maximum rate. The actual on-the-wire frame size is used for these functions to allow an accurate representation of the behavior of the subscribers packets on an Ethernet aggregation network.
The no form of the command removes any accounting size changes to packets handled by the queue. The command does not affect overrides that may exist on an associated with the queue.
This command associates an existing HSMDA slope policy to the QoS policy HSMDA queue. The specified hsmda-slope-policy-name must exist for the command to succeed. If the policy name does not exist, the command has no effect on the existing slope policy association. Once a slope policy is associated with a QoS policy queue or override, the slope policy cannot be removed from the system. Any edits to an associated slope policy are immediately applied to the queues using the slope policy.
Within the ingress and egress QoS policies, packets are classified as high priority or low-priority. For color aware policies, packets are also potentially classified as in-profile, out-of-profile or profile-undefined. Based on these classifications, packets are mapped to the RED slopes in the following manner:
The specified policy contains a value that defines the queue’s MBS value (queue-mbs). This is the maximum depth of the queue specified in bytes where all packets start to discard. The high and low priority RED slopes provide congestion control mechanisms that react to the current depth of the queue and start a random discard that increases in probability as the queue depth increases. The start point and end point for each discard probability slope is defined as follows:
The system maintains a slope policy named hsmda-default which acts as a default policy when an explicit slope policy has not been defined for an HSMDA queue. The default policy may be edited, but it cannot be deleted. If a no slope-policy hsmda-default command is executed, the default slope policy returns to the factory default settings. The factory default settings are as follows:
The no form of the command restores the association between the queue and the HSMDA default slope policy. The command has no immediate effect for queues that have a local override defined for the slope policy.
The no form of the command removes any explicitly defined constraints used to derive the operational PIR created by the application of the policy. When a specific
adaptation-rule is removed, the default constraints for
pir apply.
|
Values
|
pir — Defines the constraints enforced when adapting the PIR rate defined. The pir parameter requires a qualifier that defines the constraint used when deriving the operational PIR for the HSMDA queue. When the pir command is not specified, the default applies.
|
max — The
max (maximum) option is mutually exclusive with the
min and
closest options.
min — The
min (minimum) option is mutually exclusive with the
max and
closest options.
|
Default
|
closest — The closest parameter is mutually exclusive with the min and max parameter. When closest is defined, the operational PIR for the HSMDA queue will be the rate closest to the rate specified using the rate command
|
mbs {size [byte | kilobytes] | default}
The Maximum Burst Size (mbs) command specifies the relative amount of the buffer pool space for the maximum buffers for a specific HSMDA queue.
The no form of the command returns the MBS size for the queue to the default for the forwarding class.
Specifies the size of the MBS for the HSMDA queue.
The no form of the command returns the PIR size for the queue to the default value.
Specifies the PIR percentage rate for the HSMDA queue.
The no form of the command returns the weight value for the queue to the default value.
queue queue-id [multipoint
] [queue-type] [queue-mode] pool pool-name
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 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 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.
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.
This keyword specifies that this queue-id is for multipoint forwarded traffic only. This queue-id can only be explicitly mapped to the forwarding class multicast, broadcast, or unknown unicast ingress traffic. If you attempt to map forwarding class unicast traffic to a multipoint queue, an error is generated and no changes are made to the current unicast traffic queue mapping.
A queue must be created as multipoint. The multipoint designator cannot be defined after the queue is created. If an attempt is made to modify the command to include the multipoint keyword, an error is generated and the command will not execute.
The multipoint keyword can be entered in the command line on a pre-existing multipoint queue to edit queue-id parameters.
|
Values
|
profile-mode: When the queue is operating in the profile mode (or, the color aware mode), the queue tries to provide the appropriate bandwidth to the packets with different profiles. The profiles are assigned according to the configuration of the forwarding class or the sub-forwarding class.
|
priority-mode: The queue is capable of handling traffic differently with two distinct priorities. These priorities are assigned by the stages preceding the queueing framework in the system. In priority mode, the queue does not have the functionality to support the profiled traffic and in such cases the queue will have a degraded performance. However, the converse is not valid and a queue in profile mode should be capable of supporting the different priorities of traffic.
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
pir and
cir apply.
|
Values
|
pir — Defines the constraints enforced when adapting the PIR rate defined within the queue queue-id rate command. The pir parameter requires a qualifier that defines the constraint used when deriving the operational PIR for the queue. When the pir command is not specified, the default applies.
|
cir — Defines the constraints enforced when adapting the CIR rate defined within the
queue queue-id
rate command. The
cir parameter requires a qualifier that defines the constraint used when deriving the operational CIR for the queue. When the
cir parameter is not specified, the default constraint applies.
max — The
max (maximum) option is mutually exclusive with the
min and
closest options. When
max is defined, the operational PIR for the queue will be equal to or less than the administrative rate specified using the
rate command.
min — The
min (minimum) option is mutually exclusive with the
max and
closest options. When
min is defined, the operational PIR for the queue will be equal to or greater than the administrative rate specified using the
rate command.
closest — The
closest parameter is mutually exclusive with the
min and
max parameter. When
closest is defined, the operational PIR for the queue will be the rate closest to the rate specified using the
rate command.
The no form of this command restores the average frame overhead parameter for the queue to the default value of 0 percent. When set to 0, the system uses the packet based queue statistics for calculating port scheduler priority bandwidth allocation. If the no avg-frame-overhead command is executed in a queue-override queue id context, the avg-frame-overhead setting for the queue within the sap-egress QoS policy takes effect.
The Committed Burst Size (cbs) command specifies the relative amount of reserved buffers for a specific ingress network MDA forwarding class queue or egress network port forwarding class queue. The value is entered as a percentage.
The no form of this command
returns the CBS size for the queue to the default for the forwarding class.
The cbs value is used to calculate the queue’s CBS size based on the total amount of buffer space allocated for the buffer pool on the egress network port or channel. This buffer pool size will dynamically fluctuate based on the port or channel’s egress pool size setting.
For network ingress, each forwarding class is supported by an ingress queue per MDA. These forwarding class queues are automatically created once a single port or channel is placed in the network mode on the MDA and are removed once all network ports or channels are removed from the MDA (defined as access). The configuration parameters for each queue come from the applied ingress policy under the network context of the MDA.
The cbs value is used to calculate the queue’s CBS size based on the total amount buffer space allocated for the network ingress buffer pool on the MDA. This buffer pool will dynamically fluctuate based on the sum of all ingress pool sizes for all network ports and channels on the MDA.
The cbs forwarding class defaults are listed in the table below:
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 network queue policy.
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 network queue policy from having an affect on the queue.
The no form of this command restores the default value.
The high-prio-only forwarding class defaults are listed in the table below.
The Maximum Burst Size (mbs) command specifies the relative amount of the buffer pool space for the maximum buffers for a specific ingress network MDA forwarding class queue or egress network port forwarding class queue. The value is entered as a percentage.
The no form of the command returns the MBS size for the queue to the default for the forwarding class.
The mbs value is used to calculate the queue’s MBS size based on the total amount buffer space allocated for the buffer pool on the egress network port or channel. This buffer pool size will dynamically fluctuate based on the port or channels egress pool size setting.
The total MBS settings for all network egress queues on the port or channel based on the total percentages can exceed 100 percent. Some oversubscription can be desirable to allow exceptionally busy forwarding classes more access to buffer space. The proper use of CBS settings will ensure that oversubscribing MBS settings will not starve other queues of buffers when needed.
For network ingress, each forwarding class is supported by an ingress queue per MDA. These forwarding class queues are automatically created once a single port or channel is placed in the network mode on the MDA and are removed once all network ports or channels are removed from the MDA (defined as access). The configuration parameters for each queue come from the applied ingress policy under the network context of the MDA.
The mbs value is used to calculate the queue’s MBS size based on the total amount buffer space allocated for the network ingress buffer pool on the MDA. This buffer pool will dynamically fluctuate based on the sum of all ingress pool sizes for all network ports and channels on the MDA.
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.
The specified pool-name identifies a named pool where the policy will be applied. Each queue created within the system is tied to a physical port. When the policy is applied and the queue is created, the system will scan the named pools associated with the port to find the specified pool name. If the pool is not found on the port, the system will then look at named pools defined at the ports MDA level. If the pool name is not found on either the port or MDA, the queue will be marked as ‘pool-orphaned’ and will be mapped to the appropriate default pool. If the pool comes into existence, the queue will be moved from the default pool to the new named pool and the ‘pool-orphaned’ state will be cleared. The specified name must be an ASCII name string up to 32 characters long.
port-parent [weight
weight] [level
level] [cir-weight
cir-weight] [cir-level
cir-level]
When a network-queue policy is associated with an MDA or CMA for ingress queue definition, the port-parent association of the queues are ignored.
The no form of this command removes a port scheduler parent association for the queue or scheduler. If a port scheduler is defined on the port which the queue or scheduler instance exists, the queue or scheduler will become orphaned.
rate percent [cir
percent]
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 oversubscription 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 areconsidered 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.
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 (100, 0).
The actual PIR rate is dependent on the queue’s
adaptation-rule parameters and the actual hardware where the queue is provisioned.
A:ALA-12# show qos network-queue nq1
==============================================================================
QoS Network Queue Policy
==============================================================================
Network Queue Policy (nq1)
------------------------------------------------------------------------------
Policy : nq1
Description : (Not Specified)
------------------------------------------------------------------------------
Associations
------------------------------------------------------------------------------
Port-id : 1/1/1
==============================================================================
A:ALA-12>show>qos#
A:ALA-12>show>qos# network-queue nq1 detail
==============================================================================
QoS Network Queue Policy
==============================================================================
Network Queue Policy (nq1)
------------------------------------------------------------------------------
Policy : nq1
Description : (Not Specified)
------------------------------------------------------------------------------
Queue CIR PIR CBS MBS HiPrio
------------------------------------------------------------------------------
1 0 100 1 50 10
2 25 100 5 50 10
3 25 100 20 50 10
4 25 100 5 25 10
5 100 100 20 50 10
6 100 100 20 50 10
7 10 100 5 25 10
8 10 100 5 25 10
------------------------------------------------------------------------------
FC UCastQ
------------------------------------------------------------------------------
be 1
l2 2
af 3
l1 4
h2 5
ef 6
h1 7
nc 8
------------------------------------------------------------------------------
Associations
------------------------------------------------------------------------------
Port-id : 1/1/1
==============================================================================
A:ALA-12>show>qos#
