This command configures the high watermark for the weighted average utilization of the shared buffer space in the from-subscriber buffer pool for each ISA. When a buffer pool is not in the overload state and the wa-shared buffer utilization for an ISA crosses above the high watermark value in the ISA from-subscriber buffer pool enters an overload state and an overload notification is raised.

The no form of this command reverts to the default.

This command configures the low watermark for the weighted average utilization of the shared buffer space in the from-subscriber buffer pool. When a buffer pool is in an overloaded state and the wa-shared buffer utilization for an ISA drops below low watermark value ISA from-subscriber buffer pool leaves the overload state and a is sent to indicate the overload state has cleared.

The no form of this command reverts to the default.

This command configures a pause, in seconds, at the start of the boot process which allows system initialization to be interrupted at the console.

When system initialization is interrupted the operator is allowed to manually override the parameters defined in the boot option file (BOF).

Only one wait command can be defined in the BOF.

This command configures the time to wait for a BFD to come up in seconds. This timer is applicable to SR-TE LSPs, including auto-LSPs and PCE-initiated LSPs, as well as RSVP-TE LSPs. In case of SR-TE LSPs, this timer takes effect if BFD does not come up, or BFD goes from up to down. The timer is started when BFD is first enabled on a path or BFD transitions from up to down. When the timer expires if BFD is not yet come up, then the path is torn down by removing it from the TTM and the IOM and the retry timer is started.

In case of RSVP-TE LSPs, the timer controls the following:

The no form of this command sets the timer to its default value.

This command configures the WTR timer. It determines how long to wait until the active path of an MPLS-TP LSP is restored to the working path following the clearing of a defect on the working path. It is applicable to revertive mode, only.

This command configures the time for the Wait to Restore timer. A previously failed input reference must be valid for the time specified before it is used for either the BITSout or the central clock input reference.

The no form of this command disables the timer.

This command configures the Wireless Application Protocol (WAP) 1.X.

This command enables Oversubscribed Multi-Chassis Redundancy (OMCR) model where subscriber hosts are synchronized between the two chassis only in the control plane and are kept there (as part of the Multi-Chassis Synchronization (MCS) state) until the switchover occurs. Link or nodal failure will trigger the switchover at which point the subscriber hosts are being fully instantiated in the control and the forwarding plane. This approach allows oversubscription of the resources in the central standby (or protecting) node that is backing-up several active nodes. The total number of protected subscribers in the OMCR cluster exceeds the forwarding capacity of the protecting node. This is achievable by not fully occupying the resources for the subscriber hosts until the failure occurs.

The restoration times depend on the amount of the subscriber hosts that are affected by the switchover and it is related to the time needed for the full instantiation of the subscribers in the forwarding plane.

Although this command is configured on a peer level, the warm-standby property is a nodal characteristic. In other words, mixing of N:1 and 1:1 (hot standby) mode in the central standby node is not supported. Consequently all peers on the central standby node must be configured for warm-standby (N:1), or all peers must be configured for hot-standby (1:1) by omitting the warm-standby keyword from the configuration.

The peer of the central backup node is not aware of the redundancy model supported. In in other words, the peer of the central-backup node does not know whether it peers with a warm-standby peer or host-standby-peer.

This command enables/disables the generation of a specific dynamic data service script debugging event output: warnings.

This command enables/disables the generation of a specific script debugging event output: warnings.

This command configures the interval between consecutive watchdog messages. On the first timeout of the DWR, the SR OS node will resend the DWR message. The peer is still operational during this time. On the second timeout, the peer transitions into a suspended mode and the peer-failover procedure is initiated (if the peer-failover is enabled by configuration). In this state the peer is not used for new transactions. At the same time, the cooldown procedure is started which means that it would take three successful DWR/DWA message exchanges to reinstate the peer in a fully operation state.

On the third timeout, the peer is removed and its connection is closed.

This command is applicable only to legacy implementations of Diameter base in the SR OS.

The no form of this command reverts to the default.

Watchdog messages are used to verify liveliness of a Diameter peer. A single watchdog messages will be sent to a peer in case that no traffic is received from it within a configured watchdog-timer. This watchdog request message will solicit a watchdog answer message from the peer. If no traffic (watchdog answer or otherwise) is received from the peer in response to watchdog request while the watchdog timer is running, the peer will be put in suspicious state and a peer failover routine will be triggered.

The peer will be closed after it has been in suspicious mode for the duration of one more watchdog-timer interval without receiving any traffic from it.

