Configuration Command Reference

This command creates a text description for a configuration context to help identify the content in the configuration file.

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

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.

The operational state of the entity is disabled as well as the operational state of any entities contained within.

The no form of this command administratively enables an entity.

This mandatory command enables access to the chassis card Input/Output, Control Forwarding Module (IOM/CFM), slot, MCM, MDA, XCM and XMA CLI contexts.

The no form of this command removes the card from the configuration. All associated ports, services, and MDAs must be shutdown.

This mandatory command adds an IOM/XCM to the device configuration for the slot. The card type can be preprovisioned, meaning that the card does not need to be installed in the chassis.

A card must be provisioned before an MDA, MCM, or port can be configured.

A card can only be provisioned in a slot that is vacant, meaning no other card can be provisioned (configured) for that particular slot. To reconfigure a slot position, use the no form of this command to remove the current information.

A card can only be provisioned in a slot if the card type is allowed in the slot. An error message is generated if an attempt is made to provision a card type that is not allowed.

If a card is inserted that does not match the configured card type for the slot, then a log event and facility alarm is raised. The alarm is cleared when the correct card type is installed or the configuration is modified.

A log event and facility alarm are is raised if an administratively enabled card is removed from the chassis. The alarm is cleared when the correct card type is installed or the configuration is modified. A log event is issued when a card is removed that is administratively disabled.

Because IMMs do not have the capability to install separate MDAs, the configuration of the MDA is automatic. This configuration only includes the default parameters such as default buffer policies. Commands to manage the MDA such as shutdown, named buffer pool, etc., remain in the MDA configuration context.

An appropriate alarm is raised if a partial or complete card failure is detected. The alarm is cleared when the error condition ceases.

The no form of this command removes the card from the configuration.

This command controls the behavior of the card when any one of a specific set of card level errors is encountered in the system. When the fail-on-error command is enabled, and any one (or more) of the specific errors is detected, then the Operational State of the card is set to Failed. This Failed state will persist until the clear card command is issued (reset) or the card is removed and re-inserted (re-seat). If the condition persists after re-seating the card, then Nokia support should be contacted for further investigation.

Enabling fail-on-error is only recommended when the network is designed to be able to route traffic around a failed card (redundant cards, nodes or other paths exist).

The list of specific errors includes:

On platforms without independent IOM/IMM and CPM cards, such as the 7750 SR c4/c12 or 7450 ESS-1, the node will be rebooted if fail-on-error is enabled and one of the card level errors is encountered.

The tmnxEqCardPChipError is only considered as a trigger for card fail-on-error for ingress FCS errors (not egress FCS errors), and only for Ethernet MDAs or IMMs.

Note that upon the detection of the event/error in the system, the reporting of the event (logs) and the fail-on-error behavior of the card are independent. Log event control configuration will determine whether the events are reported in logs (or SNMP traps, etc) and the fail-on-error configuration will determine the behavior of the card. This implies that the card can be configured to fail-on-error even if the events are suppressed (some may be suppressed in the system by default). In order to facilitate post-failure analysis, Nokia recommends that you enable the reporting of the specific events/errors (configure log event-control) when fail-on-error is enabled.

This command places an IOM in the named pool mode. When in named pool mode, the system will change the way default pools are created and allow for the creation of MDA and port level named buffer pools. When not enabled, the system will create default ingress and egress pools per port. When enabled, the system will not create per port pools, instead a default network and access pool is created for ingress and egress and is shared by queues on all ports.

The named pool mode may be enabled and disabled at anytime. Care should be taken when changing the pool mode for an IOM as the process of changing to or from named pool mode causes an IOM reset if MDAs are currently provisioned on the slot. If MDAs have not been provisioned at the time the named-pool-mode or no named-pool-mode command is executed, the IOM is not reset (for example, when the system is booting, the named pool mode command does not reset the IOM since the mode is set prior to provisioning the IOM’s MDAs).

This command is not enabled for the ISA-AA MDA.

The no form of the command converts the pool mode on the IOM card to the default mode. If MDAs are currently provisioned on the IOM, the card is reset.

This mandatory command enables access to a card’s MCM CLI context to configure MCMs.

This mandatory command provisions a specific MCM type to the device configuration for the slot. The MCM can be preprovisioned but an MDA must be provisioned before ports can be configured. Ports can be configured once the MDA is properly provisioned.

To modify an MCM slot, shut down all port associations. MCMs are required to provision MDAs. MCMs are not required to provision CMAs.

This mandatory command enables access to a card’s MDA CLI context to configure MDAs.

This command defines the clocking mode on the specified CMA/MDA. This command is only supported on CES CMAs and MDAs.

This command enables the fail-on-error feature. If an MDA is experiencing too many Egress XPL Errors, this feature causes the MDA to fail. This can force an APS switchover or traffic re-route. The purpose of this feature is to avoid situations where traffic is forced to use a physical link that suffers from errors but is still technically operational.

