6.4. Service Egress and Ingress QoS Policy Command Reference

This command creates a text description stored in the configuration file for a configuration context.

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

This command is used to create or edit a service egress QoS policy. The egress policy defines the Service Level Agreement (SLA) for service packets as they egress on the SAP.

Policies in effect are templates that can be applied to multiple services as long as the scope of the policy is template. The queues defined in the policy are not instantiated until a policy is applied to a service.

A sap-egress policy differs from sap-ingress policies in the complexity of the QoS parameters that can be defined. At ingress, policies determine queue mappings based on ingress DSCP and dot1p criteria. Multiple queues can be created per forwarding class and each queue can have different CIR or PIR parameters.

At egress, the policies are much simpler, since the forwarding class and in-profile or out-of-profile determination is done at the original service ingress SAP. Egress SAP QoS policies allow the definition of queues and the mapping of forwarding classes to those queues. Each queue needs to have a relative CIR for determining its allocation of QoS resources during periods of congestion. A PIR can also be defined that forces a hard limit on the packets transmitted through the queue. When the forwarding class is mapped to the queue, a dot1p value can optionally be specified. If specified, and the SAP has a dot1q or qinq encapsulation type, the dot1p value will be used for all packets that egress on that forwarding class. If the SAP is qinq-encapsulated, the qinq-mark-top-only command (under config>service) can be used to specify which qtags will have their dot1p marked or re-marked with the specified dot1p value. If the dot1p value is not specified, a dot1p value of 0 will be used. If the SAP is null-encapsulated, the dot1p value has no meaning.

Note: The ATM access egress shaping configuration in a SAP egress QoS policy is ignored when that policy is assigned to an ATM SAP. The shaping of the egress cell stream is controlled by the atm-td-profile command. If the atm-td-profile is not configured, the default atm-td-profile is in effect. See the atm-td-profile command for more information.

The sap-egress policy with policy-id 1 is the default sap-egress QoS policy and is applied to service egress SAPs when an explicit policy is not specified or removed.

The factory default settings for sap-egress policy-id 1 define a single queue with PIR set to the maximum value and a CIR set to 0. The single queue is the default queue and all forwarding classes will map to it. Packets being tagged according to the defined SAP encapsulation will have the dot1p bits set to 0 for the new tags being added. If the tag already exists and the default sap-egress policy is being used, the dot1p bits are not changed.

Note: If the egress port encapsulation type is qinq, the SAP type is X.Y, and one tag already exists and a new tag must be added, then the new outer tag’s dot1p bits will be set to the inner tag’s dot1p bits value. For all other port types and SAP types, new tags will have a dot1p-bits value of 0 if the default policy is used.

Any changes made to an existing policy, using any of the sub-commands, will be applied immediately to all egress SAPs where this policy is applied. For this reason, when many changes are required on a policy, it is highly recommended that the policy be copied to a work area policy-id. That work-in-progress policy can be modified until complete and then written over the original policy-id. Use the config qos copy command to maintain policies in this manner.

The no form of this command deletes the sap-egress policy. A policy cannot be deleted until it is removed from all service SAPs where it is applied. When a sap-egress policy is removed from a SAP, the SAP will revert to the default sap-egress policy-id 1.

The fc fc-name mode within the SAP egress QoS policy is used to contain the explicitly defined queue mapping and dot1p marking commands for fc-name. When the mapping for fc-name points to the default queue and the dot1p marking is not defined, the mode for fc-name is not displayed in the show configuration or save configuration output unless the detail option is specified.

The no form of the command removes the explicit queue mapping and dot1p marking commands for fc-name. The queue mapping reverts to the default queue for fc-name, and the dot1p marking (if appropriate) uses the default of 0.

This command is used to modify the size of the packet that schedulers operate on. Modification only impacts schedulers and queue statistics. The actual packet size is not modified, nor can it be. Only the size used by the schedulers to determine the scheduling is changed. The packet-byte-offset command is meant to be a mechanism that can be used to compensate for downstream encapsulation or header removal. The scheduling rates are affected by the offset, as well as the statistics (accounting) associated with the queue. The packet-byte-offset command does not affect port-level and service-level statistics. It only affects the queue statistics. The network-queue policy applies in both the ingress and egress directions.

