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.
no description
This command creates a context to configure a network queue policy. Network queue policies define the ingress network queuing at the FP network node level and on the Ethernet port and SONET/SDH path level to define network egress queuing.
network-queue “default”
This command enters the context to configure queue definitions for use on HSMDAs.
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 14-byte Ethernet DLC header, 4-byte or 8-byte VLAN tag (optional), 20-byte IP header, IP payload, and the 4-byte CRC (everything except the preamble and inter-frame gap). For example, the packet-byte-offset command can be used to add the frame encapsulation overhead (20 bytes) to the queue’s accounting functions. The accounting functions affected include:
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 add or subtract keywords 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. For example, in 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.
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 subscriber packets on an Ethernet aggregation network.
The packet-byte-offset value may be overridden for the HSMDA queue at the network queue level.
The no form of this command removes any accounting size changes to packets handled by the queue.
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 create or dynamically assign the queue to the object to which the policy is applied. The queue identified by queue-id always exists whether the command is executed or not. For HSMDA SAPs and subscribers, all eight queues exist when 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 queue’s Best-Effort or Expedited nature and the dynamic rate of the queue relative to the defined CIR. The HSMDA queues are handled differently. The create time auto-expedite, explicit expedite, and best-effort qualifiers have been eliminated; instead, the scheduling behavior is based solely on the queue’s identifier. Queues with a queue-id of 1 are placed in scheduling class 1. Queues with a queue-id of 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.
Unlike standard service queues, the HSMDA queues do not need to be placed into the special mode profile at create time in order to support ingress color aware policing. Each queue may handle in-profile, out-of-profile, and profile undefined packets simultaneously. As with standard queues, the explicit profile of a packet is dependent on the ingress sub-forwarding class to which the packet is mapped.
The no form of this 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 defines the method used by the system to derive the operational PIR settings when the HSMDA queue is provisioned in hardware. For the PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.
The no form of this 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.
This command defines 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 the 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 Maximum Burst Size (mbs) command specifies the relative amount of the buffer pool space for the maximum buffers for a specific HSMDA queue.
The MBS value is used by a queue to determine whether it has exhausted its total allowed buffers while enqueuing packets. When the queue has exceeded its maximum number 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 against 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 no form of the command returns the MBS size for the queue to the default for the forwarding class.
This command specifies the PIR shaping rate for the HSMDA queue.
The no form of this command returns the PIR size for the queue to the default value.
This command associates an existing HSMDA slope policy with 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. When 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:
Ingress Slope Mapping
Egress Slope Mapping
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:
Up to 1024 HSMDA slope policies may be configured on a system.
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:
High Slope:
Low Slope:
Time-Average-Factor: 0
The no form of this 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.
This command assigns the weight value to the HSMDA queue.
The no form of this command returns the weight value for the queue to the default value.
This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop policy with the HSMDA queue.
The fc command is used to enter the forwarding class mapping context for the given fc-name. Each forwarding class maps by default to queues 1 (unicast) and 9 (multipoint).
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 create or dynamically assign the queue to the object to 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.
Best-Effort, Expedited, and Auto-Expedite Queue Behavior Based on Queue-ID
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; instead, the scheduling behavior is based solely on the queue’s 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.
Every HSMDA Queue Supports Profile Mode Implicitly
Unlike standard service queues, the HSMDA queues do not need to be placed into the special mode profile at create time in order to support ingress color aware policing. Each queue may handle in-profile, out-of-profile, and profile undefined packets simultaneously. As with standard queues, the explicit profile of a packet is dependent on the ingress sub-forwarding class to which the packet is mapped.
The no form of this 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 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. When 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 this 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 FP 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.
This command enters the context to configure a QoS network-queue policy queue.
Explicit definition of an ingress queue’s type status is supported. A single ingress queue allows support for multiple forwarding classes. The default behavior automatically chooses the expedited or best effort 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 best effort 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 queue type 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 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.
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 preexisting multipoint queue to edit queue-id parameters.
This command defines the method used by the system to derive the operational FIR, CIR, and PIR settings when the queue is provisioned in hardware. For the FIR, CIR, and PIR parameters individually, the system attempts to find the best operational rate depending on the defined constraint.
When configured on an egress HSQ queue group queue, the cir keyword is ignored. This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the adaptation-rule is performed under the hs-wrr-group within the network queue policy.
The no form of this command removes any explicitly defined constraints used to derive the operational FIR, CIR, and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for fir, cir, and pir apply.
adaptation-rule pir closest cir closest fir closest
This command configures the average frame overhead to define the average percentage that the offered load to a queue will expand during the frame encapsulation process before sending traffic on-the-wire. While the avg-frame-overhead value may be defined on any queue, it is only used by the system for queues that egress a SONET or SDH port or channel. Queues operating on egress Ethernet ports automatically calculate the frame encapsulation overhead based on a 20 byte per packet rule (8 bytes for preamble and 12 bytes for Inter-Frame Gap).
When calculating the frame encapsulation overhead for port scheduling purposes, the system determines the following values:
For egress Ethernet queues, the frame-encapsulation overhead is calculated by multiplying the number of offered-packets for the queue by 20 bytes. If a queue was offered 50 packets, the frame-encapsulation overhead would be 50 x 20 or 1000 octets.
As a special case, when a queue or associated intermediate scheduler is configured with a CIR-weight equal to 0, the system automatically sets the queue’s frame-based within-CIR offered-load to 0, preventing it from receiving bandwidth during the port scheduler’s within-CIR pass.
Port Scheduler Operation Using Frame Transformed Rates — The port scheduler uses the frame-based rates to figure the maximum rates that each queue may receive during the within-CIR and above-CIR bandwidth allocation passes. During the within-CIR pass, a queue may receive up to its frame-based within-CIR offered load. The maximum it may receive during the above-CIR pass is the difference between the frame-based within-PIR offered load and the amount of actual bandwidth allocated during the within-CIR pass.
SAP and Subscriber SLA-Profile Average Frame Overhead Override (applies only to the 7450 ESS and 7750 SR) — The average frame overhead parameter on a sap-egress may be overridden at an individual egress queue basis. On each SAP and within the sla-profile policy used by subscribers, an avg-frame-overhead command may be defined under the queue-override context for each queue. When overridden, the queue instance will use its local value for the average frame overhead instead of the sap-egress-defined overhead.
The no form of this command restores the average frame overhead parameter for the queue to the default value of 0%. 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.
no avg-frame-overhead
The Committed Burst Size (cbs) command specifies the relative number of reserved buffers for a specific ingress network FP 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. When the queue has exceeded the number 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. At egress, there are two additional RED slopes maintained in each buffer pool: the highplus slope is used by inplus-profile packets, and the exceed slope is used by exceed-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 slope policy assigned to the FP 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 no form of this command returns the CBS size for the queue to the default for the forwarding class.
The cbs forwarding class defaults are listed in the Table 25.
Forwarding Class | Forwarding Class Label | Default CBS |
Network-Control | nc | 3 |
High-1 | h1 | 3 |
Expedited | ef | 1 |
High-2 | h2 | 1 |
Low-1 | l1 | 3 |
Assured | af | 1 |
Low-2 | l2 | 3 |
Best-Effort | be | 1 |
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.
The total reserved buffers based on the total percentages can exceed 100 percent. This might not be desirable and should be avoided as a rule of thumb. If the total percentage equals or exceeds 100 percent of the buffer pool size, no buffers will be available in the shared portion of the pool. Any queue exceeding its CBS size will experience a hard drop on all packets until it drains below this threshold.
The cbs value is used to calculate the queue’s CBS size based on the total amount of buffer space allocated for the network ingress buffer pool on the FP. This buffer pool will dynamically fluctuate based on the sum of all ingress pool sizes for all network ports and channels on the FP.
The total reserved buffers based on the total percentages can exceed 100 percent. This might not be desirable and should be avoided as a rule of thumb. If the total percentage equals or exceeds 100 percent of the buffer pool size, no buffers will be available in the shared portion of the pool. Any queue exceeding its CBS size will experience a hard drop on all packets until it drains below this threshold.
This command enters the context to configure queue drop tail parameters.
This command enters the context to configure the queue low drop tail parameters. The low drop tail defines the queue depth beyond which out-of-profile packets will not be accepted into the queue and will be discarded.
This command configures the ingress and egress network queue low drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and percent-reduction-from-mbs is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value and will be discarded.
The exceed drop tail is not configurable for network queues, however, it is set to a value of 10% in addition to low drop tail and capped by the MBS.
percent-reduction-from-mbs 10
This command specifies the relative amount of buffer pool space for the maximum buffers for a specific ingress network FP forwarding class queue or egress network port forwarding class queue. The value is entered as a percentage.
The MBS value is used by a queue to determine whether it has exhausted its total allowed buffers while enqueuing packets. When 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 is not guaranteed to have a buffer available when needed or that the packet’s RED slope will not force the discard of the packet. In order to safeguard against queue starvation (when a queue does not receive its fair share of buffers), set proper CBS parameters and control CBS oversubscription. Another safeguard is to properly set the RED slope parameters for the needs of the network queues.
The MBS 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.
The no form of this command returns the MBS 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 over-subscription 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.
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 FP. This buffer pool will dynamically fluctuate based on the sum of all ingress pool sizes for all network ports and channels on the FP.
The total MBS settings for all network egress queues on the port or channel based on the total percentages can exceed 100 percent. Some over-subscription 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.
This command specifies whether this queue feeds off a port-level scheduler. For the network-queue policy context, only the port-parent command is supported. When a port scheduler exists on the port, network queues without a port-parent association will be treated as an orphan queue on the port scheduler and treated according to the current orphan behavior on the port scheduler. If the port-parent command is defined for a network queue on a port without a port scheduler defined, the network queue will operate as if a parent association does not exist. When a port scheduler policy is associated with the egress port, the port-parent command will come into effect.
When a network-queue policy is associated with an FP for ingress queue definition, the port-parent association of the queues is 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 then the queue or scheduler instance exists, the queue or scheduler will become orphaned.
no port-parent
This command defines the administrative Peak Information Rate (PIR), the administrative Committed Information Rate (CIR), and the administrative Fair Information Rate (FIR) parameters for the queue.
The PIR defines the percentage that the queue can transmit packets through the switch fabric (for ingress queues) or out of an egress port (for 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 bandwidth.
The CIR defines the percentage at which the system prioritizes the queue over other queues competing for the same bandwidth.
The CIR can be used by the queue’s port-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 port scheduler.
The FIR defines an additional percentage at which the system prioritizes the queue over other queues competing for the same bandwidth above that used by the CIR percentage.
The rate command can be executed at any time, altering the PIR, CIR, and FIR for all queues created through the association of the network queue policy with the queue-id.
When configured on an egress HSQ queue group queue, the cir keyword is ignored.
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the rate is performed under the hs-wrr-group within the network queue policy.
The no form of the command returns all queues created with the queue-id by association with the network queue policy to the default PIR, CIR, and FIR parameters.
rate 100 cir 0 fir 0
The actual PIR used is dependent on the queue’s adaptation-rule parameters and the actual hardware where the queue is provisioned.
This command copies or overwrites existing network queue QoS policies to another network queue policy ID.
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.
This command displays network queue policy information.
The following output is an example of network-queue information.