The feature uses values configured in the config>card>mda>egress-xpl context. When this feature is enabled on a MDA, if window consecutive minutes pass in which the MDA experiences more than threshold Egress XPL Errors per minute, then the MDA will be put in the failed state.

The no form of this command disables the feature on the MDA.

This command enables the context to configure egress MDA parameters.

This command enables the context to configure egress-xpl settings used by the fail-on-error feature.

This command configures the Egress XPL Error Threshold value used by the fail-on-error feature.

This command configures the Error Window value used by the fail-on-error feature.

This command enables the context to configure ingress MDA parameters.

This command enables the context to configure local MDA settings for ingress multicast path management.

This command enables the context to configure ancillary path bandwidth override parameters.

This command overrides the path limits contained in the bandwidth policy associated with the MDA.

The no form of the command removes the path limit override from an ingress multicast path and restores the path limit defined in the bandwidth policy associated with the MDA.

This command specifies an existing multicast bandwidth policy. Bandwidth policies are used to manage the ingress multicast path bandwidth. Each forwarding plane supports multicast forwarding paths into the switch fabric. Bandwidth policy parameters are configured in the config>mcast-mgmt context.

This command enables the context to configure primary path limit override parameters.

This command enables the context to configure secondary path limit override parameters.

This command designates the MDA as a high-bandwidth IP multicast source, expecting the ingress traffic to include high-bandwidth IP multicast traffic. When configured, the system attempts to allocate a dedicated multicast switch fabric plane (MSFP) to the MDA. If a group is specified, all MDAs in the group will share the same MSFP. If the alarm parameter is specified and the system cannot allocate a dedicated MSFP to the new group or MDA, the MDAs will be brought online and generate an event (SYSTEM: 2052 - mdaHiBwMulticastAlarm). Similarly, if during normal operation there is a failure or removal of resources, an event will be generated if the system cannot maintain separation of MSFPs for the MDAs.

This command is supported on the 7950 XRS, 7750 SR-7, 7750 SR-12, 7450 ESS-7 and 7450 ESS-12.

The no form of the command removes the high-bandwidth IP multicast source designation from the MDA.

This mandatory command provisions a specific MDA type to the device configuration for the slot. The MDA can be preprovisioned but an MDA must be provisioned before ports can be configured. Ports can be configured once the MDA is properly provisioned.

A maximum of two MDAs can be provisioned on an IOM/XCA. Only one MDA can be provisioned per IOM/MDA slot. To modify an MDA slot, shut down all port associations.

A maximum of six MDAs or eight CMAs (or a combination) can be provisioned on a 7750 SR-c12. Only one MDA/CMA can be provisioned per MDA slot. To modify an MDA slot, shut down all port associations.

CMAs do not rely on MCM configuration and are provisioned without MCMs.

Note that CMAs/XMAs are provisioned using MDA commands. A medium severity alarm is generated if an MDA/CMA is inserted that does not match the MDA/CMA type configured for the slot. This alarm is cleared when the correct MDA/CMA is inserted or the configuration is modified. A high severity alarm is raised when an administratively enabled MDA/CMA is removed from the chassis. This alarm is cleared if the either the correct MDA/CMA type is inserted or the configuration is modified. A low severity trap is issued if an MDA/CMA is removed that is administratively disabled.

An MDA can only be provisioned in a slot if the MDA type is allowed in the MDA slot. An error message is generated when an MDA is provisioned in a slot where it is not allowed.

A medium severity alarm is generated if an MDA is inserted that does not match the MDA type configured for the slot. This alarm is cleared when the correct MDA is inserted or the configuration is modified.

A high severity alarm is raised when an administratively enabled MDA is removed from the chassis. This alarm is cleared if the either the correct MDA type is inserted or the configuration is modified. A low severity trap is issued if an MDA is removed that is administratively disabled.

An alarm is raised if partial or complete MDA failure is detected. The alarm is cleared when the error condition ceases.

All parameters in the MDA context remain and if non-default values are required then their configuration remains as it is on all existing MDAs.

The no form of this command deletes the MDA from the configuration. The MDA must be administratively shut down before it can be deleted from the configuration.

The named-pool-mode CLI context is used to store the MDA and port level named pool mode configuration commands. Currently, only the ingress and egress named-pool-policy commands are supported. Any future named pool mode configuration commands or overrides will be placed in the named-pool-mode CLI context. Within the context is an ingress and egress context.

Enter the named-pool-mode to define the ingress and egress named pool policy associations for either an MDA or port. The node may be entered regardless of the current named-pool-mode state of the IOM.

The egress node within the named-pool-mode context is used to contain the egress named-pool-policy configuration. Enter the egress node when defining or removing the MDA or port level egress named pool policy.