The add and subtract keywords are mutually exclusive. Either add, subtract, or none must be specified.

There are three possible modes of packet-byte-offset operation:

Packet byte offset configuration can be applied at the policy level, in which case it applies to all of the queues within the policy, or at the individual queue level so that it applies only to a specific queue.

The no version of this command enables legacy 7705 SAR behavior where the queue rates are relative to the packet size with the internal fabric header added, but without the FCS.

This command configures a policy name for the SAP egress policy.

This command enables the context to configure a service egress policy queue. Explicit definition of an egress queue’s hardware scheduler status is supported. A single egress 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 egress ports. The hardware status of the queue must be defined at the time of queue creation within the policy.

The no form of the command removes the queue-id from the service egress policy. Removing the queue-id also removes it from any existing SAPs using the policy. If any forwarding classes are mapped to the queue, they revert to the default queue.

When a queue is removed, pending accounting information for each service egress queue created due to the definition of the queue in the policy is discarded.

This command is used to enter the scope of the policy. The scope of the policy cannot be changed if the policy is applied to one or more services.

The no form of this command sets the scope of the policy to the default of template.

This command explicitly defines the egress dot1p priority bits values for the forwarding class.

Note: When the dot1p dot1p-value command is used, the value is applied to both in-profile and out-of-profile packets. When the dot1p in-profile dot1p-value out-profile dot1p-value form is used, different dot1p values for in-profile or out-of-profile packets can be specified. For QinQ applications, the top and bottom dot1p bits or top-only dot1p bits are set based on the qinq-mark-top-only configuration. For more information, refer to the command description and the “QinQ Top-Only Mark Option” section in the 7705 SAR Services Guide.

The no form of the command sets the dot1p priority bits value to 0.

This command defines the DSCP name or DSCP priority bits mapping for the forwarding class.

Note: When the dscp dscp-name command is used, the dscp-name is applied to all packets regardless of the profile state. The in-profile and out-profile form of the command allows differentiated values to be applied to packets based on the profile state.

Access IP traffic (that is, VPRN and IES access interfaces) will always be re-marked if the interfaces are configured as part of the SAP egress QoS policy.

The no form of the command removes the DSCP mapping associated with the forwarding class.

This command specifies the egress queue to which the traffic associated with the forwarding class is to be forwarded. The command overrides the default queue mapping for fc fc-name. The specified queue-id must exist within the policy before the mapping can be made. Once the forwarding class mapping is executed, all traffic classified to the fc-name on a SAP using this policy will use the indicated queue.

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

This command enables the context to configure MC-MLPPP SAP egress QoS commands.

This command is used to create or edit an MC-MLPPP SAP egress QoS policy. The egress policy defines the Service Level Agreement (SLA) for service packets as they egress on the SAP.

Policies are templates that can be applied to multiple services as long as the scope of the policy is template. The queues defined in the policy are not instantiated until a policy is applied to a service. At egress, the forwarding class and in- or out-of-profile determination is done at the original service ingress SAP. MC-MLPPP egress SAP QoS policies allow the definition of queues and the mapping of forwarding classes to those queues. Each queue must have a PIR defined that forces a hard limit on the packets transmitted through the queue.

The sap-egress policy with policy-id 1 is the default sap-egress QoS policy and is applied to MC-MLPPP egress SAPs when an explicit policy is not specified or is removed.

The default settings for sap-egress policy-id 1 define a single queue with PIR set to the maximum value. The single queue is the default queue and all forwarding classes will map to it. Any changes made to an existing policy, using any of the sub-commands, will be applied immediately to all egress SAPs where this policy is applied. For this reason, when many changes are required on a policy, it is highly recommended that the policy be copied to a work area policy-id. That work-in-progress policy can be modified until complete and then written over the original policy-id. Use the config qos copy command to maintain policies in this manner.

The no form of this command deletes the sap-egress policy. A policy cannot be deleted until it is removed from all service SAPs where it is applied. When a sap-egress policy is removed from a SAP, the SAP will revert to the default sap-egress policy-id 1, which cannot be deleted.

The fc fc-name mode within the MC-MLPPP SAP egress QoS policy is used to contain the explicitly defined queue mapping for fc-name.

The no form of the command removes the explicit queue mapping for fc-name. The queue mapping reverts to the default queue for fc-name.

