For more information about monitor commands, refer to the 7450 ESS, 7750 SR, and 7950 XRS Basic System Configuration Guide for command usage and CLI syntax.
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 content in the configuration file.
The no form of this command removes the string from the configuration.
This command enables the context to define ingress and egress queue group templates.
This command enables the context to create ingress queue group templates. Ingress queue group templates can be applied to ingress ports to create an ingress queue group of the same name.
An ingress template must be created for a group-name prior to creating a queue group with the same name on an ingress port.
This command creates a queue group template. The system does not maintain default queue groups or queue group templates. Each queue group template used in the system must be explicitly created.
The queue-group-name parameter is required when executing the queue-group command and identifies the name of the template to be either created or edited. Each ingress queue group template must be uniquely named within the system. Multiple ingress queue group templates may not share the same name. An ingress and egress queue group template may share the same name.
The no form of this command removes the specified queue group template from the system. If the queue group template is currently in use by an ingress port, the command will fail. If queue-group-name does not exist, the command has no effect and does not return an error.
This command is used in ingress and egress queue-group templates to create, modify, or delete a policer.
Policers are created and used in a similar manner to queues. The policer ID space is separate from the queue ID space, allowing both a queue and a policer to share the same ID. The ingress queue-group template may have up to 32 policers (numbered 1 through 32) and may be defined, while the egress queue-group template supports a maximum of eight (numbered 1 through 8). While a policer may be defined in a queue-group template, it is not actually created until the queue-group template is instantiated on the ingress context of a forwarding plane or on the egress context of a port.
When a policer is created, the policer's metering rate and profiling rates may be defined, as well as the policer's maximum and committed burst sizes (MBS and CBS, respectively). Unlike queues that have dedicated counters, policers allow various stat-mode settings that define the counters that will be associated with the policer. Another supported feature—packet-byte-offset—provides a policer with the ability to modify the size of each packet based on a defined number of bytes.
When a policer is created, it cannot be deleted from the queue-group template unless any forwarding classes that are redirected to the policer are first removed.
The no version of this command deletes the policer.
This command defines the method used by the system to derive the operational CIR and PIR settings when the queue is provisioned in hardware. For the CIR and 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 CIR and PIR created by the application of the policy. When a specific adaptation-rule is removed, the default constraints for rate and cir apply.
adaptation-rule pir closest cir closest
This command specifies the name of the advanced configuration policy to be applied with this policer.
The cbs command is used to define the default committed buffer size for the template queue or the CBS for the template policer. Overall, the cbs command follows the same behavior and provisioning characteristics as the cbs command in the SAP ingress and egress QoS policy.
The no form of this command restores the default CBS size to the template policer.
default
Minimum non-zero default value - maximum of 10 ms of CIR or 6 kbytes on an FP2 and 7680 bytes on an FP3
This command is used to configure the percentage of the policer’s PIR leaky bucket's MBS (maximum burst size) that is reserved for high-priority traffic. While the mbs value defines the policer’s high-priority violate threshold, the percentage value defined is applied to the mbs value to derive the bucket’s low-priority violate threshold. See the mbs command details for information on which types of traffic is associated with each violate threshold.
This command specifies the default maximum buffer size for the template queue in bytes or kilobytes.
The MBS value is used by a queue to determine whether it has exhausted all of its buffers while enqueuing packets. When the queue has exceeded the amount of buffers allowed by MBS, all packets are discarded until packets have been drained from the queue.
The port>ethernet>access>ingress>queue-group and port>ethernet>access>egress>queue-group contexts for mbs provides a mechanism for overriding the default maximum size for the queue.
The sum of the MBS for all queues on an ingress access port can oversubscribe the total amount of buffering available. When congestion occurs and buffers become scarce, access to buffers is controlled by the RED slope that a packet is associated with. 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 services on this port or channel.
When configured on an egress queue group queue, this command and the queue-delay command are mutually exclusive. In order to change between the mbs and queue-delay parameters, the current parameter must be removed before adding the new parameter; that is, changing from mbs to queue-delay requires a no mbs before the queue-delay is configured and changing from queue-delay to mbs requires a no queue-delay before the mbs is configured. If queue-delay is configured for an egress queue group queue, it is not possible to override the MBS for that queue.
For policers, this command is used to configure the policer’s PIR leaky bucket’s high-priority violate threshold. The high-prio-only command is applied to the MBS value to derive the bucket’s low-priority violate threshold.
At ingress, trusted in-profile packets and untrusted high-priority packets use the policer’s high-priority violate threshold while trusted out-of-profile and untrusted low-priority packets use the policer's low-priority violate threshold.
At egress, inplus-profile and in-profile packets use the policer’s high-priority violate threshold and out-of-profile packets use the policer's low-priority violate threshold. Exceed-profile packets are discarded unless enable-exceed-pir is configured, in which case they are forwarded.
The PIR bucket’s violate threshold represents the maximum burst tolerance allowed by the policer. If the policer's offered rate is equal to or less than the policer's defined rate, the PIR bucket depth hovers around the 0 depth with spikes up to the maximum packet size in the offered load. If the offered rate increases beyond the metering rate, the amount of data allowed above the rate is capped by the threshold. The low-priority violate threshold provides a smaller burst size for the lower priority traffic associated with the policer. Since all lower priority traffic is discarded at the lower burst tolerance size, the remaining burst tolerance defined by high-prio-only is available for the higher priority traffic.
The policer’s mbs size defined in the QoS policy may be overridden on an SLA profile or SAP where the policy is applied.
The no form of this command returns the MBS size assigned to the queue to the value.
64 kbytes when PIR is the maximum; otherwise 10 ms volume of traffic for a configured non-zero or non-maximum PIR.
This command configures a packet byte offset for the QoS ingress queue-group policer.
none
This command is used to create a child-to-parent mapping between each instance of the policer and either the root arbiter or a specific tiered arbiter on the object where the policy is applied. Defining a parent association for the policer causes the policer to compete for the parent policer’s available bandwidth with other child policers mapped to the policer control hierarchy.
Policer control hierarchies may be created on SAPs or on a subscriber or multiservice site context. To create a policer control hierarchy on an ingress or egress SAP context, a policer-control-policy must be applied to the SAP. When applied, the system will create a parent policer that is bandwidth limited by the policy’s max-rate value under the root arbiter. The root arbiter in the policy also provides the information used to determine the various priority level discard-unfair and discard-all thresholds. Besides the root arbiter, the policy may also contain user-defined tiered arbiters that provide arbitrary bandwidth control for subsets of child policers that are either directly or indirectly parented by the arbiter.
When the QoS policy containing the policer with a parent mapping to an arbiter name exists on the SAP, the system will scan the available arbiters on the SAP. If an arbiter exists with the appropriate name, the policer to arbiter association is created. If the specified arbiter does not exist either because a policer-control-policy is not currently applied to the SAP or the arbiter name does not exist within the applied policy, the policer is placed in an orphan state. Orphan policers operate as if they are not parented and are not subject to any bandwidth constraints other than their own PIR. When a policer enters the orphan state, it is flagged as operationally degraded due to the fact that it is not operating as intended and a trap is generated. Whenever a policer-control-policy is added to the SAP or the existing policy is modified, the SAP's policer's parenting configurations must be reevaluated. If an orphan policer becomes parented, the degraded flag is cleared and a resulting trap is generated.
For subscribers, the policer control hierarchy is created through the policer-control-policy applied to the sub-profile used by the subscriber. A unique policer control hierarchy is created for each subscriber associated with the sub-profile. The QoS policy containing the policer with the parenting command comes into play through the subscriber sla-profile that references the QoS policy. The combining of the sub-profile and the sla-profile at the subscriber level provides the system with the proper information to create the policer control hierarchy instance for the subscriber. This functionality is available only for the 7450 ESS and 7750 SR.
Executing the parent command will fail if:
A policer with a parent command applied cannot be configured with stat-mode no-stats in either the QoS policy or as an override on an instance of the policer
When a policer is successfully parented to an arbiter, the parent commands level and weight parameters are used to determine at what priority level and at which weight in the priority level that the child policer competes with other children (policers or other arbiters) for bandwidth.
The no form of this command is used to remove the parent association from all instances of the policer.
This command enables a limit on the profile.
no profile-capped
This command defines the administrative Peak Information Rate (PIR) and the administrative Committed Information Rate (CIR) parameters for the queue or policer. The PIR defines the maximum rate that the queue or policer can transmit packets out an egress interface (for SAP egress queues or policer). Defining a PIR does not necessarily guarantee that the queue can transmit at the intended rate. The actual rate sustained by the queue or policer can be limited by oversubscription factors or available egress bandwidth.
The CIR defines the rate at which the system prioritizes the queue or policer over other queues or policer competing for the same bandwidth. In-profile, then out-of-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 throughout the network, the packets must be marked accordingly for profiling at each hop.
The CIR can be used by the queue or policer’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 any time, altering the PIR and CIR rates for all queues created through the association of the SAP egress QoS policy with the queue-id or policer-id.
The no form of this command returns all queues or policer created with the queue-id or policer-id by association with the QoS policy to the default PIR and CIR parameters (max, 0).
The actual PIR rate is dependent on the queue’s adaptation-rule parameters and the actual hardware where the queue or policer is provisioned.
Fractional values are not allowed and must be given as a positive integer. When max is specified, the maximum policer rate used will be equal to the maximum capacity of the card on which the policer is configured. If the policer rate is set to a value larger than the maximum rate possible for the card, the CIR used is equivalent to max.
This command is used to configure the forwarding plane counters that allow offered, forwarded, and dropped accounting to occur for the policer. An ingress policer has multiple types of offered packets (explicit in-profile, explicit out-of-profile, uncolored, high-priority or low-priority) and each of these offered types is interacting with the policer’s metering and profiling functions resulting in colored output packets (green, yellow, and red). Due to the large number of policers, it is not economical to allocate counters in the forwarding plane for all possible offered packet types and output conditions. Many policers, for example, will not be configured with a CIR profiling rate and not all policers will receive explicitly profiled offered packets. The stat-mode command allows provisioning of the number of counters each policer requires and how the offered packet types and output conditions should be mapped to the counters.
While a no-stats mode is supported that prevents any packet accounting, the use of the policer’s parent command requires that the policer's stat-mode be set at least to the minimal setting so that offered stats are available for the policer's Fair Information Rate (FIR) to be calculated. When a policer has been made a child to a parent policer, the stat-mode cannot be changed to no-stats unless the policer parenting is first removed.
Each time the policer’s stat-mode is changed, any previous counter values are lost and any new counters are set to zero.
Each mode uses a certain number of counters per policer instance that are allocated from the forwarding plane’s policer counter resources. The total/allocated/free stats can be viewed by using the tools dump resource-usage card fp command. If insufficient counters exist to implement a mode on any policer instance, the stat-mode change will fail and the previous mode will continue unaffected for all instances of the policer.
The stat-modes are described in Table 57.
Stat Mode | Stat Resources | Traffic Counters (Packet/Octets) | Comments | |
Offered | Dropped/Forwarded | |||
no-stats | 0 | None | None | |
Minimal | 1 | Single counter entering policer | Single counter for dropped/forwarded exiting policer | |
offered-profile-no-cir | 2 | In/out entering policer | In/out entering policer | Intended for when the policer does not change the profile of packets. Includes only in- and out-of-profile. |
offered-priority-no-cir | 2 | High/low entering policer | High/low entering policer | Intended for when only packet priority stats are required. |
offered-profile-cir | 4 | In/out/uncolored entering policer | In/out exiting policer | Intended for when the policer can change the profile of packets to in- and out-of-profile. |
offered-priority-cir | 4 | High/low entering policer | In/out exiting policer | Intended for when packet priority entering the policer and profile exiting the policer is required. |
offered-total-cir | 2 | Single counter entering policer | In/out exiting policer | |
offered-limited-profile-cir | 3 | Out/uncolored entering policer | In/out exiting policer | Intended for when the policer can change the profile of packet to in- and out-of-profile. The information is limited compared to offered-profile-capped-cir with the benefit of using one less stat resource. |
offered-profile-capped-cir | 5 | In/out/uncolored entering policer | In/out exiting policer | Intended for when the policer has profile-capped configured. |
offered-limited-capped-cir | 4 | In/uncolored entering policer | In/out exiting policer | Intended for when the policer has profile-capped configured. The information is limited compared to offered-profile-capped-cir with the benefit of using one less stat resource. |
The default stat-mode when a policer is created within the policy is minimal.
The stat-mode setting defined for the policer in the QoS policy may be overridden on an sla-profile or SAP where the policy is applied. If insufficient policer counter resources exist to implement the override, the stat-mode override command will fail. The previous stat-mode setting active for the policer will continue to be used by the policer.
The no form of this command attempts to return the policer’s stat-mode setting to minimal. The command will fail if insufficient policer counter resources exist to implement minimal where the QoS policer is currently applied and has a forwarding class mapping.
The policer does not have any forwarding plane counters allocated and cannot provide offered, dropped and forwarded statistics. A policer using no-stats cannot be a child to a parent policer and the policer’s parent command will fail.
When collect-stats is enabled, no statistics are generated.
This stat-mode provides the minimal accounting resource usage and counter information, and includes the total offered, dropped and forwarded packet and octet counters for traffic entering (offered) and exiting (dropped/forwarded) the policer.
The default stat-mode for a policer is minimal. The minimal mode allocates 1 forwarding plane offered counter and one traffic manager discard counter. The forwarding counter is derived by subtracting the discard counter from the offered counter. The counters do not differentiate possible offered types (profile or priority) and do not count in-profile or out-of-profile output. This does not prevent the policer from supporting different offered packet types and does not prevent the policer from supporting a CIR rate.
This counter mode is useful when only the most basic accounting information is required.
The counters displayed in the show output and those collected when collect-stats is enabled (the actual fields collected depends on the record configured in the applied accounting policy) are described in Table 58.
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. All | apo | AllPacketsOffered |
aoo | AllOctetsOffered | |
Dro. All | apd | AllPacketsDropped |
aod | AllOctetsDropped | |
For. All | apf | AllPacketsForwarded |
aof | AllOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the profile of traffic entering the policer.
The offered-profile-no-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-profile-no-cir mode is most useful when the policer is receiving only in-profile and out-of-profile premarked (and trusted) packets. It is expected that, in this instance, a CIR rate will not be defined since all packets are already premarked. This mode does not prevent the policer from receiving untrusted (color undefined) nor does it prevent the policer from being configured with a CIR rate.
This mode is intended to be used without profile-capped configured within the policer as it could cause the traffic profile to be modified by the policer.
The counters displayed in the show output and those collected when collect-stats is enabled (the actual fields collected depends on the record configured in the applied accounting policy) are described in Table 59.
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. InProf | ipo | InProfilePacketsOffered |
ioo | InProfileOctetsOffered | |
Off. OutProf | opo | OutOfProfilePacketsOffered |
ooo | OutOfProfileOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the packet priority of traffic entering the policer.
The offered-priority-no-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-priority-no-cir mode is most useful when the policer is receiving only untrusted packets and the ingress priority high and priority low classification options are being used without a CIR profiling rate defined. This mode does not prevent the policer from receiving trusted packets that are premarked in-profile or out-of-profile nor does it prevent the policer from being configured with a CIR rate.
This mode is intended to be used without profile-capped configured within the policer as it could cause the traffic profile to be modified by the policer.
The counters displayed in the show output and those collected when collect-stats is enabled (the actual fields collected depends on the record configured in the applied accounting policy) are described in Table 60.
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. HiPrio | hpo | HighPriorityPacketsOffered |
hoo | HighPriorityOctetsOffered | |
Off. LowPrio | lpo | LowPriorityPacketsOffered |
loo | LowPriorityOctetsOffered | |
Dro. HiPrio | hpd | HighPriorityPacketsDropped |
hod | HighPriorityOctetsDropped | |
Dro. LowPrio | lpd | LowPriorityPacketsDropped |
lod | LowPriorityOctetsDropped | |
For. HiPrio | hpf | HighPriorityPacketsForwarded |
hof | HighPriorityOctetsForwarded | |
For. LowPrio | lpf | LowPriorityPacketsForwarded |
lof | LowPriorityOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer when ingress reclassification is performed so that the traffic entering the policer comprises of hard in/out and uncolored. The offered counters cover traffic explicitly profiled to in-profile, traffic explicitly profiled to out-of-profile, and traffic that has not been explicitly profiled at ingress (uncolored).
The offered-profile-cir mode allocates four forwarding plane offered counters and four traffic manager discard counters.
The offered-profile-cir mode is most useful when the policer is receiving trusted out-of-profile and in-profile traffic and is also receiving untrusted packets that are being applied to a defined CIR profiling rate. This mode differs from offered-limited-profile-cir mode in that it expects both trusted in-profile and out-of-profile packets while still performing CIR profiling on packets with untrusted markings. If trusted in-profile packets are not being received, the offered-limited-profile-cir stat-mode could be used instead, which has the benefit of using a reduced number of stat resources.
This mode is intended to be used without profile-capped configured within the policer as this could cause the traffic profile to be modified by the policer in a way that is not accounted for in the statistics.
The counters displayed in the show output and those collected when collect-stats is enabled (the actual fields collected depends on the record configured in the applied accounting policy) are described in Table 61.
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. InProf | ipo | InProfilePacketsOffered |
ioo | InProfileOctetsOffered | |
Off. OutProf | opo | OutOfProfilePacketsOffered |
ooo | OutOfProfileOctetsOffered | |
Off. Uncolor | ucp | UncoloredPacketsOffered |
uco | UncoloredOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the priority of traffic entering the policer and the profile exiting the policer.
The offered-priority-cir mode allocates four forwarding plane offered counters and four traffic manager discard counters.
The offered-priority-cir mode is most useful when the policer is receiving only untrusted packets that are being classified as high priority or low priority and are being applied to a defined CIR profiling rate. This mode differs from offered-profile-cir mode in that it does not expect trusted in-profile and out-of-profile packets but does not exclude the ability of the policer to receive them.
This mode is intended to be used without profile-capped configured within the policer as it could cause the traffic profile to be modified by the policer in a way that is not accounted for in the statistics.
The counters displayed in the show output and those collected when collect-stats is enabled (the actual fields collected depends on the record configured in the applied accounting policy) are described in Table 62.
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. HiPrio | hpo | HighPriorityPacketsOffered |
hoo | HighPriorityOctetsOffered | |
Off. LowPrio | lpo | LowPriorityPacketsOffered |
loo | LowPriorityOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer. All offered traffic is provided in a single counter.
The offered-total-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-total-cir mode is most useful when the policer is not receiving trusted in-profile or out-of-profile traffic and both high- and low-priority classifications are not being used on the untrusted packets and the offered packets are being applied to a defined CIR profiling rate. This mode does not prevent the policer from receiving trusted in-profile or out-of-profile packets and does not prevent the use of priority high or low classifications on the untrusted packets.
This mode is intended to be used without profile-capped configured within the policer as it could cause the traffic profile to be modified by the policer in a way that is not accounted for in the statistics.
The counters displayed in the show output and those collected when collect-stats is enabled (the actual fields collected depends on the record configured in the applied accounting policy) are described in Table 63.
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. All | apo | AllPacketsOffered |
aoo | AllOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer when ingress reclassification is performed so that the traffic entering the policer comprises of hard out and uncolored. The offered counters cover traffic explicitly profiled to out-of-profile and traffic that has not been explicitly profiled at ingress (uncolored). The traffic explicitly profiled to in-profile is counted with the uncolored traffic.
The offered-limited-profile-cir mode allocates three forwarding plane offered counters and three traffic manager discard counters.
The offered-limited-profile-cir mode is most useful when the policer is receiving trusted out-of-profile (profile out but no profile in) traffic and untrusted packets are being applied to a defined CIR profiling rate. This mode does not prevent the policer from receiving trusted in-profile packets. If trusted in-profile packets are not being received, the offered-limited-profile-cir is preferred over offered-profile-cir because it uses a reduced number of stat resources.
This mode is intended to be used without profile-capped configured within the policer as it could cause the traffic profile to be modified by the policer in a way that is not accounted for in the statistics.
The counters displayed in the show output and those collected when collect-stats is enabled (the actual fields collected depends on the record configured in the applied accounting policy) are described in Table 64.
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. OutProf | opo | OutOfProfilePacketsOffered |
ooo | OutOfProfileOctetsOffered | |
Off. Uncolor | ucp | UncoloredPacketsOffered |
uco | UncoloredOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer when ingress reclassification is performed so that the traffic entering the policer comprises of hard in/out and uncolored. The offered counters cover traffic explicitly profiled to in-profile, traffic explicitly profiled to out-of-profile, and traffic that has not been explicitly profiled at ingress (uncolored).
When offered-profile-capped-cir is defined, the system creates five offered-output counters in the forwarding plane and five discard counters in the traffic manager.
The offered-profile-capped-cir mode is similar to the offered-profile-cir mode except that it includes support for profile in and soft-in-profile that may be output as ‘out-of-profile’ due to enabling profile-capped mode on the ingress policer.
The impact of using offered-profile-capped-cir stat-mode while profile-capped mode is disabled is that one of the counting resources in the forwarding plane and traffic manager will not be used.
The counters displayed in the show output and those collected when collect-stats is enabled (the actual fields collected depends on the record configured in the applied accounting policy) are described in Table 65.
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. InProf | ipo | InProfilePacketsOffered |
ioo | InProfileOctetsOffered | |
Off. OutProf | opo | OutOfProfilePacketsOffered |
ooo | OutOfProfileOctetsOffered | |
Off. Uncolor | ucp | UncoloredPacketsOffered |
uco | UncoloredOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer when ingress reclassification is performed resulting in the traffic entering the policer comprising of hard in/out and uncolored. The offered counters cover in-profile traffic and traffic that has not been explicitly profiled at ingress (uncolored). The traffic explicitly profiled to out-of-profile is counted with the uncolored traffic.
offered-limited-capped-cir is defined, the system creates four forwarding plane offered-output counters in the network processor and four discard counters in the traffic manager.
The offered-limited-capped-cir mode is similar to the offered-profile-capped-cir mode except that it combines soft in-profile with profile in (InProf) and profile out (OutProf) with soft-out-of-profile (Uncolor) and eliminates the 'offered undefined' statistic. If trusted out-of-profile packets are not being received, the offered-limited-capped-cir is preferred over offered-profile-capped-cir because it uses a reduced number of stat resources.
This mode is intended to be used with profile-capped configured within the policer.
The impact of using offered-limited-capped-cir stat-mode while profile-capped mode is disabled is that one of the counting resources in the forwarding plane and traffic manager will not be used.
The counters displayed in the show output and those collected when collect-stats is enabled (the actual fields collected depends on the record configured in the applied accounting policy) are described in Table 66.
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. InProf | ipo | InProfilePacketsOffered |
ioo | InProfileOctetsOffered | |
Off. Uncolor | ucp | UncoloredPacketsOffered |
uco | UncoloredOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This command creates a queue for use in a queue group template. When created, the defined queue-id acts as a repository for the default parameters for the queue. The template queue is created on each queue-group object that is created with the queue group template name. Each queue is identified within the template by a queue-id number. The template ensures that all queue groups created with the template name will have the same queue-ids providing a uniform structure for the forwarding class redirection commands in the SAP ingress QoS policies. The parameters within the template queue will be used as the default settings for each queue in the actual queue group. The queue parameters may be individually changed for each queue in each queue group using per queue overrides.
When a queue within a template is mapped by a forwarding class on any object, the queue may be edited, but not deleted.
The no form of this command removes a template queue from the queue group template. If the queue is specified as a forwarding class redirection target in any SAP ingress QoS policy, the command will fail.
none
The queue burst-limit command is used to define 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 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.
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 queue group 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 the percentage reduction is configured to be 30% for the low drop tail, the low drop tail will be at 420 kbytes. Out-of-profile packets will not be accepted into the queue and will be discarded if the queue depth is greater than this value.
10%
This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the ingress scheduling and profiling is changed. The packet-byte-offset command is meant to be an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the scheduling and profiling throughput is affected by the offset as well as the stats (accounting) associated with the queue. The packet-byte-offset does not apply to drop statistics, received valid statistics, or the offered managed and unmanaged statistics used by Ingress Multicast Path Management.
The no form of this command is used to remove per packet size modifications from the queue.
This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers, policers (at egress only), and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.
Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multiservice customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The SAP that the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.
The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state and automatically returns to normal operation when the parent scheduler is available again.
When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.
The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. When a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.
All weight values from all weighted active queues, policers, and schedulers with a common parent scheduler are added together. Then, each individual active weight is divided by the total, deriving the percentage of remaining bandwidth provided to the queue, policer, or scheduler. A weight is considered to be active when the pertaining queue or scheduler has not reached its maximum rate and still has packets to transmit. All child policers, queues, and schedulers with a weight of 0 are considered to have the lowest priority level and are not serviced until all non-zero weighted queues, policers, and schedulers at that level are operating at the maximum bandwidth or are idle.
Children of the parent scheduler with a lower strict priority will not receive bandwidth until all children with a higher strict priority have either reached their maximum bandwidth or are idle. Children with the same strict level are serviced relative to their weights.
This command allows the queue to receive buffers from an explicit buffer pool instead of the default buffer pool. The specified pool-name must have been explicitly created in a named pool policy and the policy must have been applied to the MDA or port on which the queue resides. Named pools are not supported on the 7950 XSR, 7750 SRc4/12, 7750 SR-a4/a8, or 7750 SR-1e/2e/3e.
If the specified pool-name does not exist on the MDA, the queue will be treated as pool orphaned and will be mapped to the appropriate default pool. When the pool comes into existence on the MDA or port, the queue will be mapped to the new pool.
When the queue is created within the policy, the pool command may be used to either remove the queue from the pool or specify a new pool name association for the queue. The pool command does not appear in save or show command output. Instead, the current pool name for the queue will appear on the queue command output using the pool keyword if it is configured.
The no form of this command removes the pool name from the configuration.
This command defines the administrative Peak Information Rate (PIR) and the administrative Committed Information Rate (CIR) parameters for the queue. The PIR defines the maximum rate that the queue can transmit packets through the switch fabric (for SAP ingress 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 rate at which the system prioritizes the queue over other queues competing for the same bandwidth. For SAP ingress, the CIR also defines the rate that packets are considered in-profile by the system. In-profile, then out-of-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 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 any time, 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 this command returns all queues created with the queue-id by association with the QoS policy to the default PIR and CIR parameters (max, 0).
The actual PIR rate is dependent on the queue’s adaptation-rule parameters and the actual hardware where the queue is provisioned.
If the police keyword is not specified, the individual queue group overrides may override both the defined shaping rate and the cir defined profiling rate. When police is defined, only the policing rate may be overridden.
This command enters the context to configure QoS egress queue groups. Egress queue group templates can be applied to egress Ethernet ports to create an egress queue group.
The fc command is used to enter the forwarding class mapping context for the given fc-name. Each forwarding class has a default mapping depending on the egress queue group template. The system-created policer-output-queue template contains queues 1 and 2 by default with queue 1 being best-effort and queue 2 expedited. Forwarding classes be, l1, af and l2 all map to queue 1 by default. Forwarding classes h1, ef, h2 and nc all map to queue 2 by default. More queues may be created within the policer-output-queues template and the default forwarding classes may be changed to any defined queue within the template.
When all other user-defined egress queue group templates are created, only queue 1 (best-effort) exists and all forwarding classes are mapped to that queue. Other queues may be created and the forwarding classes may be changed to any defined queue within the template.
Besides the default mappings within the templates, the egress queue group template forwarding class queue mappings operate the same as the forwarding class mappings in a sap-egress QoS policy.
The template forwarding class mappings are the default mechanism for mapping egress policed traffic to a queue within an egress port queue group associated with the template. If a queue-id is explicitly specified in the QoS policy forwarding class policer mapping, and that queue exists within the queue group, the template forwarding class mapping is ignored.
On the 7450 ESS and 7750 SR, egress policed subscriber traffic works in a slightly different way. The subscriber and subscriber host support destination and organization strings are used to identify the egress port queue group. In this instance, the forwarding class mappings are always used and any queue overrides in the QoS policy are ignored. If neither string exists for the subscriber host, the egress queue group queue-id can be derived from either the QoS policy policer mapping or the template forwarding class queue mappings.
The no form of this command is used to return the specified forwarding class to its default template queue mapping.
This command is used to map the forwarding class to the specified queue-id. The specified queue-id must exist within the egress queue group template. When a queue is defined in a forwarding class mapping, that queue cannot be deleted unless the forwarding class mapping is moved to another queue within the template. Other criteria may also exist preventing the queue from being deleted from the template such as an applied SAP egress QoS policy mapping to the queue.
This command specifies an HS attachment policy. An attachment policy defines how queues and WRR groups are attached to the port scheduler classes.
The no form of the command removes the policy name from the configuration.
This command enables the context to configure HS WRR (Weighted Round Robin) group information on SAP egress policies.
The no form of the command removes the policy name from the configuration.
This command specifies how the system should resolve differences between the specified scheduling limit derived from the WRR group’s rate command and the actual operational rate obtainable in hardware. The min, max, and closest mutually exclusive keywords specify whether the next highest rate or next lowest rate should be selected by the system.
The no form of the command reverts to the default value.
closest
This command specifies the class weight.
The no form of the command reverts to the default value.
1
This command specifies the percent rate.
The no form of the command reverts to the default value.
This command specifies the PIR rates.
The no form of the command reverts to the default value.
max
This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed.
The packet-byte-offset command is meant to be an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers.
When a packet-byte-offset value is applied to a queue or policer instance, it adjusts the immediate packet size. This means that the queue rates (i.e., operational PIR and CIR) and policer or queue bucket updates use the adjusted packet size. In addition, the statistics will also reflect the adjusted packet size. Scheduler policy rates, which are data rates, will use the adjusted packet size.
The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, are always on-the-wire rates and thus use the actual frame size. The same applies for the agg-rate-limit on a SAP, a subscriber, or a Multiservice Site (MSS) when the queue is port-parented.
When the user enables frame-based-accounting in a scheduler policy or queue-frame-based-accounting with agg-rate-limit in a port scheduler policy, the policer or queue rate will be capped to a user-configured on-the-wire rate and the packet-byte-offset is not included; however the offsets are applied to the statistics.
The no form of this command is used to remove per packet size modifications from the queue.
This command configures a QoS egress queue-group policer.
none
This command enables the forwarding of traffic exceeding the PIR for a SAP egress or a network egress queue group (configured in the egress queue group template) policer. This traffic is forwarded as exceed-profile instead of being dropped.
no enable-exceed-pir
The sap-egress QoS policy's policer stat-mode command is used to configure the forwarding plane counters that allow offered, forwarded, and dropped accounting to occur for the policer. An egress policer has multiple types of offered packets (soft in-profile and out-of-profile from ingress and hard in-profile, out-of-profile, and exceed-profile due to egress profile overrides) and each of these offered types is interacting with the policer’s metering and profiling functions resulting in colored output packets (green, yellow, and red). Due to the potential large number of egress policers, it is not economical to allocate counters in the forwarding plane for all possible offered packet types and output conditions. Many policers, for example, will not be configured with a CIR profiling rate and not all policers will receive explicitly reprofiled offered packets. The stat-mode command allows provisioning of the number of counters each policer requires and how the offered packet types and output conditions should be mapped to the counters.
While a no-stats mode is supported that prevents any packet accounting, the use of the policer's parent command requires that the policer’s stat-mode to be set at least to the minimal setting so that offered stats are available for the policer’s Fair Information Rate (FIR) to be calculated. When a policer has been made a child to a parent policer, the stat-mode cannot be changed to no-stats unless the policer parenting is first removed.
Each time the policer's stat-mode is changed, any previous counter values are lost and any new counters are set to zero.
Each mode uses a certain number of counters per policer instance that are allocated from the forwarding plane's policer counter resources. The total/allocated/free stats can be viewed by using the tools dump resource-usage card fp command. If insufficient counters exist to implement a mode on any policer instance, the stat-mode change will fail and the previous mode will continue unaffected for all instances of the policer.
The ingress policer stat-modes are described in Table 67.
Stat Mode | Stat Resources | Traffic Counters (Packet/Octets) | Comments | |
Offered | Dropped/Forwarded | |||
no-stats | 0 | None | None | |
Minimal | 1 | Single counter entering policer | Single counter for dropped/forwarded exiting policer | |
offered-profile-no-cir | 2 | In/out entering policer | In/out entering policer | Intended for when the policer does not change the profile of packets. Includes only in- and out-of-profile. |
offered-profile-cir | 4 | In/out/uncolored (that corresponds to in- or out-of-profile from the ingress processing) entering policer | In/out exiting policer | Intended for when the policer can change the profile of packets to in- and out-of-profile. |
offered-total-cir | 2 | Single counter entering policer | In/out exiting policer | |
offered-limited-capped-cir | 4 | In/out entering policer | In/out exiting policer | Intended for when the policer has profile-capped configured. The information is limited compared to offered-profile-capped-cir with the benefit of using one less stat resources. |
offered-profile-capped-cir | 5 | In/out/uncolored (that corresponds to in- or out-of-profile from the ingress processing) entering policer | In/out exiting policer | Intended for when the policer has profile-capped configured. |
offered-total-cir-exceed | 3 | Single counter entering policer | In/out/exceed exiting policer | Intended for when the policer is configured with enable-exceed-pir to forward packets that exceed its configured PIR or when traffic is egress reclassified to profile exceed. |
offered-four-profile-no-cir | 4 | Inplus/in/out/exceed entering policer | Inplus/in/out/exceed entering policer | Intended to be used when the policer does not change the profile of the packets and traffic is egress reclassified to profile inplus and/or exceed. |
offered-total-cir-four-profile | 4 | Single counter entering policer | Inplus/in/out/exceed exiting policer | Intended to be used when the policer can change the profile of the packet and traffic is egress reclassified to profile inplus. |
The default stat-mode when a policer is created within the policy is minimal.
The stat-mode setting defined for the policer in the QoS policy may be overridden on an sla-profile or SAP where the policy is applied. If insufficient policer counter resources exist to implement the override, the stat-mode override command will fail. The previous stat-mode setting active for the policer will continue to be used by the policer.
The no form of this command attempts to return the policer’s stat-mode setting to minimal. The command will fail if insufficient policer counter resources exist to implement minimal where the QoS policer is currently applied and has a forwarding class mapping.
The policer does not have any forwarding plane counters allocated and cannot provide offered, discard, and forward statistics. A policer using no-stats cannot be a child to a parent policer and the policer’s parent command will fail.
When collect-stats is enabled, no statistics are generated.
This stat-mode provides the minimal accounting resource usage and counter information, and includes only the total offered, dropped and forwarded packet and octet counters for traffic entering (offered) and exiting (dropped/forwarded) the policer.
The default stat-mode for a policer is minimal. The minimal mode allocates one forwarding plane offered counter and one traffic manager discard counter. The forwarding counter is derived by subtracting the discard counter from the offered counter. The counters do not differentiate possible offered types and do not count different profile output. This does not prevent the policer from supporting different offered packet types and does not prevent the policer from supporting a CIR rate or using exceed PIR.
The counters displayed in the show output and those collected when collect-stats is enabled are described in Table 68 (the actual fields collected depends on the record configured in the applied accounting policy).
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. All | apo | AllPacketsOffered |
aoo | AllOctetsOffered | |
Dro. All | apd | AllPacketsDropped |
aod | AllOctetsDropped | |
For. All | apf | AllPacketsForwarded |
aof | AllOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the profile of traffic entering the policer. inplus-profile traffic is counted with the in-profile counters and exceed-profile traffic is counted with the out-of-of profile counters.
The offered-profile-no-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-profile-no-cir mode is most useful when profile-based offered, dropped and forwarded statistics are required from the egress policer, but a CIR or enable-exceed-pir is not being used to recolor the soft in-profile and out-of-profile packets. This mode does not prevent the policer from being configured with a CIR rate or using enable-exceed-pir.
This mode is intended to be used without profile-capped configured within the policer as it could cause the traffic profile to be modified by the policer.
The counters displayed in the show output and those collected when collect-stats is enabled are described in Table 69 (the actual fields collected depends on the record configured in the applied accounting policy).
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. InProf | ipo | InProfilePacketsOffered |
ioo | InProfileOctetsOffered | |
Off. OutProf | opo | OutOfProfilePacketsOffered |
ooo | OutOfProfileOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer when egress reclassification is performed so that the traffic entering the policer comprises of hard inplus/in/out/exceed and soft in/out. The offered counters cover traffic reclassified to in-profile (that includes traffic reclassified to inplus-profile), traffic reclassified to out-of-profile (that includes traffic reclassified to exceed-profile), and traffic that has not been reclassified at egress (Uncolor). In the dropped and forwarded counters, inplus-profile traffic is counted with the in-profile counter and exceed-profile traffic is counted with the out-of-profile counter.
The offered-profile-cir mode allocates four forwarding plane offered counters and four traffic manager discard counters.
The offered-profile-cir mode is most useful when profile-based offered, dropped and forwarded stats are required from the egress policer and a CIR rate is being used to recolor the soft in-profile and out-of-profile packets.
This mode is intended to be used without profile-capped or enable-exceed-pir configured within the policer as these could cause the traffic profile to be modified by the policer in a way that is not accounted for in the statistics.
The counters displayed in the show output and those collected when collect-stats is enabled are described in Table 70 (the actual fields collected depends on the record configured in the applied accounting policy).
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. InProf | ipo | InProfilePacketsOffered |
ioo | InProfileOctetsOffered | |
Off. OutProf | opo | OutOfProfilePacketsOffered |
ooo | OutOfProfileOctetsOffered | |
Off. Uncolor | ucp | UncoloredPacketsOffered |
uco | UncoloredOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped, and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer. All offered traffic is provided in a single counter. In the dropped and forwarded counters, inplus-profile traffic is counted with the in-profile counter and exceed-profile traffic is counted with the out-of-profile counter.
The offered-total-cir mode allocates two forwarding plane offered counters and two traffic manager discard counters.
The offered-total-cir mode is most useful when the policer is not receiving trusted in-profile or out-of-profile traffic and both high- and low-priority classifications are not being used on the untrusted packets and the offered packets are being applied to a defined CIR profiling rate. This mode does not prevent the policer from receiving trusted in-profile or out-of-profile packets and does not prevent the use of priority high or low classifications on the untrusted packets.
This mode is intended to be used without profile-capped or enable-exceed-pir configured within the policer as these could cause the traffic profile to be modified by the policer in a way that is not accounted for in the statistics.
The counters displayed in the show output and those collected when collect-stats is enabled are described in Table 71 (the actual fields collected depends on the record configured in the applied accounting policy).
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. All | apo | AllPacketsOffered |
aoo | AllOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer when egress reclassification is performed so that the traffic entering the policer comprises of hard inplus/in/out/exceed and soft in/out. The offered counters cover in-profile traffic (that includes traffic reclassified to inplus-profile) and out-of-profile traffic (that includes traffic reclassified to exceed-profile). In the dropped and forwarded counters, inplus-profile traffic is counted with the in-profile counter and exceed-profile traffic is counted with the out-of-profile counter.
When offered-limited-capped-cir is defined, the system creates four forwarding plane offered-output counters in the network processor and three discard counters in the traffic manager.
The offered-limited-capped-cir mode is similar to the offered-profile-capped-cir mode except that it combines soft-in-profile with profile in and soft-out-of-profile with profile out and eliminates the offered-undefined statistic.
The impact of using offered-limited-capped-cir stat-mode while profile-capped mode is disabled is that one of the counting resources in the forwarding plane and traffic manager will not be used and soft-in-profile will be treated as offered-in instead of offered-undefined.
This mode is intended to be used with profile-capped configured within the policer but without enable-exceed-pir configured as this could cause the traffic profile to be modified by the policer in a way that is not accounted for in the statistics.
The counters displayed in the show output and those collected when collect-stats is enabled are described in Table 72 (the actual fields collected depends on the record configured in the applied accounting policy).
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. InProf | ipo | InProfilePacketsOffered |
ioo | InProfileOctetsOffered | |
Off. OutProf | opo | OutOfProfilePacketsOffered |
ooo | OutOfProfileOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped, and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer when egress reclassification is performed so that the traffic entering the policer is comprised of hard inplus, hard in, hard out, and hard exceed, as well as soft in and soft out. The offered counters cover traffic reclassified to in-profile (that includes traffic reclassified to inplus-profile), traffic reclassified to out-of-profile (that includes traffic reclassified to exceed-profile), and traffic that has not been reclassified at egress (uncolor). In the dropped and forwarded counters, inplus-profile traffic is counted with the in-profile counter and exceed-profile traffic is counted with the out-of-profile counter.
When offered-profile-capped-cir is defined, the system creates five offered-output counters in the forwarding plane and five discard counters in the traffic manager.
The offered-profile-capped-cir mode is similar to the offered-profile-cir mode except that it includes support for profile inplus, profile in, and soft-in-profile that may be output as out-of-profile due to enabling profile-capped mode on the ingress policer.
The impact of using offered-profile-capped-cir stat-mode while profile-capped mode is disabled is that one of the counting resources in the forwarding plane and traffic manager will not be used and soft-in-profile will be treated as offered-in (hard in-profile) instead of offered-undefined (uncolored).
This mode is intended to be used with profile-capped configured within the policer but without enable-exceed-pir configured as this could cause the traffic profile to be modified by the policer in a way that is not accounted for in the statistics.
The counters displayed in the show output and those collected when collect-stats is enabled are described in Table 73 (the actual fields collected depends on the record configured in the applied accounting policy) .
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. InProf | ipo | InProfilePacketsOffered |
ioo | InProfileOctetsOffered | |
Off. OutProf | opo | OutOfProfilePacketsOffered |
ooo | OutOfProfileOctetsOffered | |
Off. Uncolor | ucp | UncoloredPacketsOffered |
uco | UncoloredOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded |
This stat-mode provides offered, dropped, and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer. All offered traffic is provided in a single counter. In the dropped and forwarded counters, inplus-profile traffic is counted with the in-profile counter. The offered-total-cir-exceed mode allocates three forwarding plane offered counters and three traffic manager discard counters.
The offered-total-cir-exceed mode is similar to the offered-total-cir mode except that it includes support for forwarded and dropped counters for profile exceed.
This mode is intended to be used when the policer is configured with enable-exceed-pir to forward packets that exceed its configured PIR or when traffic is egress reclassified to profile exceed. The mode gives the forwarded and dropped counters per profile (in, out, exceed). It is also intended to be used without profile-capped configured within the policer as it could cause the traffic profile to be modified by the policer. This stat-mode is not supported for dynamic policers.
The counters displayed in the show output and those collected when collect-stats is enabled are described in Table 74 (the actual fields collected depends on the record configured in the applied accounting policy).
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. All | apo | AllPacketsOffered |
aoo | AllOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
Dro. ExcProf | xpd | ExceedProfilePktsDropped |
xod | ExceedProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded | |
For. ExcProf | xpf | ExceedProfilePktsForwarded |
xof | ExceedProfileOctetsForwarded |
This stat-mode provides offered, dropped, and forwarded packet and octet counters corresponding to the profile of traffic entering the policer. Offered, dropped, and forwarded counters are provided for inplus-profile, in-profile, out-of-profile, and exceed-profile traffic.
The offered-four-profile-no-cir mode allocates four forwarding plane offered counters and four traffic manager discard counters.
The offered-four-profile-no-cir mode is similar to the offered-profile-no-cir mode except that it includes support for offered, dropped and forwarded counters for both profile inplus and profile exceed.
This mode is intended to be used when traffic is egress reclassified to profile inplus and/or exceed. It is also intended to be used without profile-capped configured within the policer as it could cause the traffic profile to be modified by the policer. This stat-mode is not supported for dynamic policers.
The counters displayed in the show output and those collected when collect-stats is enabled are described in Table 75 (the actual fields collected depends on the record configured in the applied accounting policy).
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. InProf | ipo | InProfilePacketsOffered |
ioo | InProfileOctetsOffered | |
Off. OutProf | opo | OutOfProfilePacketsOffered |
ooo | OutOfProfileOctetsOffered | |
Off. ExcProf | xpo | ExceedProfilePacketsOffered |
xoo | ExceedProfileOctetsOffered | |
Off. InplusProf | ppo | InplusProfilePacketsOffered |
poo | InplusProfileOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
Dro. ExcProf | xpd | ExceedProfilePktsDropped |
xod | ExceedProfileOctetsDropped | |
Dro. InplusProf | ppd | InplusProfilePktsDropped |
pod | InplusProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded | |
For. ExcProf | xpf | ExceedProfilePktsForwarded |
xof | ExceedProfileOctetsForwarded | |
For. InplusProf | ppf | InplusProfilePktsForwarded |
pof | InplusProfileOctetsForwarded |
This stat-mode provides offered, dropped, and forwarded packet and octet counters corresponding to the profile of traffic entering (offered) and exiting (dropped/forwarded) the policer. All offered traffic is provided in a single counter. There is a separate dropped and forwarded counter for inplus, in, out, and exceed-profile traffic.
The offered-total-cir-four-profile mode allocates four forwarding plane offered counters and four traffic manager discard counters.
The offered-total-cir-four-profile mode is similar to the offered-total-cir except that it includes support for forwarded and dropped counters for both inplus-profile and exceed-profile.
This mode is intended to be used when traffic is egress reclassified to inplus-profile. It is also intended to be used without profile-capped configured within the policer as it could cause the traffic profile to be modified by the policer. This stat-mode is not supported for dynamic policers.
The counters displayed in the show output and those collected when collect-stats is enabled are described in Table 76 (the actual fields collected depends on the record configured in the applied accounting policy).
Show Output | Accounting Stats Collected | |
Field | Field Description | |
Off. All | apo | AllPacketsOffered |
aoo | AllOctetsOffered | |
Dro. InProf | ipd | InProfilePacketsDropped |
iod | InProfileOctetsDropped | |
Dro. OutProf | opd | OutOfProfilePacketsDropped |
ood | OutOfProfileOctetsDropped | |
Dro. ExcProf | xpd | ExceedProfilePktsDropped |
xod | ExceedProfileOctetsDropped | |
Dro. InprofProf | ppd | InplusProfilePktsDropped |
pod | InplusProfileOctetsDropped | |
For. InProf | ipf | InProfilePacketsForwarded |
iof | InProfileOctetsForwarded | |
For. OutProf | opf | OutOfProfilePacketsForwarded |
oof | OutOfProfileOctetsForwarded | |
For. ExcProf | xpf | ExceedProfilePktsForwarded |
xof | ExceedProfileOctetsForwarded | |
For. InplusProf | ppf | InplusProfilePktsForwarded |
pof | InplusProfileOctetsForwarded |
This command creates a queue for use in a queue group template. When created, the defined queue-id acts as a repository for the default parameters for the queue. The template queue is created on each queue group object that is created with the queue group template name. Each queue is identified within the template by a queue ID. The template ensures that all queue groups created with the template name will have the same queue-ids providing a uniform structure for the forwarding class redirection commands in the SAP egress QoS policies. The parameters within the template queue will be used as the default settings for each queue in the actual queue group. The queue parameters may be individually changed for each queue in each queue group using per queue overrides.
This command enables support for dynamically modifying the MBS size of a queue using HQoS in order to maintain the maximum latency for traffic in the queue based on the queue’s configured MBS and the ratio of its operational PIR to its administrative PIR. As the HQoS algorithm updates the operational PIR, by reducing or increasing it, the MBS of the queue is adjusted accordingly.
The configuration of dynamic MBS and the configuration of queue depth monitoring (monitor-depth command) are mutually exclusive. Queue depth monitoring is an override on the queue where the queue group is applied.
The no form of this command disables dynamic MBS resizing.
no dynamic-mbs
This command specifies whether the HS alternate class port pool buffer should be used for traffic.
The no form of the command reverts to the default.
hs-alt-port-class-pool
This command specifies the Weighted Round Robin (WRR) weight which this queue should parent into the scheduler. The weight of each queue determines how much bandwidth that queue gets out of the total rate for the scheduling class
The no form of the command reverts to the default.
1
This command specifies the weight of the scheduling class.
The no form of the command reverts to the default.
1
This command specifies the WRED queue.
The no form of the command reverts to the default.
"_tmnx_hs_default"
This command enters the context to configure the queue exceed drop-tail parameters. The exceed drop tail defines the queue depth beyond which exceed-profile packets will not be accepted into the queue and will be discarded.
This command enters the context to configure the queue high drop-tail parameters. The high drop tail defines the queue depth beyond which in-profile packets will not be accepted into the queue and will be discarded.
This command enters the context to configure the queue highplus drop-tail parameters. The highplus drop tail defines the queue depth beyond which inplus-profile packets will not be accepted into the queue and will be discarded.
This command configures the egress queue group queue drop tails as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and the percentage reduction is configured to be 30% for the low drop tail, the low drop tail will be at 420 kbytes. Out-of-profile packets will not be accepted into the queue and will be discarded if the queue depth is greater than this value.
The drop tails apply to packets with the following profile states:
exceed drop tail: 20%
low drop tail: 10%
high drop tail: 0%
highplus drop tail: 0%
The percent-rate command within the egress queue group template enables support for a queue’s PIR and CIR rate to be configured as a percentage of the egress port’s line rate. When the rates are expressed as a percentage within the template, the actual rate used per instance of the queue group queue-id will vary based on the port speed. For example, when the same template is used to create a queue group on a 1-Gb and a 10-Gb Ethernet port, the queue’s rates will be 10 times greater on the 10 Gb port due to the difference in port speeds. This enables the same template to be used on multiple ports without needing to use port-based queue overrides to modify a queue’s rate to get the same relative performance from the queue.
If the port’s speed changes after the queue is created, the queue’s shaping and CIR rates will be recalculated based on the defined percentage value.
The rate and percent-rate commands override one another. If the current rate for a queue is defined using the percent-rate command and the rate command is executed, the percent-rate values are deleted. Similarly, the percent-rate command causes any rate command values to be deleted. A queue’s rate may dynamically be changed back and forth from a percentage to an explicit rate at any time.
The no form of this command returns the queue to its default shaping rate and CIR rate.
This command defines the port scheduling parameters used to control the queue’s behavior when a virtual egress port scheduling is enabled where the egress queue group template is applied. The port-parent command follows the same behavior and provisioning characteristics as the parent command in the SAP egress QoS policy. The port-parent command and the parent command are mutually exclusive.
The no form of this command removes the values from the configuration.
none
This command configures the target queue delay for packets forwarded through the queue. It is used to determine the related queue parameters based on the administrative PIR of the queue. This command and the mbs command are mutually exclusive.
In order to change between the mbs and queue-delay parameters, the current parameter must be removed before adding the new parameter; that is, changing from mbs to queue-delay requires a no mbs before the queue-delay is configured and changing from queue-delay to mbs requires a no queue-delay before the mbs is configured.
If queue-delay is configured for an egress queue group queue, it is not possible to override the MBS for that queue.
The no form of this command disables the determination of the queue parameters based on the queue delay.
no queue-delay
This command allows the configuration of WRED per queue with the following options:
Native Hardware WRED
When the wred-queue mode native command is configured, the queue uses the WRED capabilities of the FP3. In this case, the out and exceed-profile traffic map to the low and exceed WRED slopes specified within the slope policy, and the inplus and in-profile traffic uses the MBS drop tail; this requires the slope-usage to be configured as exceed-low. The instantaneous queue depth is compared against the low and exceed slopes so the time average factor in the slope policy is ignored.
When a policy is not explicitly defined, the default slope policy is used.
When native mode is enabled for a queue, the drop-tail commands are ignored; traffic mapped to a slope that is shut down will use the MBS drop tail.
Native hardware WRED is only supported on FP3 hardware and is ignored on FP2 hardware.
The no form of this command restores the queue default congestion control behavior to the queue.
Pool-per-queue WRED
When the wred-queue mode pool-per-queue command is defined and the queue ID is created on FP2 or higher based hardware, a buffer pool is created specifically for the queue and the queue obtains all buffers from that pool. The size of the pool is the same as the size of the queue. In this manner, the WRED slopes that operate based on the pool’s buffer utilization are also reacting to the congestion depth of the queue.
The size of the buffer pool is dictated by the queue’s mbs parameter. The size of the reserved CBS portion of the buffer pool is dictated by the queue’s cbs parameter. The provisioning characteristics of the mbs and cbs commands are not changed.
In the case where this is applied on FP2- or higher-based hardware that has WRED queue support shutdown (config>card>fp>egress>wred-queue-control>shutdown), the queue will continue to map to either its default pool or the pool defined in the pool command. If the no shutdown command is executed in the wred-queue-control context, the queue will be automatically moved to its own WRED pool.
Each pool created for a queue using the wred-queue command shares buffers with all other wred-queue enabled queues on the same forwarding plane. The WRED pool buffer management behavior is defined within the config>card>fp>egress>wred-queue-control CLI context.
The WRED slopes within the pool are defined by the slope policy associated with the queue. When a policy is not explicitly defined, the default slope policy is used. The slope policy enables, disables, and defines the relative geometry of the highplus, high, low, and exceed WRED slopes in the pool. The policy also specifies the time average factor used by the pool when calculating the weighted average pool depth.
As packets attempt to enter the egress queue, they are associated with the highplus, high, low, or exceed WRED slope based on the packet’s profile. If the packet is inplus-profile, the highplus slope is used. If the packet is in-profile, the high slope is used. If the packet is out-of-profile, the low slope is used, and if the packet is exceed-profile, the exceed slope is used. This mapping of packet profile to slope is enabled using the slope-usage default parameter. Each WRED slope performs a probability discard based on the current weighted average pool depth.
When wred-queue is enabled for an egress queue group queue, the queue pool and drop-tail commands are ignored; traffic mapped to a slope that is shut down will use the MBS drop tail.
The resource usage for the wred-queue pool-per-queue per forwarding plane can be seen in the tools dump resource-usage card [slot-num] fp [fp-number] output under Dynamic Q2 Wred Pools.
The no form of this command restores the generic buffer pool behavior to the queue. The WRED pool is removed from the system. The queue will be moved to either the default buffer pool or to a named pool if defined and the pool exists. The queue then uses the default congestion control behavior.
no wred-queue
This command specifies that the queues within this egress queue group template are to be managed by the Hierarchical QoS (HQoS) process when the template is applied to an Ethernet access egress or network egress context. It is applicable to all egress queue group templates, including the default policer-output-queues template.
The no queues-hqos-manageable command must be configured for access egress queue groups that are used for post-policer traffic in order to prevent HQoS from measuring the traffic through a policer managed by HQoS then again through a post-policer access egress queue group queue.
Avoid scenarios that result in traffic being either not being measured or being measured twice by HQoS as they will cause the HQoS result to be inaccurate; see Child Policer Hierarchical QoS Parenting for more information.
A template configured for no queues-hqos-manageable cannot be applied to an Ethernet network egress context. Any egress queue group templates applied to an Ethernet network egress context cannot be configured as no queues-hqos-manageable. The configuration of no queues-hqos-manageable and the configuration of policers and queue packet-byte-offset within the egress queue group template are mutually exclusive.
When a queue group template with no queues-hqos-manageable is configured under a port's Ethernet access egress context, the configuration of an aggregate rate or scheduler policy is not permitted under that context, nor are parent overrides for any of the queues in the queue group. If a port scheduler is configured on the port, the queue group queues are not parented to the port scheduler.
The no form of this command specifies that queues within this egress queue group are not managed by HQoS.
queues-hqos-manageable
This command configures a queue group redirect list that is used to redirect traffic to different instances of a queue group.
The no form of this command deletes the queue group redirect list. A list can only be deleted when there no references to it.
This command configures the value of the field in the ingress or egress packet which, when matched, will cause the packet to be redirected to the specified queue group instance. The field-value is dependent on the setting of the type and therefore must be a valid VXLAN VNI.
A maximum of 16 match statements are supported in a queue group redirect list.
The no form of this command removes the match statement from the redirect list.
This command configures the type of a queue group redirect list. The default value is vxlan-vni, which is the only possible value.
The command outputs in the following section are examples only; actual displays may differ depending on supported functionality and user configuration.
This command displays queue-group information.
The following outputs are examples of queue group information.
Related queue-group command output
This command displays queue group redirect list information.
The following output is an example of queue group redirect list information.
This command displays SAP egress QoS policy information. Queue group information is displayed in the FC section.
The following output is an example of SAP egress information.
This command displays SAP ingress QoS policy information. Queue group information is displayed in the FC section.
The following output is an example of SAP ingress information.
This command displays queue group pool information.
The following output is an example of pool information.
This command displays physical port information for the port’s queue group.
The following output is an example of port information for the port’s queue group.
This command monitors policer statistics in an ingress FP queue group.
This command monitors arbiter statistics in an ingress FP queue group.
This command monitors arbiter statistics in an egress port queue group.
port-id | slot/mda/port [.channel] | ||
eth-sat-id | esat-id/slot/port | ||
esat | keyword | ||
id | 1 to 20 | ||
pxc-id | pxc-id.sub-port | ||
pxc | keyword | ||
id | 1 to 64 | ||
sub-port | a, b |
This command enables port traffic monitoring.
port-id | slot/mda/port [.channel] | ||
eth-sat-id | esat-id/slot/port | ||
esat | keyword | ||
id | 1 to 20 | ||
pxc-id | pxc-id.sub-port | ||
pxc | keyword | ||
id | 1 to 64 | ||
sub-port | a, b |