For more information on the following FP configuration commands, refer to the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide.
This command creates a text description for a configuration context to help identify the content in the configuration file.
This command is supported on TDM satellite.
The no form of this command removes any description string from the context.
no description
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.
no description
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.
This command is supported on TDM satellite.
The no form of this command administratively enables an entity.
This mandatory command enables access to the chassis card IOM, 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.
no card
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, connector, 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 and so on, remain in the MDA configuration context.
Some card hardware can support two different firmware loads. One load includes the base Ethernet functionality, including 10G WAN mode, but does not include 1588 port-based timestamping. The second load includes the base Ethernet functionality and 1588 port-based timestamping, but does not include 10G WAN mode. These are identified as two card types that are the same, except for a “-ptp” suffix to indicate the second loadset; for example, imm40-10gb-sfp and imm40-10gb-sfp-ptp. A hard reset of the card occurs when switching between the two provisioned types.
An appropriate alarm is raised if a partial or complete card failure is detected. The alarm is cleared when the error condition ceases.
New generations of cards include variants controlled by hardware and software licensing. For these cards, the license level must be provisioned in addition to the card type. A card can not become operational unless the provisioned license level matches the license level of the card installed into the slot. The set of license levels varies by card type.
The provisioned level controls aspects related to connector provisioning and the consumption of hardware egress queues and egress policers. Changes to the provisioned license level may be blocked if configuration exists that would not be permitted with the new target license level.
If the license level is not specified, the level is set to the highest license level for that card.
The no form of this command removes the card from the configuration.
no card-type
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, the node is 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, and so on) 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.
no fail-on-error
This command specifies the filter profile for 7750 SR-a line cards.
filter-profile none
This command enables power-save mode on a specific card when it is not in use. Power-save mode allows a card to be installed and configured in a platform for future use, while having minimal impact on the overall power consumption. The card placed in power-save mode is forced into an idle state to consume minimal power. This command resets the card and then disallows the download of a software image when the card comes back up. To enable power-save mode, the desired card must first be shut down, then placed into power-save mode. In this mode, the card is not counted in the intelligent power management budget. Cards set to power-save mode do not pass traffic.
The no form of this command removes the card from power-save mode.
no power-save
This command configures the behavior of the card when a fatal memory parity error is detected on a Q-chip of the card. If reset-on-recoverable-error is enabled, the card is reset, regardless of the setting of the fail-on-error parameter.
The no form of this command specifies that the recovery action is taken instead of resetting the card.
no reset-on-recoverable-error
This command assigns a license level upgrade to the card, XIOM, or XMA. There can be multiple upgrades applied to a card, XIOM, or XMA. The first upgrade must use index 1 and then next index 2 and so on. Also, when removing upgrades, the largest index must be removed first and then the next largest removed and so on.
The path indicates the starting level and the new level that will apply due to the upgrade. For example, "cr1200g-cr1600g" can be applied to an XMA that is currently at the cr1200g level and after application of the upgrade, the operational level of the XMA shall be cr1600g.
There must be an upgrade license available for the path specified. Available upgrades can be checked using the show licensing entitlements command.
![]() | Note: Some upgrades require a hard reset of the card or MDA to take effect. In general, this is required when the Full Duplex bandwidth is being changed. |
This mandatory command enables access to a card’s MDA CLI context to configure MDAs.
This command defines the clocking mode on the specified MDA. This command is only supported on CES MDAs.
clock-mode adaptive
This command allows the user to control the action to be taken when a specific hardware error event is raised against the target MDA.
If no event action has been created for a specific event-type, then the hardware errors related to that event-type are ignored by the management plane of the router.
The no form of this command clears any action defined for the event.
This command defines the action to be taken when a specific hardware error event is raised against the target mda.
Only one action can be enabled at a time. Entering a new action will override a previously defined action.
The no form of this command sets the action to the default value.
action log-only
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.
threshold 1000
The threshold value cannot be changed while fail-on-error is enabled for this MDA.
This command configures the Error Window value used by the fail-on-error feature.
window 60
The window value cannot be changed while fail-on-error is enabled for this 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 or XCM. To modify an MDA slot, shut down all port associations.
XMAs are provisioned using MDA commands. 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 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.
Some MDA hardware can support two different firmware loads. One load includes the base Ethernet functionality, including 10G WAN mode, but does not include 1588 port-based timestamping. The second load includes the base Ethernet functionality and 1588 port-based timestamping, but does not include 10G WAN mode. These are identified as two MDA types that are the same, except for a “-ptp” suffix to indicate the second loadset; for example, x40-10gb-sfp and x40-10gb-sfp-ptp. A hard reset of the MDA occurs when switching between the two provisioned types.
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.
New generations of XMAs include variants controlled through hardware and software licensing. For these XMAs, the license level must be provisioned in addition to the MDA type. An XMA cannot become operational unless the provisioned license level matches the license level of the XMA installed into the slot. The set of license levels varies by MDA type.
The provisioned level controls aspects related to connector provisioning and the consumption of hardware egress queues and egress policers. Changes to the provisioned license level may be blocked if configuration that would not be permitted with the new target license level exists.
If the license level is not specified, the level is set to the highest license level for that XMA.
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.
This command sets the power priority value for an XMA or MDA-s on platforms that support intelligent power management.
power-priority-level 150
This command configures the behavior of the MDA when a fatal memory parity error is detected on a Q-chip of the MDA. If reset-on-recoverable-error is enabled, the MDA is reset, regardless of the setting of the fail-on-error parameter.
The no form of this command specifies that the recovery action is taken instead of resetting the MDA.
no reset-on-recoverable-error
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 this 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.
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.
This command configures pool policies.
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 FP level for non-channelized MDAs.
pool default
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), the amber alarm threshold cannot be more than the red alarm threshold.
The no form of this command reverts to the default value.
no amber-alarm-threshold
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), the amber alarm threshold cannot be more than the red alarm threshold.
The no form of this command reverts to the default value.
no red-alarm-threshold
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 clears all the adaptive configurations. There cannot be any adaptive sizing enabled for default resv-cbs.
resv-cbs 30
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.
slope-policy default
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.
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.
threshold 1000
The threshold value cannot be changed while fail-on-error is enabled for this MDA.
This command configures the Error Window value used by the fail-on-error feature.
window 60
The window value cannot be changed while fail-on-error is enabled for this MDA.
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.
This command configures an XIOM in one of the slots of an XCM. An XIOM can be used instead of an XMA and operates as a carrier module to support MDA-s modules.
Configures an MDA-s in one of the slots of an XIOM.
This command adds an MDA-s to the device configuration for the slot. The MDA-s type can be preprovisioned, which means that the MDA-s does not have to be installed in the chassis.
An MDA-s must be provisioned before a connector or a port can be configured.
An MDA-s can only be provisioned in a slot that is vacant. No other MDA-s 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.
An MDA-s can only be provisioned in a slot if the MDA-s type is allowed in the slot. An error message is generated if an attempt is made to provision an MDA-s type that is not allowed.
If an MDA-s is inserted that does not match the configured MDA-s type for the slot, then a log event and a facility alarm are raised. The alarm is cleared when the correct MDA-s type is installed or the configuration is modified.
A log event and a facility alarm are raised if an administratively enabled MDA-s is removed from the chassis. The alarm is cleared when the correct MDA-s type is installed or the configuration is modified. A log event is issued when a MDA-s is removed that is administratively disabled.
The no form of this command removes the MDA-s from the configuration.
This command configures the behavior of the XIOM when a fatal memory parity error is detected on a Q-chip of the XIOM. If reset-on-recoverable-error is enabled, the XIOM is reset, regardless of the setting of the fail-on-error parameter.The no form of this command specifies that the recovery action is taken instead of resetting the XIOM.
no reset-on-recoverable-error
This command adds an XIOM to the device configuration for the slot. The XIOM type can be preprovisioned, which means that the XIOM does not have to be installed in the chassis.
An XIOM must be provisioned before an MDA-s, connector, or port can be configured.
An XIOM can only be provisioned in a slot that is vacant. No other XIOM or XMA 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.
An XIOM can only be provisioned in a slot if the XIOM type is allowed in the slot. An error message is generated if an attempt is made to provision an XIOM type that is not allowed.
If an XIOM is inserted that does not match the configured XIOM type for the slot, then a log event and a facility alarm are raised. The alarm is cleared when the correct XIOM type is installed or the configuration is modified.
A log event and a facility alarm are raised if an administratively enabled XIOM is removed from the chassis. The alarm is cleared when the correct XIOM type is installed or the configuration is modified. A log event is issued when a XIOM is removed that is administratively disabled.
XIOMs are controlled by hardware and software licensing. For these cards, the license level must be provisioned in addition to the XIOM type. An XIOM cannot become operational unless the provisioned license level matches the license level of the card installed into the slot. The set of license levels varies by XIOM type.
The provisioned license level controls aspects related to connector provisioning and the consumption of hardware egress queues and egress policers. Changes to the provisioned license level may be blocked if a configuration exists that would not be permitted with the new target license level.
If the license level is not specified, the level is set to the highest license level for that XIOM.
The no form of this command removes the XIOM from the configuration.
The following power commands are supported the 7950 XRS only.
This command sets the power mode.
mode basic
This command sets the PCM slot number.
This command sets the type of PCM for the designated PCM slot. This is not a mandatory configuration; however, by configuring a PCM type of quad-pcm, this ensures the system will always monitor for the presence of PCM fan trays and will provide an indication if no PCM fan trays are detected.
The no form of this command moves the PCM to an unprovisioned state.
no pcm-type
This command sets the APEQ slot number.
This command sets the type of APEQ for the designated APEQ slot.
The no form of this command moves the APEQ to an unprovisioned state.
no peq-type
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 startup and recovery from power depression.
power-safety-level 100
This command enables the context to configure the virtual scheduler processing on the card. This is only applicable to queues and to policers parented to a scheduler.
This command specifies the internal scheduler (tier 0) weight mode for all ingress queues on a LAG on the card on which it is applied.
internal-scheduler-weight-mode default
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 Mb/s. Once a policer or queue is categorized as slow, its rate must rise to 1.5 Mb/s before being categorized as a fast policer or queue. The categorization threshold may be modified by using the slow-queue-threshold command.
The no form of this command restores the default fast queue and slow queue minimum rate calculation interval.
no rate-calc-min-int
This command overrides 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 form of this command restores the default minimum scheduler run interval for all virtual schedulers on the card.
no sched-run-min-int
This command overrides 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 Mb/s. 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 Mb/s. The slow-queue-threshold 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 form of this command restores the default slow queue and fast rate thresholds.
no slow-queue-threshold
The fast rate threshold is derived by multiplying the new slow rate threshold by a factor of 1.5.
This command overrides 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 form of this command restores 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.
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.
Commands can only be configured under card>fp if the hardware that the FP resides on (either a card or an XMA) is provisioned. Conversely, all commands under card>fp of the corresponding FPs are automatically removed when that hardware is unprovisioned.
This command enables access to the egress fp CLI context.
This command specifies the egress aggregate shaper high burst limit threshold delta for this HSQ IOM FP. An aggregate rate can be applied to each egress HSQ queue group, HS secondary shaper and (for subscribers configured with HS SLA expanded mode) primary shaper which manages the maximum burst limit over a specified shaping rate. Each aggregate shaper supports two thresholds which are used in conjunction with the low-burst-max-class setting. The system utilizes the lowest value attainable for each low threshold aggregate burst limit without causing shaper under run conditions. The high burst limit threshold is determined by adding the configured hs-fixed-high-thresh-delta value to the aggregate’s low burst limit threshold value. The hs-fixed-high-thresh-delta value should be set to at least two times the maximum frame size to prevent lower threshold class forwarding from also affecting the higher threshold classes when forwarding larger packet sizes. An insufficient high threshold delta defeats the intended purpose of mapping classes to the higher threshold.
The hs-fixed-high-thresh-delta value can be changed at any time. Modifying the setting causes all aggregate shapers on this FP to reconfigure the low and high burst limit thresholds to reflect the new value.
The no form of this command reverts this parameter to the default.
hs-fixed-high-thresh-delta 4000
This command specifies the HS pool policy for this FP.
An HS pool policy contains the required parameters to create and size root and mid-tier buffer pools on an HSQ IOM, and apply a slope policy to each.
A single HS pool policy is supported per port FP. This command is only applicable to the HSQ IOM (iom4-e-hs) and will fail if configured on all other card types.
The no form of this command removes the policy and reapplies the default policy.
hs-pool-policy default
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. 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 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 to their default buffer pool.
The no form of this command immediately restores the default min and max percentage values for sizing the WRED mega-pool.
buffer-allocation min 25.00 max 25.00
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 this command immediately restores the default min and max percentage values for sizing the WRED mega-pool CBS reserve.
resv-cbs min 25.00 max 25.00
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 this command reverts to the default slope policy to the WRED mega-pool.
slope-policy default
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 its appropriate default 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 this command enables WRED queuing on an egress forwarding plane.
shutdown
This command configures the FP resource policy for the specified FP.
If the allocation configured within the FP resources policy is not achievable with the current ingress or egress queue consumption, the command fails. The configuration within the newly applied FP resource policy takes effect on the FP on which the FP resources policy is applied, and that includes removing an applied user created FP resource policy to return to the default policy, and causes the router to immediately reset the associated cards, XIOMs, and MDAs, except on the 7750 SR-1 where the configuration must be saved, and the router rebooted, immediately after committing the configuration transaction.
The no form of this command reverts to the default value by applying the default fp-resource-policy to the FP.
no fp-resource-policy
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 - tmnxChassisHiBwMulticastAlarm). 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 this command removes the high-bandwidth IP multicast source designation from the forwarding plane.
no hi-bw-mcast-src
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 this 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.
No accounting policies are specified by default. You must explicitly specify a policy. If configured, the accounting policy configured as the default is used.
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.
no collect-stats
This command configures policer control overrides.
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 form of this command returns the policer-control-policy’s parent policer maximum rate to max.
max-rate 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.
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.
no min-thresh-separation
The kilobytes keyword is optional and is mutually exclusive with the bytes keyword. When specified, size is interpreted as specifying the size of min-thresh-separation in kilobytes.
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 configures 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:
FIR Rate | FIR MBS | |
Child 1 | 4 Mb/s | 10 kbytes |
Child 2 | 3 Mb/s | 10 kbytes |
Child 3 | 1 Mb/s | 10 kbytes |
The 12 Mb/s of the higher priority traffic and the 8 Mb/s of fair traffic equal the 20 Mb/s decrement rate of the parent policer.
It is clear that the higher priority traffic is consuming 12 Mb/s of the parent policer’s decrement rate, leaving 8 Mb/s of decrement rate for the lower priority’s fair traffic.
If all three children burst simultaneously (unlikely), they will consume 30 kbytes above 8 Mb/s. 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.
The no form of this command reverts to the policy’s priority level’s MBS contribution to the default value. When changed, the thresholds for the priority level and all higher priority levels for all instances of the parent policer are recalculated.
no mbs-contribution
The kilobytes keyword is optional and is mutually exclusive with the bytes keyword. When specified, size is interpreted as specifying the size of min-thresh-separation in kilobytes.
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.
no policer-control-policy
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 this command removes any existing policer overrides.
no policer-override
This command creates, modifies or deletes 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 fails.
The no form of this command deletes 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 configures 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 configures 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 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, 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 reverts the policer to its default MBS size.
This command modifies the size of each packet handled by the policer 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 the can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the policing metering and profiling throughput is affected by the offset as well as the stats associated with the policer.
When child policers are adding to or subtracting from the size of each packet, the parent policer’s min-thresh-separation value should also need to be modified by the same amount.
The policer’s packet-byte-offset 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 removes per packet size modifications from the policer.
This command configures the policer’s metering and optional profiling rates. The metering rate is used by the system to configure the policer’s PIR leaky bucket’s decrement rate while the profiling rate configures the policer’s CIR leaky bucket’s decrement rate. The decrement function empties the bucket while packets applied to the bucket attempt to fill it based on its packet size. If the bucket fills faster than how much is decremented per packet, the bucket’s depth eventually reaches it's exceeded (CIR) or violate (PIR) threshold. The cbs, mbs, and high-prio-only commands are used to configure the policer’s PIR and CIR thresholds.
If a packet arrives at the policer while the bucket’s depth is less than the threshold associated with the packet, the packet is considered to be conforming to the bucket’s rate. If the bucket depth is equal to or greater than the threshold, the packet is considered to be in the exception state. For the CIR bucket, the exception state is exceeding the CIR rate while the PIR bucket's exception state is violating the PIR bucket rate. If the packet is violating the PIR, the packet is marked red and will be discarded. If the packet is not red, it may be green or yellow based on the conforming or exceeding state from the CIR bucket.
When a packet is red neither the PIR nor the CIR bucket depths are incremented by the packets size. When the packet is yellow the PIR bucket is incremented by the packet size, but the CIR bucket is not. When the packet is green, both the PIR and CIR buckets are incremented by the packet size. This ensures that conforming packets impact the bucket depth while exceeding or violating packets do not.
The policer’s adaptation-rule command settings are used by the system to convert the specified rates into hardware timers and decrement values for the policer’s buckets.
By default, the policer’s metering rate is max and the profiling rate is 0 kb/s (all packets out-of-profile).
The rate settings defined for the policer in the QoS policy may be overridden on an sla-profile or SAP where the policy is applied.
The no form of this command reverts to the default metering and profiling rate of a policer.
This command configures the forwarding plane counters that allow offered, output and discard accounting to occur for the policer. An ingress policer has multiple types of offered packets (explicit in-profile, explicit out-of-profile, 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 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 which prevents any packet accounting, the use of the policer’s parent command requires at 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. Once 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. You can view the total/allocated/free stats by using the tools dump system-resources 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 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.
This CLI node contains the forwarding plane settings for ingress multicast path management. Enter the node to configure the bandwidth-policy and the administrative state of ingress multicast path management.
This command explicitly associates a bandwidth policy to a forwarding plane or MDA. The bandwidth policy defines the dynamic rate table and the multicast paths bandwidth and queuing parameters.
If a bandwidth policy is not explicitly associated with a forwarding plane or MDA, the default bandwidth policy is used when ingress multicast path management is enabled.
The no form of this command removes an explicit bandwidth policy from a forwarding plane or MDA and restores the default bandwidth policy.
This command specifies the CLI node that contains the network forwarding-plane parameters.
This command configures the per-FP network ingress pool.
pool default
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 this command reverts to the default value.
no amber-alarm-threshold
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 this command reverts to the default value.
no amber-alarm-threshold
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 clears all the adaptive configurations. There cannot be any adaptive sizing enabled for default resv-cbs.
resv-cbs 30
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.
slope-policy default
This command creates a queue-group instance in the network ingress context of a forwarding plane.
Only a queue-group containing policers can be instantiated. If the queue-group template contains policers and queues, the queues are not instantiated. If the queue-group contains queues only, the instantiation in the data path is failed.
One or more instances of the same policer queue-group name and/or a different policer queue-group name can be created on the network ingress context of a forwarding plane.
The queue-group-name must be unique within all network ingress and access ingress queue groups in the system. The queue-group instance-id must be unique within the context of the forwarding plane.
The no form of this command deletes the queue-group instance from the network ingress context of the forwarding plane.
This command specifies the network-queue policy which defines queue parameters such as CBS, high priority only burst size, MBS, CIR and PIR rates, as well as forwarding-class to queue mappings. The network-queue policy is defined in the config>qos>network-queue context.
queue-policy default
This command allows the user to configure an ingress buffer allocation percentage per forwarding plane from 20.00% to 80.00%. Ingress buffer allocation applies to user-accessible buffers (total buffers less those reserved for system use).
The ingress buffer allocation percentage determines how much of the user-accessible buffers will be available for ingress purposes. The remaining buffers will be available for egress purposes.
This command is supported on all 50G FP2-based and 100G/200G FP3-based hardware. It is not supported on other FP2 or FP3-based hardware, nor on FP4-based hardware.
The no form of this command reverts the ingress buffer allocation to the default value.
ingress-buffer-allocation 50.00
This command allows the user to configure the number of stats resources for policy accounting for the forwarding plane.
no policy-accounting
This command provides a stable buffer pool allocation environment for all default port buffer pools on a forwarding plane. This stable environment is provided at the expense of optimal buffer allocation between the various port buffer pools. Normally, port pools are sized according to a ports relative bandwidth with other ports and the ability of a port to use pool buffers. As an example, on a forwarding plane with two potential MDAs and only one equipped, the normal behavior is to provide all available default pool buffers to the ports on the currently equipped MDA. If a second MDA is equipped in the future, buffers are freed from the existing MDA and provided to the ports on the new MDA. Stable pool sizing alters this behavior by reserving buffers for both MDAs whether they are equipped or not thus preventing a resizing event when an MDA is equipped. In addition, existing ports on a module always receive their maximum bandwidth share of buffers independent on any sub-rate condition that may currently exist. This provides a stable amount of buffers to other ports on the module independent of link or configuration events that may occur on the port.
Stable pool sizing preserves the ability to modify the effective bandwidth used to determine a port’s relative share of the available buffers through the use of the ing-percentage-of-rate and egr-percentage-of-rate commands under the port configuration. Changing the values associated with these commands will cause a reevaluation of buffer distribution and thus a possible resizing of pools on each port within the module. These commands have no effect on ports associated with other modules on the forwarding plane.
Stable pool sizing may be enabled or disabled at any time on a forwarding plane. The system will dynamically change the pool sizes according to the stable pool sizing state.
When a port connector breakout is configured, its ports will be included in the stable pool sizing calculation. Consequently, adding or removing a port connector breakout to or from the configuration will cause the buffer pool allocation to be recalculated even when stable pool sizing is enabled.
The no form of this command disables stable pool sizing on a forwarding plane. Existing buffer pools are resized according to normal pool sizing behavior.
This command enables the context for MACsec configuration. The MACsec MKA profile can be configured under this command.
This command configures a connectivity association. MACsec connectivity associations are applied to a port dot1x configuration to enable MACsec on that port.
The no form of this command removes the connectivity association.
This command configures encryption of data path PDUs. When all parties in the Connectivity Association (CA) have the SAK, they use the above algorithm in conjunction with the SAK to encrypt the data path PDUs.
The XPN 64 bit (extended packet number) can be used for higher rate ports such as 10 GigE to minimize the window rollover and renegotiation of the SAK.
The no form of this command disables encryption of data path PDUs.
cipher-suite gcm-aes-128
This command puts 802.1Q tags in clear text before the SecTAG. There are two modes: single-tag and dual-tag.
Table 42 explains the encrypted dot1q and QinQ packet format when clear-tag-mode single-tag or dual-tag is configured.
The no form of this command puts all dot1q tags encrypted after the SecTAG.
Unencrypted format | Clear-tag-mode | Pre-encryption (Tx) | Pre-decryption (Rx) |
Single tag (dot1q) | single-tag | DA, SA, TPID, VID, Etype | DA, SA, TPID, VID, SecTag |
Single tag (dot1q) | dual-tag | DA, SA, TPID, VID, Etype | DA, SA, TPID, VID, SecTag |
Double tag (q-in-q) | single-tag | DA, SA, TPID1, VID1, IPID2, VID2, Etype | DA, SA, TPID1, VID1, SecTag |
Double tag (QinQ) | dual-tag | DA, SA, TPID1, VID1, IPID2, VID2, Etype | DA, SA, TPID1, VID1, IPID2, VID2, SecTag |
no clear-tag-mode
This command enters a description for connectivity association.
The no form of this command removes the connectivity association description.
This command specifies the offset of the encryption in MACsec packet.
The encryption-offset is distributed by MKA (Key-server) to all parties.
It is signaled via MACsec capabilities. There are four basic settings for this. Table 43 breaks down the settings.
Setting | Description |
0 | MACsec is not implemented |
1 | Integrity without confidentiality |
2 | The following are supported:
|
3 1 | The following are supported:
|
Note:
The no form of this command rejects all arriving traffic whether MACsec is secured or not.
encryption-offset 0
This command specifies all PDUs will be encrypted and authenticated (ICV payload).
The no form of this command specifies all PDUs are transmitted with clear text, but still authenticated and have the trailing ICV.
macsec-encrypt
Specifies the size of the replay protection window.
This command must be configured to force packet discard when it has detected a packet that is not within the replay-window-size.
When replay protection is enabled, the sequence of the ID number of the received packets are checked. If the packet arrives out of sequence and the difference between the packet numbers exceeds the replay window size, the packet is counted by the receiving port and then discarded. For example, if the replay protection window size is set to five and a packet assigned the ID of 1006 arrives on the receiving link immediately after the packet assigned the ID of 1000, the packet that is assigned the ID of 1006 is counted and discarded because it falls outside the parameters of the replay window size.
Replay protection is especially useful for fighting man-in-the-middle attacks. A packet that is replayed by a man-in-the-middle attacker on the Ethernet link will arrive on the receiving link out of sequence, so replay protection helps ensure the replayed packet is dropped instead of forwarded through the network.
Replay protection should not be enabled in cases where packets are expected to arrive out of order.
no replay-protection
This command specifies the size of the replay protection window.
This command must be configured to enable replay protection. When replay protection is enabled, the sequence of the ID number of received packets are checked. If the packet arrives out of sequence and the difference between the packet numbers exceeds the replay protection window size, the packet is dropped by the receiving port. For example, if the replay protection window size is set to five and a packet assigned the ID of 1006 arrives on the receiving link immediately after the packet assigned the ID of 1000, the packet that is assigned the ID of 1006 is dropped because it falls outside the parameters of the replay protection window.
Replay protection is especially useful for fighting man-in-the-middle attacks. A packet that is replayed by a man-in-the-middle attacker on the Ethernet link will arrive on the receiving link out of sequence, so replay protection helps ensure the replayed packet is dropped instead of forwarded through the network.
Replay protection should not be enabled in cases where packets are expected to arrive out of order.
When the number-of-packets variable is set to 0, all packets that arrive out-of-order are dropped.
The no form of this command reverts to the default value.
replay-window-size 0
This command shuts down the CA profile. All ports using this profile will not transmit PDUs as this command shuts down the MACsec for this profile.
shutdown
This command allows the configuration of a Connectivity Association Key (CAK). A CAK is responsible for managing the MKA.
This command specifies which pre-shared-key is the active transmitting pre-shared-key. If there are two pre-shared-keys configured, the arriving MACsec MKA can be decrypted via CAKs of both pre-shared keys; however, only the active-psk will be used for TX encryption of MKA PDUs.
active-psk 1
This command specifies the MKA hello interval.
The no form of this command disables the MKA hello interval.
mka-hello-interval 2
This command specifies the key server priority used by the MACsec Key Agreement (MKA) protocol to select the key server when MACsec is enabled using static connectivity association key (CAK) security mode.
The no form of this command disables the mka-key-server-priority.
mka-key-server-priority 16
This command specifies the pre-shared key used to enable MACsec using static connectivity association key (CAK) security mode. This command also specifies the encryption algorithm used for encrypting the SAK.
A pre-shared key includes a connectivity association key name (CKN) and a connectivity association key (CAK). The pre-shared key-the CKN and CAK-must match on both ends of a link.
A pre-shared key is configured on both devices at each end of point-to-point link to enable MACsec using static CAK security mode. The MACsec Key Agreement (MKA) protocol is enabled after the successful MKA liveliness negotiation.
The encryption-type is used for encrypting SAK and authentication of the MKA packet. The symmetric encryption key SAK (Security Association Key) needs to be encrypted (wrapped) via the above protocols. The AES key is derived via pre-shared-key.
The no form of this command removes the index.
Specifies the connectivity association key (CAK) for a pre-shared key. Two values are derived from CAK.
The no form of this command removes the value.
Specifies the connectivity association key name (CKN) for a pre-shared key.
CKN is appended to the MKA for identification of the appropriate CAK by the peer.
The no form of this command reverts to the default value.
This command configures MAC address policy groups.
The no form of this command removes the MAC address policy group configuration.
This command specifies the destination MAC address.
The no form of this command removes the MAC address.
This command enables access to the context to configure ports, multilink bundles, and bundle protection groups (BPGs). Before a port can be configured, the chassis slot must be provisioned with a valid card type and the MDA parameter must be provisioned with a valid MDA type.
No ports are configured. All ports must be explicitly configured and enabled.
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 |
bundle-ppp-slot/mda.bundle-num | Creates a multilink PPP bundle. |
bundle-ima-slot/mda.bundle-num | Creates an IMA bundle. |
bundle-fr-slot/mda.bundle-num | Creates an MLFR bundle. |
where: | bundle: keyword |
slot: IOM/MDA slot numbers | |
bundle-num: 1 to 336 |
When an aps-id is created all applicable parameters under the port CLI tree (including parameters under any submenus) assume aps-id defaults, or when those are not explicitly specified, default to SONET/SDH port defaults for any SONET port.
All but a few exception SONET/SDH parameters for the working channel port must be configured in the config>port>aps>sonet-sdh context. The protection channel inherits all the configured parameters. The exception parameters for the protection channel can be configured in the config>port>aps>sonet-sdh context.
Signal failure (SF) and signal degrade (SD) alarms are not enabled by default on POS interfaces. It is recommended to change the default alarm notification configuration for POS ports that belong to APS groups in order to be notified of SF/SD occurrences to be able to interpret the cause for an APS group to switch the active line.
For path alarms, modify the logical line aps-id in the config>port aps-id <sonet-sdh>path report-alarm context. For example:
configure port aps-1 sonet-sdh path report-alarm p-ais
For line alarms, separately, modify the 2 physical ports that are members of the logical aps-id port (the working and protect lines). APS reacts only to line alarms, not path alarms. For example:
configure port 1/2/3 sonet-sdh report-alarm lb2er-sd
configure port 4/5/6 sonet-sdh report-alarm lb2er-sd
If the SD and SF threshold rates must be modified, the changes must be performed at the line level on both the working and protect APS port member.
The no form of this command deletes an aps-group-id or bundle-aps-group-id. In order for an aps-group-id to be deleted,
The same rules apply for physical ports, bundles deletions apply to APS ports/bundles deletions (for example an aps-group-id must be shutdown, have no service configuration on it, and no path configuration on it). In addition working and protection circuits must be removed before an aps-group-id may be removed.
bpgrp: | keyword |
type: | ppp — Provides protection of one PPP bundle by another. |
ima — Provides protection of one IMA bundle by another IMA bundle. | |
bpgrp-num: | 1 to 1600 |
This command enables the context to configure connector parameters.
This command defines the port breakout of the transceiver that will be used in the connector. Specifying the type triggers the creation of the ports that will be accessible under the connector.
When a QSFP28 connector uses an SFP+ optical module with the QSFP28-to-SFP+/SFP28 adapter, the breakout parameter should be set to c1-10g. This value indicates the presence of the adapter.
The no form of this command removes the ports under the connector.
no breakout
This command enables RS-FEC on the Ethernet connector.
no rs-fec-mode
This command enables Digital Diagnostic Monitoring (DDM) events for the port.
The no form of this command disables DDM events.
This command configures the Dense Wavelength Division Multiplexing (DWDM) parameters.
This command enables you to tune the optical amplifier parameters.
This command allows users to enable/disable the optical amplifier alarms for the port.
All alarms are enabled
This command configures the coherent optical module parameters.
This command configures the Dense Wavelength Division Multiplexing (DWDM) ITU channel at which a tunable MDA optical interface will be configured to operate. It is expressed in a form that is derived from the laser's operational frequency. For example 193.40 THz corresponds to DWDM ITU channel 34 in the 100 GHz grid and 193.45 THz corresponds to DWDM ITU channel 345 in the 50 GHz grid. Provisioning rules: The provisioned MDA type must have DWDM tunable optics (for example, p1-100g-tun).
Where: | 17 to 61 is used for 100 GHz channels |
175, 185 to 605 is used for 50 GHz channels | |
0 is only valid on disabled (shutdown) ports |
C-Band | |||||
100 GHz Grid | 50GHz Grid | ||||
nm | THz | ITU Channel | nm | THz | ITU Channel |
1528.77 | 196.10 | 61 | 1529.16 | 196.05 | 605 |
1529.55 | 196.00 | 60 | 1529.94 | 195.95 | 595 |
1530.33 | 195.90 | 59 | 1530.72 | 195.85 | 585 |
1531.12 | 195.80 | 58 | 1531.51 | 195.75 | 575 |
1531.90 | 195.70 | 57 | 1532.29 | 195.65 | 565 |
1532.68 | 195.60 | 56 | 1533.07 | 195.55 | 555 |
1533.47 | 195.50 | 55 | 1533.86 | 195.45 | 545 |
1534.25 | 195.40 | 54 | 1534.64 | 195.35 | 535 |
1535.04 | 195.30 | 53 | 1535.43 | 195.25 | 525 |
1535.82 | 195.20 | 52 | 1536.22 | 195.15 | 515 |
1536.61 | 195.10 | 51 | 1537.00 | 195.05 | 505 |
1537.40 | 195.00 | 50 | 1537.79 | 194.95 | 495 |
1538.19 | 194.90 | 49 | 1538.58 | 194.85 | 485 |
1538.98 | 194.80 | 48 | 1539.37 | 194.75 | 475 |
1539.77 | 194.70 | 47 | 1540.16 | 194.65 | 465 |
1540.56 | 194.60 | 46 | 1540.95 | 194.55 | 455 |
1541.35 | 194.50 | 45 | 1541.75 | 194.45 | 445 |
1542.14 | 194.40 | 44 | 1542.54 | 194.35 | 435 |
1542.94 | 194.30 | 43 | 1543.33 | 194.25 | 425 |
1543.73 | 194.20 | 42 | 1544.13 | 194.15 | 415 |
1544.53 | 194.10 | 41 | 1544.92 | 194.05 | 405 |
1545.32 | 194.00 | 40 | 1545.72 | 193.95 | 395 |
1546.12 | 193.90 | 39 | 1546.52 | 193.85 | 385 |
1546.92 | 193.80 | 38 | 1547.32 | 193.75 | 375 |
1547.72 | 193.70 | 37 | 1548.11 | 193.65 | 365 |
1548.51 | 193.60 | 36 | 1548.91 | 193.55 | 355 |
1549.32 | 193.50 | 35 | 1549.72 | 193.45 | 345 |
1550.12 | 193.40 | 34 | 1550.52 | 193.35 | 335 |
1550.92 | 193.30 | 33 | 1551.32 | 193.25 | 325 |
1551.72 | 193.20 | 32 | 1552.12 | 193.15 | 315 |
1552.52 | 193.10 | 31 | 1552.93 | 193.05 | 305 |
1553.33 | 193.00 | 30 | 1553.73 | 192.95 | 295 |
1554.13 | 192.90 | 29 | 1554.54 | 192.85 | 285 |
1554.94 | 192.80 | 28 | 1555.34 | 192.75 | 275 |
1555.75 | 192.70 | 27 | 1556.15 | 192.65 | 265 |
1556.55 | 192.60 | 26 | 1556.96 | 192.55 | 255 |
1557.36 | 192.50 | 25 | 1557.77 | 192.45 | 245 |
1558.17 | 192.40 | 24 | 1558.58 | 192.35 | 235 |
1558.98 | 192.30 | 23 | 1559.39 | 192.25 | 225 |
1559.79 | 192.20 | 22 | 1560.20 | 192.15 | 215 |
1560.61 | 192.10 | 21 | 1561.01 | 192.05 | 205 |
1561.42 | 192.00 | 20 | 1561.83 | 191.95 | 195 |
1562.23 | 191.90 | 19 | 1562.64 | 191.85 | 185 |
1563.05 | 191.80 | 18 | 1563.45 | 191.75 | 175 |
1563.86 | 191.70 | 17 | — | — | — |
This command configures the optical mode and rate of operation.
This command configures the window size used for carrier phase recovery.
32
This command configures the residual chromatic dispersion to be compensated when the coherent receiver is operating in manual dispersion control mode.
0
This command configures the mode used to compensate for chromatic dispersion.
This command configures the alarms that will be reported for the coherent module.
modflt mod netrx nettx hosttx
This command configures the reaction to an RX LOS.
This command configures the average input power LOS threshold.
-23.00
This command allows users to configure the dispersion sweep ‘start’ and ‘end’ values for the automatic mode of coherent control. If the user knows the approximate or theoretical residual dispersion of the link, this command can be used to limit the range of sweeping for the automatic control mode and thus achieve faster link up.
This command configures the target transmit optical power for the port.
target-power 1.00
This command enables you to adjust the optical receive decision threshold voltage (RxDTV).
no rxdtv-adjust
This command configures the Tunable Dispersion Compensation Module parameters.
This command allows users to configure the dispersion compensation for the port when manual mode is selected.
This command allows users to configure the dispersion algorithm mode used for the port. Manual mode is used when the user knows the residual dispersion on the link. Automatic mode is used to let the software determine the optimal dispersion compensation required. Automatic mode should be used during service commissioning and when the state if the TDCM control is converged, the user can change to manual mode and configure the dispersion compensation found by the software. Because automatic mode uses a search algorithm that will sweep the entire range of dispersion specified in the sweep command, it can take up to 10 minutes for the link to come up. In manual mode, the link can come up in 2 minutes or less.
This command allows users to enable or disable logging of TDCM alarms on the port.
All alarms are enabled
This command allows users to configure the dispersion sweep ‘start’ and ‘end’ values for the automatic mode of TDCM control. If the user knows the approximate or theoretical residual dispersion of the link, this command can be used to limit the range of sweeping for the automatic control mode and thus achieve faster link up.
This command validates whether or not the port supports Wavetracker.
This command specifies whether or not Wavetracker keys should be encoded on the transmitted optical signal.
no encode
DWDM ITU Channel Number | Key 1 Minimum | Key 1 Maximum | Key 2 Minimum | Key 2 Maximum |
17 | 1276 | 1290 | 1760 | 1774 |
18 | 1259 | 1273 | 1743 | 1757 |
19 | 1242 | 1256 | 1726 | 1740 |
20 | 1225 | 1239 | 1709 | 1723 |
21 | 528 | 542 | 1072 | 1086 |
22 | 511 | 525 | 1055 | 1069 |
23 | 494 | 508 | 1038 | 1052 |
24 | 477 | 491 | 1021 | 1035 |
25 | 1208 | 1222 | 1692 | 1706 |
26 | 460 | 474 | 1004 | 1018 |
27 | 443 | 457 | 987 | 1001 |
28 | 426 | 440 | 970 | 984 |
29 | 409 | 423 | 953 | 967 |
30 | 1191 | 1205 | 1675 | 1689 |
31 | 392 | 406 | 936 | 950 |
32 | 375 | 389 | 919 | 933 |
33 | 358 | 372 | 902 | 916 |
34 | 341 | 355 | 885 | 899 |
35 | 1174 | 1188 | 1658 | 1672 |
36 | 324 | 338 | 868 | 882 |
37 | 307 | 321 | 851 | 865 |
38 | 290 | 304 | 834 | 848 |
39 | 273 | 287 | 817 | 831 |
40 | 1157 | 1171 | 1641 | 1655 |
41 | 256 | 270 | 800 | 814 |
42 | 239 | 253 | 783 | 797 |
43 | 222 | 236 | 766 | 780 |
44 | 205 | 219 | 749 | 763 |
45 | 1140 | 1154 | 1624 | 1638 |
46 | 188 | 202 | 732 | 746 |
47 | 171 | 185 | 715 | 729 |
48 | 154 | 168 | 698 | 712 |
49 | 137 | 151 | 681 | 698 |
50 | 1123 | 1137 | 1607 | 1621 |
51 | 120 | 134 | 664 | 678 |
52 | 103 | 117 | 647 | 661 |
53 | 86 | 100 | 630 | 644 |
54 | 69 | 83 | 613 | 627 |
55 | 1106 | 1120 | 1590 | 1604 |
56 | 52 | 66 | 596 | 610 |
57 | 35 | 49 | 579 | 593 |
58 | 18 | 32 | 562 | 576 |
59 | 1 | 15 | 545 | 559 |
60 | 1089 | 1103 | 1573 | 1587 |
61 | 1548 | 1548 | 2032 | 2032 |
175 | 3553 | 3567 | 4065 | 4079 |
185 | 3536 | 3550 | 4048 | 4062 |
195 | 3519 | 3533 | 4031 | 4045 |
205 | 3502 | 3516 | 4014 | 4028 |
215 | 3840 | 3854 | 2304 | 2318 |
225 | 3823 | 3837 | 2287 | 2301 |
235 | 3806 | 3820 | 2270 | 2284 |
245 | 3789 | 3803 | 2253 | 2267 |
255 | 3485 | 3499 | 3997 | 4011 |
265 | 3772 | 3786 | 2236 | 2250 |
275 | 3755 | 3769 | 2219 | 2233 |
285 | 3738 | 3752 | 2202 | 2216 |
295 | 3721 | 3735 | 2185 | 2199 |
305 | 3468 | 3482 | 3980 | 3994 |
315 | 3704 | 3718 | 2168 | 2182 |
325 | 3687 | 3701 | 2151 | 2165 |
335 | 3670 | 3684 | 2134 | 2148 |
345 | 3653 | 3667 | 2117 | 2131 |
355 | 3451 | 3465 | 3963 | 3977 |
365 | 3636 | 3650 | 2100 | 2114 |
375 | 3619 | 3633 | 2083 | 2097 |
385 | 3602 | 3616 | 2066 | 2080 |
395 | 3585 | 3599 | 2049 | 2063 |
405 | 3434 | 3448 | 3946 | 3960 |
415 | 1548 | 1562 | 2032 | 2046 |
425 | 1531 | 1545 | 2015 | 2029 |
435 | 1514 | 1528 | 1998 | 2012 |
445 | 1497 | 1511 | 1981 | 1995 |
455 | 3908 | 3922 | 2372 | 2386 |
465 | 1480 | 1494 | 1964 | 1978 |
475 | 1463 | 1477 | 1947 | 1961 |
485 | 1446 | 1460 | 1930 | 1944 |
495 | 1429 | 1443 | 1913 | 1927 |
505 | 3891 | 3905 | 2355 | 2369 |
515 | 1412 | 1426 | 1896 | 1910 |
525 | 1395 | 1409 | 1879 | 1893 |
535 | 1378 | 1392 | 1862 | 1876 |
545 | 1361 | 1375 | 1845 | 1859 |
555 | 3874 | 3888 | 2338 | 2352 |
565 | 1344 | 1358 | 1828 | 1842 |
575 | 1327 | 1341 | 1811 | 1825 |
585 | 1310 | 1324 | 1794 | 1808 |
595 | 1293 | 1307 | 1777 | 1791 |
605 | 3857 | 3871 | 2321 | 2335 |
This command specifies whether the power control loop should be turned on to actively control the laser’s launch power to the specified target power. When power-control is disabled, the launch power is set to the laser’s maximum achievable power.
no power-control
This command specifies launch power in dBm for the DWDM Wavetracker-enabled interface.
target-power -20.00
This command specifies the alarms which are enabled or outstanding against a Wave Tracker-enabled interface.
The no form of this command removes the alarm parameters.
This command configures a queue-group instance in the network egress context of a port.
Queue-groups containing queues only or policers and queues can be instantiated. When a port is a LAG, one instance of the queue-group is instantiated on each member link.
One or more instances of the same queue-group name and/or a different queue-group name can be created in the network egress context of a port.
The queue-group-name must be unique within all network egress and access egress queue groups in the system. The queue-group instance-id must be unique within the context of the port.
The no version of this command deletes the queue-group instance from the network egress context of the port.
This command specifies whether or not to enable OTU encapsulation. The port must be shut down before OTU is enabled. This command is valid only for ports on assemblies that support this encapsulation mode. Refer to the appropriate Installation Guide for ports assembly to determine if OTU encapsulation is supported.
Note that OTU cannot be disabled on OTU3 encapsulated OC768 or 40-Gigabit Ethernet.by the no otu command. Therefore, the default depends on the port type. The default for OTU3 encapsulated OC768 or 40-Gigabit Ethernet is otu.
The no form of this command disables OTU (clear channel 10GE-LAN/WAN or OC192).
no otu
This command enables the Forwarding Error Correction (FEC) encoder/decoder and specifies the FEC encoder/decoder mode to use when enabled.
The following rules must be followed:
Note that FEC cannot be disabled on OTU3 encapsulated OC768 or 40-Gigabit Ethernet by the no fec command. Therefore, the default depends on the port type. The default for OTU3 encapsulated OC768 or 40-Gigabit Ethernet is fec enhanced.
The no form of this command disables FEC encoder and decoder.
no fec
This command specifies the data rate to use when configured for an OTU encapsulated 10GE-LAN signal. The port must be shut down before changing the 10GE LAN OTU2 data rate.
otu2-lan-data-rate 11.049
This command enables the context to configure path monitoring trail trace identifier parameters.
This command allows the user to configure the expected RX trail trace identifier (TTI) for path monitoring (PM) in the ODU overhead. This identifier can be a string or a non-printable sequence of bytes. The length of the string or sequence of bytes cannot exceed 64 bytes. This trace should match the far-end port’s PM trace. When this trace does not match the received PM trace, the ODU-TIM alarm will be reported if enabled.
Blank (all zeros)
This command allows the user to configure the consequent action to a pm-tti mismatch.
The no form of this command reverts to the default value.
n/a, the received traffic is passed through.
This command enables the user to configure the transmit (tx) trail trace identifier (TTI) for path monitoring (PM) in the ODU overhead. This identifier can be a string or a non-printable sequence of bytes. The length of the string or sequence of bytes cannot exceed 64 bytes.
The no form of this command reverts to the default TTI value.
Auto-generated in the format of nodename:iomnum/mdanum/portnum/dwdmchan
The auto-generated value has five sections:
This command enables the context to configure payload structure identifier payload parameters.
This command allows the user to configure the expected received payload type value in byte 0 of the Payload structure identifier (PSI) of the OPU overhead. When this values does not match the received value, the OPU-PLM alarm will be reported if it is enabled.
3 for 10GE-LAN/WAN or OC192 with OTU encapsulation; 5 for GFP framed 10GE-LAN with OTU encapsulation.
This command allows the user to configure the consequent action to a psi-payload type mismatch.
This command specifies the method used to determine the signal failure (SF) and signal degrade (SD) alarms. When the bip8 method is selected, the SM-BIP8 errors are used. When the fec method is selected, the FEC corrected bits are used.
The following rules must be followed:
sf-sd-method fec
This command defines the error rate at which to declare the signal degrade (SD) condition.
The parameters define an error rate of (coefficient/10) * 10E-threshold. For example, sd-threshold 5 coefficient 20 defines an error rate of (20/10) * 10E-5, or 2 * 10E-5, or 0.000 02.
The SD threshold must be:
The coefficient parameter is only used when sf-sd-method is set to fec. When sf-sd-method is set to bip8, coefficient is considered to have the value of 10.
This command defines the signal degrade (SD) threshold clear value.
When the bit error rate falls below this value, the SD condition is cleared. The parameters define an error rate of (coefficient/10) * 10E-threshold. For example, sd-threshold-clear 7 coefficient 10 defines an error rate of (10/10) * 10E-7, or 10E-7, or 0.000 000 1.
This SD threshold clear setting is valid only when sf-sd-method is set to fec.
This command defines the error rate at which to declare the signal failure (SF) condition.
The parameters define an error rate of (coefficient/10) * 10E-threshold. For example, sf-threshold 5 coefficient 20 defines an error rate of (20/10) * 10E-5, or 2 * 10E-5, or 0.000 02.
The SF threshold must be the following:
The coefficient parameter is only used when sf-sd-method is set to fec. When sf-sd-method is set to bip8, coefficient is considered to have the value of 10.
This command defines the signal failure (SF) threshold clear value.
When the bit error rate falls below this value, the SF condition is cleared. The parameters define an error rate of (coefficient/10) * 10E-threshold. For example, sf-threshold-clear 7 coefficient 10 defines an error rate of (10/10) * 10E-7, or 10E-7, or 0.000 000 1.
This SF threshold clear setting is valid only when sf-sd-method is set to fec.
This command enables the context to configure section monitoring trail trace identifier parameters.
This command enables the user to configure the expected RX Trail Trace Identifier (TTI) for Section Monitoring (SM) in the OTU overhead. This identifier can be a string or a non-printable sequence of bytes. The length of the string or sequence of bytes cannot exceed 64 bytes. This trace should match the expected far-end port’s SM trace. When this trace does not match the received SM trace, the OTU-TIM alarm will be reported if enabled.
Blank (all zeros)
This command allows the user to configure the consequent action to a sm-tti mismatch.
n/a
This command allows the user to configure the transmit payload type value in byte 0 of the payload structure identifier (PSI) of the OPU overhead.
3 for 10GE-LAN/WAN or OC192 with OTU encapsulation; 5 for GFP framed 10GE-LAN with OTU encapsulation.
This command allows the user to configure the transmit (tx) trail trace identifier (TTI) for section monitoring (SM) in the OTU overhead. This identifier can be a string or a non-printable sequence of bytes. The length of the string or sequence of bytes cannot exceed 64 bytes.
The no form of this command reverts to the default TTI value.
Auto-generated in the format of nodename:iomnum/mdanum/portnum/dwdmchan
The auto-generated value has five sections:
This command allows the user to configure the transmit trace in bytes 1 to 255 (skipping byte 0) of the payload structure identifier (PSI) of the OPU overhead. This identifier can be a string or a non-printable sequence of bytes. The length of the string or sequence of bytes cannot exceed 255 bytes.
Blank (all zeros)
This command allows the user to configure the port to support asynchronous mapping of the payload inside the OTU. If the port is configured for async-mapping and the payload clock is asynchronous to the OTU clock, there will be positive or negative pointer justification that will show up in the OTU statistics and the data will be received error free. If the port is configured for synchronous mapping and the received data is asynchronously mapped, there will be errors in the received data.
async-mapping is the only mode of operation that is supported on the OTU3 encapsulated 40-Gigabit Ethernet and therefore the 'no async-mapping' is not supported on that port type and the default on the is async-mapping.
The no form of this command configures the port to receive synchronously mapped data.
no async-mapping
This command enables OTU alarms. Specify specific alarms to add to the list of reported alarms.
The no form of this command disables OTU alarm reporting.
loc, los, lof, lom, otu-ber-sf, otu-bdi, fec-sf
Alarm | Description |
loc | Loss of lock. |
lof | Loss of OTU framing. |
lom | Loss of Multi-frame. |
los | Loss of signal transitions on the data. |
otu-ais | OTU Alarm Indication Signal (all 1s, overwrites all OTU overhead, even framing bytes). |
otu-ber-sf | SM Signal Fail (based on BPI8). |
otu-ber-sd | SM Signal Degrade (based on BPI8). |
otu-bdi | SM Backward defect indication. |
otu-tim | SM Trace Id Mismatch. |
otu-iae | SM Incoming Alignment Error. |
otu-biae | SM Backward Incoming Alignment Error. |
fec-sf | Signal Fail (based on FEC corrected bits). |
fec-sd | Signal Degrade (based on FEC corrected bits). |
fec-fail | FEC Mode mismatch (EFEC-GFEC) or High Uncorrectable rate (>10E-2). |
fec-uncorr | One or More Uncorrectable FEC errors. |
odu-ais | ODU Alarm Indication Signal. |
odu-oci | ODU Open connection Indication. |
odu-lck | ODU Locked. |
odu-bdi | PM Backward Defect indication. |
odu-tim | PM Trace Id Mismatch. |
opu-plm | OPU PSI Payload Type Mismatch. |
This command enables the context to configure transceiver parameters.
This command specifies if a digital coherent optics module is used for this port.
The no form of this command specifies that the optical module used in this port is not a digital coherent optics module.
no digital-coherent-optics
This command enables the context for configuring hybrid port buffer allocation parameters.
This command configures the sharing of the egress buffers allocated to a hybrid port among the access and network contexts. By default, it is split equally between network and access.
The no form of this command reverts to the default values for the egress access and network weights.
This command configures the sharing of the ingress buffers allocated to a hybrid port among the access and network contexts. By default, it is split equally between network and access.
The no form of this command reverts to the default values for the ingress access and network weights.
This command enables the context to configure ingress and egress percentage of rate parameters. This command only applies to physical ports (for example, it will not work on APS or similar logical ports). The percentage of rate commands are used to define a percentage value that affects the amount of buffers used by ingress and egress port managed buffer space. Enter the modify-buffer-allocation-rate context when editing the port’s percentage of rate commands.
The egr-percentage-of-rate command increases or decreases the active bandwidth associated with the egress port that affects the amount of egress buffer space managed by the port. Changing a ports active bandwidth using the egr-percentage-of-rate command is an effective means of artificially lowering the buffers managed by one egress port and giving them to other egress ports on the same MDA.
The egr-percentage-of-rate command accepts a percentage value that increases or decreases the active bandwidth based on the defined percentage. A value of 50% causes the active bandwidth to be reduced by 50%. A value of 150% causes the active bandwidth to be increased by 50%. Values from 1 to 1000 percent are supported.
A value of 100 (the default value) is equivalent to executing the no egr-percentage-of-rate command and restores the egress active rate to the normal value.
The no form of this command removes any artificial increase or decrease of the egress active bandwidth used for egress buffer space allocation to the port. The no egr-percentage-of-rate command sets the egress rate percentage to 100%.
This command increases or decreases the active bandwidth associated with the ingress port that affects the amount of ingress buffer space managed by the port. Changing a port’s active bandwidth using the ing-percentage-of-rate command is an effective means of artificially lowering the buffers managed by one ingress port and giving them to other ingress ports on the same MDA.
The ing-percentage-of-rate command accepts a percentage value that increases or decreases the active bandwidth based on the defined percentage. A value of 50% causes the active bandwidth to be reduced by 50%. A value of 150% causes the active bandwidth to be increased by 50%. Values from 1 to 1000 percent are supported.
A value of 100 (the default value) is equivalent to executing the no ing-percentage-of-rate command and restores the ingress active rate to the normal value.
The no form of this command removes any artificial increase or decrease of the ingress active bandwidth used for ingress buffer space allocation to the port. The no ing-percentage-of-rate command sets the ingress rate percentage to 100%.
This command enables the monitoring of aggregate egress queue statistics on the port. All queues on the port are monitored, including SAP egress, network egress, subscriber egress, and egress queue group queues, as well as system queues that can be used, for example, to send port-related protocol packets (LACP, EFM, and so on). The aggregate in-profile, out-of-profile, and total statistics are provided for both forwarded and dropped packets and octets.
Monitoring of aggregate statistics is supported on PXC sub-ports but not on a PXC physical port. It is also not supported on satellite ports or ports on an HSMDA.
The no form of this command disables aggregate egress queue statistics monitoring on the specified port.
This command applies egress scheduler overrides. When a port scheduler is associated with an egress port, it is possible to override the following parameters:
See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Quality of Service Guide for command syntax and usage for the port-scheduler-policy command.
The no form of this command removes all override parameters from the egress port or channel scheduler context. Once removed, the port scheduler reverts all rate parameters back to the parameters defined on the port-scheduler-policy associated with the port.
This command overrides the maximum and CIR rate parameters for a specific priority level on the port or channel’s port scheduler instance. When the level command is executed for a priority level, the corresponding priority level command in the port-scheduler-policy associated with the port is ignored.
The override level command supports the keyword max for the rate and cir parameter. When executing the level override command, at least the rate or cir keywords and associated parameters must be specified for the command to succeed.
The no form of this command removes the local port priority level rate overrides. Once removed, the port priority level will use the port scheduler policies level command for that priority level.
This command overrides the max-rate parameter found in the port-scheduler-policy associated with the port. When a max-rate is defined at the port or channel level, the port scheduler policies max-rate parameter is ignored.
The egress-scheduler-override max-rate command supports a parameter that allows the override command to restore the default of not having a rate limit on the port scheduler. This is helpful when the port scheduler policy has an explicit maximum rate defined and it is desirable to remove this limit at the port instance.
The no form of this command removes the maximum rate override from the egress port or channels port scheduler context. Once removed, the max-rate parameter from the port scheduler policy associated with the port or channel will be used by the local scheduler context.
This command enables the provisioning of an existing port-scheduler-policy to a port or channel.
The egress-scheduler-override node allows for the definition of the scheduler overrides for a specific port or channel.
When a port scheduler is active on a port or channel, all queues and intermediate service schedulers on the port are subject to receiving bandwidth from the scheduler. Any policers, queues, or schedulers with port-parent associations are mapped to the appropriate port priority levels based on the port-parent command parameters. Any policers, queues, or schedulers that do not have a port-parent or valid intermediate scheduler parent defined are treated as orphaned and are handled based on the port scheduler policies default or explicit orphan behavior.
The port scheduler maximum rate and priority level rate parameters may be overridden to allow unique values separate from the port-scheduler-policy-name attached to the port or channel. Use the egress-scheduler-override command to specify the port or channel specific scheduling parameters.
The command used to associate an egress scheduler policy on the port is also used for the HSMDA. HSMDA policies should be associated with HSMDA ports.
The no form of this command removes a port scheduler policy from an egress port or channel. Once the scheduler policy is removed, all orphaned policers, queues, and schedulers revert to a free running state governed only by the local queue or scheduler parameters. This includes any queues or schedulers with a port-parent association.
This command configures Ethernet Local Management Interface (E-LMI) parameters for the Ethernet port. E-LMI is only supported on Ethernet access ports with Dot1q encapsulation type.
This command configures the Ethernet LMI mode.
This command configures the monitored count of consecutive errors.
This command configures the polling timer for UNI-C.
This command configures the polling verification timer for UNI-N.
This command configures an Ethernet port, TDM channel, or SONET/SDH path (sub-port) for access, network or hybrid mode operation.
An access port or channel is used for customer facing traffic on which services are configured. A Service Access Point (SAP) can only be configured on an access port or channel. When a port is configured for access mode, the appropriate encap-type must be specified to distinguish the services on the port or SONET path. Once an Ethernet port, a TDM channel or a SONET path has been configured for access mode, multiple services can be configured on the Ethernet port, a TDM channel or SONET path. Note that ATM, Frame Relay, and cHDLC port parameters can only be configured in the access mode.
A network port or channel participates in the service provider transport or infrastructure network when a network mode is selected. When the network option is configured, the encap-type cannot be configured for the port/channel.
When network mode is selected on a SONET/SDH path, the appropriate control protocols are activated when the need arises. For example, configuring an IP interface on the SONET path activates IPCP while the removal of the IP interface causes the IPCP to be removed. The same applies for MPLS, MPLSCP, and OSICP. When configuring a SONET/SDH port, the mode command must be entered in the channel context or an error message is generated.
A hybrid Ethernet port allows the combination of network and access modes of operation on a per-VLAN basis and must be configured as either dot1q or QinQ encapsulation.
When the hybrid port is configured to the dot1q encapsulation, the user configures a SAP inside a service simply by providing the SAP ID which must include the port-id value of the hybrid mode port and an unused VLAN tag value. The format is <port-id>:qtag1. A SAP of format <port-id>:* also supported.
The user configures a network IP interface under config>router>if>port by providing the port name which consists of the port-id of the hybrid mode port and an unused VLAN tag value. The format is <port-id>:qtag1. The user must explicitly enter a valid value for qtag1. The <port-id>:* value is not supported on a network IP interface. The 4096 VLAN tag space on the port is shared among VLAN SAPs and VLAN network IP interfaces.
When the hybrid port is configured to QinQ encapsulation, the user configures a SAP inside a service simply by providing the SAP ID which must include the port-id value of the hybrid mode port and the outer and inner VLAN tag values. The format is <port-id>:qtag1.qtag2. A SAP of format <port-id>: qtag1.* is also supported. The outer VLAN tag value must not have been used to create an IP network interface on this port. In addition, the qtag1.qtag2 value combination must not have been used by another SAP on this port.
The user configures a network IP interface under config>router>if>port by providing the port name which consists of the port-id of the hybrid mode port and a VLAN tag value. The format is <port-id>:qtag1.*. An outer VLAN tag qtag2 of * creates an IP network interface. In addition, the qtag1.qtag2 value combination must not have been used on another SAP or IP network interface on this port.
The no form of this command restores the default.
mode network — Configures the Ethernet port, TDM channel or SONET path for transport network use.
mode access — Default channel/port mode for channelized, ASAP, and ATM MDAs.
This command, supported on access LAG only, specifies the operational group to monitor. The state of the operational group affects the state of this LAG. When the operational group is inactive, the state of the LAG goes down and the LAG uses the configured lag>standby-signaling mechanism (lacp or power-off) to signal the CE that the LAG is not available.
no monitor-oper-group
This command assigns a specific MAC address to an Ethernet port, Link Aggregation Group (LAG), Ethernet tunnel, or BCP-enabled port or sub-port.
Only one MAC address can be assigned to a port. When multiple mac commands are entered, the last command overwrites the previous command. When the command is issued while the port is operational, IP will issue an ARP, if appropriate, and BPDUs are sent with the new MAC address.
The no form of this command returns the MAC address to the default value.
A default MAC address is assigned by the system from the chassis MAC address pool.
This command configures the maximum payload MTU size for an Ethernet port, PPP-enabled port or sub-port and Frame Relay-enabled port or subport. The Ethernet port level MTU parameter indirectly defines the largest physical packet the port can transmit or the far-end Ethernet port can receive. Packets that cannot be fragmented at egress and exceed the MTU are discarded.
The value specified for the MTU includes the destination MAC address, source MAC address, the Ethertype or Length field and the complete Ethernet payload. The MTU value does not include the preamble, start of frame delimiter or the trailing CRC.
PoS channels use the MTU to define the largest PPP payload a PoS frame may contain. A significant difference between SONET/SDH PoS channel and Ethernet physical MTU values the overhead considered part of the framing method and the overhead considered to be part of the application using the frame. In Ethernet, the preamble, start of frame delimiter and the CRC are considered part of the framing overhead and not part of the frame payload. For a PoS channel, the HDLC framing overhead is not included in the physical MTU; only the PPP and PPP payload are included. If the port mode or encapsulation type is changed, the MTU assumes the default values of the new mode or encapsulation type.
The no form of this command restores the default values.
The default MTU value depends on the (sub-)port type, mode and encapsulation and are listed in Table 47:
Type | Mode | Encap Type | Default (Bytes) |
10/100, Gig, or 10GigE | Access | null | 1514 |
10/100, Gig, or 10GigE | Access | dot1q | 1518 |
10/100, Gig, or 10GigE | Access | q-in-q | 1522 |
SONET/SDH or TDM | Access | mpls | 1506 |
SONET/SDH or TDM | Access | bcp-null | 1518 |
SONET/SDH or TDM | Access | bcp-dot1q | 1522 |
SONET/SDH or TDM | Access | ipcp | 1502 |
SONET/SDH or TDM | Access | frame-relay | 1578 |
ATM, SONET/SDH or TDM | Access | atm | 1524 |
10/100 or 100FX Ethernet | Network | null | 1514 |
10/100 or 100FX Ethernet | Network | dot1q | 1518 |
SONET/SDH | Network | ppp-auto | 1524 |
512 to 9212 | config>port>ethernet |
512 to 9800 | config>port>ethernet (for FP4-based connector ports) |
512 to 9208 | config>port>sonet-sdh>path |
512 to 9208 | config>port>tdm>ds1>channel-group |
512 to 9208 | config>port>tdm>ds3 |
512 to 9208 | config>port>tdm>e1>channel-group |
512 to 9208 | config>port>tdm>e3 |
This command enables the context to configure network channel group parameters.
This command specifies an existing network policy to apply to the channel group.
This command specifies the network-queue policy which defines queue parameters such as CBS, high priority only burst size, MBS, CIR and PIR rates, as well as forwarding-class to queue mappings. The network-queue policy is defined in the config>qos>network-queue context.
queue-policy default
This command enables access to the context to configure the LCP operational parameters for a SONET/SDH PoS link, a DS--3/E-3 port or channel, a DS-1/E-1 channel or a DS-0 channel.
This command enables and disables Protocol Field Compression (PFC) per RFC 1661, The Point-to-Point Protocol (PPP), Section 6.5 and Address and Control Field Compression (ACFC) as per Section 6.6.
This command is only supported on DS-1 and E-1 channel groups on ASAP MDAs.
The no form of this command disables the header compression.
no compress
This command enables the port down on BER-SF alarm. When enabled, the link will be placed out of service once ber-sf is detected.
The no form of this command reverts to normal operation where the link remains in-service when ber-sf is encountered.
no ber-sf-link-down
This command enables logging of DS-3 and E-3 alarms for a DS-3/E-3 port or channel.
The no form of this command disables logging of the specified alarms.
This command enables payload scrambling on channel groups.
Scrambling randomizes the pattern of 1s and 0s carried in a SONET frame. Rearranging or scrambling the pattern prevents continuous strings of all 1s or all 0s and meets the needs of physical layer protocols that rely on sufficient transitions between 1s and 0s to maintain clocking.
For ATM, this command enables or disables ATM cell-level payload scrambling/descrambling using x43+1 polynomial as defined in ITU-T I.432.1. Scrambling is enabled by default for the ATM path/channel. Note that this scrambling is done in addition to SONET/SDH frame scrambling/descrambling, which is always enabled in the framer.
The no form of this command disables scrambling.
no scramble
This command sets the keepalive interval.
The no form of this command returns the interval to the default value.
keepalive 10
The port XC commands are supported on the 7450 ESS only.
This command enables the context to configure port-cross connect functionality.
This command creates a port cross-connect (PXC) object. Referencing an Ethernet port within the PXC object will automatically configure this Ethernet port as a loopback port. The node will automatically create two PXC sub-ports under this Ethernet port. The configuration of PXC sub-ports can be accessed through the CLI.
This command configures the referenced Ethernet port as a loopback or a cross-connect port (PXC). Once this command is executed, the system automatically creates two PXC sub-ports under this Ethernet port. The two PXC sub-ports are logical configurations used by the node to transmit traffic bi-directionally through a single physical port that is internally cross-connected.
The physical PXC port does not require any external connectivity or optical transceivers to function properly. Consequently, all optic-related alarms are disabled on the port.
The physical PXC port is automatically configured as a hybrid port. The MTU is preset to 9212 bytes, The encapsulation type is set to dot1q and dot1x tunneling is turned on.
Since the PXC is using a single physical port to transmit traffic in both directions, the nominal port bandwidth is asymmetrically divided between the two directions. For example, a 10Gb/s Ethernet port in PXC mode can accommodate nine Gb/s of traffic in one direction and one Gb/s in the other. Any other ratio can be achieved as long as the sum of the bandwidth of the two PXC sub-ports does not exceed the bandwidth capacity of the physical port (10 Gb/s in this case).
The following apply to PXC ports:
This command enables access to PXC sub-port level parameters. The PXC sub-ports are automatically created once the external Ethernet port is configured inside of an PXC object. The PXC sub-ports are by default administratively disabled (shutdown). In order for PXC sub-ports to became operational, both, the underlying external Ethernet port and the PXC object must be operationally up.
This command provides context for configuring Forwarding Path Extensions (FPE). FPE is utilized by certain applications that rely on PXC functionality. Its purpose is to simplify configuration of such applications.
This command configures an FPE object which associates the application with a PXC (paired set of PXC sub-ports or a paired set of PXC based LAGs).
The no form of this command disables the FPE object association.
This command references a PXC (pair of PXC sub-ports) and consequently create an association between the PXC and the application which is referenced under the same FPE object. Each application will utilize the PXC in the form of an internal cross-connect. The exact use and internal provisioning of this cross-connect depends on the application itself.
The no form of this command removes the reference and association from the configuration.
no path
This command informs the system about the type of the cross-connect that is required in order to terminate an external tunnel to an anchored PW port. The system automatically builds the internal infrastructure required to perform the tunnel termination on a PW port.
PW ports support the following types of tunnels:
The no form of this command removes the cross-connect type from the configuration.
no pw-port
This command configures FPE for subscriber management extensions. The FPE cannot be used for other applications but can be used for multiple subscriber management applications.
The no version of this command disables FPE for subscriber management extensions.
no sub-mgmt-extensions
This command informs the system about the cross-connect type that is required for non-system IPv4 and IPv6 VXLAN termination. Internally, it triggers the automatic creation of two internal IP interfaces in the PXC ports and enables those internal interfaces to process and terminate VXLAN.
If no parameters are used, the VXLAN termination occurs in the base router; however, when the FPE is used for static VXLAN termination (no BGP-EVPN services), non-system IPv4 and IPv6 VXLAN can be terminated in a VPRN service. In this case, the VPRN router instance or service name must be configured with the vxlan-termination command.
The no form of this command disables the cross-connect type from the configuration.
no vxlan-termination
router-name: router-name or vprn-svc-id | ||
router-name | “Base” | |
vprn-svc-id | 1 to 2147483647 |
This command reserves an SDP ID range used by the FPE based PW-Port and VXLAN termination applications.
Each configured FPE based PW-Port is associated with two internal SDPs (one in each direction) whose id(s) are allocated from the configured sdp-id-range.
When the FPE is associated to VXLAN termination, an internal SDP is allocated from the configured sdp-id-range and is used for R-VPLS services that terminate VXLAN IPv6. A spoke-sdp per VXLAN IPv6 R-VPLS service is created on that SDP for egress processing of the packets. Sdp-id-range cannot be modified if any of its IDs are currently in use.
no sdp-id-range
This command configures APS (Automatic Protection Switching). APS is used by SONET/SDH add/drop multiplexers (ADMs) or other SONET/SDH-capable equipment to protect against circuit or equipment failure.
An APS group contains a working and a protect circuit and can span a single node (SC-APS) or two nodes (MC-APS).
The working and protection configurations on the 7750 SRs must match the circuit configurations on the peer. This means that the working circuit on the 7750 SR must be connected to the peer’s working circuit and the protect circuit must be connected to the peer’s protection circuit.
The aps command is only available for APS groups and not physical ports.
This command specifies the time interval, in 100s of milliseconds, between 'I am operational' messages sent by both protect and working circuits to their neighbor for multi-chassis APS.
The advertise-interval value is valid only for a multi-chassis APS as indicated by the value of the neighbor command value if it is not set to 0.0.0.0.
10
This command specifies how much time can pass, in 100s of milliseconds, without receiving an advertise packet from the neighbor before the multi-chassis signaling link is considered not operational.
The hold-time is usually 3 times the value of the advertise-interval. The value of the advertise-interval is valid only for a multi-chassis APS as indicated by the value of neighbor IP address if it is not set to 0.0.0.0.
This command configures hold-down timers to debounce signal failure conditions (lais, b2err-sf) and signal degrade conditions (b2err-sd) for Uni 1+1 Sig+Data APS switching mode (switching mode uni-1plus1).
The no version of this command resets the hold-down timer to the default value.
0 (disabled)
This command configures the APS group for 1+1 Optimized operation as described in Annex B of ITU.T G.841. Note that Annex B operates in non-revertive bi-directional switching mode only as defined in G.841.
This command specifies the neighbor's IP address only on a multi-chassis APS where the working and protect circuits are configured on different routers. When the value the neighbor IP address is set to 0.0.0.0, this implies that the APS group is configured as a single-chassis APS group.
The route to the neighbor must not traverse the multi-chassis APS member (working or protect) circuits. It is recommended that the neighbor IP address configured is on a shared network between the routers that own the working and protect circuits.
By default no neighbor address is configured and both the working and protect circuits should be configured on the same router (i.e., single-chassis APS). APS is assumed to be configured wholly on a single chassis.
ipv4-address: | a.b.c.d |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x:-[0 to FFFF]H | |
d: [0 to 255]D |
This command configures a physical port that will act as the protection circuit for this APS group. The protect circuit port must contain only the default configuration and cannot belong to another APS group. The protect circuit port must be of the same type as the working circuit for the APS group, for the port to be added to an APS group port. If that’s not the case, the command will return an error.
A protection circuit can only be added if the working circuit already exists; the protection circuit must be removed from the configuration before the working circuit is removed.
When a port is a protect-circuit of an APS group, the configuration options available in the config>port port-id>sonet-sdh context is not allowed for that port unless it is part of the noted exceptions. The exception list includes these SONET/SDH commands:
When is port configured as a protection circuit of an APS group, the configurations described above and all service configurations related to APS port are operationally inherited by the protect circuit. If the protect circuit cannot inherit the configurations (due to resource limitations), the configuration attempt fails and an error is returned to the user.
The protect circuit must be shutdown before it can be removed from the APS group port. The inherited configuration for the circuit and APS operational commands for that circuit are not preserved when the circuit is removed from the APS group.
The no form of this command removes the protect-circuit.
port-id | slot/mda/port | ||
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 |
Also see Modifying Hold-Down Timer Values for information about modifying the timer defaults in the event of communication delays between the APS controllers.
This command configures how RDI alarms (line, path, section) are generated on physical circuits of an APS ports. The command configuration changes are supported only for switching-mode set to uni_1plus1. The configuration can be changed only when no working and protecting circuit has been added. Options:
rdi-alarms circuit
This command configures the revert-time timer to determine how long to wait before switching back to the working circuit after that circuit has been restored into service.
A change in the minutes value takes effect upon the next initiation of the wait to restore (WTR) timer. It does not modify the length of a WTR timer that has already been started. The WTR timer of a non-revertive switch can be assumed to be infinite.
The no form of this command restores the default (non-revertive mode).
The default is to not revert back unless the protect circuit fails or there is an operator intervention.
This command configures the switching mode for the APS group.
This command configures a physical port that will act as the working circuit for this APS group. The working circuit port must contain only the default configuration and cannot be part of another APS group. The working circuit must be created before the protection circuit.
When a port is a working circuit of an APS group, the configuration available under config>port port-id context (including submenus) is not allowed for that port unless it is a part of the noted exceptions.
When a port is being configured as a working circuit of an APS group, all common configuration as described above and all service configurations related to the APS port is operationally inherited by the working circuit from the aps-group-id. If the working circuit cannot inherit that configuration, for example, due to resource limitations, the configuration attempt fails and an error is returned to the user.
Before a working circuit can be removed from an APS group, the working circuit port must be shutdown. The inherited configuration for the circuit and APS operational commands for that circuit are not preserved when the circuit is removed from the APS group.
Note that all configurations for aps-group-id under the config>port context and its submenus and all configuration for services that use this aps-group-id is preserved as a non-activated configuration since the APS group no longer has any physical circuits assigned.
The no form of this command removes the working-circuit. The working circuit can only be removed from the configuration after the protect circuit has been removed.
port-id | slot/mda/port | ||
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 |
Modifying Hold-Down Timer Values
Note that for APS configurations, the hold-time down and hold-time up default values are 100 ms and 500 ms respectively. But, if there is a large difference in the transmission delay between the APS working (working-circuit) and protect line (protect-circuit), it is highly recommended that you increase the default timer on the working line accordingly with the transmission delay present on the protect line.
The following output shows an example of the timers on POS interfaces.
This command waits to restore for Annex B mode operation. The delay after which the newly active section becomes the primary section after a switch-over from the primary section to the secondary section occurs and the switch request clears normally.
This command enables access to configure Ethernet port attributes.
This context can only be used when configuring Fast Ethernet, gigabit, or 10-Gb Ethernet LAN ports on an appropriate MDA.
This command configures an Ethernet port for access, network, or hybrid mode of operation. It also configures a TDM channel or SONET/SDH path (sub-port) for access or network mode operation.
An access port or channel is used for customer facing traffic on which services are configured. A Service Access Point (SAP) can only be configured on an access port or channel. When a port is configured for access mode, the appropriate encap-type must be specified to distinguish the services on the port or SONET path. Once an Ethernet port, a TDM channel or a SONET path has been configured for access mode, multiple services can be configured on the Ethernet port, a TDM channel or SONET path. Note that ATM, Frame Relay, and cHDLC port parameters can only be configured in the access mode.
A network port or channel participates in the service provider transport or infrastructure network when a network mode is selected. When the network option is configured, the encap-type cannot be configured for the port/channel.
When network mode is selected on a SONET/SDH path, the appropriate control protocols are activated when the need arises. For example, configuring an IP interface on the SONET path activates IPCP while the removal of the IP interface causes the IPCP to be removed. The same applies for MPLS, MPLSCP, and OSICP. When configuring a SONET/SDH port, the mode command must be entered in the channel context or an error message is generated.
A hybrid Ethernet port allows the combination of network and access modes of operation on a per-VLAN basis and must be configured as either dot1q or QinQ encapsulation.
When the hybrid port is configured to the dot1q encapsulation, the user configures a SAP inside a service simply by providing the SAP ID which must include the port-id value of the hybrid mode port and an unused VLAN tag value. The format is <port-id>:qtag1. A SAP of format <port-id>:* also supported.
The user configures a network IP interface under config>router>if>port by providing the port name which consists of the port-id of the hybrid mode port and an unused VLAN tag value. The format is <port-id>:qtag1. The user must explicitly enter a valid value for qtag1. The <port-id>:* value is not supported on a network IP interface. The 4096 VLAN tag space on the port is shared among VLAN SAPs and VLAN network IP interfaces.
When the hybrid port is configured to QinQ encapsulation, the user configures a SAP inside a service simply by providing the SAP ID which must include the port-id value of the hybrid mode port and the outer and inner VLAN tag values. The format is <port-id>:qtag1.qtag2. A SAP of format <port-id>: qtag1.* is also supported. The outer VLAN tag value must not have been used to create an IP network interface on this port. In addition, the qtag1.qtag2 value combination must not have been used by another SAP on this port.
The user configures a network IP interface under config>router>if>port by providing the port name which consists of the port-id of the hybrid mode port and a VLAN tag value. The format is <port-id>:qtag1.*. An outer VLAN tag qtag2 of * creates an IP network interface. In addition, the qtag1.qtag2 value combination must not have been used on another SAP or IP network interface on this port.
The no form of this command restores the default.
mode network — For Ethernet ports.
mode access — For TDM channel or SONET paths.
This command configures Ethernet access port parameters.
This command configures Ethernet access egress port parameters.
This command creates an ingress or egress queue group on an Ethernet port. A queue group is a collection of queues identified by a group name. Queue groups created on access ports are used as an alternative queue destination for SAPs.
Within a SAP, a forwarding class may be redirected from the local SAP queue to a port queue group queue. The forwarding classes from multiple SAPs may be redirected to the same queue group which can be used to minimize the number of per-SAP queues.
Queue groups may be created on both access and network oriented ports. When the port is in access mode, the queue groups must be created within the port access node.
Within the access node, queue groups are also configured as ingress or egress. Access ingress queue groups can only be used by ingress SAP forwarding classes and only a single ingress queue group per port is supported. Multiple access egress queue groups may be created on a single port and are used by egress SAP forwarding classes. The instance-id parameter identifies different instances of the same queue group template. Creating multiple queue groups with a different instance ID but the same queue group name results in separate queue groups being created on the port. The instance-id parameter is only valid for egress queue groups on access ports.
When the queue group is created in an ingress port context, the group-name must be an existing ingress queue group template. Similarly, queue groups created in an egress port context must have a group-name of an existing egress queue group template. Two ingress queue groups with the same name cannot be created on the same port. Two egress queue groups can only be created on the same port with the same queue group template name if they have different instance-id values.
The queues defined in the template are created on the queue group. The queue parameters within the template are used as the default queue parameters for each queue in the queue group. The default queue parameters for each queue may be overridden on the queue group with specific queue parameters.
Each queue group supports the application of a scheduler-policy for the purpose of managing the queues within the group into an aggregate SLA. The queues defined within the template may be configured with parent scheduler defining the mapping of a queue to one of the schedulers within the scheduler policy. Egress queue groups also support the agg-rate parameter and the queues in the egress template support the port-parent command. Each command is used for configuring egress port virtual scheduling behavior.
Each queue group allows the application of an accounting policy and the ability to enable and disable collecting statistics. The statistics are derived from the queue counters on each queue within the queue group. The accounting policy defines which queue counters are collected and to which accounting file they will be written.
A queue group does not have an administrative shutdown or no shutdown command. A queue group is considered to be always on once created.
When creating a queue group, the system will attempt to allocate queue resources based on the queues defined in the queue group template. If the appropriate queue resources do not currently exist, the queue group will not be created. Ingress port queue groups do not support the shared-queuing or multipoint-shared queuing behavior.
When the queue group is created on a LAG (Link Aggregation Group), it must be created on the primary port member. The primary port member is the port with the lowest port ID based on the slot, MDA position and port number on the MDA. A queue group created on the primary LAG port will be automatically created on all other port members. If a new port is being added to a LAG with an existing queue group, the queue group must first be created on the port prior to adding the port to the LAG. If the LAG queue group has queue overrides, the queue overrides must also be defined on the port queue group prior to adding the port to the LAG.
A port queue group cannot be removed from the port when a forwarding class is currently redirected to the group. All forwarding class redirections must first be removed prior to removing the queue group.
This command configures Ethernet egress port parameters.
This command configures Ethernet access ingress port parameters.
This command creates an ingress or egress queue group on an Ethernet port. A queue group is a collection of queues identified by a group name. Queue groups created on access ports are used as an alternative queue destination for SAPs.
Within a SAP, a forwarding class may be redirected from the local SAP queue to a port queue group queue. The forwarding classes from multiple SAPs may be redirected to the same queue group which can be used to minimize the number of per-SAP queues.
Queue groups may be created on both access and network oriented ports. When the port is in access mode, the queue groups must be created within the port access node.
Within the access node, queue groups are also configured as ingress or egress. Access ingress queue groups can only be used by ingress SAP forwarding classes and only a single ingress queue group per port is supported. Multiple access egress queue groups may be created on a single port and are used by egress SAP forwarding classes. The instance-id parameter identifies different instances of the same queue group template. Creating multiple queue groups with a different instance ID but the same queue group name results in separate queue groups being created on the port. The instance-id parameter is only valid for egress queue groups on access ports.
When the queue group is created in an ingress port context, the group-name must be an existing ingress queue group template. Similarly, queue groups created in an egress port context must have a group-name of an existing egress queue group template. Two ingress queue groups with the same name cannot be created on the same port. Two egress queue groups can only be created on the same port with the same queue group template name if they have different instance-id values.
The queues defined in the template are created on the queue group. The queue parameters within the template are used as the default queue parameters for each queue in the queue group. The default queue parameters for each queue may be overridden on the queue group with specific queue parameters.
Each queue group supports the application of a scheduler-policy for the purpose of managing the queues within the group into an aggregate SLA. The queues defined within the template may be configured with parent scheduler defining the mapping of a queue to one of the schedulers within the scheduler policy. Egress queue groups also support the agg-rate parameter and the queues in the egress template support the port-parent command. Each command is used for configuring egress port virtual scheduling behavior.
Each queue group allows the application of an accounting policy and the ability to enable and disable collecting statistics. The statistics are derived from the queue counters on each queue within the queue group. The accounting policy defines which queue counters are collected and to which accounting file they will be written.
A queue group does not have an administrative shutdown or no shutdown command. A queue group is considered to be always on once created.
When creating a queue group, the system will attempt to allocate queue resources based on the queues defined in the queue group template. If the appropriate queue resources do not currently exist, the queue group will not be created. Ingress port queue groups do not support the shared-queuing or multipoint-shared queuing behavior.
When the queue group is created on a LAG (Link Aggregation Group), it must be created on the primary port member. The primary port member is the port with the lowest port ID based on the slot, MDA position and port number on the MDA. A queue group created on the primary LAG port will be automatically created on all other port members. If a new port is being added to a LAG with an existing queue group, the queue group must first be created on the port prior to adding the port to the LAG. If the LAG queue group has queue overrides, the queue overrides must also be defined on the port queue group prior to adding the port to the LAG.
A port queue group cannot be removed from the port when a forwarding class is currently redirected to the group. All forwarding class redirections must first be removed prior to removing the queue group.
This command controls an H-QoS aggregate rate limit. It is used in conjunction with the following parameter commands: rate, limit-unused-bandwidth, and queue-frame-based-accounting.
When specified under a Vport, the agg-rate rate, port-scheduler-policy and scheduler-policy commands are mutually exclusive. Changing between the use of a scheduler policy and the use of an agg-rate/port-scheduler-policy involves removing the existing command and applying the new command.
This command enables aggregate rate overrun protection on the agg-rate context.
The no form of this command disables aggregate rate overrun protection on the agg-rate context.
This command enables frame based accounting on all policers and queues associated with the agg-rate context. It is only supported on Ethernet ports but not on HSMDA Ethernet ports. Packet byte offset settings are not included in the applied rate when queue frame-based accounting is configured, regardless of how offsets are applied to the statistics.
The no form of this command disables frame based accounting on all policers and queues associated with the agg-rate context.
This command defines the enforced aggregate rate for all queues associated with the agg-rate context. A rate must be specified for the agg-rate context to be considered to be active on the context’s object.
The no form of this command removes an explicit rate value from the aggregate rate returning it to its default value.
This command defines the enforced aggregate rate for all queues associated with the agg-rate context. A rate must be specified for the agg-rate context to be considered to be active on the context’s object.
The no form of this command removes an explicit rate value from the aggregate rate returning it to its default value.
This command configures host matching for the Ethernet port egress queue-group.
The no form of this command removes host matching for the Ethernet port egress queue-group.
This command configures HSMDA egress queue overrides parameters.
This command configures a packet offset for HSMDA queue accounting.
This command configures overrides for an HSMDA egress queue.
This command configures the maximum buffer space override.
This command configures the peak information rate.
This command configures the slope policy.
This command configures the weighted round robin (WRR).
This command configures the HSMDA egress secondary shaper.
This command configures the HSMDA egress wrr-policy.
This command configures the policer control policy for the QoS egress queue-group.
This command enables the context to define optional queue parameter overrides for each queue within the queue group.
This command associates a queue for use in a queue group template. 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 which 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’s 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.
The no form of this command removes the queue-id from the configuration.
This command associates a queue for use in a queue group template. 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 which 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’s 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.
The no form of this command removes the queue-id from the configuration.
This command, when used in the queue-overrides context for a queue group queue, defines an optional weight and cir-weight for the queue treatment by the parent scheduler that further governs the available bandwidth given the queue aside from the queue PIR setting. When multiple schedulers 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 bandwidth.
This command specifies 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.
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case the configuration of the adaptation rule is performed under the hs-wrr-group within the egress queue group template.
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
The queue burst-limit command overrides the 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 no form of this command removes the current burst limit override for the queue. The queue’s burst limit is controlled by its defining template.
no burst-limit
This command defines the default committed buffer size for the template queue. Overall, the CBS command follows the same behavior and provisioning characteristics as the CBS command in the queue-group or network QoS policy. The exception is the addition of the cbs-value qualifier keywords bytes or kilobytes.
The no form of this command restores the default CBS size to the template queue.
cbs default
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 overrides the low queue drop tail as a percentage reduction from the MBS of the queue. For example, if a queue has an MBS of 600 kbytes and this percentage is configured to be 30% for the low drop tail, then the low drop tail will be at 420 kbytes and out-of-profile packets will not be accepted into the queue if its depth is greater than this value, and so will be discarded.
The Maximum Burst Size (MBS) command specifies the default maximum buffer size for the template queue. The value is given in kilobytes.
The MBS value is used by a queue to determine whether it has exhausted all of its buffers while enqueuing packets. Once the queue has exceeded the amount of buffers allowed by MBS, all packets are discarded until packets have been drained from the queue.
The queue-group or network egress QoS context 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 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 packets RED slope will not force the discard of the packet. Setting proper CBS parameters and controlling CBS oversubscription is one major safeguard to 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.
This command applies to egress queue group queues as the queue-delay is only supported on egress queues. This command the queue-delay command are mutually exclusive.
The no form of this command returns the MBS size assigned to the queue to the value.
mbs default
This command enables queue depth monitoring for the specified queue. This command and the dynamic-mbs command are mutually exclusive on the related queue group queue.
The no form of this command removes queue depth monitoring for the specified queue.
This command specifies percent rates (CIR and PIR).
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the percent-rate is performed under the hs-wrr-group within the egress queue group template.
This command specifies 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 out an egress interface (for SAP egress queues). Defining a PIR does not necessarily guarantee that the queue can transmit at the intended rate. The actual rate sustained by the queue can be limited by oversubscription factors or available egress bandwidth.
The CIR defines the rate at which the system prioritizes the queue over other queues 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’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.
This command is ignored for egress HSQ queue group queues which are attached to an HS WRR group within an associated HS attachment policy. In this case, the configuration of the rate is performed under the hs-wrr-group within the egress queue group template.
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).
rate max cir 0 - The max default specifies the amount of bandwidth in kilobits per second (thousand bits per second). The max value is mutually exclusive to the pir-rate value.
The actual PIR rate is dependent on the queue’s adaptation-rule parameters and the actual hardware where the queue is provisioned.
This command specifies the set of attributes whose values have been overridden by management on this virtual scheduler. Clearing a given flag will return the corresponding overridden attribute to the value defined on the ingress or egress queue group template.
The no form of this command removes all of the scheduler overrides and returns the scheduler’s parent weight and CIR weight, and its PIR and CIR to the values configured in the applied scheduler policy.
This command can be used to override specific attributes of the specified scheduler name. A scheduler defines bandwidth controls that limit each child (other schedulers and queues) associated with the scheduler. Scheduler objects are created within the hierarchical tiers of the policy. It is assumed that each scheduler created will have queues or other schedulers defined as child associations. The scheduler can be a child which takes bandwidth from a scheduler in a higher tier. A total of 32 schedulers can be created within a single scheduler policy with no restriction on the distribution between the tiers. The scheduler-name must exist in the applied scheduler policy.
The no form of this command removes the scheduler overrides for the specified scheduler and returns the scheduler’s parent weight and CIR weight, and its PIR and CIR to the values configured in the applied scheduler policy.
This command can be used to override the scheduler's parent weight and CIR weight. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the applied scheduler policy.
The override weights are ignored if the scheduler does not have a parent command configured in the scheduler policy - this allows the parent of the scheduler to be removed from the scheduler policy without having to remove all of the queue group overrides. If the parent scheduler does not exist, causing the configured scheduler to be fostered on an egress port scheduler, the override weights will be ignored and the default values used; this avoids having non-default weightings for fostered schedulers.
The no form of this command returns the scheduler's parent weight and cir-weight to the value configured in the applied scheduler policy.
no parent
A 0 (zero) weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict level.
A 0 (zero) cir-weight value signifies that the child scheduler will receive bandwidth only after bandwidth is distributed to all other non-zero weighted children in the strict cir-level.
This command can be used to override specific attributes of the specified scheduler rate. The rate command defines the maximum bandwidth that the scheduler can offer its child queues or schedulers. The maximum rate is limited to the amount of bandwidth the scheduler can receive from its parent scheduler. If the scheduler has no parent, the maximum rate is assumed to be the amount available to the scheduler. When a parent is associated with the scheduler, the CIR parameter provides the amount of bandwidth to be considered during the parent scheduler's 'within CIR' distribution phase.
The actual operating rate of the scheduler is limited by bandwidth constraints other than its maximum rate. The scheduler's parent scheduler may not have the available bandwidth to meet the scheduler's needs or the bandwidth available to the parent scheduler could be allocated to other child schedulers or child queues on the parent based on higher priority. The children of the scheduler may not need the maximum rate available to the scheduler due to insufficient offered load or limits to their own maximum rates.
When a scheduler is defined without specifying a rate, the default rate is max. If the scheduler is a root scheduler (no parent defined), the default maximum rate must be changed to an explicit value. Without this explicit value, the scheduler will assume that an infinite amount of bandwidth is available and allow all child policers, queues, and schedulers to operate at their maximum rates.
The no form of this command returns the scheduler's PIR and CIR parameters to the value configured in the applied scheduler policy.
This command configures a scheduler policy for the egress queue group.
This command configures the Ethernet egress expanded secondary shaper on this port.
This command specifies the aggregate burst limits.
This command specifies a high burst increase.
This command specifies a low burst limit.
This command assigns the low burst maximum class to associate with the Ethernet egress expanded secondary shaper.
The no form of this command returns the class id for the Ethernet egress expanded secondary shaper to the default value.
This command specifies the class to associate with the Ethernet egress expanded secondary shaper.
The no form of this command returns the class number value for the Ethernet egress expanded secondary shaper to the default value.
This command configures the shaper’s metering and optional profiling rates. The metering rate is used by the system to configure the shaper’s PIR leaky bucket’s decrement rate. The decrement function empties the bucket while packets applied to the bucket attempt to fill it based on its packet size. If the bucket fills faster than how much is decremented per packet, the bucket’s depth eventually reaches its violate (PIR) threshold.
The no form of this command restores the default metering and profiling rate to a policer.
This command configures a scheduling node, referred to as virtual port, within the context of an egress Ethernet port. The Vport scheduler operates either like a port scheduler with the difference that multiple Vport objects can be configured on the egress context of an Ethernet port, or it can be an aggregate rate when an egress port-scheduler policy is applied to the port.
The Vport is always configured at the port level even when a port is a member of a LAG.
When a port scheduler policy is applied to a Vport the following command is used:
The CLI will not allow the user to apply a port scheduler policy to a Vport if one has been applied to the port. Conversely, the CLI will not allow the user to apply a port scheduler policy to the egress of an Ethernet port if one has been applied to any Vport defined on the access egress context of this port. The agg-rate, along with an egress port-scheduler, can be used to ensure that a given Vport does not oversubscribe the port’s rate.
SAP and subscriber host queues can be port-parented to a Vport scheduler in a similar way they port-parent to a port scheduler or can be port-parented directly to the egress port-scheduler if the agg-rate is used.
This command configures an aggregate rate for the Vport. The agg-rate rate, port-scheduler-policy and scheduler-policy commands are mutually exclusive. Changing between the use of a scheduler policy and the use of an agg-rate or port-scheduler-policy involves removing the existing command and applying the new command.
This command applies HQoS Adjustment to a Vport. HQoS Adjustment refers to the dynamic adjustment of the rate limit at an QoS enforcement point within a Nokia router when the multicast traffic stream is disjointed from the unicast traffic stream. This QoS enforcement point within the router represents the physical point further down in the access part of the network where the two streams join each other and potentially can cause congestion.
An example would be a PON port which is shared amongst subscriber’s multicast traffic (single copy of each channel) and subscriber’s unicast traffic. The bandwidth control point for this PON port resides in the upstream Nokia BNG node in the form of a Vport. In the case where the multicast delivery method of the BNG utilizes redirection, the multicast traffic in the BNG will flow outside of the subscriber or the Vport context and thus will bypass any bandwidth enforcement in the Nokia router. To correct this, a Vport bandwidth adjustment is necessary in the router that will account for the multicast bandwidth consumption that is bypassing Vport in the router but is present in the PON port whose bandwidth is controlled by Vport.
An estimate of the multicast bandwidth consumption on the PON port can be made at the Vport level based on the IGMP messages sourced from the subscribers behind the PON port. This process is called HQoS Adjustment.
A multicast channel bandwidth is subtracted from or added to the Vport rate limit according to the received IGMP Join/Leave messages and the channel bandwidth definition policy associated with the Vport (indirectly through a group-interface). Since the multicast traffic on the PON port is shared amongst subscribers behind this PON port, only the first IGMP Join or the last IGMP Leave per multicast channel is tracked for the purpose of the Vport bandwidth modification.
The Vport rate that will be affected by this functionality depends on the configuration:
The channel bandwidth definition policy is defined in the mcac policy in the config>router>mcac>policy context. The policy is applied under the group-interface or in case of redirection under the redirected-interface.
The rates in effect can be displayed with the following two commands:
The configuration of a scheduler policy under a Vport, which is only applicable to Ethernet interfaces, is mutually exclusive with the configuration of the egress-rate-modify parameter.
Context: HQoS Adjustment for Vport is disabled.
This command specifies the destination and organization strings to be used for matching subscriber hosts with this Vport.
The parent Vport of a subscriber host queue, which has the port-parent option enabled, is determined by matching the destination string dest string associated with the subscriber and the organization string org string associated with the subscriber host with the strings defined under a Vport on the port associated with the subscriber.
If a given subscriber host queue does not have the port-parent option enabled, it will be foster-parented to the Vport used by this subscriber and which is based on matching the dest string and org string. If the subscriber could not be matched with a Vport on the egress port, the host queue will not be bandwidth controlled and will compete for bandwidth directly based on its own PIR and CIR parameters.
By default, a subscriber host queue with the port-parent option enabled is scheduled within the context of the port’s port scheduler policy.
This command enables congestion monitoring on an Egress Port Scheduler (EPS) that is applied to a physical port or to a Vport.
Congestion monitoring must be further configured under the port-scheduler CLI hierarchy. Once the congestion monitoring is in effect, the offered rate (incoming traffic) is compared to the configured port-scheduler congestion threshold. The results of these measurements are stored as the number of samples representing the number of times the offered rates exceeded the configured congestion threshold since the last clearing of the stats. Therefore, the results represent the number of times that the port-scheduler that is applied to a port/Vport was congested since the last reset of the stats (via a clear command).
The no form of this command disables congestion monitoring.
no mon-port-sch
This command specifies the destination and organization strings to be used for matching subscriber hosts with this Vport.
The parent Vport of a subscriber host queue, which has the port-parent option enabled, is determined by matching the destination string dest string associated with the subscriber and the organization string org string associated with the subscriber host with the strings defined under a Vport on the port associated with the subscriber.
If a given subscriber host queue does not have the port-parent option enabled, it will be foster-parented to the Vport used by this subscriber and which is based on matching the dest string and org string. If the subscriber could not be matched with a Vport on the egress port, the host queue will not be bandwidth controlled and will compete for bandwidth directly based on its own PIR and CIR parameters.
By default, a subscriber host queue with the port-parent option enabled is scheduled within the context of the port’s port scheduler policy.
The no form of this command removes the port-scheduler-policy-name from the configuration. The agg-rate rate, port-scheduler-policy and scheduler-policy commands are mutually exclusive. Changing between the use of a scheduler policy and the use of an agg-rate/port-scheduler-policy involves removing the existing command and applying the new command.
This command configures a scheduler policy for the egress virtual port.
This command enables speed and duplex autonegotiation on Fast Ethernet ports and enables far-end fault indicator support on Gb ports.
There are three possible settings for autonegotiation:
When autonegotiation is enabled on a port, the link attempts to automatically negotiate the link speed and duplex parameters. If autonegotiation is enabled, the configured duplex and speed parameters are ignored.
When autonegotiation is disabled on a port, the port does not attempt to autonegotiate and will only operate at the speed and duplex settings configured for the port. Note that disabling autonegotiation on Gb ports is not allowed as the IEEE 802.3 specification for Gb Ethernet requires autonegotiation be enabled for far end fault indication.
If the autonegotiate limited keyword option is specified the port will auto-negotiate but will only advertise a specific speed and duplex. The speed and duplex advertised are the speed and duplex settings configured for the port. One use for limited mode is for multi-speed Gb ports to force Gb operation while keeping autonegotiation enabled for compliance with IEEE 802.3.
Router requires that autonegotiation be disabled or limited for ports in a Link Aggregation Group to guarantee a specific port speed.
The no form of this command disables autonegotiation on this port.
autonegotiate
This command enters the context to configure exponential port dampening for an Ethernet port.
Exponential Port Dampening (EPD) reduces the number of physical link transitions reported to upper layer protocols, potentially reducing upper layer protocol churn caused by a faulty link. Penalties are added against a port whenever the port’s physical link state transitions from a link-up state to a link-down state. When the penalties exceed a configurable threshold, port-up and -down transitions are no longer advertised to upper layers and the port’s operational state will remain down until the penalty amount drops below a configurable reuse threshold. Each transition of link-up state to link-down state increments the accumulated penalty value by 1000. The accumulated penalties for a port are reduced at an exponential decay rate according to a configurable half-life parameter.
This command configures the half-life decay time and the maximum period of time for which the port-up state can be suppressed.
The half-life and max-time values must be set at the same time and the ratio of max-time/half-life must be less than or equal to 49 and greater than or equal to 1.
maximum penalty = (reuse threshold) × 2 expo:(max-time/half-life)
This command configures the penalties thresholds at which the port state events to the upper layer are to be dampened (suppress threshold) and then permitted (reuse threshold).
This command specifies the Ethertype expected when the port's encapsulation type is dot1q. Dot1q encapsulation is supported only on Ethernet interfaces.
The no form of this command reverts to the default value.
This command configures the duplex of a Fast Ethernet port when autonegotiation is disabled.
This configuration command allows for the configuration of the duplex mode of a Fast Ethernet port. If the port is configured to autonegotiate this parameter is ignored.
duplex full
This command configures EFM-OAM attributes.
This command enables reactions to loopback control OAM PDUs from peers.
The no form of this command disables reactions to loopback control OAM PDUs.
no accept-remote-loopback
This command enables generation of the Information OAM PDU off-cycle when the soft reset notification is received by the EFM application. The local port state remains under the control of the Soft Reset application and does not change based on this EFM function. If the port is operationally up then the local node will continue to consider the port as available for service data and forwarding. If the upstream node requires notification to route around the local node undergoing the soft reset, notification must be sent to those nodes. This is a disruptive function.
This command is disabled by default at the system level and enabled by default at the port level. The combination of the system-level and port-level configuration determines if the dying gasp on soft reset function is active on individual ports. Both the system-level and port-level commands must be enabled in order to support generation of the Information OAM PDU for soft reset. If either is disabled, dying gasp is not active on those ports. This functionality must be enabled prior to the soft reset.
When both grace-tx-enable and dying-gasp-tx-on-reset are active on the same port, grace-tx-enable takes precedence when a soft reset is invoked if the Peer Vendor OUI being received is 00:16:4d (ALU) or the configured grace-vendor-oui value. The grace-tx-enable command should not be configured if the Nokia Vendor Specific Grace TLV is not supported on the remote peer, including Nokia 7750 SR equipment prior to release 11.0 R4.
config>system>ethernet>efm-oam>no dying-gasp-tx-on-reset
config>port>ethernet>efm-oam>dying-gasp-tx-on-reset
This is the top level of the hierarchy containing various discovery parameters that allow the operator to control certain aspects of the negotiation process as well as what action to take when there is a mismatch in peer capabilities.
This is the top level of the hierarchy which allows for the overriding of default advertising of capabilities to a remote peer.
When the link monitoring function is in a no shutdown state, the Link Monitoring capability (EV) is advertised to the peer through the EFM OAM protocol. This may not be desired if the remote peer does not support the Link Monitoring functionality.
The no version of this command suppresses the advertisement of capabilities.
link-monitoring
Enables the sending of grace for all the enabled EFM-OAM sessions on the node. Disabled by default at the system level and enabled by default at the port level. The combination of the system level and port level configuration will determine if the grace function is enabled on the individual ports. Both the system level and the port level must be enabled in order to support grace on a specific port. If either level is disabled, grace is not enabled on those ports. Enabling grace during an active ISSU or soft reset does not invoke the grace function for the active event.
When both grace-tx-enable and dying-gasp-tx-on-reset are active on the same port, grace-tx-enable takes precedence when a soft reset is invoked if the Peer Vendor OUI being received is 00:16:4d (ALU) or the configured grace-vendor-oui value. The grace-tx-enable command should not be configured if the Nokia Vendor Specific Grace TLV is not supported on the remote peer, including Nokia 7750 SR equipment prior to release 11.0 R4.
The no form of this command disables the sending of the Nokia Vendor Specific Grace TLV.
config>system>ethernet>efm-oam>no grace-tx-enable
config>port>ethernet>efm-oam>grace-tx-enable
This optional command configures an additional peer vendor OUI which indicates support for the Vendor Specific EFM-OAM Grace functionality, allowing grace to be preferred over dying gasp when both are configured. This is in addition to the Nokia Vendor OUI 00:16:4d.
When both grace-tx-enable and dying-gasp-tx-on-reset are active on the same port, grace-tx-enable takes precedence when a soft reset is invoked if the Peer Vendor OUI being received is 00:16:4d (ALU) or the configured grace-vendor-oui value. The grace-tx-enable command should not be configured if the Nokia Vendor Specific Grace TLV is not supported on the remote peer, including Nokia 7750 SR equipment prior to release 11.0 R4.
The no form of this command removes the additional Vendor OUI but does not remove the Nokia 00:16:4d value.
no grace-vendor-oui
This command configures efm-oam operational transition dampening timers which reduce the number of efm-oam state transitions reported to upper layers.
no hold-time
A hold-time value of zero indicates that there should be no delay in transitioning to the operational state. A non-zero value will cause the efm-oam protocol to attempt to negotiate with a peer if possible, but it will remain in the send-local-remote-ok state until the hold time has expired if negotiation is successful.
If efm-oam is administratively shutdown while it was in the operational state and then re-enabled when a non-zero hold time is configured, efm-oam will attempt transition to the operational state immediately.
The no form of this command reverts the value to the default.
When the ignore-efm-state command is configured, any failure in the protocol state machine (discovery, configuration, timeout, loops, and so on) does not impact the state of the port. There is only be a protocol warning message on the port. If this optional command is not configured, the port state is affected by any existing EFM-OAM protocol fault condition.
no ignore-efm-state
This context contains link monitoring specific options defining the various local thresholds, port interaction and peer notification methods. In order to activate Link monitoring function, this context must be configured with the no shutdown option. Shutting down link monitoring will clear all historical link monitoring counters. If the port was removed from service and placed in a non-operational down state and a port state of link up because a signal failure threshold was crossed and link monitoring is shutdown, the port will be returned to service assuming no underlying conditions prevent this return to service.
When the link monitoring function is in a no shutdown state, the Link Monitoring capability (EV) is advertised to the peer through the EFM OAM protocol. This may not be desired if the remote peer does not support the Link Monitoring functionality.
The context used to define errored frame parameters including thresholds, and windows of time to which the error count will be compared. An errored frame is counted when there is any frame error detected by the Ethernet physical layer. This excludes jumbo frames above 9192 bytes which are dropped prior to this function.
Allows the frame error sf-threshold crossing events to transmit the Event Notification OAMPDU with the specific Link Event TLV information. The Event Notification OAM PDU will only be generated when the initial sf-threshold is reached. No subsequent notification will be sent until the event that triggered until the event is manually cleared. The burst parameter under the local-sf-action will determine the number of Event Notification OAMPDUs to generate when the event occurs. The reception of the event notification will be processed regardless of this parameter.
The no version of this command will disable the transmission of the Event Notification OAMPDU for this event type.
event-notification
The option defines the number of errored frames within the configured window which indicates the port has gone beyond an acceptable error rate and should be considered degraded. This is a first level warning that a port may be suspect. This generates an information log event message only and will be recorded in the Port event index but has no port level actions when the error count is equal to or greater than the threshold. This value must be lower than or equal to the sf-threshold value.
The no value of this option disables the sd-threshold.
no sd-threshold
The option defines the number of frame errors within the configured window which indicates the port has exceeded an acceptable error rate. A log event will be raised, and the port will be taken out of service by default. Configuration options exist to take additional actions when the error rate exceeds the threshold. These actions are defined using the local-sf-action configuration. This event can only be cleared through manual intervention that affects the state of the port.
This command defines the size of the window using a 100ms base deciseconds. Errors are accumulated until the end of the window. At the end of the window the actual errors are compared to the thresholds to determine if a threshold has been crossed. There is no mid-window threshold checking. The window represents a unique non-overlapping period of time.
window 10
The context used to define errored frame parameters including thresholds, and windows of received packets to which the error count will be compared. An errored frame is counted when there is any frame error detected by the Ethernet physical layer. This excludes jumbo frames above 9192 bytes which are dropped prior to this function. The received packet count will be checked every one second to see if the window has been reached.
The option defines the number of errored frames within the configured window which indicates the port has gone beyond an acceptable error rate and should be considered degraded. This is a first level warning that a port may be suspect. This generates an information log event message only and will be recorded in the Port event index but has no port level actions when the error count is equal to or greater than the threshold. This value must be lower than or equal to the sf-threshold value.
The no value of this option disables the sd-threshold
no sd-threshold
This command defines the number of frame errors within the configured window which indicates the port has exceeded an acceptable error rate. A log event will be raised, and the port will be taken out of service by default. Configuration options exist to take additional actions when the error rate exceeds the threshold. These actions are defined using the local-sf-action configuration. This event can only be cleared through manual intervention that affects the state of the port.
sf-threshold 1
This command defines the size of the window based on a packet receive rate. The minimum serviceable rate is the number of minimum size packets that can be received in one second. The window receive count value will be polled at a minimum one second intervals to see if the window size has been reached. Errors are accumulated until the end of the window. At the end of the window the actual errors are compared to the thresholds to determine if a threshold has been crossed. There is no mid-window threshold checking. The window represents a unique non-overlapping period of time.
This command defines the errored frame seconds parameters including thresholds, and windows of time to which the error count will be compared. An errored second is any second in which a single frame error occurred. An errored frame is counted when there is any frame error detected by the Ethernet physical layer. This excludes jumbo frames above 9192 bytes that are dropped prior to this function.
This command defines the number of errored frame seconds within the configured window which indicates the port has gone beyond an acceptable error rate and should be considered degraded. This is a first level warning that a port may be suspect. This event is raised when the error count is equal to or greater than the configured threshold. This is an information log event message only and will be recorded in the Port event index but has no port level actions. This value must be lower than or equal to the sf-threshold value.
The no version of this command disables the sd-threshold.
This command defines the number of errors seconds within the configured window which indicates the port has exceeded an acceptable error rate. A log event will be raised, and the port will be taken out of service by default. Configuration options exist to take additional actions when the error rate exceeds the threshold. These actions are defined using the local-sf-action configuration. This event can only be cleared through manual intervention that affects the state of the port.
This command defines the size of the window using a 100ms base deciseconds. Errored seconds are accumulated until the end of the window. At the end of the window, the actual errors are compared to the thresholds to determine if a threshold has been crossed. There is no mid-window threshold checking. The window represents a unique non-overlapping period of time.
This command defines the symbol error parameters including thresholds, and windows of time (converted to symbols in that time) to which the error count will be compared. A symbol error occurs when any encoded symbol is in error and independent of frame counters.
This command allows the symbol error event threshold crossing actions to transmit the Event Notification OAM PDU with the specific Link Event TLV information. The Event Notification OAM PDU will only be generated on the initial sf-threshold is reached. No subsequent notification will be sent until the event that triggered the notification clears, through manual intervention or a window where the configured sd-threshold is not reached. The burst parameter under the local-sf-action will determine the number of Event Notification OAM PDUs to generate when the event occurs. The reception of the event notification will be processed regardless of this parameter.
The no version of this command will disable the transmission of the Event Notification OAM PDU for this event type.
event-notification
This command defines the number of errored frames within the configured window which indicates the port has gone beyond an acceptable error rate and should be considered degraded. This is a first level warning that a port may be suspect. An event is raised when the error count is equal to or greater than this value. This is an information log event message only and will be recorded in the Port event index but has no port level actions. This value must be lower than or equal to the sf-threshold value. Specific to symbol errors, this value must be configured with the value that indicates anything less is acceptable and the port can be returned to service. If this value is not configured then manual operation is required to return the port to service.
The no value of this option means there is there is no automatic return to service.
no sd-threshold
This command defines the number of symbol errors within the configured window which indicates the port has exceeded an acceptable error rate. A log event will be raised, and the port will be taken out of service by default. Configuration options exist to take additional actions when the error rate exceeds the threshold. These actions are defined using the local-sf-action configuration.
This command defines the size of the window using a 100ms base deciseconds. The time value is converted to a number of symbols for the underlying medium. Errors are accumulated until the end of the window. At the end of the window, the actual errors are compared to the thresholds to determine if a threshold has been crossed. There is no mid-window threshold checking. The window represents a unique non-overlapping period of time.
This command enables the link monitoring function. Issuing a no shutdown will start the process. Issuing a shutdown will clear any previously established negative conditions that were a result of the link monitoring process on this port and all collected data. This also controls the advertising capabilities.
The no form of this command activates the link monitoring function.
shutdown
This command enables or disables the local counting, thresholding and actions associated with this type of local monitor. Peer received errors are not controlled by this command. Reaction to peer messaging is defined in the peer-rdi-rx hierarchy.
The no form of this command activates the local monitoring function and actions for the event.
shutdown
This command defines how crossing the local signal failure threshold (sf-threshold) will be handled. This includes local actions and if and how to notify the peer that the threshold has been crossed.
This command defines the number of the Event Notification OAM PDU to be send to the peer if the local signal failure threshold (sf-threshold) has been reached. The sending of the Event Notification OAMPDU is configured under the individual monitors.
Interactions: The sf-thresh threshold will trigger these actions.
The context allows the operator to set different flags in the Information OAM PDU. The flags can be used to notify the peer that a local signal failure threshold has been exceeded within the configured window. This is useful when the local node supports the link monitoring function, but the remote peer does not support this capability. Information OAM PDUs are sent on the interval where the Event Notification OAM PDU is typically only sent on the initial sf-threshold crossing event. It is strongly suggested one of the Information OAM PDU Flag fields used to continually communicate current monitor state to the peer.
Interactions: The signal failure threshold will trigger these actions.
This command sets the critical event Flag field in the Information OAMPDU when the local signal failure (sf-threshold) threshold is reached. This will be maintained in all subsequent Information OAM PDUs until the situation is cleared.
Interactions: The signal failure threshold will trigger these actions.
no critical-event
This command sets the dying gasp Flag field in the Information OAM PDU when the local signal failure (sf-threshold) threshold is reached. This will be maintained in all subsequent Information OAM PDUs until the situation is cleared.
Interactions: The signal failure threshold will trigger these actions.
no dying-gasp
This command configures the parameters that define if and how the local port will be affected when the local signal failure threshold (sf-threshold) has been reached within the configured window.
Interactions: The signal failure threshold will trigger these actions.
local-port-action out-of-service
This command configures the mode of OAM operation for this Ethernet port. These two modes differ in that active mode causes the port to continually send out efm-oam info PDUs while passive mode waits for the peer to initiate the negotiation process. A passive mode port cannot initiate monitoring activities (such as loopback) with the peer.
mode active
This container allows an action to be configured for the various event conditions that can be received from a peer under the context of the EFM OAM protocol.
This command defines how to react to the reception of a critical event Flag field set in the informational OAMPDU.
critical-event local-port-action out-of-service
This command defines how to react to the reception of a dying gasp Flag field set in the informational OAMPDU.
dying-gasp local-port-action out-of-service
This command defines how to react to the reception of event TLVs contained in the Event Notification OAMPDU. The event TLVs contained in the event notification OAMPDU will be analyzed to determine if the peer has crossed the error threshold for the window. The analysis does not consider any local signal degrades or signal failure threshold. The analysis is based solely on the information receive form the peer. The analysis is performed on all event TLVs contained in the Event Notification OAMPDU without regard for support of a specific error counters or local configuration of any thresholds. In the case of symbol errors only, a threshold below the error rate can be used to return the port to service.
event-notification local-port-action log-only
This command defines how to react to the reception of a link fault flag set in the informational PDU from a peer.
link-fault local-port-action out-of-service
This command configures the transmit interval of OAM PDUs.
transmit-interval 10 multiplier 5
This command configures the appropriate flag field in the Information OAM PDU, bursting three consecutive packets during the off cycle. If the local port state is operational, this command changes the local port state to “Link Up”. If the local port state is not operational, this configuration is installed as an EFM reason to prevent the port from returning to an Up operational state. This command can be used as a precursor to a port shutdown. This terminates the peering relationship without having to wait for protocol timeouts, assuming the peer supports the necessary action when receiving the dying gasp or critical event flag setting.
The no form of this command disables this functionality.
no trigger-fault
This command enables EFM OAM PDU tunneling. Enabling tunneling will allow a port mode Epipe SAP to pass OAM frames through the pipe to the far end.
The no form of this command disables tunneling.
no tunneling
This command configures the rate of traffic leaving the network. The configured sub-rate uses packet-based accounting. An event log is generated each time the egress rate is modified unless the port is part of a LAG.
This command is not supported on ports of the following MDA types:
The no form of this command returns the value to the default.
no egress-rate
This command configures the encapsulation method used to distinguish customer traffic on an Ethernet access port, or different VLANs on a network port.
The no form of this command restores the default.
encap-type null
This command allows rate changes received in ETH-BN messages on a port-based MEP to update the egress rate used on the port. The egress rate is capped by the minimum of the configured egress-rate and the maximum port rate, and the minimum egress rate is 1 kb/s. The no form of this command returns the value to the default.
This command is not supported on the following MDA types:
no eth-bn-egress-rate-changes
This command configures port link dampening timers which reduce the number of link transitions reported to upper layer protocols. The hold-time value dampens interface transitions.
When an interface transitions from an up state to a down state, it is immediately advertised to the rest of the system if the hold-time down interval is zero, but if the hold-time down interval is greater than zero, interface down transitions are not advertised to upper layers until the hold-time down interval has expired. Likewise, an interface is immediately advertised as up to the rest of the system if the hold-time up interval is zero, but if the hold-time up interval is greater than zero, up transitions are not advertised until the hold-time up interval has expired.
For ESM SRRP setup, MCS synchronizes subscriber information between the two chassis. After a chassis recovers from a power reset/down, MCS immediately synchronizes all subscriber information at once. The longer the host list, the longer it will take to synchronize the chassis. In a fully populated chassis, it is recommended to allow at least 45 minutes for MCS synchronization. It is also recommended to hold the port down, facing the subscriber, on the recovering chassis for 45 minutes before it is allowed to forward traffic again.
The no form of this command reverts to the default values.
down 0 seconds — No port link down dampening is enabled; link down transitions are immediately reported to upper layer protocols.
up 0 seconds — No port link up dampening is enabled; link up transitions are immediately reported to upper layer protocols.
This command enables the context to configure ingress and egress HSMDA scheduler override parameters. Executing hsmda-scheduler-override places the current CLI context into the egress scheduler override node either at the ingress MDA or egress port level.
Default values are listed in Table 48.
Command | Configuration |
description | no description |
max-rate | no max-rate |
group | group 1 rate max group 2 rate max |
scheduling-class | scheduling-class 1 rate max scheduling-class 2 rate max scheduling-class 3 rate max scheduling-class 4 rate max scheduling-class 5 rate max scheduling-class 6 rate max scheduling-class 7 rate max scheduling-class 8 rate max |
The no form of this command removes the overridden parameters from the HSMDA egress port or ingress MDA scheduler. Once existing overrides are removed, the scheduler reverts all scheduling parameters back to the parameters defined on the hsmda-scheduler-policy associated with the egress port or ingress MDA.
This command changes the maximum rate allowed for a weighted scheduling group on the local HSMDA scheduler. Scheduling classes within the group are managed with an aggregate rate limit when either an explicit group rate is defined on the HSMDA scheduling policy or a local override is defined based on the group override command.
The no form of this command removes the local overrides for the weighted scheduling group. Once removed, the defined behavior within the HSMDA scheduling policy for the weighted scheduling group is used.
The max keyword removes any existing rate limit imposed by the HSMDA scheduler policy for the weighted scheduling group allowing it to use as much total bandwidth as possible.
This command overrides the max-rate parameters configured in the hsmda-scheduler-policy associated with the egress port or ingress MDA. When a max-rate is defined at the override level, the HSMDA scheduler policy’s max-rate parameter is ignored.
The hsmda-scheduler-override max-rate command supports a max parameter that allows the override command to restore the default of not having a rate limit on the port scheduler. This is helpful when the HSMDA scheduler policy has an explicit maximum rate defined and it is desirable to remove this limit at the port instance.
The no form of this command removes the maximum rate override from the egress port or the ingress MDA scheduler context. Once removed, the max-rate parameter from the HSMDA scheduler policy associated with the port or MDA will be used by the local scheduler context.
This command overrides the maximum rate allowed for a scheduling class or the weight of the class within a weighted scheduling group. The scheduling-class override cannot be used to change scheduling class weighted group membership; weighted group membership may only be defined within the HSMDA scheduling policy.
Scheduling classes correspond directly to the queue-IDs used by every queue on an HSMDA. All queues with an ID of 1 associated with the scheduler are members of scheduling class 1 on the scheduler. Queues with an ID of 2 are members of scheduling class 2. This is true through scheduling class 8.
When the scheduling class is not a member of a weighted group, the scheduling-class command may be used to modify the maximum rate allowed for the scheduling class. This is done using the rate parameter followed by either the max keyword or an actual rate defined as megabits-per-second. Use the rate max combination to locally remove a rate limit defined for the class on the scheduling policy. When the rate megabits-per-second combination is used, the scheduling class defined as class-id is rate limited to the specified rate. Either the max keyword or a value for megabits-per-second must follow the rate keyword.
The rate keyword is mutually exclusive with the weight keyword. The weight keyword may only be specified when class-id is a member of a weighted scheduling group. When the weight keyword is specified, a weight value specified as weight must follow. The new weight locally overrides the weight defined for the scheduling class in the HSMDA scheduling policy.
When the scheduling-class command is executed, either the rate or weight keyword must follow.
When a scheduling class has a local rate override, the HSMDA policy associated with the override cannot move the scheduling class into a weighted scheduling group. Similarly, when a scheduling class has a local weight override, the HSMDA policy associated with the override cannot define a rate (neither max nor a megabit-per-second value) for the scheduling class. The local overrides of the scheduling class must be removed before these changes may be made.
The no form of this command removes the local overrides for the scheduling class. Once removed, the defined behavior for the scheduling class within the HSMDA scheduling policy will used.
The max keyword removes any existing rate limit imposed by the HSMDA scheduler policy for the scheduling class allowing it to use as much total bandwidth as possible.
This command specifies the HS secondary shaper class.
The no form of this command reverts the rate for this class to the default value.
This command configures the maximum amount of ingress bandwidth that this port can receive with the configured sub-rate using packet-based accounting.
The no form of this command returns the value to the default.
no ingress-rate
This command enables LACP packet tunneling for the Ethernet port. When tunneling is enabled, the port will not process any LACP packets but will tunnel them instead. The port cannot be added as a member to a LAG group.
In this context, the lacp-tunnel command is supported for Epipe and VPLS services only.
The no form of this command disables LACP packet tunneling for the Ethernet port.
no lacp-tunnel
This command specifies the load balancing algorithm to be used on this port.
In the default mode, no load-balancing-algorithm, the port inherits the global settings. The value is not applicable for ports that do not pass any traffic.
The configuration of load-balancing-algorithm at logical port level has three possible values:
The hashing algorithm addresses finer spraying granularity where many hosts are connected to the network. To address more efficient traffic distribution between network links (forming a LAG group), a hashing algorithm extension takes into account Layer 4 information (src/dst L4-protocol port). The hashing index can be calculated according to the following algorithm:
If [(TCP or UDP traffic) & enabled]
hash (<TCP/UDP ports>, <IP addresses>)
else if (IP traffic)
hash (<IP addresses>)
else
hash (<MAC addresses>)
endif
This algorithm will be used in all cases where IP information in per-packet hashing is included (see LAG and ECMP Hashing). However the Layer 4 information (TCP/UDP ports) will not be used in the following cases:
no load-balancing-algorithm
This command configures the minimum transmitted frame length.
This command configures the Ethertype used for PBB encapsulation.
no pbb-etype
This command configures the PTP asymmetry delay delta on an Ethernet port. The command corrects for known asymmetry for time of day or phase recovery of PTP packets on both local and downstream PTP clocks.
no ptp-asymmetry
This command configures the Ethertype used for Q-in-Q encapsulation.
The no form of this command reverts the qinq-etype value to the default.
no qinq-etype
This command specifies when and if to generate alarms and alarm clear notifications for this port.
This command enables RS-FEC on the Ethernet port. RS-FEC Clause 91 is required for QSFP28, CFP4, 100GBase-SR4, 100GBase-ER4 lite, and CWDM4 for the QSFP28 package optics for short-reach optics.
no rs-fec-mode
This command enables sFlow data collection for a port and its SAPs that support sFlow data collection.
The no form of this of this command disables sFlow.
no sflow
This command enables packet gathering and redirection of IP packets from a single fiber (RX) port of the Ethernet or SONET/SDH interface and redistributes packets to other interfaces through either static routes or policy-based forwarding.
This parameter can be applied in conjunction with the strip-label command. If they are applied together, the port must have the single-fiber option configured before it can be associated with an interface that is configured with the strip-label option.
Once a port is configured with single-fiber, traffic will no longer be transmitted out of that port.
no single-fiber
For ports that support multiple speeds, this command configures the port speed to be used. This applies to the following:
If the port is configured to autonegotiate this parameter is ignored. Speed cannot be configured for ports that are part of a Link Aggregation Group (LAG).
dependent on port type
This command enables the Ethernet Synchronization Messaging Channel (ESMC) for the Ethernet port. ESMC carries the Synchronization Status Message (SSM) code representing the quality level of the source of frequency of the central clock of the node.
This command configures the encoding of synchronization status messages. For example, whether to use an SDH or SONET set of values. Configuring the network-type is only applicable to SyncE ports. It is not configurable on SONET/SDH ports. For the network-type, sdh refers to ITU-T G.781 Option I, while sonet refers to G.781 Option II (equivalent to Telcordia GR-253-CORE).
code-type sdh
This command allows ESMC frames that are received into the Ethernet port to be tunneled in an Epipe or VPLS service. This is not recommended because it breaks the concepts inherent in Synchronous Ethernet, however it is required for compliance to MEF 6.1.1 EPL Option 2.
The no form of this command extracts the ESMC frames upon reception by the port. The ESMC frames are not tunneled through the service.
no esmc-tunnel
This command forces the QL value transmitted from the SSM channel of the SONET/SDH port or the Synchronous Ethernet port to be set to QL-DUS/QL-DNU. This capability is provided to block the use of the interface from the SR/ESS for timing purposes.
no tx-dus
This command configures Ethernet Symbol Monitoring parameters. Support for symbol monitoring is hardware dependent. An error message indicating that the port setting cannot be modified will be presented when attempting to enable the feature or configure the individual parameters on unsupported hardware.
This command specifies the error rate at which to declare the Signal Degrade condition on an Ethernet interface. The value represents M*10E-N a ratio of symbol errors over total symbols received over W seconds of the sliding window. The symbol errors on the interface are sampled once per second. A default of 10 seconds is used when there is no additional window-size configured. The multiplier keyword is optional. If the multiplier keyword is omitted or no sd-threshold is specified the multiplier will return to the default value of 1.
no sd-threshold
This command specifies the error rate at which to declare the Signal Fail condition on an Ethernet interface. The value represents M*10E-N symbol errors over total symbols received over W seconds of the sliding window. The symbol errors on the interface are sampled once per second. A default of 10 seconds is used when there is no additional window-size configured. The multiplier keyword is optional. If the multiplier keyword is omitted or no sf-threshold is specified, the multiplier will return to the default value of 1.
no sf-threshold
This command specifies sliding window size over which the symbols are sampled to detect signal failure or signal degraded conditions.
window-size 10
This command configures the interval used to calculate the utilization statistics.
Port utilization statistics are only available for physical Ethernet ports on a host system. These statistics are not available for the following:
This command configures a 10 Gb/s interface to be in Local or Wide Area Network (LAN or WAN) mode. When configuring the port to be in WAN mode certain SONET/SDH parameters can be changed to reflect the SONET/SDH requirements for this port.
When the port is configured for LAN mode, all SONET/SDH parameters are pre-determined and not configurable.
xgig lan
This command configures Ethernet CRC Monitoring parameters.
This command specifies the error rate at which to declare the Signal Degrade condition on an Ethernet interface. The value represents M*10E-N a ratio of errored frames over total frames received over W seconds of the sliding window. The CRC errors on the interface are sampled once per second. A default of 10 seconds is used when there is no additional window-size configured. The multiplier keyword is optional. If the multiplier keyword is omitted or no sd-threshold is specified the multiplier will return to the default value of 1.
no sd-threshold
This command specifies the error rate at which to declare the Signal Fail condition on an Ethernet interface. The value represents M*10E-N errored frames over total frames received over W seconds of the sliding window. The CRC errors on the interface are sampled once per second. A default of 10 seconds is used when there is no additional window-size configured. The multiplier keyword is optional. If the multiplier keyword is omitted or no sf-threshold is specified the multiplier will return to the default value of 1.
no sf-threshold
This command specifies sliding window size over which the Ethernet frames are sampled to detect signal fail or signal degrade conditions. The command is used jointly with the sf-threshold and the sd-threshold to configure the sliding window size.
The no version of this command reverts to the default value of 10 seconds.
no window-size
This command configures the system to bring a port operationally down in the event the system has detected internal MAC transmit errors (Int MAC Tx Errs).
no down-on-internal-error
This command enables packet gathering and redirection of IP packets from a single fiber (RX) port of the Ethernet or SONET/SDH interface and redistributes packets to other interfaces through either static routes or policy-based forwarding.
This parameter can be applied in conjunction with the strip-label command. If they are applied together, the port must have the single-fiber option configured before it can be associated with an interface that is configured with the strip-label option.
Once a port is configured with single-fiber, traffic will no longer be transmitted out of that port. This command can be used in conjunction with strip-label.
no single-fiber
This command configures MACsec under this port.
This command specifies the MAC policy to be excluded from MACsec encryption.
The no form of this command removes the policy from the MACsec and allows all destination MAC addresses.
no exclude-mac-policy
Specifies protocols whose packets are not secured using Media Access Control Security (MACsec) when MACsec is enabled on a port.
When this option is enabled in a connectivity association that is attached to an interface, MACsec is not enabled for all packets of the specified protocols that are sent and received on the link.
When this option is enabled on a port where MACsec is configured, packets of the specified protocols will be sent and accepted in clear text.
no exclude-protocol
When the rx-must-be-encrypted option is enabled, all traffic that is not MACsec-secured that is received on the port is dropped.
When the rx-must-be-encrypted option is disabled, all arriving traffic, whether MACsec secured or not, will be accepted.
![]() | Note: This command is only available on the NULL port level and does not have per-VLAN granularity. |
The no form of this command disables the rx-must-be encrypted option.
rx-must-be-encrypted
This command creates a MACsec instance on a physical port, targeting the specific subset of traffic defined by the encap-match command.
The no form of this command removes the MACsec instance.
This command configures the Connectivity Association (CA) linked to this MACsec sub-port. The specified CA provides the MACsec parameter to be used or negotiated with other peers.
The no form of this command removes the CA from the MACsec sub-port.
The EAPoL destination MAC address uses a destination multicast MAC address of 01:80:C2:00:00:03. Some networks cannot tunnel this packet over the network and consume these packets, causing the MKA session to fail. This command can change the destination MAC of the EAPoL to the unicast address of the MACsec peer, and as such, the EAPoL and MKA signaling will be unicasted between two peers.
The no form of this command returns the value to the default.
no eapol-destination-address
This command defines the sub-set of traffic on this port affected by this MACsec sub-port.
In order to establish an end-to-end communication between the remote MACsec peers encrypting VLAN-tagged traffic, the MKA packets have to be able to travel over the network following the same path as the encrypted traffic. MKA packets are generated with specific tags depending on the traffic match criteria configured, as shown in Table 49.
The no form of this command removes all traffic sub-set definitions from the MACsec sub-port.
Configuration | Config Example (<s-tag>.<c-tag>) | MKA Packet Generation | Traffic pattern match/behavior |
PORT all-encap | Config>port>ethernet>dot1x>macsec Sub-port 10 encap-match all-encap ca-name 10 | untagged MKA packet | Matches all traffic on the port, including untagged, single-tag, double-tag. This is the Release 15.0 default behavior. |
Untagged | Config>port>ethernet>dot1x>macsec Sub-port 1 encap-match untagged ca-name 2 | untagged MKA packet | Matches only untagged traffic on the port |
802.1Q single S-TAG (specific S-TAG) | Config>port>ethernet>dot1x>macsec Sub-port 2 encap-match dot1q 1 ca-name 3 | MKA packet generated with S-TAG=1 | Matches only single-tag traffic on port with tag ID of 1 |
802.1Q single S-TAG (any S-TAG) | Config>port>ethernet>dot1x>macsec Sub-port 3 encap-match dot1q * ca-name 4 | untagged MKA packet | Matches any single-tag traffic on port |
802.1ad double tag (both tag have specific TAGs) | Config>port>ethernet>dot1x>macsec Sub-port 4 encap-match qinq 1.1 ca-name 5 | MKA packet generated with S-tag=1 and C-TAG=1 | Matches only double-tag traffic on port with service tag of 1 and customer tag of 1 |
802.1ad double tag (specific S-TAG, any C-TAG) | Config>port>ethernet>dot1x>macsec Sub-port 6 encap-match qinq 1.* ca-name 7 | MKA packet generated with S-TAG=1 | Matches only double-tag traffic on port with service tag of 1 and customer tag of any |
802.1ad double tag (any S-TAG, any C-TAG | Config>port>ethernet>dot1x>macsec Sub-port 7 encap-match double-tag *.* ca-name 8 | untagged MKA packet | Matches any double-tag traffic on port |
encap-match all-encap
Type | Parameter |
all-encap | — |
untagged | — |
dot1q | [*|s] (s = 0..4094) |
qinq | [*.*|s.*|s.c] (s and c = 0..4094) |
where:
This command configures the max peer allowed under this MACsec instance.
![]() | Note: The peer establishment is a race condition and first come first serve. On any security zone, only 32 peers can be supported. See SA Exhaustion Behavior for more details. |
The no form of this command returns the value to the default.
no max-peer
This command shuts down the MACsec under this sub-port specifically, including MKA negotiation. In the shutdown state, this port is not MACsec capable and all PDUs will be transmitted and expected without encryption and authentication.
The no form of this command puts the port in MACsec-enabled mode. A valid CA, different than any other CA configured on any other sub-port of this port and also a max-peer value larger than 0 must be configured. In MACsec-enabled mode, packets are sent in clear text until the MKA session is up, and if the rx-must-be-encrypted is set on the port, all incoming packets with no MACsec encapsulations are dropped.
shutdown
This command configures the maximum number of times that the router will send an access request RADIUS message to the RADIUS server. If a reply is not received from the RADIUS server after the specified number attempts, the 802.1x authentication procedure is considered to have failed.
The no form of this command returns the value to the default.
max-auth-req 2
This command configures the 802.1x authentication mode.
The no form of this command returns the value to the default.
port-control force-auth
This command configures the period between two authentication sessions during which no EAPOL frames are sent by the router.
The no form of this command returns the value to the default.
quiet-period 60
This command configures the RADIUS policy to be used for 802.1x authentication. An 802.1x RADIUS policy must be configured (under config>security>dot1x) before it can be associated to a port. If the RADIUS policy-id does not exist, an error is returned. Only one 802.1x RADIUS policy can be associated with a port at a time.
The no form of this command removes the RADIUS policy association.
no radius-plcy
This command configures the period after which re-authentication is performed. This value is only relevant if re-authentication is enabled.
The no form of this command returns the value to the default.
re-auth-period 3600
This command enables/disables periodic 802.1x re-authentication.
When re-authentication is enabled, the router will re-authenticate clients on the port every re-auth-period seconds.
The no form of this command returns the value to the default.
no re-authentication
This command configures the period during which the router waits for the RADIUS server to respond to its access request message. When this timer expires, the router will re-send the access request message, up to the specified number times.
The no form of this command returns the value to the default.
server-timeout 30
This command configures the period during which the router waits for a client to respond to its EAPOL messages. When the supplicant-timeout expires, the 802.1x authentication session is considered to have failed.
The no form of this command returns the value to the default.
supplicant-timeout 30
This command configures the period after which the router sends a new EAPOL request message.
The no form of this command returns the value to the default.
transmit-period 30
This command enables the tunneling of untagged 802.1x frames received on a port and is supported only when the dot1x port-control is set to force-auth. 802.1x tunneling is applicable to both Epipe and VPLS services using either a null SAP or a default SAP on a dot1q port. When configured, untagged 802.1x frames will be switched into the service with the corresponding supported SAP.
The no form of this command disables tunneling of untagged 802.1x frames.
no tunneling
This command configures Ethernet loop detection attributes.
This command enables access to the context to configure port-specific 802.1x authentication attributes. This context can only be used when configuring a Fast Ethernet, Gigabit or 10-Gb Ethernet LAN ports on an appropriate MDA.
This command configures the time interval between keep-alive PDUs.
no keep-alive
This command configures the minimum wait time before re-enabling port after loop detection.
no retry-timeout
This command specifies whether or not the down when looped destination MAC address is the broadcast address, or the local port MAC address, as specified in the port's MAC address.
This command enables the context to configure Link Layer Discovery Protocol (LLDP) parameters on the specified port.
This command configures destination MAC address parameters.
nearest-bridge | Specifies to use the nearest bridge. |
nearest-non-tpmr | Specifies to use the nearest non-Two-Port MAC Relay (TPMR). |
nearest-customer | Specifies to use the nearest customer. |
This command configures LLDP transmission/reception frame handling.
admin-status disabled
This command enables LLDP notifications.
The no form of this command disables LLDP notifications.
no notification
This command specifies how to encode the PortID TLV transmit to the peer. Some releases of the NSP NFM-P require the PortID value require the default if-Alias in order to properly build the Layer Two topology map using LLDP. Selecting a different option will impact the NSP NFM-P’s ability to build those Layer Two topologies.
port-id-subtype tx-local
This command allows LLDP packets received on the port with the destination address of the nearest bridge to be tunneled without being intercepted on the local port. The dest-mac nearest-bridge must be disabled for tunneling to occur. This is applicable to NULL SAP Epipe and VPLS services only.
no tunnel-nearest-bridge
This command specifies which management address to transmit. The operator can choose to send the system IPv4 address, the system IPv6 address, the out-of-band IPv4 address, the out-of-band IPv6 address, or any combination of these. The system address is sent only once. The address must be configured for the specific version of the protocol in order to send the management address.
no tx-mgmt-address
This command specifies which LLDP TLVs to transmit. The TX TLVs, defined as a bitmap, includes the basic set of LLDP TLVs whose transmission is allowed on the local LLDP agent by the network management. Each bit in the bitmap corresponds to a TLV type associated with a specific optional TLV. Organizationally-specific TLVs are excluded from this bitmap.
There is no bit reserved for the management address TLV type since transmission of management address TLVs are controlled by another object.
The no form of this command resets the value to the default.
no tx-tlvs
This command enables access to the context to configure network port parameters.
This command configures an accounting policy that can apply to an interface.
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. Accounting policies associated with network ports can only be associated with interfaces. Only one accounting policy can be associated with an interface at a time.
The no form of this command removes the accounting policy association from the network interface, and the accounting policy reverts to the default.
No accounting policies are specified by default. You must explicitly specify a policy. If configured, the accounting policy configured as the default is used.
This command enables the collection of accounting and statistical data for the network interface. 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 by the XCM/IOM cards, 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.
no collect-stats
This command specifies the existing network queue policy which defines queue parameters such as CBS, high priority only burst size, MBS, CIR and PIR rates, as well as forwarding-class to queue mappings. The network-queue policy is defined in the config>qos>network-queue context.
queue-policy default
This command enables HS turbo queues which allows the corresponding HSQ queue group queues to achieve a higher throughput. The hs-turbo command is not applicable to 10G ports and is ignored when configured under a queue group instance on a 10G port.
This command is only applicable to the HSQ IOM (iom4-e-hs) and will fail if configured on all other card types.
The no form of this command disables the command.
This command specifies an HS port pool policy to associate with the port egress.
An HS port buffer pool policy defines and sizes the port-class buffer pools on an HSQ IOM egress port.
A single HS port pool policy is supported per port egress. This command is only applicable to the HSQ IOM (iom4-e-hs) and will fail if configured on all other card types.
The no form of this command removes the policy and reapplies the default policy.
hs-port-pool-policy default
This command enables the context to configure HS scheduler overrides which override parameters in the applied HS scheduler policy.This command is only applicable to the HSQ IOM (iom4-e-hs) and will fail if configured on all other card types.
This command overrides a group rate configured in the HS scheduler policy applied to the port egress.
The no form of this command removes the rate override from the port egress configuration.
This command overrides the max-rate configured in the HS scheduler policy applied to the port egress.
The no form of this command removes the max-rate override from the port egress configuration.
This command overrides the scheduling class configuration in the HS scheduler policy applied to the port egress. The scheduling class rate or weight within the WRR group can be overridden.
The no form of this command removes the scheduling class override parameters from the port egress configuration.
This command specifies an HS scheduler policy to associate with the port egress which provisions the scheduling behavior of the HSQ scheduler classes.
A single HS scheduler policy is supported per port egress. This command is only applicable to the HSQ IOM (iom4-e-hs) and will fail if configured on all other card types.
The no form of this command removes the policy and reapplies the default policy.
hs-scheduler-policy default
This command specifies an HS secondary shaper on the port egress. HS secondary shapers are used to apply an aggregate rate and per-scheduling class rates to the set of SAP egress HSQ queue groups which reference them using the SAP egress queue-override hs-secondary-shaper command.
By default, the hs-secondary-shaper default is applied to each port egress on all HSQ ports and the settings under it can be modified.
Multiple HS secondary shapers are supported per port egress, up to the number supported per-HSQ FP, which is 4096 HS secondary shapers. The number of HS secondary shapers allocated on an HSQ FP can be seen using the tools dump resource-usage card slot-number fp fp-number command.
Non-default HS secondary shapers are only configurable on access or hybrid mode ports.
This command is only applicable to the HSQ IOM (iom4-e-hs) and will fail if configured on all other card types.
The no form of this command removes the HS secondary shaper from the port egress configuration. An HS scheduler policy cannot be removed when HS scheduler overrides exist on the port egress.
hs-secondary-shaper default
This command enables the context to configure aggregate parameters.
The no form of this command removes all of the aggregate parameter values from the configuration of this HS secondary shaper.
This command specifies which scheduling classes map to the low burst-limit threshold of an egress HS secondary shaper. Egress SAPs can be configured to use an HS secondary shaper that manages their maximum burst limit over a specified aggregate shaping rate. Each HS secondary shaper supports two thresholds, a low burst limit threshold and a high burst limit threshold.
By default, all scheduling classes are mapped to the low burst limit threshold. It is important to note that when mapping scheduling classes to the high burst limit threshold an adequate value for the card>fp>egress>hs-fixed-high-thresh-delta must be specified. This is due to the fact that the queues associated with the lower classes may burst over the lower threshold in normal operation due to the scheduler forwarding whole packets. The hs-fixed-high-thresh-delta value should be set to at least two times the maximum frame size to prevent lower threshold class forwarding from also affecting the higher threshold classes when forwarding larger packet sizes. An insufficient high threshold delta defeats the intended purpose of mapping classes to the higher threshold.
The system utilizes the lowest value attainable for each low threshold aggregate burst limit without causing shaper underrun conditions. The high burst limit threshold is determined by adding the hs-fixed-high-thresh-delta value configured in the config>card>fp>egress context to the aggregate’s low burst limit threshold value.
The low-burst-max-class value can be changed at any time for an HS secondary shaper.
The no form of this command restores the HS secondary shaper’s aggregate low burst limit threshold maximum scheduling class mapping to the default value. This causes all sets of queues associated with the hs-secondary-shaper secondary-shaper-name to have all scheduling classes mapped to the low burst limit threshold.
low-burst-max-class 6
This command specifies the rate allowed for the HS secondary shaper's aggregate rate and per-class rates.
The no form of this command reverts to the default.
rate max
This command specifies the HS secondary shaper class.
The no form of this command reverts the classes rate to its default value.
This command creates an interface group handler that can be associated with a number of independent IP links. The purpose of the group is to operationally disable all interfaces in a common group if the number of active links drops below the minimum interface threshold.
The no form of this command deletes the interface group handler. All members must be removed before the IGH can be deleted.
This command binds the specified port with the associate Interface Group Handler. Up to eight member commands can be issued to add multiple ports to the associated IGH. The member must be a port or channel on a SONET or POS MDA. It must be a physical port or channel in network mode, and not bound to any router interfaces. A port or channel cannot be a member of more than one IGH at the same time. MLPPP bundles and their members cannot be IGH members.
The no form of this command removes the specified port ID from the associated IGH.
This command identifies the minimum number of active links that must be present for the interface group handler to be active. A threshold of 1 effectively disables the effect of the interface group handler.
The no form of this command resets the threshold to 1.
Note that for APS configurations, if the ber-sd or ber-sf threshold rates must be modified, the changes must be performed at the line level on both the working and protect APS port member.
threshold 1
The following Multilink-Bundle Port commands are supported on the 7750 SR only.
This command creates the context to configure bundle properties for this bundle port.
This command sets the maximum length in bytes of a fragment transmitted across a multilink bundle.
The no form of this command resets the fragment threshold back to the default value.
fragment-threshold 128
This command enables Link Fragmentation and Interleaving on the multilink bundle.
The no form of this command disables Link Fragmentation and Interleaving on the multilink bundle.
This command binds a channel group to a multilink bundle. For IMA and MLFR groups, this command binds a channel group filling up the entire DS-1 or E-1. For MLPPP groups, fractional (n x ds0) DS1 or E1 links are also allowed. However, fractional DS1 links and fractional E1 links may not be combined in the same multilink bundle. If a channel with a different number of timeslots than the primary-link member is added to the bundle, a warning will be provided.
The no form of this command removes the specified channel group from the multilink bundle.
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 sets the minimum number of links that must be active for the bundle to be active.
If the number of active links drops below the configured minimum then the multilink bundle will transition to an operationally down state.
The no form of this command removes the minimum link limit.
minimum-links 1
This command enables the context to configure a Multi-link Frame Relay (MLFR) bundle.
This command defines the identifier for the MLFR bundle. The no form of this command resets the value to null.
null
This command defines the identifier for a frame-relay link when used in an MLFR bundle. The no form of this command resets the value to null.
null
This command enables the context to configure the ingress QoS profile for the MLFR bundle.
This command enables the context to configure the egress QoS profile for an MLFR bundle or a Frame Relay port with FRF.12 UNI/NNI fragmentation enabled.
This command specifies the ingress or egress QoS profile to be used for the configuration of the ingress or egress QoS parameters of an MLFR bundle or a Frame Relay port with FRF.12 UNI/NNI fragmentation enabled. Note that qos-profile on ingress is only applicable to MLFR.
The no form of this command removes the parameters from the configuration.
This command configures the Frame Relay parameters.
This command configures the LMI type.
This command configures the DCE/DTE mode of the Frame Relay interface.
This command configures the number of DTE full status polling intervals for the LMI.
This command configures the DCE error threshold for the LMI.
n392dce 3
This command configures the DTE error threshold for the LMI.
This command configures the DCE monitored event count for the LMI.
This command configures the DTE monitored event count for the LMI.
This command configures the DTE keepalive timer value for the LMI.
This command configures the DCE keepalive timer value for the LMI.
This command specifies the value of the MLFR bundle T_HELLO timer. The timer controls the rate that hello messages are sent. Following a period of T_HELLO duration, a HELLO message is transmitted onto the bundle link.
Note that T_HELLO timer is also used during the bundle link add process as an additional delay before resending an ADD_LINK message to the peer bundle link when the peer bundle link does not answer as expected.
hello-interval 10
This command specifies the value of the MLFR bundle T_ACK timer.
This timer defines the maximum period to wait for a response to any message sent onto the bundle link before attempting to retransmit a message onto the bundle link.
ack-timeout 4
This command specifies the value of the MLFR bundle N_RETRY counter.
The counter specifies the number of times a retransmission onto a bundle link will be attempted before an error is declared and the appropriate action taken.
retry-limit 2
This command defines the context to configure the parameters of FRF.12 frame relay fragmentation.
This command sets the maximum length in bytes of a fragment transmitted across a frame relay port with the FRF.12 UNI/NNI fragmentation enabled.
The no form of this command resets the fragment threshold back to the default value.
fragment-threshold 128
This command enables the context to configure multi-link PPP bundle attributes.
This command enables the context to configure egress MLPPP QoS profile parameters for the multilink bundle.
This command enables the context to configure ingress MLPPP QoS profile parameters for the multilink bundle.
This command specifies the egress QoS profile to be used for the outgoing traffic over this MLPPP bundle.
The no form of this command removes the parameters from the configuration.
This command configures the endpoint-discriminator class and ID. The port must be shutdown to modify command parameters.
The no form of this command removes the parameters from the configuration.
This command specifies the ingress QoS profile to be used for the incoming traffic over this MLPPP bundle.
This command allows loopback detection to be enabled and disabled for MLPPP bundles. It is disabled by default. When the magic number option is disabled, the magic number option will not be requested when a member is trying to bring up the LCP layer on a member link; if the remote peer requests this option, it will be rejected. When transmitting echo-requests a magic number of 0 is used. When responding to echo-requests a magic number of 0 is sent.
The magic number option is sent to the remote peer during protocol negotiation. If this option is rejected by the remote peer, the router will bring the link up but will be unable to detect loopbacks since the router will always send a magic number of 0 in the echo messages. If this option is accepted by the remote peer, the router will send echo messages with randomly generated magic-numbers. If the SR receives a config-req with the same magic number that was sent out, the router will calculate a new magic number to use and send out another config-request. If the router is persistently seeing the randomly generated magic number in the received config-req, the router will declare a loopback.
The no form of this command disables the loopback detection.
no magic-number
This command enables multi-class MLPPP as defined by RFC 2686, The Multi-Class Extension to Multi-Link PPP, on a MLPPP bundle (including MLPPP bundle protection groups) with 2, 3 or 4 classes. For multiclass MLPPP bundles with a non-zero count, the class index takes valid values from 0 to one less than the maximum number of classes inclusive. For example a 4-class MLPPP bundle has 4 classes with indexes 0, 1, 2, and 3. A bundle must be shutdown with no links for this value to be changed.
Entries are created and deleted by the system depending on the number of classes being used by a given MLPPP bundle.
The no form of this command disables multi-class MLPPP.
multiclass 4
This command specifies whether the bundle will perform a stateful or a stateless APS switchover.
The value can be changed for APS bundle protection groups of type MLPPP.
A stateless switchover implies that PPP is re-negotiated on each member link after the switchover. PPP negotiations may take a few seconds to complete.
A stateful switchover implies that after an APS switchover the PPP state of the bundle will be restored based on the bpgrp bundle state before the switchover.
The state cannot be changed for normal MLPPP bundles (only applicable for bpgrps).
The no form of this command disables stateless APS switchover.
no stateless-aps-switchover
This command specifies the maximum received reconstructed unit (MRRU), similar to a maximum transmission unit (MTU), but applies only to MLPPP multilink bundles. The MRRU is the maximum frame size that can be reconstructed from multilink fragments. This command is only valid for MLPPP bundles.
The no form of this command resets the MRRU to the default.
mrru 1524
This command configures a protect bundle that is part of this BPGrp.
bundle-PPP or IMA-slot/mda.bundle-num | Creates an MLPPP or IMA bundle. |
where: | bundle: keyword |
slot: IOM/MDA slot numbers | |
bundle-num: 1 to 336 |
This command sets the maximum acceptable differential delay for individual links within a multilink bundle. The differential delay is calculated as the round-trip differential delay for MLPPP bundles, and as uni-directional differential delay for IMA bundles.
The no form of this command restores the red-differential-delay defaults.
This command specifies that the Multi-link Point to Point Protocol (MLPPP) bundle should use short (12 bit) sequence numbers instead of the default 24-bit sequence number. This command is only valid for MLPPP bundles.
The no form of this command disables the short-sequence feature.
no short-sequence
This command configures a working bundle that is part of this BPGrp.
bundle-PPP or IMA-slot/mda.bundle-num | Creates an MLPPP or IMA bundle. |
where: | bundle: keyword |
slot: IOM/MDA slot numbers | |
bundle-num: 1 to 336 |
This command sets the yellow warning threshold for the differential delay for members within a multilink bundle. If circuit’s delay exceeds the yellow-differential delay value, a log message and SNMP trap is sent. This command is only valid for MLPPP bundles. The differential delay is calculated as the round-trip differential delay for MLPPP bundles.
The no form of this command removes the yellow-differential-delay.
This command enables the context to configure parameters for an Inverse Multiplexing over ATM (IMA) group. An IMA group is a collection of physical links bundled together and assigned to an ATM interface. IMA enables a high-speed channel that is composed of ATM cells to be transported as a number of lower-speed circuits. Then they are reassembled as the original high-speed ATM channel. This command is only valid for IMA bundles.
This command specifies the time to delay between detection of a link activation/deactivation condition and acting upon it (going in/out of the RX failure state on a link).
This command specifies the number of links used to determine the maximum configurable bandwidth that is allowed to be used for this IMA group.
The maximum bandwidth is computed as:
Maximum Configurable ATM Bandwidth (MCAB) =
(number-links) * (M-1)/M * (2048/2049) * primary member link speed
Where: | M is the IMA frame size (128) |
Primary member link speed is either E-1 — 1920 kb/s or DS-1 — 1539 kb/s. E-1 speed is used for a group with no members. |
The total ATM bandwidth of services over shaped VCs cannot exceed the MCAB value as result of adding more services or removing member links.
The no form of this command resets the max-bandwidth to its default value.
max-bandwidth 8
This command enables the context to configure IMA test pattern procedures. Note that this command and sub-commands are not saved in the router configuration between reboots.
This command specifies IMA members on which an IMA test pattern procedure is to be performed.
The no form of this command deletes the link from test-pattern procedure. The test-pattern procedure must be shutdown first.
no test-link
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 | ||
aps-id | aps-group-id[.channel] | ||
aps | keyword | ||
group-id | 1 to 128 |
This command specifies the transmit test pattern in an IMA group loopback operation. This value can only be changed when the test-pattern-procedure command is shut down.
The no form of this command restores the test-pattern to the default.
test-pattern 0
This command enables a configured IMA test pattern procedure.
The no form of this command disables the IMA test pattern procedure.
This command configures the IMA version for the multilink bundle group. If there is a version mismatch between this IMA group and the far end IMA group, the IMA group will become operationally down. Automatic version changing is not supported. To change the IMA version, all member links must be removed from the group first.
version 1-1
This command enables access to the context to configure SONET/SDH ports. This context can only be used when configuring an OC-3, OC-12, OC-48, OC-192, and OC-768 SONET/SDH ports on an appropriate MDA.
This command also enables access to the context to configure SONET/SDH parameters for an Ethernet port in WAN PHY (xgig wan) mode.
The 10 Gigabit Ethernet LAN port also has SONET/SDH characteristics. However, these characteristics are predetermined and not configurable.
This command is supported by TDM satellite.
This command configures the clock to be used for transmission of data out towards the line. The options are to use the locally recovered clock from the line's receive data stream or the node central reference.
When changing the clock source for a port on an OC-48 MDA, a brief transmit interruption can occur on all ports of that MDA. Note that all SONET/SDH MDAs support loop timing.
The node-timed parameter in this command is supported by TDM satellite.
This command specifies SONET/SDH framing to be either SONET or SDH.
This command is supported by TDM satellite.
framing sonet
This command configures payload of the SONET/SDH group.
This command is supported by TDM satellite, however the tu3 parameter is not.
For example:
config>port>sonet-sdh#
group tug3-1.1 payload tu3 group tug3-1.2 payload vt2 group tug3-1.3 payload vt2 group tug3-2.1 payload vt15 group tug3-2.2 payload vt15 group tug3-2.3 payload tu3 group tug3-3.1 payload tu3 group tug3-3.2 payload tu3 group tug3-3.3 payload tu3
This command configures SONET link dampening timers in 100s of milliseconds. This guards against reporting excessive interface transitions. This is implemented by not advertising subsequent transitions of the interface to upper layer protocols until the configured timer has expired.
Note: For APS configurations, the hold-time down and up default values are 100 ms and 500 ms respectively. If there is a large communication delay (time to exchange K1/K2 bytes) between the APS Controllers of the two endpoints of an APS link, it is highly suggested to increase the default hold-time down timer on the APS group port accordingly with the communication delay. See the aps command for more information.
This command is supported by TDM satellite.
no hold-time
This command activates a loopback on the SONET/SDH port.
The SONET port must be in a shut down state to activate any type of loopback. The loopback setting is never saved to the generated/saved configuration file.
Note that loopback mode changes on a SONET/SDH port can affect traffic on the remaining ports.
This command is supported by TDM satellite.
no loopback
This command enables logging of SONET (SDH) line and section alarms for a SONET-SDH port. Only line and section alarms can be configured in the SONET/SDH context, for path alarms see the sonet-sdh>path context.
The no form of this command disables logging of the specified alarms.
This command is supported on TDM satellites.
This command configures whether the SONET/SDH port will reset when the path transitions to an operationally down state. This command only affects SONET/SDH ports on 7750 4-port OC48 SFP “-B” MDAs.
no reset-port-on-path-down
This command configures the section trace bytes in the SONET section header to inter-operate with some older versions of ADMs or regenerators that require an incrementing STM ID. You can explicitly configure an incrementing STM value rather than a static one in the SDH overhead by specifying the z0-increment.
This command is supported on TDM satellite.
section-trace byte 0x1
This command configures the speed of a SONET/SDH port as either OC3 or OC12. The framer for this MDA operates in groups of four. Changing the port speed for a port requires resetting the framer and causes a slight disruption on all four ports. The first framer controls ports 1,2,3,4, the second framer controls ports 5,6,7,8 and so on.
To change the port speed on a SONET/SDH port, the port must be administratively shut down and all channels must be removed. When the port speed is changed, the default channel configuration is recreated.
The no form of this command reverts back to default.
This command is supported on TDM satellite.
speed oc12
This command enables the suppression of lower order alarms on SONET/SDH port such as MLPPP bundle alarms, DS1/E1 links alarms and 336 APS channel groups alarms.
The no form of this command disables the suppression of lower order alarms on SONET/SDH port.
This command forces the QL value transmitted from the SSM channel of the SONET/SDH port or the Synchronous Ethernet port to be set to QL-DUS/QL-DNU. This capability is provided to block the use of the interface from the SR/ESS for timing purposes.
This command is supported on TDM satellite.
no tx-dus
This command configures the line signal degradation bit error rate (BER) and line signal failure thresholds.
Line signal (b2) bit interleaved parity error rates are measured and when they cross either the degradation or failure thresholds alarms are raised (see the report-alarm command), furthermore if the failure threshold is crossed the link will be set to operationally down.
For APS configurations, if the ber-sd or ber-sf threshold rates must be modified, the changes must be performed at the line level on both the working and protect APS port member.
The no form of this command reverts to the default value.
threshold ber-sd rate 6 — Signal degrade BER threshold of 10-6.
threshold ber-sf rate 3 — Signal failure BER threshold of 10-3.
This command defines the SONET/SDH path.
The no form of this command removes the specified SONET/SDH path.
This command is supported on TDM satellite.
full channel (or clear channel)
SONET | SDH | ||
OC-192 | STS-48-index STS-12-index STS-3-index STS-1-index | STM-64 | AUG-16-index AUG-4-index AUG-1-index AU-3-index |
OC-48 | STS-12-index STS-3-index STS-1-index | STM-16 | AUG-4-index AUG-1-index AU-3-index |
OC-12 | STS-3-index STS-1-index | STM-4 | AUG-1-index AU-3-index |
OC-3 | STS-1-index | STM-1 | AU-3-index |
This command specifies if the associated SONET/SDH path is an asynchronous circuit or a virtual tributary group (VT). This command is only applicable to channelized MDAs.
This command is supported on TDM satellite, however the sts3, ds3, and e3 parameters are not supported.
This command configures the time interval at which keepalive requests are issued.
This command enables logging of SONET (SDH) path alarms for a SONET-SDH port. Only path alarms can be configured in the channel context.
The no form of this command disables logging of the specified alarms.
This command is supported on TDM satellites.
A 16 bit CRC can only be configured on an OC-3 channel, all other channel speeds must use a 32 bit CRC except for the paths configured with encap-type atm at OC3 speed.
crc 16 for OC-3, DS-1, DS-3 crc 32 for OC-12, OC-48, ATM-OC12/3, AT-MOC-3, and so on
![]() | Note: The CRC default is 32 when the encap-type is set to ATM and also, the default cannot be changed when the encap-type is set to ATM. |
This command configures the encapsulation method used to distinguish customer traffic on an access SONET/SDH channel sub-port.
When the encap-type is set to ATM the CRC default cannot be changed.
When the encap-type is ATM, ATM sub-layer verification (GR-1248-CORE, Generic Requirements for Operations of ATM Network Elements (NEs)) is automatically enabled. The result of the verification includes:
The encap-type is only required when configuring a SONET/SDH path for access mode.
The no form of this command restores the default.
encap-type bcp-null
Note that null ports will accept q-tagged frames.
This command enables access to the context to configure the LCP operational parameters for a SONET/SDH Point-to-Point Protocol (PPP) link.
This command enables logging of SONET (SDH) path alarms for a SONET-SDH port. Only path alarms can be configured in the channel context.
The no form of this command disables logging of the specified alarms.
This command enables SONET/SDH payload scrambling. Scrambling randomizes the pattern of 1s and 0s carried in a SONET frame. Rearranging or scrambling the pattern prevents continuous strings of all 1s or all 0s and meets the needs of physical layer protocols that rely on sufficient transitions between 1s and 0s to maintain clocking.
For ATM, this command enables or disables ATM cell-level payload scrambling/descrambling using x43+1 polynomial as defined in ITU-T I.432.1. Scrambling is enabled by default for the ATM path/channel. Note that this scrambling is done in addition to SONET/SDH frame scrambling/descrambling, which is always enabled in the framer.
The no form of this command disables scrambling.
no scramble
This command sets the C2 byte value. The purpose of this byte is to communicate the payload type being encapsulated by SONET framing.
This command is supported on TDM satellite.
signal-label 0xcf
This command specifies that a J1-path-trace that identifies the circuit is inserted continuously at source. This can be checked against the expected value by the receiver. If no trace string is entered then a null string is used.
The no form of this command resets the string to its default.
This command is supported on TDM satellite.
The default J1 value is Alcatel-Lucent XXX YYY where XXX is the platform number, such as “7750” or “7450”, and YYY is the platform acronym, such as “SR” or “ESS”. The value does not change when the encap-type changes. The J1 string contains all zeros for a non-provisioned path.
This command specifies the interval, in seconds, used to send periodic keepalive packets. The receiver process expects to receive a keepalive packet every “keepalive interval”. The link is declared down if the receiver process does not receive a keepalive within the “timeout interval”. The link is declared up once the number of continual keepalive packets received equals to the up-count. The nodes at the two endpoints of the cHDLC link should be provisioned with the same values. A keepalive value of 0 means no keepalive packets are sent.
keepalive 10
This command configures the number of continual keepalive packets that have to be received in order to declare the link up. It is expected that the nodes at the two endpoints of the cHDLC link are provisioned with the same values.
up-count 1
ATM Interface commands are supported on the 7750 SR only.
This command enables the context to configure ATM interface properties.
This command configures the ATM cell format.
This command configures the ATM cell mapping for DS-3 channels. The mapping value specifies the cell mapping that is to be used on this ATM interface.
mapping direct
This command sets the minimum allowable virtual path identifier (VPI) value that can be used on the ATM interface for a VPC.
This command configures ATM port custom buffer parameters.
This command configures the ATM port buffer pool percentage.
This command configures the ATM port VC threshold.
This command creates an ILMI link PVCC by default on VPI/VCI 0/16. Deleting an ILMI link deletes the PVCC. ILMI is supported only on ATM interfaces on SONET/SDH paths.
vpi | 0 to 4095 (NNI) |
0 to 255 (UNI) | |
vci | 1, 2, 5 to 65535 |
This command enables the context to configure egress traffic attributes for the ILMI link.
This command enables the context to configure ingress traffic attributes for the ILMI link.
This command associates an ATM traffic descriptor profile to an ILMI link. It is recommended to change this to the traffic profile as defined in the ILMI specification.
traffic-desc 1
This command configures keepalive parameters to monitor ILMI link connectivity.
The no form of this command resets the default values on an ILMI link.
Last Config Change: 03/29/2007 20:35:19 Poll Count: 4
Poll Freq: 5 Test Freq: 1
This command configures the protocol.
Frame Relay commands are supported on the 7750 SR only.
This command allows access to the context to configure the Frame Relay Local Management Interface (LMI) operational parameters for a SONET/SDH PoS link, a DS-0 channel group, or a DS-3/E-3 port or channel.
The port’s mode must be set to access in config>port>sonet-sdh>path>mode access context.
The port’s encapsulation type must be set to frame-relay in the config>port>sonet-sdh>path>encap-type frame-relay context.
The no form of this command removes the Frame Relay LMI operational parameters.
This command defines the context to configure the parameters of FRF.12 Frame Relay fragmentation.
This command enables the context to configure the egress QoS profile for an MLFR bundle or a Frame Relay port with FRF.12 UNI/NNI fragmentation enabled.
This command specifies the ingress or egress QoS profile to be used for the configuration of the egress QoS parameters of a Frame Relay port with FRF.12 UNI/NNI fragmentation enabled.
The no form of this command removes the parameters from the configuration.
This command sets the maximum length in bytes of a fragment transmitted across a frame relay port with the FRF.12 UNI/NNI fragmentation enabled.
The no form of this command resets the fragment threshold back to the default value.
fragment-threshold 128
This command defines the identifier for the FR bundle when used in an MLFR bundle. The no form of this command resets the value to null.
null
This command configures the Local Management Interface (LMI) type for Frame Relay interfaces. LMIs are sets of enhancements to the basic Frame Relay specification.
The no form of this command changes the LMI type back to the default value.
itu
This command sets the Frame Relay interface into the DCE, DTE, or Bidirectional mode of LMI operation. The DTE mode causes the router to send status inquiries over the interface. The DCE mode causes the router to respond to status inquiries. In bidirectional mode, the router performs both DTE and DCE operation over the FR interface. The bidirectional mode applies to the ANSI and ITU LMI types only.
This feature is used when two routers are connected back-to-back, running frame relay encapsulation.
mode dte
This command sets the DTE full status polling interval for the Frame Relay Local Management Interface (LMI). The number specifies the frequency at which inquiries expect a full status report.
The no form of this command returns the n391dte counter to the default value.
n391dte 6
This command sets the DCE error threshold for the Frame Relay Local Management Interface (LMI).
The threshold specifies the number of errors needed to bring down a link.
The no form of this command returns the n392dce counter to the default value.
n392dce 3
This command sets the DTE error threshold for the Frame Relay Local Management Interface (LMI).
The count specifies the number of errors needed to bring down a link.
The no form of this command returns the n392dte counter to the default value.
n392dte 3
This command sets the DCE monitored event count for the Frame Relay Local Management Interface (LMI).
The no form of this command returns the n393dce counter to the default value.
n393dce 4
This command sets the DTE monitored event count for the Frame Relay Local Management Interface (LMI).
The no form of this command returns the n393dte counter to the default value.
n393dte 4
This command sets the DTE keepalive timer for the Frame Relay Local Management Interface (LMI).
This number specifies the period at which the DTE sends out a keepalive response request to the DCE and updates status depending on the DTE error threshold value.
The no form of this command returns the t391dte keepalive timer to the default value.
t391dte 10
This command sets the DCE keepalive timer for the Frame Relay Local Management Interface (LMI).
This number specifies the period at which the DCE checks for keepalive responses from the DTE and updates status depending on the DCE error threshold value.
The no form of this command returns the t392dce keepalive timer to the default value.
t392dce 15
TDM commands are only supported on the 7750 SR.
This command enables the context to configure DS-1/E-1 and DS-3/E-3 parameters for a port on a channelized MDA T1/E1. This context cannot be accessed on non-channelized MDAs.
TDM is a mechanism to divide the bandwidth of a stream into separate channels or time slots by assigning each stream a different time slot in a set. TDM repeatedly transmits a fixed sequence of time slots over a single transmission channel. Each individual data stream is reassembled at the receiving end based on the timing.
This command enables the context to configure digital signal level 1 (DS-1) frame parameters. The T-Carrier system was the first successful system that supported digitized voice transmission. The original transmission rate (1.544 Mb/s) in the T-1 (DS-1) line is commonly used by Internet service providers (ISPs) to connect to the Internet.
North America uses the T-Carrier system while Europe uses the E-Carrier system of transmission, using multiples of the DS- system. Digital signals are carried inside the carrier systems.
T-1 transmits DS-1-formatted data at 1.544 Mb/s through the network. The corresponding European carrier is E-1 with a data rate of 2.048 Mb/s. E-1 and T-1 (DS-1) can be interconnected for international use.
The no form of this command disables DS-1 capabilities.
This command enables the context to configure DS-3 parameters. DS-3 lines provide a speed of 44.736 Mb/s and is also frequently used by service providers. DS-3 lines carry 28 DS-1 signals and a 44.736 Mb/s data rate.
A DS-3 connection typically supports data rates of about 43 Mb/s. A T-3 line actually consists of 672 individual channels, each supporting 64 kb/s. T-3 lines are used mainly by Service Providers to connect to the Internet backbone and for the backbone itself.
Depending on the MDA type, the DS-3 parameters must be disabled if clear channel is enabled by default (for example, on the m12-ds3 MDA). Clear channel is a channel that uses out-of-band signaling, not in-band signaling, so the channel's entire bit rate is available. Channelization must be explicitly specified. Note that if DS-3 nodes are provisioned on a channelized SONET/SDH MDA you must provision the parent STS-1 SONET/STM0 SDH path first.
North America uses the T-Carrier system while Europe uses the E-Carrier system of transmission, using multiples of the DS system. Digital signals are carried inside the carrier systems.
The no form of this command disables DS-3 capabilities.
This command enables the context to configure E-1 parameters. E-1 is a basic time division multiplexing scheme used to carry digital circuits. It is also a standard WAN digital communication format designed to operate over copper facilities at a rate of 2.048 Mb/s.
North America uses the T-Carrier system while Europe uses the E-Carrier system of transmission, using multiples of the DS system. Digital signals are carried inside the carrier systems.
The no form of this command disables E-1 capabilities.
This command enables the context to configure E-3 parameters. E-3 lines provide a speed of 44.736 Mb/s and is also frequently used by service providers. E-3 lines carry 16 E-1 signals with a data rate of 34.368 Mb/s.
An E-3 connection typically supports data rates of about 43 Mb/s. An E-3 line actually consists of 672 individual channels, each supporting 64 kb/s. E-3 lines are used mainly by Service Providers to connect to the Internet backbone and for the backbone itself.
Depending on the MDA type, the E-3 parameters must be disabled if clear channel is enabled by default (for example, on the m12-ds3e3 MDA). Clear channel is a channel that uses out-of-band signaling, not in-band signaling, so the channel's entire bit rate is available. Channelization must be explicitly specified. Note that if E-3 nodes are provisioned on the channelized SONET/SDH MDA you must provision the parent STS-1 SONET/STM0 SDH path first.
North America uses the T-Carrier system while Europe uses the E-Carrier system of transmission, using multiples of the DS system. Digital signals are carried inside the carrier systems.
The no form of this command disables E-3 capabilities.
This command initiates or restarts a Bit Error Rate Test (BERT) on the associated DS-1/E-1 or DS-3/E-3 circuit.
The associated DS-1, E-1, DS-3, or E-3 must be in a shutdown (admin down) state to initiate this test.
The no form of this command terminates the BERT test if it has not yet completed.
Notes:
bert 2e3
This command inserts bit errors into a running BERT test. The number of errors inserted corresponds to 10^(-rate). A rate of 0 will cause 1 error in every bit transmitted. A rate of 7 will cause an error rate of 10^(-7), or 1 error in every one billion bits transmitted.
The no command disables the insertion of bit errors into the bit error rate test stream.
Note that this command is not saved in the router configuration between boots.
no bit-error-insertion
This command specifies line buildout (cable length) for physical DS-1/DS-3 ports.
buildout short
This command configures link dampening timers in 100s of milliseconds. This guards against reporting excessive interface transitions. This is implemented by not advertising subsequent transitions of the interface to upper layer protocols until the configured timer has expired.
This command is only supported on the m4-chds3-as, m12-chds3-as, and c4-ds3 MDAs.
no hold-time
This command applies only to a DS-1 port configured with a 'long' buildout (see the buildout command). Specify the number of decibels the transmission signal decreases over the line.
For 'short' buildout the following values are valid:
lboNotApplicable — Not applicable
For 'long' buildout the following values are valid:
lbo0dB | For 0 dB |
lboNeg7p5dB | For -7.5 dB |
lboNeg15p0dB | For -15.0 dB |
lboNeg22p5dB | For -22.5 dB |
The default for 'short' build out is 'NotApplicable' while the default for 'long' buildout is 'lbo0dB'.
This command applies only to a DS-1 port configured with a 'short' buildout. The length command configures the length of the line (in feet). For line lengths longer than 655 feet, configure the DS-1 port buildout as 'long'.
For 'long' buildout the following values are valid:
NotApplicable — Not applicable
For 'short' buildout the following values are valid:
The default for 'long' buildout is 'NotApplicable' while the default for 'short' buildout is '0 to 133'.
This command creates DS0 channel groups in a channelized DS1 or E1 circuit. Channel groups cannot be further subdivided.
The no form of this command deletes the specified DS1 or E1 channel.
This command specifies that the associated DS-3 is a channelized DS-3 with DS-1/E-1 sub-channels. Depending on the MDA type, the DS-3 parameters must be disabled if clear channel is the default (for example, on m12-ds3 MDAs). Clear channel is a channel that uses out-of-band signaling, not in-band signaling, so the channel's entire bit rate is available. Channelization must be explicitly specified. The no form specifies the associated DS-3 is a clear channel circuit and cannot contain sub-channel DS-1s/E-1s. The sub-channels must be deleted first before the no command is executed.
no channelized.
This command enables the context to configure Cisco HDLC parameters. Cisco HDLC is an encapsulation protocol that governs information transfer. It specifies a data encapsulation method on synchronous serial links using frame characters and checksums.
Cisco HDLC monitors line status on a serial interface by exchanging keepalive request messages with peer network devices. It also allows routers to discover IP addresses of neighbors by exchanging Serial Link Address Resolution Protocol (SLARP) address-request and address-response messages with peer network.
Only IES SAPs (including SAPs in VPRN service) can provision a Cisco-HDLC-capable configuration.
This command configures the clock to be used for transmission of data out towards the line. The options are to use the locally recovered clock from the line's receive data stream, the node central reference, or an adaptively recovered clock using the received packets.
The following tables show MDAs that support loop timing at DS3/E3 and DS1/E1 channelization options.
TDM DS3/E3 | LoopTimed | Default |
Channelized OC-12 | No | node-timed |
Channelized OC-3 | No | node-timed |
Channelized DS3/E3 | No | node-timed |
Channelized ASAP OC-12 | Yes | node-timed |
Channelized ASAP OC-3 | Yes | node-timed |
Channelized ASAP DS3/E3 | Yes | node-timed |
CES OC-3 | Yes | node-timed |
TDM DS1/E1 | LoopTimed | Default |
Channelized OC-12 | Yes | loop-timed |
Channelized OC-3 | Yes | loop-timed |
Channelized DS3/E3 | Yes | loop-timed |
Channelized ASAP OC-12 | Yes | loop-timed |
Channelized ASAP OC-3 | Yes | loop-timed |
Channelized ASAP DS3/E3 | Yes | loop-timed |
CES OC-3 | Yes | loop-timed |
This command configures the precision of the cyclic redundancy check (CRC).
crc 16 for non-ATM channel groups configured under DS-1, E-1 and for non-ATM E-3 and DS-3 channel/ports.
crc 32 for ATM channel-groups configured under DS-1 and E-1, and for ATM E-3 and DS-3 channels/ports. The default cannot be changed.
This command configures the number of keepalive intervals that must pass without receiving a keepalive packet before the link is declared down. It is expected that the nodes at the two endpoints of the cHDLC link are provisioned with the same values.
down-count 3
This command configures the encapsulation method used to on the specified port, path, or channel. This parameter can be set on both access and network ports.
When the encap-type is set to ATM the CRC, timeslots, scrambling (if applicable), and idle-cycle-flags are set to ATM defaults respectively. When the encap-type is changed from ATM, those parameters are set to their non-ATM defaults.
When the encap-type is ATM, ATM sub-layer verification (GR-1248-CORE, Generic Requirements for Operations of ATM Network Elements (NEs)) is automatically enabled. When ATM PLCP cell mapping is used, the results of this verification include:
When ATM direct cell mapping is used, the result of the verification includes:
The no form of this command restores the default.
encap-type bcp-null
This command enables the associated DS-3 interface to respond to remote loop signals.
The DS-3 far-end alarm and control (FEAC) signal is used to send alarm or status information from the far-end terminal back to the local terminal. DS-3 loopbacks at the far-end terminal from the local terminal are initiated.
The no form of this command prevents the associated DS-3 interface from responding to remote loop signals.
no feac-loop-respond
This command specifies the DS-1 framing to be used with the associated channel.
framing esf
This command specifies the E-1 framing to be used with the associated channel.
framing g704
This command specifies DS-3 framing for the associated DS-3 port or channel.
framing c-bit
This command specifies E-3 framing for the associated E-3 port or channel.
for E-3 non-ATM: framing g751 and cannot be changed. for E-3 ATM: framing g832 and cannot be changed.
This command configures the value that the HDLC TDM DS-0, E-1, E-3, DS-1, or DS-3 interface transmits during idle cycles. For ATM ports/channels/channel-groups, the configuration does not apply and only the no form is accepted.
The no form of this command reverts the idle cycle flag to the default value.
flags (0x7E)
no flags (ATM)
This command defines the data pattern to be transmitted when the circuit emulation service is not operational or temporarily experiences under-run conditions. This command is only valid for cesopsn and cesopsn-cas circuit emulation services. It is blocked with a warning for unstructured (satop) circuit emulation services.
idle-payload-fill all-ones
This command defines the signaling pattern to be transmitted when the circuit emulation service is not operational or temporarily experiences under-run conditions. This command is only valid for cesopsn-cas circuit emulation services. It is blocked with a warning for unstructured (satop) and basic cesopsn circuit emulation services.
idle-signal-fill all-ones
This command causes all data bits to be inverted, to guarantee ones density. Typically used with AMI line encoding.
no invert-data
This command puts the specified port or channel into a loopback mode.
The corresponding port or channel must be in a shutdown state in order for the loopback mode to be enabled. The upper level port or channel or parallel channels should not be affected by the loopback mode
Note that this command is not saved in the router configuration between boots.
The no form of this command disables the specified type of loopback.
no loopback
This command puts the specified port or channel into a loopback mode.
The corresponding port or channel must be in a shutdown state in order for the loopback mode to be enabled. The upper level port or channel or parallel channels should not be affected by the loopback mode.
Note that this command is not saved in the router configuration between boots.
The no form of this command disables the specified type of loopback.
no loopback
This command puts the specified port or channel into a loopback mode.
The corresponding port or channel must be in a shutdown state in order for the loopback mode to be enabled. The upper level port or channel or parallel channels should not be affected by the loopback mode
Note that this command is not saved in the router configuration between boots.
The no form of this command disables the specified type of loopback.
no loopback
This command configures the maintenance data link (MDL) message for a DS-3/E-3.
This command is only applicable if the DS-3/E-3 is using C-bit framing (see the framing command).
The no form of this command removes the MDL string association and stops the transmission of any IDs.
no mdl
This command enables the transmission of an MDL message on a DS-3/E-3 over channelized interface.
The no form of this command disables transmission of the specified message or all messages.
no mdl-transmit
This command configures the national use bits.
When enabled, the channel responds to requests for remote loopbacks.
no remote-loop-respond — The port will not respond.
This command enables logging of DS-1/DS-3 or E-1/E-3 alarms for DS-1/DS-3 or E-1/E-3 ports or channels.
The no form of this command disables logging of the specified alarms.
This command activates the signal mode on the channel. When enabled, it uses routing information to direct the payload of voice or data to its destination.
The no form of this command reverts to the default value.
no signal-mode
This command sets the speed of the DS-0 channels used in the associated channel-group.
speed 64
This command configures the channel service unit (CSU) compatibility mode to interoperate with existing DS-3 subrate standards.
This configuration applies only for non-channelized DS-3s on ASAP TDM MDAs.
The no form of this command remove the subrate functionality.
no subrate
This command configures the line signal degradation bit error rate (BER) and line signal failure thresholds.
Line signal (b2) bit interleaved parity error rates are measured and when they cross either the degradation or failure thresholds alarms are raised (see the report-alarm command), furthermore if the failure threshold is crossed the link will be set to operationally down.
The no form of this command reverts to the default value.
threshold ber-sd rate 5 threshold ber-sf rate 50
This command defines the list of DS-0 timeslots to be used in the DS-1 or E-1 channel-group. The timeslots are defaulted as defined below when encap-type is set to/from atm. ATM channel groups do not allow timeslots to change.
The no form of this command removes DS-0 timeslots from a channel group.
This command creates the context for configuring Link Aggregation Group (LAG) attributes.
A LAG can be used to group multiple ports into one logical link. The aggregation of multiple physical links allows for load sharing and offers seamless redundancy. If one of the links fails, traffic will be redistributed over the remaining links.
Note that all ports in a LAG group must have autonegotiation set to Limited or Disabled.
There are three possible settings for autonegotiation:
When autonegotiation is enabled on a port, the link attempts to automatically negotiate the link speed and duplex parameters. If autonegotiation is enabled, the configured duplex and speed parameters are ignored.
When auto-negotiation is disabled on a port, the port does not attempt to autonegotiate and will only operate at the speed and duplex settings configured for the port. Note that disabling auto-negotiation on gigabit ports is not allowed as the IEEE 802.3 specification for gigabit Ethernet requires gigabyte be enabled for far end fault indication.
If the autonegotiate limited keyword option is specified the port will autonegotiate but will only advertise a specific speed and duplex. The speed and duplex advertised are the speed and duplex settings configured for the port. One use for limited mode is for multi-speed gigabit ports to force gigabit operation while keeping auto-negotiation is enabled for compliance with IEEE 801.3.
The system requires that auto-negotiation be disabled or limited for ports in a LAG to guarantee a specific port speed.
LAG ID, ranging from 1 to 64, support up to 64 LAG members, and LAG ID above 64, support 32 LAG members.
The no form of this command deletes the LAG from the configuration. Deleting a LAG can only be performed while the LAG is administratively shut down. Any dependencies such as IP-Interfaces configurations must be removed from the configuration before issuing the no lag command.
This command enables the context to configure access parameters.
This command specifies how the LAG SAP queue and virtual scheduler buffering and rate parameters are adapted over multiple active XMAs/MDAs. This command applies only to access LAGs.
adapt-qos distribute
When this parameter is configured, all SAPs on this LAG which have explicit hashing configured, the egress HQos and HPol (including queues, policers, schedulers and arbiters) will receive 100% of the configured bandwidth (essentially operating in adapt-qos link mode). For any Multi-Service-Sites assigned to such a LAG, bandwidth will continue to be divided according to adapt-qos distribute mode.
A LAG instance that is currently in adapt-qos link mode may be placed at any time in port-fair mode. Similarly, a LAG instance that is currently in adapt-qos port-fair mode may be placed at any time in link mode. However, a LAG instance in adapt-qos distribute mode may not be placed into port-fair (or link) mode while QoS objects are associated with the LAG instance. To move from distribute to port-fair mode it is necessary to remove all QoS objects from the LAG instance.
This command specifies the admin bandwidth assigned to SAPs, ports and LAGs which is used by SAP bandwidth CAC. The admin bandwidth on a port or LAG can be over or under booked using the booking-factor command.
Port or LAG: Increasing the port or LAG admin bandwidth will increase the available admin bandwidth on that port or LAG. Reducing the port or LAG admin bandwidth will reduce the available admin bandwidth on that port or LAG, however, if the reduction of available admin bandwidth would cause it to be insufficient to cover the sum of the current SAP admin bandwidth on the port or LAG then the command will fail.
The no version of the command reverts to the default value.
no bandwidth
This command specifies the booking factor applied against the port or LAG administrator bandwidth by SAP administrator bandwidth CAC.
The service manager keeps track of the available administrator bandwidth for each port or LAG configured with an administrator bandwidth. The port or LAG available administrator bandwidth is adjusted by the user configured booking factor, allowing the port or LAG bandwidth to be over or under booked.
If the booking factor is increased then available administrator bandwidth on the port or LAG increases. If the booking factor is decreased then available administrator bandwidth on the port or LAG decreases, however, if the reduction of available administrator bandwidth would cause it to be insufficient to cover the sum of the current SAP administrator bandwidth on the port or LAG then the command fails.
The no form of this command reverts to the default value.
booking-factor 100
This command specifies whether a more efficient method of queue allocation for LAG SAPs should be utilized.
The no form of this command disables the method of queue allocation for LAG SAPs.
This command specifies whether a more efficient method of queue allocation for LAG SAPs should be utilized.
The no form of this command disables the method of queue allocation for LAG SAPs.
This command enables optimized SAP instance allocation on a LAG. When enabled, SAP instance is allocated per each FP the LAG links exits on instead of per each LAG port.
The no form of this command disables optimized SAP instance allocation.
no per-fp-sap-instance
This command creates the bfd context and enables BFD over the associated LAG links.
This command enables the BFD context and enables BFD over LAG links. Additional parameter configuration is required to make BFD over LAG links operational. Normally, BFD session timers are automatically extended during soft-reset operation on the IOMs and IMMs to avoid BFD sessions timing out and causing protocol events. However, in some cases this behavior is not desired as it could delay fast re-route transitions if they are in place. The optional disable-soft-reset-extension keyword allows this behavior to be disabled so that the BFD timers are not automatically extended.
no disable-soft-reset-extension
This command specifies the address family for the micro-BFD session over the associated LAG links.
family ipv4
This command enables restricting micro-BFD sessions to links in LACP state distributing.
The no form of this command disables restricting micro-BFD sessions
no bfd-on-distributing-only
This command is used to specify the IPv4 or IPv6 address of the BFD source.
The no form of this command removes this address from the configuration.
no local-ip-address
ipv4-address: | a.b.c.d |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x:-[0 to FFFF]H | |
d: [0 to 255]D |
This command specifies the maximum amount of time the router will continue to forward traffic over a link after the micro-BFD sessions has transitioned to a Down state because it received an ADMIN-DOWN state from the far-end. This timer provide the administrator the configured amount of time to disable or de-provision the micro-BFD session on the local node before forwarding is halted over the associated link(s).
The no form of this command removes the time interval from the configuration.
max-admin-down-time 0
This command specifies the maximum amount of time the router will forward traffic over a link that has transitioned from Standby to Active, before the micro-BFD session must be fully established (Up state).
The no form of this command returns the timer value to the default (0) which indicates that forwarding will not start until the BFD session is established.
max-setup-time infinite
This command specifies the detect multiplier used for a micro-BFD session over the associated LAG links. If a BFD control packet is not received for a period of multiplier X receive-interval then the session is declared down.
The no form of this command removes multiplier from the configuration.
multiplier 3
This command specifies the receive timer used for micro-BFD session over the associated LAG links.
The no form of this command removes the receive timer from the configuration.
receive-interval 100
This command specifies the IPv4 or IPv6 address of the BFD destination.
The no form of this command removes this address from the configuration.
no remote-ip-address
ipv4-address: | a.b.c.d |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x:-[0 to FFFF]H | |
d: [0 to 255]D |
This command specifies the transmit timer used for micro-BFD session over the associated LAG links.
The no form of this command removes the transmit timer from the configuration.
transmit-interval 100
This command disables micro BFD sessions for this address family.
The no form of this command re-enables micro BFD sessions for this address family.
shutdown
This command enables OSPF or ISIS costing of a Link Aggregation Group (LAG) based on the available aggregated, operational bandwidth.
The path cost is dynamically calculated based on the interface bandwidth. OSPF path cost can be changed through the interface metric or the reference bandwidth.
If dynamic cost is configured, then costing is applied based on the total number of links configured and the cost advertised is inversely proportional to the number of links available at the time. This is provided that the number of links that are up exceeds the configured LAG threshold value at which time the configured threshold action determines if, and at what cost, this LAG will be advertised.
For example: Assume a physical link in OSPF has a cost associated with it of 100, and the LAG consists of four physical links. The cost associated with the logical link is 25. If one link fails then the cost would automatically be adjusted to 33.
If dynamic cost is not configured and OSPF autocost is configured, then costing is applied based on the total number of links configured. This cost will remain static provided the number of links that are up exceeds the configured LAG threshold value at which time the configured threshold action determines if and at what cost this LAG will be advertised.
If dynamic-cost is configured and OSPF autocost is not configured, the cost is determined by the cost configured on the OSPF metric provided the number of links available exceeds the configured LAG threshold value at which time the configured threshold action determines if this LAG will be advertised.
If neither dynamic-cost nor OSPF autocost are configured, the cost advertised is determined by the cost configured on the OSPF metric provided the number of links available exceeds the configured LAG threshold value at which time the configured threshold action determines if this LAG will be advertised.
The no form of this command removes dynamic costing from the LAG.
no dynamic-cost
This command configures the encapsulation method used to distinguish customer traffic on a LAG. The encapsulation type is configurable on a LAG port. The LAG port and the port member encapsulation types must match when adding a port member.
If the encapsulation type of the LAG port is changed, the encapsulation type on all the port members will also change. The encapsulation type can be changed on the LAG port only if there is no interface associated with it. If the MTU is set to a non-default value, it will be reset to the default value when the encap type is changed.
The no form of this command restores the default.
encap-type null — All traffic on the port belongs to a single service or VLAN.
This command controls the operational status of the LAG or the IGP cost based on the sum of the hash-weight values for the active links in the LAG.
The no form of this command disables the hash weight threshold.
This command specifies the timer, in tenths of seconds, which controls the delay between detecting that a LAG is down (all active ports are down) and reporting it to the higher levels.
A non-zero value can be configured, for example, when active/standby signaling is used in a 1:1 fashion to avoid informing higher levels during the small time interval between detecting that the LAG is down and the time needed to activate the standby link.
no hold-time
This command specifies the LACP mode for aggregated Ethernet interfaces only. This command enables the LACP protocol. Per the IEEE 802.1ax standard, the Link Aggregation Control Protocol (LACP) provides a standardized means for exchanging information between Partner Systems on a link to allow their Link Aggregation Control instances to reach agreement on the identity of the Link Aggregation Group to which the link belongs, move the link to that Link Aggregation Group, and enable its transmission and reception functions in an orderly manner.
Note that if any of the parameters are omitted, the existing configuration is preserved. The default parameter values are used if a parameter is never explicitly configured.
no lacp
This command configures the type of multiplexing machine control to be used in a LAG with LACP in active/passive modes.
The no form of this command disables multiplexing machine control.
lacp-mux-control coupled
This command specifies the interval signaled to the peer and tells the peer at which rate it should transmit.
lacp-xmit-interval fast
This command enables LACP message transmission on standby links.
The no form of this command disables LACP message transmission. This command should be disabled for compatibility when using active/standby groups. This forces a timeout of the standby links by the peer. Use the no form if the peer does not implement the correct behavior regarding the lacp sync bit.
lacp-xmit-stdby
This command creates the link map profile that can to control which LAG ports are to be used on egress or enables the configuration context for previously created link map profile. link map profiles are not created by default.
The no form of this command, deletes the specified link map profile.
This command designates one of the configured ports of the LAG to be used on egress as either a primary or secondary link (based on the option selected) by all SAPs and network interfaces that use this LAG link map profile.
Links are part of a profile When a link is added or deleted, all SAPs and network interfaces that use this link-map-profile may be re-hashed if required.
The no form of this command deletes the link from this LAG link mapping profile. A port must be deleted from all LAG link profiles if it is to be deleted from the LAG.
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 defines the failure mode for egress traffic of SAPs/network interfaces that use this link-map-profile when neither primary nor secondary links of this profile are available.
failure-mode per-link-hash
This command adds ports to a Link Aggregation Group (LAG).
The port configuration of the first port added to the LAG is used as a basis to compare to subsequently added ports. If a discrepancy is found with a newly added port, that port will not be added to the LAG.
Multiple (space separated) ports can be added or removed from the LAG link assuming the maximum of number of ports is not exceeded.
Ports that are part of a LAG must be configured with auto-negotiate limited or disabled.
The no form of this command removes ports from the LAG.
No ports are defined as members of a LAG.
Note that the maximum number of ports in a LAG depends on platform-type, hardware deployed, and SR OS software release. Adding a port over the maximum allowed per given router/switch is blocked. Some platforms support double port scale for some port types on LAGs with lag-id in the range of 1 to 64 inclusive. Up to 16 ports can be specified in a single statement, up to 64 ports total.
slot/mda/port | ||
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 to b |
This command configures per-link-hashing on a LAG. When enabled, SAPs/subscribers/interfaces are hashed on LAG egress to a single LAG link.
The no form of this command disables per-link-hashing on a LAG.
no per-link-hash
This command configures the behavior for the Link Aggregation Group (LAG) if the number of operational links is equal to or below a threshold level.
Nokia recommends that operators use the weight-threshold or hash-weight-threshold command instead of the port-threshold command to control LAG operational status. For example, when 10GE and 100GE ports are mixed in a LAG, each 10GE port will have a weight of 1, while each 100GE port will have a weight of 10.
The weight-threshold or hash-weight-threshold command can also be used for LAGs with all ports of equal speed to allow a common operational model. For example, each port has a weight of 1 to mimic port-threshold and its related configuration.
The no form of this command reverts to the default values.
port-threshold 0 action down
This command configures the port type for the link aggregation group.
The no form of this command reverts to the default.
port-type standard
This command enables mixed port-speed LAG operation.
Parameter specified with the command defines what type of ports are allowed in a LAG, and what is the weight of each port for total LAG weight calculation.
The no form specifies that all LAG links must be of the same speed. Each link weight is 1. The no form disables mixed port-speed LAG operation if there are no mixed-speed links. Issuing this command automatically checks that all links are the same speed and re-calibrates the link weights. If all links are not the same speed, no-port-weight-speed is rejected.
no port-weight-speed
For existing LAGs:
no port-weight-speed can be changed to port-weight-speed 1 when the LAG consists of only 1GE links. no port-weight-speed can be changed to port-weight-speed 10 when the LAG consists of only 10GE links.
port-weight-speed 1 or port-weight-speed 10 can be changed to no port-weight-speed in service, when all links of the LAG are 1GE, 10GE, 40GE, or 100GE.
All other configuration changes require shutdown of the LAG and removal of all ports first.
This command specifies which selection criteria should be used to select the active sub-group. If there is a tie for highest-count or highest-weight, the LAG will prefer the port with the lowest priority. If that does not break the tie, the currently active subgroup will stay active (that is, non-revertive behavior).
The no form of this command reverts to the default value.
selection-criteria highest-count
not specified | Equivalent to specifying a value of 0. Specifies no delay and to switchover immediately to a new candidate active sub-group. |
0 to 2000 | Integer specifying the timer value in 10ths of a second. |
infinite | Do not switchover from existing active sub-group if the subgroup remains UP. Manual switchover possible using tools perform lag force command. |
This command specifies how the state of a member port is signaled to the remote side when the status corresponding to this member port has the standby value.
standby-signaling lacp
This command configures the behavior for the Link Aggregation Group (LAG) if the total weight of operational links is equal to or below the configured threshold level. The command can be used for mixed port-speed LAGs and for LAGs with all ports of equal speed.
The no form of this command disables the weight-threshold operation in LAG.
weight-threshold 0 action down
This command configures a G.8031 protected Ethernet tunnel.
The no form of this command deletes the Ethernet tunnel specified by the tunnel-id.
This command configures eth-tunnel CCM dampening timers.
The no form of this command reverts to the default.
no ccm-hold-time
This command adds a text description for the eth-tunnel.
The no form of this command removes the text description.
Eth-tunnel
This command enables the context to configure Ethernet parameters.
This command configures the encapsulation method.
encap-type dot1q
This command assigns a specific MAC address to an Ethernet port, Link Aggregation Group (LAG), Ethernet tunnel or BCP-enabled port or sub-port. Only one MAC address can be assigned to a port. When multiple mac commands are entered, the last command overwrites the previous command. When the command is issued while the port is operational, IP will issue an ARP, if appropriate, and BPDUs are sent with the new MAC address.
The no form of this command returns the MAC address to the default value.
A default MAC address is assigned by the system from the chassis MAC address pool.
This command configures eth-tunnel load sharing parameters.
This command configures eth-tunnel load sharing access parameters
This command configures how the Ethernet Tunnel group SAP queue and virtual scheduler buffering and rate parameters are adapted over multiple active MDAs.
The no form of this command reverts the default.
no adapt-qos
A LAG instance that is currently in adapt-qos link mode may be placed at any time in port-fair mode. Similarly, a LAG instance currently in adapt-qos port-fair mode may be placed at any time in link mode. However, a LAG instance in adapt-qos distribute mode may not be placed into port-fair (or link) mode while QoS objects are associated with the LAG instance. To move from distribute to port-fair mode either remove all QoS objects from the LAG instance or remove all member ports from the LAG instance.
This command configures whether a more efficient method of queue allocation for Ethernet Tunnel Group SAPs should be utilized.
The no form of this command reverts the default.
no per-fp-ing-queuing
This command configures the behavior for the eth-tunnel if the number of operational members is equal to or below a threshold level
no path-threshold
This command configures the model used for determining which members are actively receiving and transmitting data.
The no form of this command reverts to the default.
protection-type g8031-1to1
This command configure how long to wait before switching back to the primary path after it has been restored to Ethernet tunnel.
The no form of this command disables the revert behavior, effectively setting the revert time to zero.
no revert-time
This command configures one of the two paths supported under the Ethernet tunnel. Although the values indicate 1 to 8, only two paths, 1 and 2, are currently supported.
The no form of this command removes the path from under the Ethernet tunnel. If this is the last path, the associated SAP needs to be un-configured before the path can be deleted.
no path
This command configures a text description for the path.
The no form of this command removes the text description.
no description
This command associates a port with the path defined under the Ethernet tunnel. If the operator wants to replace an existing member port or control tag, the whole path needs to be shutdown first. The alternate path will be activated as a result keeping traffic interruption to a minimum. Then the whole path must be deleted, the alternate path precedence modified to primary before re-creating the new path.
The following port-level configuration needs to be the same across the two member ports of an Ethernet tunnel:
The Ethernet tunnel will inherit the configuration from the first member port for these parameters. Additional member port that is added must have the same configuration.
The operator is allowed to update these port parameters only if the port is the sole member of an Ethernet tunnel. This means that in the example below, the operator needs to remove port 1/1/4 and port 1/1/5 before being allowed to modify 1/1/1 for the above parameters.
The no form of this command is used just to indicate that a member is not configured. The procedure described above, based on the no path command must be used to un-configure/change the member port assigned to the path.
no member
This command specifies the VLAN-ID to be used for Ethernet CFM and G.8031 control plane exchanges. If the operator wants to replace an existing control-tag, the parent path needs to be in shutdown state, then deleted and recreated before a new control-tag can be specified.
The no form of this command is used just to indicate that a control-tag is not configured. The procedure described above, based on ‘no path’ command must be used to un-configure/change the control-tag assigned to the path.
no control-tag
This command specifies the precedence to be used for the path. Only two precedence options are supported: primary and secondary.
The no form of this command sets the precedence to the default value.
precedence secondary
This command enables the context to configure ETH-CFM parameters.
This command provisions an 802.1ag maintenance endpoint (MEP).
The no form of this command reverts to the default values.
This command enables the Ethernet ring control on the MEP. The use of control-mep command is mandatory for a ring. MEP detection of failure using CCM may be enabled or disabled independently of the control mep.
The no form of this command disables Ethernet ring control.
This command enables the generation of CCM messages.
The no form of this command disables the generation of CCM messages.
This command specifies the priority value for CCMs and LTMs transmitted by the MEP.
The no form of this command removes the priority value from the configuration.
The highest priority on the bridge-port.
This command enables eth-test functionality on MEP. For this test to work, operators need to configure ETH-test parameters on both sender and receiver nodes. The ETH-test then can be done using the following OAM commands:
oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
A check is done for both the provisioning and test to ensure the MEP is an Y.1731 MEP (MEP provisioned with domain format none, association format icc-based). If not, the operation fails. An error message in the CLI and SNMP will indicate the problem.
This command configures the test pattern for eth-test frames.
The no form of this command removes the values from the configuration.
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
low-priority-defect remErrXcon
allDef | DefRDICCM, DefMACstatus, DefRemoteCCM, DefErrorCCM |
macRemErrXcon | Only DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM |
remErrXcon | Only DefRemoteCCM, DefErrorCCM, and DefXconCCM |
errXcon | Only DefErrorCCM and DefXconCCM |
xcon | Only DefXconCCM; or |
noXcon | No defects DefXcon or lower are to be reported |
This command specifies the MAC address of the MEP.
The no form of this command reverts the MAC address of the MEP back to that of the port (if the MEP is on a SAP) or the bridge (if the MEP is on a spoke SDP).
This command enables the usage of the CC state by the Ethernet tunnel manager for consideration in the protection algorithm. The use of control-mep command is recommended if fast failure detection is required, especially when Link Layer OAM does not provide the required detection time.
The no form of this command disables the use of the CC state by the Ethernet tunnel manager.
no control-mep
This command administratively enables/disables the MEP.
The no form of this command enables the MEP.
shutdown
This command administratively enables/disables the path.
The no form of this command enables the path.
shutdown
This command enables the context to configure 802.1ag CFM parameters.
This command provisions the maintenance endpoint (MEP).
The no form of this command reverts to the default values.
This command enables the reception of AIS messages.
The no form of this command reverts to the default values.
This command configures the client maintenance entity group (MEG) level(s) to use for AIS message generation. Up to 7 levels can be provisioned with the restriction that the client MEG level must be higher than the local MEG level. Only the lowest client MEG level will be used for facility MEPs.
The no form of this command reverts to the default values.
This command enables and disables the generation of AIS PDUs based on the associated endpoint state.
This command specifies the transmission interval of AIS messages in seconds.
The no form of this command reverts to the default values.
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
low-priority-defect remErrXcon
allDef | DefRDICCM, DefMACstatus, DefRemoteCCM, DefErrorCCM |
macRemErrXcon | Only DefMACstatus, DefRemoteCCM, DefErrorCCM, and DefXconCCM |
remErrXcon | Only DefRemoteCCM, DefErrorCCM, and DefXconCCM |
errXcon | Only DefErrorCCM and DefXconCCM |
xcon | Only DefXconCCM; or |
noXcon | No defects DefXcon or lower are to be reported |
This command specifies the priority of the AIS messages generated by the node.
The no form of this command reverts to the default values.
This command configures the MEP alarm notification parameter.
This command configures the Fault Notification Generation (FNG) alarm time.
This command configure the Fault Notification Generation (FNG) reset time.
This command enables the generation of CCM messages.
The no form of this command disables the generation of CCM messages.
This command specifies the priority of the CCM and LTM messages transmitted by the MEP. Since CCM does not apply to the Router Facility MEP only the LTM priority is of value under that context.
The no form of this command reverts to the default values.
no ccm-ltm-priority
This command inserts additional padding in the CCM packets.
The no form of this command reverts to the default.
This command allows the receiving MEP to ignore the specified TLVs in CCM PDU. Ignored TLVs will be reported as absent and will have no impact on the MEP state machine.
The no form of this command causes the receiving MEP will process all recognized TLVs in the CCM PDU.
This command enables the collection of statistics on the facility MEPs. This command is an object under the Facility MEP. This is at a different level of the hierarchy than collection of lmm statistics for service SAPs and MPLS SDP Bindings. The show mep command can be used to determine is the Facility MEP is collecting stats.
The no form of this command disables and deletes the counters for this SAP, Binding or facility.
no collect-lmm-stats
This command configures the reception of Client Signal Fail (CSF) message parameters.
This command configures the multiplier used for timing out the CSF.
This command enables the context to configure Ethernet Bandwidth Notification (ETH-BN) message handling.
This command enables the reception and processing of eth-bn messages and the retrieval and processing of the current bandwidth field for inclusion in dynamic egress rate adjustments.
The received rate is an Layer 2 rate, and is expected to be in Mb/s. If this rate is a link rate (including preamble, start frame delimiter, and inter-frame gap), this would require the use of network egress queue groups (configured in the configure qos queue-group-templates egress queue-group "qg1" queue 1 packet-byte-offset add 20). The packet-byte-offset is not supported for default network queues.
no receive
This command sets the pace for update messages to and from the eth-cfm subsystem to the QoS subsystem. The most recent update messages are held by the ETH-CFM subsystem, but the most recent update is held until the expiration of the pacing timer.
For this test to work, operators need to configure ETH-test parameters on both sender and receiver nodes. The ETH-test then can be done using the following OAM commands:
oam eth-cfm eth-test mac-address mep mep-id domain md-index association ma-index [priority priority] [data-length data-length]
The no form of this command disables eth-test capabilities.
This command specifies the lowest priority defect that is allowed to generate a fault alarm.
bit-error-threshold 1
This command specifies the test pattern of the ETH-TEST frames. This does not have to be configured the same on the sender and the receiver.
The no form of this command reverts to the default values.
test-pattern all-zeros
This command enables the context to configure Nokia ETH-CFM Grace and ITU-T Y.1731 ETH-ED expected defect functional parameters.
This command enables the context to configure ITU-T Y.1731 ETH-ED expected defect functional parameters.
This command limits the duration of the received ETH-ED expected defect window to the lower value of either the received value from the peer or this parameter.
The no form of this command removes the limitation, and any valid defect window value received from a peer MEP in the ETH-ED PDU will be used.
no max-rx-defect-window
This command sets the priority bits and determines the forwarding class based on the mapping of priority to FC.
The no form of this command disables the local priority configuration and sets the priority to the ccm-ltm-priority associated with this MEP.
no priority
This command enables the reception and processing of the ITU-T Y.1731 ETH-ED PDU on the MEP.
The no form of this command disables the reception of the ITU-T Y.1731 ETH-ED PDU on the MEP.
rx-eth-ed
This command enables the transmission of the ITU-T Y.1731 ETH-ED PDU from the MEP when a system soft reset notification is received for one or more cards.
The config>eth-cfm>system>grace-tx-enable command must be configured to instruct the system that the node is capable of transmitting expected defect windows to the peers. Only one form of ETH-CFM grace (Nokia ETH-CFM Grace or ITU-T Y.1731 ETH-ED) may be transmitted.
The no form of this command disables the transmission of the ITU-T Y.1731 ETH-ED PDU from the MEP.
no tx-eth-ed
This command enables the context to configure Nokia ETH-CFM Grace functional parameters.
This command enables the reception and processing of the Nokia ETH-CFM Grace PDU on the MEP.
The Nokia Grace function is a vendor-specific PDU that informs MEP peers that the local node may be entering a period of expected defect.
The no form of this command disables the reception of the Nokia ETH-CFM Grace PDU on the MEP.
rx-eth-vsm-grace
This command enables the transmission of the Nokia ETH-CFM Grace PDU from the MEP when a system soft reset notification is received for one or more cards.
The Nokia Grace function is a vendor-specific PDU that informs MEP peers that the local node may be entering a period of expected defect.
The config>eth-cfm>system>grace-tx-enable command must be configured to instruct the system that the node is capable of transmitting expected defect windows to the peers. Only one form of ETH-CFM grace (Nokia ETH-CFM Grace or ITU-T Y.1731 ETH-ED) may be transmitted.
The no form of this command disables the transmission of the Nokia ETH-CFM Grace PDU from the MEP.
tx-eth-vsm-grace
This command specifies the lowest priority defect that is allowed to generate a fault alarm. This setting is also used to determine the fault state of the MEP which, when enabled to do so, causes a network reaction.
low-priority-defect macRemErrXcon
This command specifies the MAC address of the MEP.
The no form of this command reverts to the MAC address of the MEP back to the default, that of the port, since this is SAP based.
no mac-address
This command enables one way delay threshold time limit.
one-way-delay-threshold 3
Allows the facility MEP to move from alarming only to network actionable function. This means a facility MEP will not merely report the defect conditions but will be able to action based on the transition of the MEP state. Without this command the facility MEP will only monitor and report and conditions of the MEP do not affect related services.
no facility-fault
Allows the individual service SAPs to react to changes in the tunnel MEP state. When tunnel-fault accept is configured at the service level, the SAP will react according to the service type, Epipe will set the operational flag and VPLS, IES and VPRN SAP operational state will become down on failure or up on clear. This command triggers the OAM mapping functions to mate SAPs and bindings in an Epipe service as well as setting the operational flag. If AIS generation is the requirement for the Epipe services this command is not required. See the ais-enable command under the config>service>epipe>sap>eth-cfm>ais-enable context for more details. This works in conjunction with the tunnel-fault accept on the individual SAPs. Both must be set to accept to react to the tunnel MEP state. By default the service level command is “ignore” and the SAP level command is “accept”. This means simply changing the service level command to “accept” will enable the feature for all SAPs. This is not required for Epipe services that only wish to generate AIS on failure.
tunnel-fault ignore (Service Level)
tunnel-fault accept (SAP Level for Epipe and VPLS)
This command allows the user to perform redundancy operations.
Associated commands include the following in the admin>redundancy context:
This command configures BGP multi-homing parameters.
This command specifies how long the service manager waits after a node reboot before running the MH procedures. The boot-timer value should be configured to allow for the BGP sessions to come up and for the NLRI information to be refreshed/exchanged. The boot-timer is activated after the no shutdown command for a MH site executed from configuration. Upon activation, the boot-timer is compared with the system up-time for the node. If the boot timer is higher than the up-time, then the service manager waits for the boot-timer-sys-up-time, then starts the site-activation-timer.
The no form of this command sets the value to 10.
no boot-timer
This command defines the amount of time the service manager will keep the local sites in standby status, waiting for BGP updates from remote PEs before running the DF election algorithm to decide whether the site should be unblocked. The timer is started when one of the following event occurs only if the site is operationally up:
The no form of this command sets the value to 2.
no site-activation-timer
This command configures the BGP multi-homing site minimum down time. When set to a non-zero value, if the site goes operationally down it will remain operationally down for at least the length of time configured for the site-min-down-timer, regardless of whether other state changes would have caused it to go operationally up. This timer is restarted every time that the site transitions from up to down.
The above operation is optimized in the following circumstances:
The no form of this command reverts to a value of 0.
no site-min-down-timer
This command enables the context to configure multi-chassis parameters.
Use this command to configure up to 20 multi-chassis redundancy peers. Note that it is only for mc-lag (20) not for mc-sync (4).
ipv4-address: | a.b.c.d |
ipv6-address: | x:x:x:x:x:x:x:x (eight 16-bit pieces) |
x:x:x:x:x:x:d.d.d.d | |
x:-[0 to FFFF]H | |
d: [0 to 255]D |
This command configures the authentication key used between this node and the multi-chassis peer. The authentication key can be any combination of letters or numbers. The no form of this command removes the authentication key.
no authentication-key
This command specifies that the endpoint is multi-chassis. This value should be the same on both MC-EP peers for the pseudowires that must be part of the same group.
The no form of this command removes the endpoint from the MC-EP. Single chassis behavior applies.
no mc-endpoint
This command enables the use of bi-directional forwarding (BFD) to control the state of the associated protocol interface. By enabling BFD on a given protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set via the BFD command under the IP interface.
The no form of this command disables BFD.
no bfd-enable
This command configures the boot timer interval. This command applies only when the node reboots. It specifies the time the MC-EP protocol keeps trying to establish a connection before assuming a failure of the remote peer. This is different from the keep-alive mechanism which is used just after the peer-peer communication was established. After this time interval passed all the mc-endpoints configured under services will revert to single chassis behavior, activating the best local PW.
The no form of this command sets the interval to default.
no boot-timer
This command specifies the number of keep-alive intervals that the local node will wait for packets from the MC-EP peer before assuming failure. After this time interval passed the all the mc-endpoints configured under services will revert to single chassis behavior, activating the best local pseudowire.
The no form of this command sets the multiplier to default value
no hold-on-neighbor-failure
This command sets the interval at which keep-alive messages are exchanged between two systems participating in MC-EP when bfd is not enabled or is down. These fast keep-alive messages are used to determine remote-node failure and the interval is set in deciseconds.
The no form of this command sets the interval to default value
no keep-alive-interval
This command configures the passive mode behavior for the MC-EP protocol. When in passive mode the MC-EP pair will be dormant until two of the pseudowires in a MC-EP will be signaled as active by the remote PEs, being assumed that the remote pair is configured with regular MC-EP. As soon as more than one pseudowire is active, dormant MC-EP pair will activate. It will use the regular exchange to select the best pseudowire between the active ones and it will block the Rx and Tx directions of the other pseudowires.
The no form of this command will disable the passive mode behavior.
no passive-mode
This command allows the operator to set the system priority. The peer configured with the lowest value is chosen to be the Master. If more than one peer has the same lowest system-priority value, then the one with the lowest system-id (chassis MAC address) is chosen as the Master.
The no form of this command sets the system priority to 0.
no system-priority
This command enables the context to configure multi-chassis LAG operations and related parameters.
The no form of this command administratively disables multi-chassis LAG. MC-LAG can be issued only when mc-lag is shutdown.
no mc-lag
This command specifies the interval that the standby node will wait for packets from the active node before assuming a redundant-neighbor node failure. This delay in switch-over operation is required to accommodate different factors influencing node failure detection rate, such as IGP convergence, or HA switch-over times and to prevent the standby node to take action prematurely.
The no form of this command sets this parameter to default value.
hold-on-neighbor-failure 3
This command sets the interval at which keep-alive messages are exchanged between two systems participating in MC-LAG. These keep-alive messages are used to determine remote-node failure and the interval is set in deciseconds.
The no form of this command sets the interval to default value.
keep-alive-interval 10
This command defines a LAG which is forming a redundant-pair for MC-LAG with a LAG configured on the given peer. The same LAG group can be defined only in the scope of 1 peer. In order MC-LAG to become operational, all parameters (lacp-key, system-id, system-priority) must be configured the same on both nodes of the same redundant pair.
The partner system (the system connected to all links forming MC-LAG) will consider all ports using the same lacp-key, system-id, system-priority as the part of the same LAG. In order to achieve this in MC operation, both redundant-pair nodes have to be configured with the same values. In case of the mismatch, MC-LAG is kept in oper-down status.
Note that the correct CLI command to enable MC LAG for a LAG in standby-signaling power-off mode is lag lag-id [remote-lag remote-lag-id]. In the CLI help output, the first three forms are used to enable MC LAG for a LAG in LACP mode. MC LAG is disabled (regardless of the mode) for a given LAG with no lag lag-id.
This command specifies a peer name.
no peer-name
This command specifies the source address used to communicate with the multi-chassis peer.
This command enables the context to configure synchronization parameters.
no sync
This command specifies whether IGMP protocol information should be synchronized with the multi-chassis peer.
no igmp
This command specifies whether IGMP snooping information should be synchronized with the multi-chassis peer.
no igmp-snooping
This command specifies whether MLD protocol information should be synchronized with the multi-chassis peer.
no mld
This command is not supported. It is not blocked for backwards-compatibility reasons but has no effect on the system if configured.
no mld-snooping
This command enables the context to synchronize NAT groups.
The no form of this command disables the feature.
nat
This command enables multi-chassis synchronization (MCS) for NAT. The health of the nat-group is exchanged between the chassis and one of the nodes that is elected as active for the nat-group, while the other node becomes a standby node.
The no form of this command reverts to the default.
no nat-group
This command specifies whether PIM snooping for IPv4 information should be synchronized with the multi-chassis peer. Entering only pim-snooping (without any parameter) results in the synchronization being applicable only to SAPs.
no pim-snooping
This command specifies the port to be synchronized with the multi-chassis peer and a synchronization tag to be used while synchronizing this port with the multi-chassis peer.
slot/mda/port | ||
lag-id | lag-id | |
lag | keyword | |
id | 1 to 800 | |
pw-id | pw-id | |
pw | keyword | |
id | 1 to 10239 | |
eth-sat-id (7950 XRS only) | esat-id/slot/port | |
esat | keyword | |
id | 1 to 20 |
This command configures a range of encapsulation values.
Dot1Q | start-tag-end-tag |
start-tag | 0 to 4094 |
end-tag | 0 to 4094 |
QinQ | qtag1.start-qtag2-qtag1.end-qtag2-start-qtag1.*-end-qtag1.* |
qtag1 | 1 to 4094 |
start-qtag1 | 1 to 4094 |
en-qtag1 | 1 to 4094 |
start-qtag2 | 0 to 4094 |
end-qtag2 | 0 to 4094 |
This command specifies whether subscriber routed redundancy protocol (SRRP) information should be synchronized with the multi-chassis peer.
no srrp
This command specifies whether subscriber management information should be synchronized with the multi-chassis peer.
no sub-mgmt
This command enables the context to configure the multi-chassis ring parameters.
no mc-ring
This command configures a multi-chassis ring.
This command enables the context to configure multi-chassis ring inband control path parameters.
This command specifies the destination IP address used in the inband control connection. If the address is not configured, the ring cannot become operational.
no dst-ip
This command specifies the name of the IP interface used for the inband control connection. If the name is not configured, the ring cannot become operational.
no interface
This command specifies the service ID if the interface used for the inband control connection belongs to a VPRN service. If not specified, the service-id is zero and the interface must belong to the Base router. This command supersedes the configuration of a service name.
The no form of this command removes the service id from the IBC configuration.
no service-id
This command specifies the service name if the interface used for the inband control connection belongs to a VPRN service. If not specified the interface must belong to the Base router. This command supersedes the configuration of a service ID.
The no form of this command removes the service name from the IBC configuration.
no service-name
This command specifies the set of upper-VLAN IDs associated with the SAPs that belong to path B with respect to load-sharing. All other SAPs belong to path A.
If not specified, the default is an empty set.
This command configures a MCR b-path VLAN range.
This command specifies the set of upper-VLAN IDs associated with the SAPs that are to be excluded from control by the multi-chassis ring.
If not specified, the default is an empty set.
This command specifies the unique name of a multi-chassis ring access node.
This command enables the context to configure node connectivity check parameters.
This command specifies the polling interval of the ring-node connectivity verification of this ring node.
interval 5
This command specifies the service ID of the SAP used for the ring-node connectivity verification of this ring node. This command supersedes the configuration of a service name.
The no form of this command removes the service id from the CV configuration.
no service-id
This command specifies the service name of the SAP used for ring-node connectivity verification of this ring node. This command supersedes the configuration of a service ID.
The no form of this command removes the service name from the CV configuration.
no service-id
This command specifies the source IP address used in the ring-node connectivity verification of this ring node.
no src-ip
This command specifies the source MAC address used for the Ring-Node Connectivity Verification of this ring node.
A value of all zeros (000000000000 H (0:0:0:0:0:0)) specifies that the MAC address of the system management processor (CPM) is used.
no src-mac
This command specifies the VLAN tag used for the Ring-node Connectivity Verification of this ring node. It is only meaningful if the value of service ID is not zero. A zero value means that no VLAN tag is configured.
no vlan
vlan-encap: | dot1q | qtag, * |
qinq | qtag1.qtag2, qtag1.*, 0.* | |
qtag | 0 to 4094 | |
qtag1 | 1 to 4094 | |
qtag2 | 0 to 4094 |
This command enables the context to configure switch fabric parameters.
This command sets the number of SFMs that are permitted to fail before the system goes into SFM overload state. This command is only applicable on the 7750 SR-7s and the 7750 SR-14s. Users can select the SFM limit based on the number possible for the system minus one. For the 7750 SR-7s this is a value of 3 and for the 7750 SR-14s this is a value of 7.
For networks that can accommodate more SFM failures than the default value, this command allows the selection of the number of SFMs to fail prior to the system going into SFM overload state.
The no form of this command reverts the threshold to the default value.
7750 SR-7s: sfm-loss-threshold 1
7750 SR-14s: sfm-loss-threshold 2
This command dumps multicast path manager CPM information.
The following output is an example of CPM information.