This command configures a policy name for the MC-MLPPP SAP egress policy.

This command enables the context to configure an MC-MLPPP SAP egress policy queue. Explicit definition of an egress queue’s hardware scheduler status is supported. A single egress queue allows support for multiple forwarding classes.

The no form of the command removes the queue-id from the MC-MLPPP SAP egress policy. Removing the queue-id also removes it from any existing SAPs using the policy. If any forwarding classes are mapped to the queue, they revert to the default queue.

When a queue is removed, pending accounting information for each SAP egress queue created due to the definition of the queue in the policy is discarded.

This command is used to enter the scope of the policy. The scope of the policy cannot be changed if the policy is applied to one or more services.

The no form of this command sets the scope of the policy to the default of template.

This command defines the DSCP name for the forwarding class.

This command specifies the MC-MLPPP egress queue to which the traffic associated with the forwarding class is to be forwarded. The command overrides the default queue mapping for fc fc-name. The specified queue-id must exist within the policy before the mapping can be made. Once the forwarding class mapping is executed, all traffic classified to the fc-name on a SAP using this policy will use the indicated queue.

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

This command is used to define how an operational rate is selected based on the configured PIR rate. Operational rates are the finite set of rates at which the schedulers on the network processor can operate.

The no form of the command removes any adaptation-rule constraints used to derive the operational rates for the policy. When a specific adaptation-rule is removed, the default constraints for rate apply.

This command overrides the default Committed Buffer Space (CBS) reserved buffers for the queue.

The value in kilobytes is converted automatically to the number of buffers. The conversion calculation uses a non-configurable buffer size of 2304 bytes or 512 bytes, depending on the type of adapter card. See Table 4 for a list of adapter cards and their associated buffers. The calculation is:

Number of buffers = Configured CBS value in bytes / Buffer size in bytes

The no form of this command returns the CBS size to the default value.

The high-prio-only command configures the percentage of buffer space for the queue, used exclusively by high-priority packets. The specified value overrides the default value for the context.

The priority of a packet can only be set in the service ingress policy and is only applicable on the ingress queues for a SAP. The profile state is used for enqueuing priority at sap-egress.

The no form of this command restores the default high-priority reserved size.

This command sets the Maximum Burst Size (MBS) value for the buffers of the specific queue. The value is configured in bytes or kilobytes and overrides the default value for the context. The default configuration is in kilobytes.

The config>qos>mc-mlppp>sap-egress>info detail screen shows the MBS in terms of bytes, unless it is a multiple of 1000. In that case, the display shows the MBS in kilobytes. For example, entering mbs 200 or mbs 200 kilobytes configures and displays “200 kilobytes”, entering mbs 200000 bytes also configures and displays “200 kilobytes”, and entering mbs 200100 bytes configures and displays “200100 bytes”.

Note: For the 7705 SAR, a 1 kbyte of buffer management space is 1000 bytes.

The MBS value in bytes is converted automatically to packets. The conversion calculation uses a non-user-configurable buffer size of 2304 bytes or 512 bytes, depending on the type of adapter card. See Table 4 for a list of adapter cards and their associated buffers. The calculation is:

Number of buffers = Configured MBS value in bytes / Buffer size in bytes (2304 or 512)

The MBS value is used by a queue to determine whether it has exhausted all of its buffers while enqueuing packets. Once the queue has exceeded the amount of buffers allowed by MBS, all packets are discarded until packets have been drained from the queue.

The sum of the MBS for all queues on an adapter card can exceed the total amount of buffering available. Therefore, for a packet arriving at a queue that has not exceeded its MBS size, it is not guaranteed that a buffer will be available. If a buffer is not available, the packet will be discarded. RED/WRED slope parameters can be configured to control congestion in the case where the buffer capacity of the card is becoming exhausted.

Setting proper CBS parameters and controlling CBS oversubscription is one major safeguard against queue starvation (that is, when a queue does not receive its fair share of buffers). Another safeguard is to properly set the RED/WRED slope parameters for the needs of services on this port or channel.

The no form of this command returns the MBS size assigned to the queue to the default value.