The ingress node within the named-pool-mode context is used to contain the ingress named-pool-policy configuration. Enter the ingress node when defining or removing the MDA or port level ingress named pool policy.

The named-pool-policy command is used to associate a named pool policy with an MDA or port ingress or egress context. The policy governs the way that named pools are created at the MDA or port level. The policy may be applied regardless of whether the IOM is in named pool mode; however, a named pool policy to an MDA or port to a card that is not on named pool mode will be ignored. Pools may not be created due to insufficient resources or pool name collisions. Pool name collisions are allowed. The name check is performed independently between ingress and egress. A port on ingress may have a named pool defined that is also on the egress side at the MDA level. Multiple ports on the same MDA may have the same policy or the same named pools defined. Ports on the same MDA may also have different named pool policies defined.

The no named-pool-policy command removes any existing policy associated with the MDA or port.

This command sets the power priority value for the 7950 XRS.

This command enables synchronous Ethernet on the MDA. Then any port on the MDA can be used as a source port in the sync-if-timing configuration.

The no form of the command disables synchronous Ethernet on the MDA.

This command enables the access context to configure egress and ingress pool policy parameters.

On the MDA level, access egress and ingress pools are only allocated on channelized MDAs/CMAs.

This command enables the context to configure egress buffer pool parameters which define the percentage of the pool buffers that are used for CBS calculations and specify the slope policy that is configured in the config>qos>slope-policy context.

On the MDA level, network and access egress pools are only allocated on channelized MDAs/CMAs.

This command configures pool policies.

On the MDA level, access and network egress and access ingress pools are only allocated on channelized MDAs. On the MDA level, access and network egress and access ingress pools are only allocated on channelized MDAs. Network ingress pools are allocated on the MDA level for non-channelized MDAs.

This command configures the threshold for the amber alarm on the over-subscription allowed.

Users can selectively enable amber or red alarm thresholds. But if both are enabled (non-zero) then the red alarm threshold must be greater than the amber alarm threshold.

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

This command configures the threshold for the red alarm on the over-subscription allowed.

Users can selectively enable amber or red alarm thresholds. But if both are enabled (non-zero) then the red alarm threshold must be greater than the amber alarm threshold.

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

This command defines the percentage or specifies the sum of the pool buffers that are used as a guideline for CBS calculations for access and network ingress and egress queues. Two actions are accomplished by this command:

It is important to note that this command does not actually set aside buffers within the buffer pool for CBS reservation. The CBS value per queue only determines the point at which enqueuing packets are subject to a RED slope. Oversubscription of CBS could result in a queue operating within its CBS size and still not able to enqueue a packet due to unavailable buffers. The resv-cbs parameter can be changed at any time.

If the total pool size is 10 MB and the resv-cbs set to 5, the ‘reserved size’ is 500 KB.

The no form of this command restores the default value.

The no resv-cbs command will clear all the adaptive configurations. There cannot be any adaptive sizing enabled for default resv-cbs.

This command specifies an existing slope policy which defines high and low priority RED slope parameters and the time average factor. The policy is defined in the config>qos>slope-policy context.

This command enables the context to configure ingress buffer pool parameters which define the percentage of the pool buffers that are used for CBS calculations and specify the slope policy that is configured in the config>qos>slope-policy context.

On the MDA level, access ingress pools are only allocated on channelized MDAs/CMAs.

This command enables the context to configure ingress MDA XPL interface error parameters.

This command configures the Ingress XPL Error Threshold value used by the fail-on-error feature.

This command configures the Error Window value used by the fail-on-error feature.

This command enables the network context to configure egress and ingress pool policy parameters.

On the MDA level, network egress pools are only allocated on channelized MDAs/CMAs.

This command sets the power mode.

This command sets the APEQ slot number.

This command sets the type of APEQ for the designated APEQ slot.

The no form of the command moves the APEQ to unprovisioned state.

This command sets the input-power-mode of the APEQ for the designated APEQ slot.

This command administratively enables/disables the APEQ.

This command sets a value in watts for the Power Safety Alert.The Power Safety Alert minor alarm is generated when the system power capacity drops below the Power Safety Level (in watts) + the Power Safety Alert. This is a critical level, which when breached the system starts shutting down IO cards based on card priority.

This command sets the Power Safety Level, which is a percentage of the calculated worst case power draw value. Once a Power Safety Level is configured by the operator, both the Basic and Advanced modes use the Power Safety Level as a reference for calculating the power redundancy using N+1 algorithm during start up and recovery from power depression.

This command overrides the default minimum time that must elapse before a policer or queue’s offered rate may be recalculated. A minimum time between offered rate calculations is enforced to both prevent inaccurate estimation of the offered rate and excessive input to the virtual scheduler process.