Once the peer is recovered, it will take 3 successful exchanges of diameter watchdog messages (DWR/DWA) for the peer to becomes used again in Diameter forwarding. This behavior is described in RFC 3539, §3.4.1, Authentication, Authorization and Accounting (AAA) Transport Profile).

This command is not applicable to legacy implementations of Diameter base in the SR OS.

The no form of this command removes the watchdog timer value from the configuration.

This command enables the context to configure watermark parameters.

This command enables the context to configure ISA watermark notifications.

This command configures the watermarks used to determine if a new prefix should be allocated or an old prefix should be removed. A new prefix is allocated when the total usage level for the ISA reaches the high watermark. A prefix is freed if no addresses are currently in use and the usage level without this prefix would be below the low watermark.

The no form of this command resets the watermarks to its default values of 95% high and 90% low.

This command configures the watermarks for this NAT pool.

This command configures the ISA NAT group watermarks.

This command configures the port usage watermarks for the NAT policy.

This command configures the session watermarks for the NAT or residential firewall policy.

This command validates whether or not the port supports Wavetracker.

This command enables the context to configure the URL filter policy using web-service filtering. The operator must configure the web service, host name, DNS server to use, the AA interface VLAN ID, and provision the category profiles.

This command configures the amount of shared memory to be used by the web service URL filter cache.

This command specifies which days of the week that the schedule will fire on. Multiple days of the week can be specified. When multiple days are configured, each of them will cause the schedule to occur. If a weekday is configured without configuring the month, weekday, day-of-month, and minute, the event will not execute.

Using the weekday command as well as the day-of month command will cause the script to run twice. For example, consider that today is Monday January 1. If Tuesday January 5 is configured, the script will run on Tuesday (tomorrow) as well as January 5 (Friday).

The no form of this command removes the specified weekday from the configuration.

This command configures the initial (and also the maximum) weight of the preferred connection and the value with which it can change.

The no form of this command resets the weight to the default.

VCs within the VP tunnel are serviced by a single scheduler assigned to each VP tunnel. VCs within the shaped VP tunnel are degraded from the originally assigned service category to a common UBR service category (default traffic descriptor). Scheduling between VCs are based on WRR with a weight parameter that can be explicitly configured in the ATM traffic descriptor profile. If weight is not specifically configured, the defaults are taken.

The explicitly configured weight parameter is honored only on the ATM MDA in the max16k-vc mode. On all other ATM capable MDAs (ASAP or ATM MDA in max8k-vc mode), the weight parameter is ignored.

The no form of this command reverts to the default.

This command configures the WRR weight scheduling parameter for each MLPPP class queue for this profile.

This command configures the WRR weight scheduling parameter for each Frame Relay scheduling class queue for this profile.

The weight parameter is not applicable to class 0 because the class 0 queue is serviced by the scheduler with the highest priority all the time over all other class queues.

After Class 0 queue packets are serviced, Class 1 queue packets are the next priority up to a rate of MIR. Beyond MIR, Class1, Class2, and Class 3 queues are serviced in proportion to the configured weights.

This command associates a weight value with a segment list of a statically-defined segment routing policy in order to achieve weighted ECMP behavior. Weight is an optional parameter.

When any segment-list in the active policy has a weight greater than 1, traffic matching the policy will be load-balanced across the segment lists according to their relative weight values.

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

This command creates a context to configure an event set threshold within a lag-port-down priority control event. The weight-down command defines a sub-node within the lag-port-down event and is uniquely identified with the lag-ports-down-weight parameter. Each weight-down node within the same lag-port-down event node must have a unique lag-ports-down-weight value. Each weight-down node has its own priority command that takes effect whenever that node represents the current threshold. A single LAG can use either weight-threshold or port threshold. The command is required for correct operation on mixed port-speed LAGs and can be used for non-mixed port-speed LAGs as well.

The total number of sub-nodes (uniquely identified by the lag-ports-down-weight parameter) allowed in the system is 2048.

A weight-down node is not required for each possible number of ports that could be down. The active threshold is always the closest lower threshold.

The no form of the command deletes the event set threshold. The threshold may be removed at any time. If the removed threshold is the current active threshold, the event set thresholds must be re-evaluated after removal.

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.

This command enables weighted ECMP for packets using tunnels that a VPRN automatically binds to. When weighted ECMP is enabled, packets are sprayed across LSPs in the ECMP according to the outcome of the hash algorithm and the configured load-balancing-weight of each LSP.