This command defines the administrative PIR parameters for the queue. The PIR defines the maximum rate that the queue can transmit packets out an egress interface. 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 rate command can be executed at any time, altering the PIR rates for all queues created through the association of the MC-MLPPP SAP egress 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 parameters (max).

This command specifies the slope parameters controlling the queue.

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

This command is used to create or edit the ingress policy. The ingress policy defines the Service Level Agreement (SLA) enforcement that service packets receive as they ingress a SAP. SLA enforcement is accomplished through the definition of queues that have Forwarding Class (FC), Committed Information Rate (CIR), Peak Information Rate (PIR) and Maximum Burst Size (MBS) characteristics. The simplest policy defines a single queue that all ingress traffic flows through. Complex policies have multiple queues that indicate which queue a packet will flow though.

Policies are templates that can be applied to multiple services as long as the scope of the policy is template. Queues defined in the policy are not instantiated until a policy is applied to a service SAP.

It is possible that a service ingress policy will include the dscp map command and the dot1p map command. When multiple matches occur for the traffic, the order of precedence will be used to arrive at the final action. The order of precedence is as follows:

The service ingress policy with policy-id 1 is a system-defined policy applied to services when no other policy is explicitly specified. The system-defined service ingress policy cannot be modified or deleted.

The no version of this command restores the factory default settings when used on policy-id 1. The default service ingress policy defines one queue associated with the best effort (be) forwarding class, with CIR of 0 and PIR of line rate.

Any changes made to the existing policy, using any of the sub-commands, are applied immediately to all services where this policy is applied. For this reason, when many changes are required on a policy, it is recommended that the policy be copied to a work area policy ID. That work-in-progress policy can be modified until complete and then written over the original policy-id. Use the config qos copy command to maintain policies in this manner.

The no sap-ingress policy-id command deletes the service ingress policy. A policy cannot be deleted until it is removed from all services where it is applied. The system default sap-ingress policy is a special case.

This command configures the Service Ingress QoS policy scope as exclusive or template.

The policy’s scope cannot be changed if the policy is applied to a service.

The no form of this command sets the scope of the policy to the default of template.

This command configures the default forwarding class for the policy. In the event that an ingress packet does not match a higher priority (more explicit) classification command, the default forwarding class will be associated with the packet. Unless overridden by an explicit forwarding class classification rule, all packets received on an ingress SAP using this ingress QoS policy will be classified to the default forwarding class. Optionally, the default ingress enqueuing priority for the traffic can be overridden as well.

The default forwarding class for default-fc is best effort (be). The default-fc settings are displayed in the show configuration and save output regardless of inclusion of the detail keyword.

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

This command configures the default enqueuing priority for all packets received on an ingress SAP using this policy.

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

This command is used to create a class of the forwarding class fc-name.

The no form of the command removes all the explicit queue mappings for fc-name forwarding types. The queue mappings revert to the default queues for fc-name.

This command explicitly sets the forwarding class and/or enqueuing priority when a packet is marked with a dot1p-priority specified. Adding a dot1p rule on the policy forces packets that match the dot1p-priority specified to override the forwarding class and enqueuing priority based on the parameters included in the dot1p rule. When the forwarding class is not specified in the rule, a matching packet preserves (or inherits) the existing forwarding class derived from earlier matches in the classification hierarchy. When the enqueuing priority is not specified in the rule, a matching packet preserves (or inherits) the existing enqueuing priority derived from earlier matches in the classification hierarchy.

The dot1p-priority is derived from the most significant three bits in the IEEE 802.1Q or IEEE 802.1P header. The three dot1p bits define eight Class-of-Service (CoS) values commonly used to map packets to per-hop Quality-of-Service (QoS) behavior.

For QinQ applications, the dot1p bits used for classification are from either the top or bottom tag based on the match-qinq-dot1p configuration. For more information, refer to the command description and the “QinQ Dot1p Match Behavior” section in the 7705 SAR Services Guide.

The no form of this command removes the explicit dot1p classification rule from the service ingress policy. Removing the rule on the policy immediately removes the rule on all ingress SAPs using the policy.

This command explicitly sets the forwarding class and/or enqueuing priority when a packet is marked with the DiffServ Code Point (DSCP) value contained in dscp-name. Adding a DSCP rule on the policy forces packets that match the specified DSCP value to override the forwarding class and enqueuing priority based on the parameters included in the DSCP rule.