In order to smooth out rapidly fluctuating offered rates, the system averages the measured offered rate with a window of previously measured offered traffic statistics and knowledge of the time between the samples.

The window size is defined by the “rate calculation minimum interval” with offered traffic statistics being read at most four times within the window. Any previous measured offered statistics within the window are used in the averaging function. Note that if there are large numbers of samples required, for example when a large number of queues are running HQoS, then it may be that a time greater than the “rate calculation minimum interval” passes before another sample of the offered statistics can be taken for a queue. In this case, in order to calculate an offered rate, HQoS will always use two samples, the current and the previous. In this case, using a smaller rate-calc-min-int will have no effect on the responsiveness of HQoS to queue rate changes.

The system separates policers and queues into fast and slow categories and maintains a separate “rate calculation minimum interval” for each type. The default for each type are as follows:

Slow Queue: 1.0 seconds

Fast Queue: 0.25 seconds

The actual minimum rate calculation interval may be increased or decreased by using the fast-queue and/or slow-queue keywords (which are also applicable for policers managed by HQoS) followed by a percent value which is applied to the default interval. The default slow-queue threshold rate is 1 Mbps. Once a policer or queue is categorized as slow, its rate must rise to 1.5 Mbps before being categorized as a fast policer or queue. The categorization threshold may be modified by using the slow-queue-thresh command.

The no rate-calc-min-interval command is used to restore the default fast queue and slow queue minimum rate calculation interval.

This command is used to override the default minimum time that must elapse before a virtual scheduler may redistribute bandwidth based on changes to the offered rates of member policers or queues. A minimum run interval is enforced to allow a minimum amount of “batching” queue changes before reacting to the changed rates. This minimum interval is beneficial since the periodic function of determining policer or queue offered rates is performed sequentially and the interval allows a number policer and queue rates to be determined prior to determining the distribution of bandwidth to the policers and queues.

The default minimum scheduler run interval is 0.5 seconds. The sched-run-min-int command uses a percent value to modify the default interval.

The no sched-run-min-int command is used to restore the default minimum scheduler run interval for all virtual schedulers on the card.

This command is used to override the system default rate threshold where policers and queues are placed in the “slow” queue category. Slow rate policers and queues use a different minimum rate calculation interval time than fast rate queues. The rate is determined based on the previous calculated offered rate for the policer or queue.

The default slow policer or queue rate is 1 Mbps. The fast rate is derived by multiplying the slow rate by a factor of 1.5 resulting in a default fast rate of 1.5 Mbps. The slow-queue-thresh command uses a “Kilobit-Per-Second” value to modify the default slow queue rate threshold and indirectly changes the fast queue rate threshold.

The no slow-queue-thresh command is used to restore the default slow queue and fast rate thresholds.

This command is used to override the system default time between scheduling the hierarchical virtual scheduling task. By default, the system “wakes” the virtual scheduler task every 50ms; this is equivalent to five 10ms timer ticks. The task-scheduling-int command uses a percent value parameter to modify the number of timer ticks.

While the system accepts a wide range of percent values, the result is rounded to the nearest 10ms tick value. The fastest wake interval is 10ms (1 timer tick).

The no scheduling-int command is used to restore the default task scheduling interval of the card’s hierarchical virtual scheduler task.

This command enables access to the configuration of the forwarding planes on a card. Depending on the type of card, there may be one or two forwarding planes.

The default forwarding plane is 1. When entering the fp node, if the forwarding plane number is omitted, the system will assume forwarding plane number 1. This command is supported on FP2 and higher-based line cards.

This command enables access to the egress fp CLI context.

This command enables the context to configure the aggregate WRED queue parameters for all WRED queues on an egress forwarding plane.

The buffer-allocation command defines the amount of buffers that will be set aside for WRED queue buffer pools. Note that the min percentage and max percentage parameters must be set to the same value. The forwarding plane protects against cross application buffer starvation by implementing a hierarchy of buffer pools. At the top of the hierarchy are mega-pools. Mega-pools are used to manage buffers at a system application level. Two mega-pools are currently used by the system. The first (default) mega-pool services all non-WRED type queues and when WRED queues are not enabled will contain all available forwarding plane queue buffers. When WRED queuing is enabled, the second mega-pool (the WRED mega-pool) is given buffers from the default mega-pool based on the buffer-allocation command.

The mega-pools provide buffers to the second tier buffer pools. The default mega-pool services all default pools and explicitly created named pools. As the name implies, the WRED mega-pool services all the WRED buffer pools created for the WRED queues. The WRED mega-pool allows each WRED queue pool to be configured to an appropriate size while allowing the sum of the WRED queue pool sizes to oversubscribe the total amount set aside for WRED queue buffering without affecting the queues using the default or named pools.