The no form of this command disables weighted ECMP for next hop tunnel selection.

This command enables weighted load-balancing for IS-IS ECMP routes in the VPRN instance. Weighted ECMP can be performed only when all the next hops are associated with the same neighbor and all of them are configured with (non-zero) load-balancing weights. The weighted ECMP support for IS-IS ECMP routes applies to both IPv4 and IPv6.

The no form of this command restores regular ECMP spraying of packets to IS-IS route destinations.

This command enables weighted ECMP on LDP using RSVP LSPs. LDP labeled packets are sprayed in proportion to the configured load-balancing-weight of RSVP LSPs.

The no form of this command removes weighted ECMP.

This command enables the weighted load-balancing, or weighted ECMP, over MPLS LSP.

When this command is enabled, packets of IGP, BGP, and static route prefixes resolved to a set of ECMP tunnel next-hops are sprayed proportionally to the weights configured for each MPLS LSP in the ECMP set.

Weighted load-balancing over MPLS LSP is supported in the following forwarding contexts:

IGP computes the normalized weight for each prefix tunnel next-hop. IGP updates the route in RTM with the set of tunnel next-hops and normalized weights. RTM downloads the information to IOM for inclusion in the FIB.

If one or more LSPs in the ECMP set of a prefix do not have a weight configured, the regular ECMP spraying for the prefix will be performed.

The weight assigned to an LSP impacts only the forwarding decision, not the routing decision. In other words, it does not change the selection of the set of ECMP tunnel next-hops of a prefix when more next-hops exist than the value of the router ecmp option. Once the set of tunnel next-hops is selected, the LSP weight is used to modulate the amount of packets forwarded over each next-hop. It also does not change the hash routine, but only the spraying of the flows over the tunnel next-hops is modified to reflect the normalized weight of each tunnel next-hop.

The no form of this command resumes regular ECMP spraying of packets of IGP, BGP, and static route prefixes over MPLS LSP.

This command enables weighted load balancing in the base router instance for certain types of OSPF, IS-IS, and static routes with equal-cost multipath (ECMP) next hops.

For OSPF and static routes, this command only applies to IPv4 routes where all the next hops are tunnel next hops corresponding to MPLS LSPs with configured load-balancing weights. Weighted load balancing over MPLS LSPs is supported in the following cases:

For IS-IS routes, in addition to enabling the behavior described for OSPF and static routes, this command also allows weighted load balancing when all the ECMP next hops are interfaces with configured load-balancing weights. The interface-level weighted ECMP support for IS-IS applies to both IPv4 and IPv6.

If one or more LSPs or interfaces in the ECMP set of a prefix do not have a load-balancing weight configured, the regular ECMP spraying for the prefix will be performed.

The no form of this command restores regular ECMP spraying of packets to static and IGP route destinations.

This command enables weighted ECMP on an SDP. When weighted ECMP is enabled, packets from services using the SDP are sprayed across LSPs in the ECMP set to the SDP far end according to the outcome of the hash algorithm and the configured load-balancing weight of each LSP.

The no version of this command disables weighted ECMP for next-hop tunnel selection.

This command enables weighted ECMP for next-hop tunnel selection for 6PE. When weighted ECMP is enabled, the RSVP-TE tunnel used to forward 6PE packets to the ECMP next hop is chosen according to the outcome of the hash on the packet at the normalized load-balancing weight of the tunnel.

The no version of this command disables weighted ECMP for next-hop tunnel selection for 6PE.

This command enables the exclusive use of wide metrics in the LSPs for the level number. Narrow metrics can have values between 1 and 63. IS-IS can generate two TLVs, one for the adjacency and one for the IP prefix. In order to support traffic engineering, wider metrics are required. When wide metrics are used, a second pair of TLVs are added, again, one for the adjacency and one for the IP prefix.

By default, both sets of TLVs are generated. When wide-metrics-only is configured, IS-IS only generates the pair of TLVs with wide metrics for that level.

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

This command enables the exclusive use of wide metrics in the LSPs for the level number. Narrow metrics can have values between 1 and 63. IS-IS can generate two TLVs, one for the adjacency and one for the IP prefix. In order to support traffic engineering, wider metrics are required. When wide metrics are used, a second pair of TLVs are added, again, one for the adjacency and one for the IP prefix.

By default, both sets of TLVs are generated. When wide-metrics-only is configured, IS-IS only generates the pair of TLVs with wide metrics for that level.

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

This command determines display terminal width.