When the forwarding class is not specified in the rule, a matching packet preserves (or inherits) the existing forwarding class derived from earlier matches in the classification hierarchy. When the enqueuing priority is not specified in the rule, a matching packet preserves (or inherits) the existing enqueuing priority derived from earlier matches in the classification hierarchy.

The DSCP value (referred to by dscp-name) is derived from the most significant six bits in the IP header ToS byte field (DSCP bits). The six DSCP bits define 64 DSCP values used to map packets to per-hop QoS behavior.

A list of up to 8 DSCP names can be specified to assign DSCP values to an FC mapping for DSCP classification.

The no form of this command removes the DiffServ code point to forwarding class association. The default-action then applies to that code point value.

This command configures a policy name for the SAP ingress policy.

This command enables the context to configure a service ingress 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 no form of this command removes the queue-id from the service ingress 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 service queue created due to the definition of the queue in the policy is discarded.

This command maps the broadcast forwarding type queue to the fc fc-name. The specified queue-id must already have been created within the policy 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 no form of the command sets the broadcast forwarding type queue-id back to the default of no mapping to an FC.

This command, when enabled on a parent forwarding class, applies a color profile mode to the packets stored in the queue associated with this forwarding class.

When this QoS policy is applied to the ingress of an FR VLL SAP, DE=1 frames are classified as out-of-profile and are not subject to the CIR marking.

All received DE=0 frames that exceed the CIR are marked as out-of-profile and have the DE set to 1, regardless of whether this command is enabled or disabled.

The priority option, if used, has no effect. All FR VLL DE=1 frames have their priority automatically set to low; DE=0 frames have their priority set to high.

All other capabilities of the Fpipe service are maintained. These capabilities include re-marking of the DE bit on egress SAP, and FR PW control word on egress network port for the packets that were classified as out-of-profile at the ingress SAP.

The de-1-out-profile command has an effect only when it is applied to the ingress of a SAP that is part of an Fpipe service.

The no form of the command disables the color profile mode of operation on all SAPs to which this ingress QoS policy is applied.

This command maps the multicast forwarding type queue to the fc fc-name. The specified queue-id must already have been created within the policy before the mapping can be made. Once the forwarding class mapping is executed, all multicast traffic on a SAP using this policy will be forwarded using the queue-id.

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

This command overrides the default forwarding type queue mapping for fc fc-name.

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

This command maps the unknown forwarding type queue to the fc fc-name. The specified queue-id must already have been created within the policy before the mapping can be made. Once the forwarding class mapping is executed, all unknown forwarding type traffic on a SAP using this policy will be forwarded using the queue-id.

The no form of the command sets the unknown forwarding type queue-id back to the default of no mapping to an FC.

This command can be used to define how an operational rate is selected based on the configured PIR or CIR rate. Operational rates are the finite set of rates at which the schedulers on the network processor can operate.

The no form of the command removes any adaptation-rule constraints used to derive the operational rates for the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.

This command overrides the default Committed Buffer Space (CBS) reserved for buffers of a specified queue. The value is configured in kilobytes.

The value in kilobytes is converted automatically to the number of buffers. The conversion calculation uses a non-configurable buffer size of 2304 bytes or 512 bytes, depending on the type of adapter card. See Table 4 for a list of adapter cards and their associated buffers. The calculation is:

Number of buffers = Configured CBS value in bytes / Buffer size in bytes

At the egress of an N > 1 Apipe, the CBS value in a SAP egress QoS policy that is assigned to a SAP aggregation group causes n times that value of buffers to be committed, where n is the number of SAPs in the SAP aggregation group. See the show pools command for information about how to view buffer pools for SAPs that are members of a SAP aggregation group. See the 7705 SAR Services Guide for information about how to configure SAP aggregation groups.

The no form of this command returns the CBS size to the default value.

This command configures the percentage of buffer space for the queue, used exclusively by high-priority packets. The specified value overrides the default value for the context.

The priority of a packet can only be set in the service ingress policy and is only applicable on the ingress queues for a SAP. The profile state is used for enqueuing priority at sap-egress.

The no form of this command restores the default high-priority reserved size.

This command sets the Maximum Burst Size (MBS) value for the buffers of the specified queue. The value is configured in bytes or kilobytes, and overrides the default MBS value. The default configuration is in kilobytes.