No buffers are allocated to the WRED mega-pool until the wred-queue-control shutdown command is set to no shutdown. When the shutdown command is executed, all buffers allocated to the WRED mega-pool are returned to the default mega-pool and all WRED queues are returned either to their default buffer pool or their specified named buffer pool.

The no form of the command immediately restores the default min and max percentage values for sizing the WRED mega-pool.

This command defines the amount of buffers within the WRED mega-pool that will be set aside for WRED queues operating within their configured CBS thresholds. Note that the min percentage and max percentage parameters must be set to the same value. The forwarding plane protects against WRED queue buffer starvation by setting aside a portion of the buffers within the WRED mega-pool. The WRED queue CBS threshold defines when a WRED queue requests buffers from reserved portion of the WRED mega-pool and when it starts requesting buffers from the shared portion of the mega-pool. With proper oversubscription provisioning, this prevents a seldom active queue from being denied a buffer from the mega-pool when the shared portion of the mega-pool is congested.

The WRED mega-slope reserve CBS size is controlled in the same manner as the overall sizing of the WRED mega-pool. A min and max parameter is provided to scope the range that the reserved portion based on percentages of the WRED mega-pool current size.

The no form of the command immediately restores the default min and max percentage values for sizing the WRED mega-pool CBS reserve.

This command configures WRED slopes within the WRED mega-pool. The WRED slopes in the WRED mega-pool are used when WRED queues are requesting buffers from the mega-pool while they are over their CBS threshold. Once over the CBS threshold, the WRED queue stops receiving buffers from the CBS reserve in the mega-pool and starts competing for buffers in the shared portion of the mega-pool. If the packet resulting in the buffer request is inplus-profile, the packet will be associated with the highplus-slope. In-profile packets are associated with the high slope. Out-of-profile packets are associated with the low slope. Exceed-profile packets are associated with the exceed slope.While the queue is within its CBS threshold, the slopes are ignored.

Within the defined slope-policy, each slope is enabled or disabled (no shutdown or shutdown) and each slope’s geometry is defined as percentages of shared portion depth. If a slope is shutdown, the related traffic uses the minimum of the queue MBS and egress WRED megapool size as a drop tail.

The slope-policy also defines the time average factor (TAF) value that is used to determine how the pool’s weighted average depth is calculated. The higher the factor, the slower the average depth tracks the actual pool depth.

The no form of the command restores the default slope policy to the WRED mega-pool.

This command enables or disables egress WRED queue support on the forwarding plane. By default, WRED queue support is disabled (shutdown). While disabled, the various wred-queue-control commands may be executed on the forwarding plane and SAP egress QoS policies and egress queue group templates with wred-queue enabled may be applied to egress SAPs and port, respectively. The forwarding plane will allocate WRED pools to the WRED queues and the appropriate WRED mega-pool size and CBS reserve size will be calculated, but the WRED mega-pool will be empty and all buffers will be allocated to the default mega-pool. Each WRED queue will be mapped to either its appropriate default pool or an explicitly defined named pool.

Once the no shutdown command is executed, the calculated WRED mega-pool buffers will be moved from the default mega-pool to the WRED mega-pool. The WRED mega-pool CBS reserve size will be applied and each egress WRED queue will be moved from its default mega-pool buffer pool to its WRED pool within the WRED mega-pool hierarchy.

The no form of the command enables WRED queuing on an egress forwarding plane.

This command designates the forwarding plane as a high-bandwidth IP multicast source, expecting the ingress traffic to include high-bandwidth IP multicast traffic. When configured, the system attempts to allocate a dedicated multicast switch fabric plane (MSFP) to the forwarding plane. If a group is specified, all FPs in the group will share the same MSFP. If the alarm parameter is specified and the system cannot allocate a dedicated MSFP to the new group or FP, the FPs will be brought online and generate an event (SYSTEM: 2052 - mdaHiBwMulticastAlarm). Similarly, if during normal operation there is a failure or removal of resources, an event will be generated if the system cannot maintain separation of MSFPs for the MDAs.

The no form of the command removes the high-bandwidth IP multicast source designation from the forwarding plane.

This command enables access to the ingress fp CLI context.

This CLI node contains the access forwarding-plane parameters.

This command creates an instance of a named queue group template on the ingress forwarding plane of a given IOM/IMM. The queue-group-name and instance instance-id are mandatory parameters when executing the command.

The named queue group template can contain only policers. If it contains queues, then the command will fail.

The no form of the command deletes a specific instance of a queue group.

This command configures an accounting policy that can apply to a queue-group on the forwarding plane.

An accounting policy must be configured before it can be associated to an interface. If the accounting policy-id does not exist, an error is returned.

Accounting policies associated with service billing can only be applied to SAPs. The accounting policy can be associated with an interface at a time.

The no form of this command removes the accounting policy association from the queue-group.