This command configures the set number of columns displayed on screen.

When enabled, this command indicates the number of UEs connected to the tunnel to which the radius message applies to. For session/host accounting this is the tunnel of the associated UE. For queue-instance accounting this attribute will not be included.

The no form of this command disables including the RADIUS Alc-Num-Attached-UEs VSA.

This command enables the inclusion of the 802.11 Received Signal Strength Indication attribute.

The no form of this command reverts to the default.

This command enables including the Alc-RSSI.

This command enables including the per-SSID VLAN ID in a Alc-Wlan-SSID-VLAN VSA.

The no form of this command disables including the per-SSID VLAN ID in Alc-Wlan-SSID-VLAN VSA.

This command enables RFC 6625 (C-*, C-*) S-PMSI functionality for NG-MVPN. When enabled, (C-*, C-*) S-PMSI is used instead of I-PMSI for this MVPN. Wildcard S-PMSI uses the I-PMSI LSP template.

auto-rp-discovery cannot be enabled together with mdt-type sender-only or mdt-type receiver-only, or wildcard-spmsi configurations.

The no form disables the (C-*, C-*) S-PMSI functionality.

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

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

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.

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 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 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 specifies the integrity of the sample window. A percentage value that suggests the measurement has enough samples (integrity) to be considered representative for that sample window. The configured percentage considers the interval of the test PDUs, and the length of the sample window to determine the number of packets required in the sample.