The config>qos>sap-ingress>info detail and sap-egress>info detail screens show the MBS in terms of bytes, unless it is a multiple of 1000. In that case, the display shows the MBS in kilobytes. For example, entering mbs 200 or mbs 200 kilobytes configures and displays “200 kilobytes”, entering mbs 200000 bytes also configures and displays “200 kilobytes”, and entering mbs 200100 bytes configures and displays “200100 bytes”.

Note: For the 7705 SAR, 1 kbyte of buffer management space is 1000 bytes.

The MBS value in bytes is converted automatically to the number of buffers. The conversion calculation uses a non-configurable buffer size of 2304 bytes or 512 bytes, depending on the type of adapter card. See Table 4 for a list of adapter cards and their associated buffers. The calculation is:

Number of buffers = Configured MBS value in bytes / Buffer size in bytes (2304 or 512)

At the egress of an N > 1 Apipe, the MBS value in a SAP egress QoS policy that is assigned to a SAP aggregation group is used for each of the per-SAP queues for SAPs that are members of a SAP aggregation group. See the show pools command for information about how to view buffer pools for SAPs that are members of a SAP aggregation group. See the 7705 SAR Services Guide for information about how to configure SAP aggregation groups.

The MBS value is used by a queue to determine whether it has exhausted all of its buffers while enqueuing packets. Once the queue has exceeded the amount of buffers allowed by MBS, all packets are discarded until packets have been drained from the queue.

The sum of the MBS for all queues on an adapter card can exceed the total amount of buffering available. Therefore, for a packet arriving at a queue that has not exceeded its MBS size, it is not guaranteed that a buffer will be available. If a buffer is not available, the packet will be discarded. RED/WRED slope parameters can be configured to control congestion in the case where the buffer capacity of the card is becoming exhausted.

Setting proper CBS parameters and controlling CBS oversubscription is one major safeguard against queue starvation (that is, when a queue does not receive its fair share of buffers). Another safeguard is to properly set the RED/WRED slope parameters for the needs of services on this port or channel.

The no form of this command returns the MBS size assigned to the queue to the default value.

This command defines the administrative PIR and the administrative CIR parameters for the queue. Defining a PIR does not necessarily guarantee that the queue can transmit at the intended rate. Similarly, defining a CIR does not necessarily guarantee that the queue can schedule at the intended rate. The actual rate sustained by the queue can be limited by oversubscription factors or available bandwidth.

The cir keyword defines the rate at which the system prioritizes the queue over other queues competing for the same bandwidth.

For service ingress, the PIR defines the maximum rate that the queue can transmit packets towards the fabric. The cir keyword 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.

For service egress queues, the PIR defines the maximum rate that the queue can transmit packets out an egress interface.

When the PIR is set to max on a SAP-ingress queue, the max value defaults to the physical port line rate. On a SAP-egress queue, the PIR is set to the physical port line rate.

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 (max, 0).

Caution: The rate command can be executed at any time but should be executed during a maintenance window because the command can be service-affecting. Altering the PIR and CIR rates affects all queues created through the association of the service ingress or service egress QoS policy with the queue-id.

Note: The ingress traffic to an Epipe, Ipipe, IES, VPLS, and VPRN service may be shaped to a lower rate than the PIR and CIR values configured in the SAP ingress policy. At SAP ingress, the CIR and PIR settings under rate include both payload (customer) traffic and overhead traffic, which affects the shaping rate internally. Additional overhead bytes include the internal fabric header minus any bytes that have been removed from the original packet (such as the four-byte FCS). At SAP ingress, the actual shaping rate is related to the service rate (PIR or CIR) specified in the SAP ingress QoS policy, as shown below:           Shaping rate (actual) = (PIR or CIR) / ratio           where ratio = (customer packet size + additional bytes - removed headers -                                     4 byte FCS) / (customer packet size) At SAP egress, shaping does not include the FCS, so the actual shaping rate is a bit higher than the PIR/CIR ratio configured in the QoS policy.           Shaping rate (actual) = (PIR or CIR) / ratio           where ratio = (customer packet size - 4 byte FCS) / (customer packet size)

This command specifies the slope parameters controlling the queue.