This command enables the collection of accounting and statistical data for the queue group on the forwarding plane. When applying accounting policies, the data, by default, is collected in the appropriate records and written to the designated billing file.

When the no collect-stats command is issued, the statistics are still accumulated, however, the CPU does not obtain the results and write them to the billing file. If the collect-stats command is issued again (enabled), then the counters written to the billing file will include the traffic collected while the no collect-stats command was in effect.

This command configures an policer-control policy that can apply to a queue-group on the forwarding plane.

The no form of this command removes the policer-control policy association from the queue-group.

This command defines the parent policer’s PIR leaky bucket’s decrement rate. A parent policer is created for each time the policer-control-policy is applied to either a SAP or subscriber instance. Packets that are not discarded by the child policers associated with the SAP or subscriber instance are evaluated against the parent policer’s PIR leaky bucket.

For each packet, the bucket is first decremented by the correct amount based on the decrement rate to derive the current bucket depth. The current depth is then compared to one of two discard thresholds associated with the packet. The first discard threshold (discard-unfair) is applied if the FIR (Fair Information Rate) leaky bucket in the packet’s child policer is in the confirming state. The second discard threshold (discard-all) is applied if the child policer's FIR leaky bucket is in the exceed state. Only one of the two thresholds is applied per packet. If the current depth of the parent policer PIR bucket is less than the threshold value, the parent PIR bucket is in the conform state for that particular packet. If the depth is equal to or greater than the applied threshold, the bucket is in the violate state for the packet.

If the result is “conform,” the bucket depth is increased by the size of the packet (plus or minus the per-packet-offset setting in the child policer) and the packet is not discarded by the parent policer. If the result is “violate,” the bucket depth is not increased and the packet is discarded by the parent policer. When the parent policer discards a packet, any bucket depth increases (PIR, CIR and FIR) in the parent policer caused by the packet are canceled. This prevents packets that are discarded by the parent policer from consuming the child policers PIR, CIR and FIR bandwidth.

The policer-control-policy root max-rate setting may be overridden on each SAP or sub-profile where the policy is applied.

The no max-rate command returns the policer-control-policy’s parent policer maximum rate to max.

This command contains the root arbiter parent policer’s min-thresh-separation command and each priority level’s mbs-contribution command that is used to internally derive each priority level’s shared-portion and fair-portion values. The system uses each priority level’s shared-portion and fair-portion value to calculate each priority level’s discard-unfair and discard-all MBS thresholds that enforce priority sensitive rate-based discards within the root arbiter’s parent policer.

The priority-mbs-thresholds CLI node always exists and does not need to be created.

The mbs-contribution command is used to configure the policy-based burst tolerance for a parent policer instance created when the policy is applied to a SAP or subscriber context. The system uses the parent policer’s min-thresh-separation value, the priority level’s mbs-contribution value and the number of child policers currently attached to the priority level to derive the priority level’s shared-portion and fair-portion of burst tolerance within the local priority level. The shared-portion and fair-portions for each priority level are then used by the system to calculate each priority level’s discard-unfair threshold and discard-all threshold.

The value for a priority level’s mbs-contribution within the policer-control-policy may be overridden on the SAP or subscriber sub-profile where the policy is applied in order to allow fine tuning of the discard-unfair and discard-all thresholds relevant to the needs of the local child policers on the object.

Accumulative Nature of Burst Tolerance for a Parent Policer Priority Level

When defining mbs-contribution, the specified size may only be a portion of the burst tolerance associated with the priority level. The packets associated with the priority level share the burst tolerance of lower within the parent policer. As the parent policer PIR bucket depth increases during congestion, the lower priority packets eventually experience discard based on each priority’s discard-unfair and discard-all thresholds. Assuming congestion continues once all the lower priority packets have been prevented from consuming bucket depth, the burst tolerance for the priority level will be consumed by its own packets and any packets associated with higher priorities.

The Effect of Fair and Unfair Child Policer Traffic at a Parent Policer Priority Level

The system continually monitors the offered rate of each child policer on each parent policer priority level and detects when the policer is in a congested state (the aggregate offered load is greater than the decrement rate defined on the parent policer). As previously stated, the result of congestion is that the parent policer's bucket depth will increase until it eventually hovers around either a discard-unfair or discard-all threshold belonging to one of the priority levels. This threshold is the point where enough packets are being discarded that the increment rate and decrement rate begin to even out. If only a single child policer is associated to the priority level, the discard-unfair threshold is not used since fairness is only applicable when multiple child policers are competing at the same priority level.