(((window-integrity %) x (sample-window length (s) x pps per test (interval)).

Ensure that the percentage and the combination of sample window and packet per second per test interval produces the desired results.

If the number of samples in the sample window are equal to or greater than the computed number of required samples, then the value has integrity and the suspect flag is set to false for that streamed result.

If the count is less than the computed number of required samples, then the suspect flag is set to true for that streamed result.

Regardless of the integrity, the average values are streamed. It is up to the higher level systems to interrogate the suspect flag and determine if the value that is set should be used, discarded, or reported separately.

The no form of this command reverts to the default.

This command specifies sliding window size over which the symbols are sampled to detect signal failure or signal degraded conditions.

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.

This command enables the context to configure WLAN GW parameters.

This node contains all the parameters to set up specific call-trace debug sessions for WLAN-GW. The no form of this command will stop all configured WLAN-GW traces.

This command enables the wlan-gw context to configure li-source related parameters.

This command configures the identifier of the WLAN Gateway ISA group that processes the cross-connect.

The no form of this command removes the NAT group IP from the cross-connect configuration.

This command specifies the WLAN GW group that is used for HLE services.

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

This command enables matching on UEs, based on the WLAN-GW group ID and, optionally, the specific ISA member they are installed on.

The no form of this command disables matching on the WLAN-GW group.

This command creates a WLAN GW group that contains a set of ISAs to be used in WLAN-GW functionality. A WLAN-GW group can also be used where a NAT group is expected. The WLAN-GW group ID shares the same number space with the NAT group.

At most, one WLAN-GW group may be configured.

The optional redundancy parameter determines the provisioning and redundancy mode.

The no form of this command removes the group.

This command specifies the ID of the wlan-gw-group that the wlan-gw gateway binds to.

The no form of this command removes the value from the wlan-gw configuration.

This command specifies the ISA WLAN gateway group.

This command configures a working bundle that is part of this BPGrp.

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.

This command specifies the working path for a GMPLS LSP. One working path must be specified for each GMPLS LSP. The path-name parameter must correspond to a path defined under config>router>gmpls>path.

The no form of the command removes the working-path definition.

This command creates or edits the working path for an MPLS-TP LSP. At least one working path (but not more than one working path) must be created for an MPLS-TP LSP. If MPLS-TP linear protection is also configured, then this is the path that is used as the default working path for the LSP, and it must be created prior to the protect path. The working-tp-path can only be deleted if no protect-tp-path exists for the LSP.

The following commands are applicable to the working-tp-path: lsp-num, in-label, out-label, mep, shutdown.

This command enables the context to configure WPP parameters.

This command enables the context to configure Wireless Portal Protocol (WPP) parameters.

The no form of the command removes configuration under WPP.

This command enables the context to configure WPP debugging parameters.

This command configures a memory filter log to log until full or to store the most recent log entries (circular buffer).

Specifying wrap-around configures the memory filter log to store the most recent filter log entries (circular buffer). When the log is full, the oldest filter log entries are overwritten with new entries.

The no form of the command configures the memory filter log to accept filter log entries until full. When the memory filter log is full, filter logging for the log filter ID ceases.

This command allows the configuration of WRED per queue with the following options:

Native Hardware WRED

When the wred-queue mode native command is configured, the queue uses the WRED capabilities of FP3- and higher-based hardware. In this case, the out-of-profile and exceed-profile traffic map to the low and exceed WRED slopes specified within the slope policy, and the inplus-profile and in-profile traffic uses the MBS drop tail; this requires the slope-usage to be configured as exceed-low. The instantaneous queue depth is compared against the low and exceed slopes so the time average factor in the slope policy is ignored.

When a policy is not explicitly defined, the default slope policy is used.

When native mode is enabled for a queue, the pool and drop-tail commands are ignored; traffic mapped to a slope that is shut down will use the MBS drop tail.

This is only supported on FP3 hardware.

The no form of this command restores the queue default congestion control behavior to the queue.

Pool-per-queue WRED

When the wred-queue mode pool-per-queue command is defined and the queue ID is created, a buffer pool is created specifically for the queue and the queue obtains all buffers from that pool. The size of the pool is the same as the size of the queue. In this manner, the WRED slopes that operate based on the pool’s buffer utilization are also reacting to the congestion depth of the queue.

The size of the buffer pool is dictated by the queue’s MBS parameter. The size of the reserved CBS portion of the buffer pool is dictated by the queue’s CBS parameter. The provisioning characteristics of the mbs and cbs commands are not changed.

In the case where this is applied with WRED queue support shutdown (config>card>fp>egress>wred-queue-control>shutdown), the queue will continue to map to its default pool. If the no shutdown command is executed in the wred-queue-control context, the queue is automatically moved to its own WRED pool.

Each pool created for a queue using the wred-queue command shares buffers with all other wred-queue enabled queues on the same forwarding plane. The WRED pool buffer management behavior is defined within the config>card>fp>egress>wred-queue-control CLI context.

The WRED slopes within the pool are defined by the slope policy associated with the queue. When a policy is not explicitly defined, the default slope policy is used. The slope policy enables, disables, and defines the relative geometry of the highplus, high, low, and exceed WRED slopes in the pool. The policy also specifies the time average factor used by the pool when calculating the weighted average pool depth.

As packets attempt to enter the egress queue, they are associated with the highplus, high, low, or exceed WRED slope based on the packet’s profile. If the packet is inplus-profile, the highplus slope is used. If the packet is in-profile, the high slope is used. If the packet is out-of-profile, the low slope is used. If the packet is exceed-profile, the exceed slope is used. This mapping of packet profile to slope is enabled using the slope-usage default parameter. Each WRED slope performs a probability discard based on the current weighted average pool depth.

When wred-queue is enabled for a SAP egress queue, the queue pool and drop-tail commands are ignored; traffic mapped to a slope that is shut down will use the MBS drop tail.

The resource usage for the WRED queue pool-per-queue per forwarding plane can be seen in the tools dump resource-usage card [slot-num] fp [fp-number] output under Dynamic Q2 Wred Pools.

The no form of this command restores the generic buffer pool behavior to the queue. The WRED pool is removed from the system. The queue will be moved to the default buffer pool. The queue then uses the default congestion control behavior.

This command allows the configuration of WRED per queue with the following options:

Native Hardware WRED

When the wred-queue mode native command is configured, the queue uses the WRED capabilities of FP3- and higher-based hardware. In this case, the out and exceed-profile traffic map to the low and exceed WRED slopes specified within the slope policy, and the inplus and in-profile traffic uses the MBS drop tail; this requires the slope-usage to be configured as exceed-low. The instantaneous queue depth is compared against the low and exceed slopes so the time average factor in the slope policy is ignored.

When a policy is not explicitly defined, the default slope policy is used.

When native mode is enabled for a queue, the drop-tail commands are ignored; traffic mapped to a slope that is shut down will use the MBS drop tail.

Native hardware WRED is supported on FP3- and higher-based hardware and is ignored on FP2 hardware.

The no form of this command restores the queue default congestion control behavior to the queue.

Pool-per-queue WRED

When the wred-queue mode pool-per-queue command is defined and the queue ID is created, a buffer pool is created specifically for the queue and the queue obtains all buffers from that pool. The size of the pool is the same as the size of the queue. In this manner, the WRED slopes that operate based on the pool’s buffer utilization are also reacting to the congestion depth of the queue.

The size of the buffer pool is dictated by the queue’s mbs parameter. The size of the reserved CBS portion of the buffer pool is dictated by the queue’s cbs parameter. The provisioning characteristics of the mbs and cbs commands are not changed.

In the case where this is applied with WRED queue support shut down (config>card>fp>egress>wred-queue-control>shutdown), the queue will continue to map to its default pool. If the no shutdown command is executed in the wred-queue-control context, the queue will be automatically moved to its own WRED pool.

Each pool created for a queue using the wred-queue command shares buffers with all other wred-queue enabled queues on the same forwarding plane. The WRED pool buffer management behavior is defined within the config>card>fp>egress>wred-queue-control CLI context.

The WRED slopes within the pool are defined by the slope policy associated with the queue. When a policy is not explicitly defined, the default slope policy is used. The slope policy enables, disables, and defines the relative geometry of the highplus, high, low, and exceed WRED slopes in the pool. The policy also specifies the time average factor used by the pool when calculating the weighted average pool depth.

As packets attempt to enter the egress queue, they are associated with the highplus, high, low, or exceed WRED slope based on the packet’s profile. If the packet is inplus-profile, the highplus slope is used. If the packet is in-profile, the high slope is used. If the packet is out-of-profile, the low slope is used, and if the packet is exceed-profile, the exceed slope is used. This mapping of packet profile to slope is enabled using the slope-usage default parameter. Each WRED slope performs a probability discard based on the current weighted average pool depth.

When wred-queue is enabled for an egress queue group queue, the queue pool and drop-tail commands are ignored; traffic mapped to a slope that is shut down will use the MBS drop tail.

The resource usage for the wred-queue pool-per-queue per forwarding plane can be seen in the tools dump resource-usage card [slot-num] fp [fp-number] output under Dynamic Q2 Wred Pools.

The no form of this command restores the generic buffer pool behavior to the queue. The WRED pool is removed from the system. The queue will be moved to the default buffer pool. The queue then uses the default congestion control behavior.

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

This command enables support of the writable-running capability in the SR OS NETCONF server. If writable-running is disabled then requests that reference the running datastore as a target return an error, and when a NETCONF client establishes a new session the writable-running capability is not advertised in the SR OS <hello>.

When management-interface configuration-mode is set to model-driven, then the writable-running capability is disabled, even if writable-running is configured.

The no form of the command disables of the writable-running capability in the SR OS NETCONF server.

This command sends a console message to a specific user or to all users with active console sessions.

This command assigns a global write algorithm for the system. The write algorithm is used to display the phrase in the config file, info, show commands, and so on.

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

This command defines how the specified group ID is attached to the scheduler. A WRR group may have one of two attachment states:

A WRR group provides a weighted scheduling context for its member queues, collapsing the queues into a single scheduling class.

The following WRR membership restrictions apply:

The queue queue-id attachment command is used to define WRR group membership.

The no form of the command reverts to the default unattached attachment state for the group ID.

This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop policy to the HSMDA queue.

This command configures the HSMDA egress wrr-policy.

This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop policy to the HSMDA queue.

This command associates an existing HSMDA Weighted Round Robin (WRR) scheduling loop policy to the HSMDA queue.

This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop policy to the HSMDA queue.

This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop policy to the HSMDA queue.

This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop policy with the HSMDA queue.

This command associates an existing HSMDA weighted-round-robin (WRR) scheduling loop policy with the HSMDA queue.

This command configures a WRR policy to assign to this HSMDA egress queue.

The no form of the command removes the policy from the configuration.

This command assigns the weight value to the HSMDA queue.

The no form of this command returns the weight value for the queue to the default value.

This command configures the weighted round robin (WRR).

This command assigns the weight value to the HSMDA queue.

The no form of this command returns the weight value for the queue to the default value.

This command assigns the weight value to the HSMDA queue.

The no form of this command returns the weight value for the queue to the default value.

This command assigns the weight value to the HSMDA queue.

The no form of this command returns the weight value for the queue to the default value.

This command assigns the weight value to the HSMDA queue.

The no form of this command returns the weight value for the queue to the default value.

This command assigns the weight value to the HSMDA queue.

The no form of this command returns the weight value for the queue to the default value.

This command assigns the weight value to the HSMDA queue.

The no form of this command returns the weight value for the queue to the default value.

This command specifies the WRR weight which this queue should parent into the scheduler. The weight of each queue determines how much bandwidth that queue gets out of the total rate for the scheduling class.

The no form of the command reverts to the default.

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.