When multiple child policers are sharing the congested priority level, the system uses the offered rates and the parenting parameters of each child to determine the fair rate per child when the parent policer is unable to meet the bandwidth needs of each child. The fair rate represents the amount of bandwidth that each child at the priority level should receive relative to the other children at the same level according to the policer control policy instance managing the child policers. This fair rate is applied as the decrement rate for each child’s FIR bucket. Changing a child’s FIR rate does not modify the amount of packets forwarded by the parent policer for the child’s priority level. It simply modifies the forwarded ratio between the children on that priority level. Since each child FIR bucket has some level of burst tolerance before marking its packets as unfair, the current parent policer bucket depth may at times rise above the discard-unfair threshold. The mbs-contribution value provides a means to define how much separation is provided between the priority level’s discard-unfair and discard-all threshold to allow the parent policer to absorb some amount of FIR burst before reaching the priority’s discard-all threshold.

This level of fair aggregate burst tolerance is based on the decrement rate of the parent policer’s PIR bucket while the individual fair bursts making up the aggregate are based on each child’s FIR decrement rate. The aggregate fair rate of the priority level is managed by the system with consideration of the current rate of traffic in higher priority levels. In essence, the system ensures that for each iteration of the child FIR rate calculation, the sum of the child FIR decrement rates plus the sum of the higher priority traffic increment rates equals the parent policers decrement rate. This means that dynamic amounts of higher priority traffic can be ignored when sizing a lower priority’s fair aggregate burst tolerance. Consider the following:

The 12 Mbps of the higher priority traffic and the 8 Mbps of fair traffic equal the 20 Mbps decrement rate of the parent policer.

It is clear that the higher priority traffic is consuming 12 Mbps of the parent policer’s decrement rate, leaving 8 Mbps of decrement rate for the lower priority’s fair traffic.

If all three children burst simultaneously (unlikely), they will consume 30 Kbytes above 8 Mbps. This is the same as the remaining decrement rate after the higher priority traffic.

Parent Policer Total Burst Tolerance and Downstream Buffering

The highest in-use priority level’s discard-all threshold is the total burst tolerance of the parent policer. In some cases the parent policer represents downstream bandwidth capacity and the max-rate of the parent policer is set to prevent overrunning the downstream bandwidth. The burst tolerance of the parent policer defines how much more traffic may be sent beyond the downstream scheduling capacity. In the worst case scenario, when the downstream buffering is insufficient to handle the total possible burst from the parent policer, downstream discards based on lack of buffering may occur. However, in all likelihood, this is not the case.

In most cases, lower priority traffic in the policer will be responsible for the greater part of congestion above the parent policer rate. Since this traffic is discarded with a lower threshold, this lowers the effective burst tolerance even while the highest priority traffic is present.

Configuring a Priority Level's MBS Contribution Value

In the most conservative case, a priority level’s mbs-contribution value may be set to be greater than the sum of child policer’s mbs and one max-size-frame per child policer. This ensures that even in the absolute worst case where all the lower priority levels are simultaneously bursting to the maximum capacity of each child, enough burst tolerance for the priority’s children will exist if they also burst to their maximum capacity.

Since simply adding up all the child policer’s PIR MBS values may result in large overall burst tolerances that are not ever likely to be needed, you should consider some level of burst oversubscription when configuring the mbs-contribution value for each priority level. The amount of oversubscription should be determined based on the needs of each priority level.

Using the Fixed Keyword to Create Deterministic Parent Policer Discard Thresholds

In the default behavior, the system ignores the mbs-contribution values for a priority level on a subscriber or SAP parent policer when a child policer is not currently associated with the level. This prevents additional burst tolerance from being added to higher priority traffic within the parent policer.

This does cause fluctuations in the defined threshold values when child policers are added or removed from a parent policer instance. If this behavior is undesirable, the fixed keyword may be used which causes the mbs-contribution value to always be included in the calculation of parent policer’s discard thresholds. The defined mbs-contribution value may be overridden on a subscriber sla-profile or on a SAP instance, but the fixed nature of the contribution cannot be overridden.

If the defined mbs-contribution value for the priority level is zero, the priority level will have no effect on the parent policer’s defined discard thresholds. A packet associated with the priority level will use the next lower priority level’s discard-unfair and discard-all thresholds.

This command defines the minimum required separation between each in-use discard threshold maintained for each parent policer context associated with the policer-control-policy. The min-thresh-separation value may be overridden on each SAP or sub-profile to which the policy is applied.

The system uses the default or specified min-thresh-separation value in order to determine the minimum separation required between each of the of the parent policer discard thresholds. The system enforces the minimum separation based on the following behavior in two ways. The first is determining the size of the shared-portion for each priority level (when the mbs-contribution command’s optional fixed keyword is not specified):

The second function the system uses the min-thresh-separation value for is determining the value per priority level for the fair-portion:

When the mbs-contribution command’s optional fixed keyword is defined for a priority level within the policy, the system will treat the defined mbs-contribution value as an explicit definition of the priority level’s MBS. While the system will continue to track child policer associations with the parent policer priority levels, the association counters will have no effect. Instead the following rules will be used to determine a fixed priority level’s shared-portion and fair-portion:

Each time the min-thresh-separation value is modified, the thresholds for all instances of the parent policer created through association with this policer-control-policy are reevaluated except for parent policer instances that currently have a min-thresh-separation override.

Determining the Correct Value for the Minimum Threshold Separation Value

The minimum value for min-thresh-separation should be set equal to the maximum size packet that will be handled by the parent policer. This ensures that when a lower priority packet is incrementing the bucket, the size of the increment will not cause the bucket's depth to equal or exceed a higher priority threshold. It also ensures that an unfair packet within a priority level cannot cause the PIR bucket to increment to the discard-all threshold within the priority.

When evaluating maximum packet size, each child policer’s per-packet-offset setting should be taken into consideration. If the maximum size packet is 1518 bytes and a per-packet-offset parameter is configured to add 20 bytes per packet, min-thresh-separation should be set to 1538 due to the fact that the parent policer will increment its PIR bucket using the extra 20 bytes.

In most circumstances, a value larger than the maximum packet size is not necessary. Management of priority level aggregate burst tolerance is intended to be implemented using the priority level mbs-contribution command. Setting a value larger than the maximum packet size will not adversely affect the policer performance, but it may increase the aggregate burst tolerance for each priority level.

One thing to note is that a priority level’s shared-portion of the parent policer’s PIR bucket depth is only necessary to provide some separation between a lower priority’s discard-all threshold and this priority’s discard-unfair threshold. It is expected that the burst tolerance for the unfair packets is relatively minimal since the child policers feeding the parent policer priority level all have some amount of fair burst before entering into an FIR exceed or unfair state. The fair burst amount for a priority level is defined using the mbs-contribution command.

The no form of this command returns the policy’s min-thresh-separation value to the default value. This has no effect on instances of the parent policer where min-thresh-separation is overridden unless the override is removed.

The priority level command contains the mbs-contribution configuration command for a given strict priority level. Eight levels are supported numbered 1 through 8 with 8 being the highest strict priority.

Each of the eight priority CLI nodes always exists and do not need to be created. While parameters exist for each priority level, the parameters are only applied when the priority level within a parent policer instance is currently supporting child policers.

This command, within the SAP ingress or egress contexts, is used to create a CLI node for specific overrides to one or more policers created on the SAP through the sap-ingress or sap-egress QoS policies.

The no form of the command is used to remove any existing policer overrides.

This command is used in the sap-ingress and sap-egress QoS policies 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 sap-ingress policy may have up to 32 policers (numbered 1 through 32) may be defined while the sap-egress QoS policy supports a maximum of 8 (numbered 1 through 8). While a policer may be defined within a QoS policy, it is not actually created on SAPs or subscribers associated with the policy until a forwarding class is mapped to the policer’s ID.

All policers must be created within the QoS policies. A default policer is not created when a sap-ingress or sap-egress QoS policy is created.

Once 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 which 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.

Once a policer is created, it cannot be deleted from the QoS policy unless any forwarding classes that are mapped to the policer are first moved to other policers or queues.

The system will allow a policer to be created on a SAP QoS policy regardless of the ability to support policers on objects where the policy is currently applied. The system only scans the current objects for policer support and sufficient resources to create the policer when a forwarding class is first mapped to the policer ID. If the policer cannot be created due to one or more instances of the policy not supporting policing or having insufficient resources to create the policer, the forwarding class mapping will fail.

The no form of this command is used to delete a policer from a sap-ingress or sap-egress QoS policy. The specified policer cannot currently have any forwarding class mappings for the removal of the policer to succeed. It is not necessary to actually delete the policer ID for the policer instances to be removed from SAPs or subscribers associated with the QoS policy once all forwarding classes have been moved away from the policer. It is automatically deleted from each policing instance although it still appears in the QoS policy.

This command is used to configure the policer’s CIR leaky bucket’s exceed threshold. The CIR bucket’s exceed threshold represents the committed burst tolerance allowed by the policer. If the policer’s forwarding rate is equal to or less than the policer’s defined CIR, the CIR bucket depth hovers around the 0 depth with spikes up to the maximum packet size in the offered load. If the forwarding rate increases beyond the profiling rate, the amount of data allowed to be in-profile above the rate is capped by the threshold.

The policer’s cbs 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 policer to its default CBS size.

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. For ingress, trusted in-profile packets and un-trusted high priority packets use the policer’s high priority violate threshold while trusted out-of-profile and un-trusted low priority packets use the policer’s low priority violate threshold. At egress, in-profile packets use the policer’s high priority violate threshold and out-of-profile packets use the policer’s low priority violate threshold.

The PIR bucket’s violate threshold represent 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 policer to its default MBS size.