This command enables or disables P2MP FEC capability for the session.

This command configures a candidate path in the P2MP policy entry for the P2MP SR tree.

A P2MP SR policy can contain multiple candidate paths, which are redundant trees. Each candidate path represents a P2MP SR tree with its own traffic engineering constraints. Each candidate path has its own preference and the candidate path with the highest preference is the active P2MP SR tunnel.

The no form of this command removes the specified candidate path.

This command configures the identifier of an RSVP P2MP LSP. An RSVP P2MP LSP is fully identified by the combination of: <P2MP ID, tunnel ID, extended tunnel ID> part of the P2MP session object, and <tunnel sender address, LSP ID> fields in the p2mp sender_template object.

The p2mp-id is a 32-bit identifier used in the session object that remains constant over the life of the P2MP tunnel. It is unique within the scope of the ingress LER.

The no form restores the default value of this parameter.

This command is not supported on the 7450 ESS.

This command enables or disables IPv4 P2MP FEC capability on the interface.

The config>router>ldp>if-params>if>ipv6>fec-type-capability>p2mp-ipv4 command is not supported on the 7450 ESS.

This command enables or disables IPv6 P2MP FEC capability on the interface.

This command is not supported on the 7450 ESS.

This command configures the option to join P2MP LDP tree towards the multicast source for the VPRN service. If p2mp-ldp-tree-join is enabled, a PIM multicast join received on an interface is processed to join P2MP LDP LSP using the in-band signaled P2MP tree for the same multicast flow. LDP P2MP tree is setup towards the multicast source. Route to source of the multicast node is looked up from the RTM. The next-hop address for the route to source is set as the root of LDP P2MP tree.

The no form of command disables joining P2MP LDP tree for IPv4 or IPv6 or both (if both or none is specified).

This command configures the option to join the P2MP LDP tree towards the multicast source. If p2mp-ldp-tree-join is enabled, a PIM multicast join received on an interface is processed to join the P2MP LDP LSP, using the in-band signaled P2MP tree for the same multicast flow. LDP P2MP tree is set up towards the multicast source. The route to the multicast node source is looked up from the RTM. The next-hop address for the route to source is set as the root of LDP P2MP tree.

The no form of this command disables joining the P2MP LDP tree for IPv4 or IPv6 or for both (if both or none is specified).

This command performs an in-band connectivity test for an RSVP P2MP LSP. The echo request message is sent on the active P2MP instance and is replicated in the data path over all branches of the P2MP LSP instance. By default, all egress LER nodes that are leaves of the P2MP LSP instance replies to the echo request message.

LDP P2MP generic-identifier along with source IP address of the head-end node can be used to uniquely identify LDP P2MP LSP in a 7750 SR or 7950 XRS network. LDP p2mp-identifier is a mandatory parameter to test LSP ping. LDP P2MP identifier specified to configure a tunnel-interface on head-end node must be used as p2mp-identifier to test an LSP.

To reduce the scope of the echo reply messages, explicitly enter a list of addresses for the egress LER nodes that are required to reply. A maximum of five addresses can be specified in a single run of the p2mp-lsp-ping command. An LER node can parse the list of egress LER addresses and, if its address is included, it replies with an echo reply message.

The output of the command without the detail option provides a high-level summary of received error codes and success codes. The output of the command with the detail option shows a line for each replying node, as in the output of the LSP ping for a P2P LSP.

The display is delayed until all responses are received or the timer configured in the timeout parameter expires. No other CLI commands can be entered while waiting for the display. Entering A ^C aborts the ping operation. Note that p2mp-lsp-ping is not supported in a VPLS/B-VPLS PMSI context.

The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the config>test-oam>mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.

This command discovers and displays the hop-by-hop path for a source-to-leaf (S2L) sub-LSP of an RSVP P2MP LSP.

The LSP trace capability allows the user to trace the path of a single S2L path of a P2MP LSP. Its operation is like p2mp-lsp-ping, but the sender of the echo reply request message includes the downstream mapping TLV to request the downstream branch information from a branch LSR or bud LSR. The branch LSR or bud LSR also includes the downstream mapping TLV to report the information about the downstream branches of the P2MP LSP. An egress LER does not include this TLV in the echo response message.

The parameter probe-count operates in the same way as in LSP Trace on a P2P LSP. It represents the maximum number of probes sent per TTL value before stops waiting for echo reply messages. If a response is received from the traced node before reaching maximum number of probes, then no more probes are sent for the same TTL. The sender of the echo request then increments the TTL and uses the information it received in the downstream mapping TLV to start sending probes to the node downstream of the last node which replied. This continues until the egress LER for the traced S2L path replies.

Like p2mp-lsp-ping, an LSP trace probe reports on all egress LER nodes that eventually receive the echo request message, but only the traced egress LER node replies to the last probe.

Any branch LSR node or bud LSR node in the P2MP LSP tree may receive a copy of the echo request message with the TTL in the outer label expiring at this node. However, only a branch LSR or bud LSR that has a downstream branch over which the traced egress LER is reachable responds.

When a branch LSR or bud LSR responds, it sets the global return code in the echo response message to RC=14 - “See DDMAP TLV for Return Code and Return Sub-Code” and the return code in the DDMAP TLV corresponding to the outgoing interface of the branch used by the traced S2L path to RC=8 - “Label switched at stack-depth <RSC>”. Note that p2mp-lsp-trace is not supported in a VPLS/B-VPLS PMSI context.

The timestamp format to be sent, and to be expected when received in a PDU, is as configured by the config>test-oam>mpls-time-stamp-format command. If RFC 4379 (obsoleted by RFC 8029) is selected, then the timestamp is in seconds and microseconds since 1900, otherwise it is in seconds and microseconds since 1970.

This command specifies a configurable timer to abort Merge-Point (MP) node procedures for an S2L of a P2MP LSP instance. When a value higher than zero is configured for this timer, it will enter into effect anytime this node activates Merge-Point procedures for one or more P2MP LSP S2L paths. As soon an ingress interface goes operationally down, the Merge-Point node starts the abort timer. Upon expiry of the timer, MPLS will clean up all P2MP LSP S2L paths which ILM is on the failed interface and which have not already received a Path refresh over the bypass LSP.

The no form of this command disables the timer.

This command creates a P2MP policy entry for the P2MP SR tree.

The no form of this command deletes the specified policy entry.

This command enables a P2MP policy for the MVPN provider tunnel.

The no form of this command disables the P2MP policy.

This command configures the re-signal timer for a P2MP LSP instance. MPLS will request CSPF to re-compute the whole set of S2L paths of a given active P2MP instance each time the P2MP re-signal timer expires. The P2MP re-signal timer is configured separately from the P2P LSP parameter. MPLS performs a global MBB and moves each S2L sub-LSP in the instance into its new path using a new P2MP LSP ID if the global MBB is successful, regardless of the cost of the new S2L path.

This command is supported on the 7750 SR, 7950 XRS, and with VPLS only on the 7450 ESS.

The no form of this command disables the timer-based re-signaling of P2MP LSPs on this system.

This command configures a global parameter to allow the user to apply a shorter retry timer for the first try after an active LSP path went down due to a local failure or the receipt of a ResvTear. This timer is used only in the first try. Subsequent retries will continue to be governed by the existing LSP level retry-timer.

The config>router>mpls>p2mp-s2l-fast-retry command is supported on the 7750 SR, 7950 XRS, and with VPLS only on the 7450 ESS.

The no form of this command disables the timer.

This command enables P2MP SR for the MVPN provider tunnel.

The no form of this command disables P2MP SR.

Commands in this context configure P2MP SR parameters.

This command configures an ingress statistics context matching on the RSVP session name for a RSVP P2MP LSP at the egress LER.

This command is supported on the 7750 SR, 7950 XRS, and with VPLS only on the 7450 ESS.

When the ingress LER signals the path of the S2L sub-LSP, it includes the name of the LSP and that of the path in the Session Name field of the Session Attribute object in the Path message. The encoding is as follows:

Session Name: <lsp-name::path-name>, where lsp-name component is encoded as follows:

The ingress statistics CLI configuration allows the user to match either on the exact name of the P2MP LSP as configured at the ingress LER or on a context that matches on the template name and the service-id as configured at the ingress LER.

When the matching is performed on a context, the user must enter the RSVP session name string in the format “templateName-svcId” to include the LSP template name as well as the mVPN VPLS/B-VPLS service ID as configured at the ingress LER. In this case, one or more P2MP LSP instances signaled by the same ingress LER could be associated with the ingress statistics configuration and the user is provided with CLI parameter max-stats to limit the maximum number of stat indices that can be assigned to this context. If the context matches more than this value, the additional request for stat indices from this context will be rejected. A background tasks monitors the ingress statistics templates which have one or more matching LSP instances with unassigned stat index and assigns one to them as they are freed.

Note the following rules when configuring an ingress statistics context based on template matching:

If there are no stat indices available at the time the session of the P2MP LSP matching a template context is signaled and the session state installed by the egress LER, no stats are allocated to the session.

Furthermore, the assignment of stat indices to the LSP names that match the context will also be not deterministic. The latter is due to the fact that a stat index is assigned and released following the dynamics of the LSP creation or deletion by the ingress LER. For example, a multicast stream crosses the rate threshold and is moved to a newly signaled S-PMSI dedicated to this stream. Later on, the same steam crosses the threshold downwards and is moved back to the shared I-PMSI and the P2MP LSP corresponding to the S-PMSI is deleted by the ingress LER.

The no form deletes the ingress statistics context matching on the RSVP session name.

This command configures a global parameter to allow the user to apply a shorter retry timer for the first try after an active LSP path went down due to a local failure or the receipt of a ResvTear. This timer is used only in the first try. Subsequent retries will continue to be governed by the existing LSP level retry-timer.

The no form of this command disables the timer.

This command configures a timer to abort Merge-Point (MP) node procedures for a P2P LSP path. When a value higher than zero is configured for this timer, it will enter into effect anytime this node activates Merge-Point procedures for one or more P2P LSP paths. As soon an ingress interface goes operationally down, the Merge-Point node starts the abort timer. Upon expiry of the timer, MPLS will clean up all P2P LSP paths which ILM is on the failed interface and which have not already received a Path refresh over the bypass LSP.

The no form of this command disables the timer.

This command configures an ingress statistics context matching on the RSVP session name for a RSVP P2P auto-LSP at the egress LER.

When the ingress LER signals the path of a template based one-hop-p2p or mesh-p2p auto-lsp, it includes the name of the LSP and that of the path in the Session Name field of the Session Attribute object in the Path message. The encoding is as follows:

Session Name: lsp-name::path-name, where lsp-name component is encoded as follows:

P2MP LSP through the user configuration for Layer 3 multicast in global routing instance: “LspNameFromConfig”

The ingress statistics CLI configuration allows the user to match either on the exact name of the P2P auto-LSP or on a context that matches on the template name and the destination of the LSP at the ingress LER.

When the matching is performed on a context, the user must enter the RSVP session name string in the format “templateName-svcId” to include the LSP template name as well as the mVPN VPLS/B-VPLS service ID as configured at the ingress LER. In this case, one or more P2MP LSP instances signaled by the same ingress LER could be associated with the ingress statistics configuration. In this case, the user is provided with CLI parameter max-stats to limit the maximum number of stat indices which can be assigned to this context. If the context matches more than this value, the additional request for stat indices from this context will be rejected.

Note the following rules when configuring an ingress statistics context based on template matching:

If there are no stat indices available at the time the session of the P2P LSP matching a template context is signaled and the session state installed by the egress LER, no stats are allocated to the session.

Furthermore, the assignment of stat indices to the LSP names that match the context will also be not deterministic. The latter is due to the fact that a stat index is assigned and released following the dynamics of the LSP creation or deletion by the ingress LER. For example, a multicast stream crosses the rate threshold and is moved to a newly signaled S-PMSI dedicated to this stream. Later on, the same steam crosses the threshold downwards and is moved back to the shared I-PMSI and the P2MP LSP corresponding to the S-PMSI is deleted by the ingress LER.

The no form deletes the ingress statistics context matching on the RSVP session name.

This command enables debugging of GTP packets sent or received by the system’s control plane.

The no form of this command disables debugging of GTP packets.

This command enables packet debugging.

The no form of this command disables packet debugging.

This command enables debugging for specific PPPoE packets.

This command enables WPP packet debugging.

This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.

This command enables or disables debugging for PIM packets.

This command enables/disables debugging for IGMP packets.

This command enables/disables debugging for IGMP packets.

This command enables and disables debugging for specific GMPLS packets.

This command enables debugging for specific LDP packets.

The no form of the command disables the debugging output.

Commands in this context debug packets.

This command enables debugging for Multicast Source Discovery Protocol (MSDP) packets.

The no form of the command disables MSDP packet debugging.

This command enables debugging for PIM packets.

The no form of this command disables debugging for PIM packets.

This command specifies the jitter buffer size, in milliseconds, and payload size, in bytes.

This command configures a packet to be launched by the OAM find-egress tool.

The no form of this command removes the packet number value.

This command defines the ETH-CFM opcodes of interest to be debugged.

The no form of this command stops packet debugging and the collection of PDUs.

This command enables debugging for IP packets.

This command enables packet debugging.

The no form of this command disables packet debugging.

This command enables debugging for mtrace and mtrace2 packets.

This command enables debugging for mtrace and mtrace2 packets.

This command enables debugging for specific RPKI packets.

The no form of this command disables debugging for specific RPKI packets.

This command enables debugging for IS-IS packets.

The no form of the command disables debugging.

This command enables debugging for OSPF packets.

This command debugs PFCP packets that are received or sent. The no form of this command disables any PFCP packet debugging.

This command is used to modify 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. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured and the policer is managed by HQoS, however the offsets are applied to the statistics.

The no form of this command removes the per packet size modifications from the policer.

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, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter for the specified policer-id. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured; however, the offsets are applied to the statistics.

The no packet-byte-offset command is used to restore the policer’s packet-byte-offset setting to the policy defined value.

This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter for the specified policer-id. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured, however the offsets are applied to the statistics.

The no form of this command restores the policer’s packet-byte-offset setting to the policy defined value.

This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter for the specified policer-id. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured, however the offsets are applied to the statistics.

The no form of this command restores the policer’s packet-byte-offset setting to the policy defined value.

This command, within the SAP ingress and egress policer-overrides contexts, is used to override the sap-ingress and sap-egress QoS policy configured packet-byte-offset parameter for the specified policer-id. Packet byte offset settings are not included in the applied rate when (queue) frame based accounting is configured, however the offsets are applied to the statistics.

The no form of this command restores the policer’s packet-byte-offset setting to the policy defined value.

This command is used to modify 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 that 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. Packet byte offset settings are not included in the applied rate when (queue) frame-based accounting is configured and the policer is managed by HQoS; however, the offsets are applied to the statistics.

The no form of this command is used to remove per packet size modifications from the policer.

This command modifies the size of each packet handled by the queue by adding or subtracting the specified number of bytes. The actual packet size is not modified, only the size used to determine the ingress scheduling and profiling is changed. The packet-byte-offset command is an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the scheduling and profiling throughput is affected by the offset as well as the statistics (accounting) associated with the queue. The packet-byte-offset does not apply to drop statistics, received valid statistics, or the offered managed and unmanaged statistics used by Ingress Multicast Path Management.

The no form of this command removes per-packet size modifications from the queue.

This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed.

The packet-byte-offset command is meant to be an arbitrary mechanism the can be used to either add downstream frame encapsulation or remove portions of packet headers.

When a packet-byte-offset value is applied to a queue instance, it adjusts the immediate packet size. This means that the queue rates, i.e., operational PIR and CIR, and queue bucket updates use the adjusted packet size. In addition, the queue statistics will also reflect the adjusted packet size. Scheduler policy rates, which are data rates, will use the adjusted packet size.

The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, are always on-the-wire rates and thus use the actual frame size. The same applies for the agg-rate-limit on a SAP, a subscriber, or a multiservice Site (MSS) when the queue is port-parented.

When the user enables frame-based-accounting in a scheduler policy or queue-frame-based-accounting with agg-rate-limit in a port scheduler policy, the queue rate will be capped to a user-configured on-the-wire rate and the packet-byte-offset is not included. However, the offsets are applied to the statistics.

The no form of this command is used to remove per packet size modifications from the queue.

This command configures a packet byte offset for the QoS ingress queue-group policer.

This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the ingress scheduling and profiling is changed. The packet-byte-offset command is meant to be an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers. Both the scheduling and profiling throughput is affected by the offset as well as the stats (accounting) associated with the queue. The packet-byte-offset does not apply to drop statistics, received valid statistics, or the offered managed and unmanaged statistics used by Ingress Multicast Path Management.

The no form of this command is used to remove per packet size modifications from the queue.

This command is used to modify the size of each packet handled by the queue by adding or subtracting a number of bytes. The actual packet size is not modified; only the size used to determine the bucket depth impact is changed.

The packet-byte-offset command is meant to be an arbitrary mechanism that can be used to either add downstream frame encapsulation or remove portions of packet headers.

When a packet-byte-offset value is applied to a queue or policer instance, it adjusts the immediate packet size. This means that the queue rates (i.e., operational PIR and CIR) and policer or queue bucket updates use the adjusted packet size. In addition, the statistics will also reflect the adjusted packet size. Scheduler policy rates, which are data rates, will use the adjusted packet size.

The port scheduler max-rate and the priority level rates and weights, if a Weighted Scheduler Group is used, are always on-the-wire rates and thus use the actual frame size. The same applies for the agg-rate-limit on a SAP, a subscriber, or a Multiservice Site (MSS) when the queue is port-parented.

When the user enables frame-based-accounting in a scheduler policy or queue-frame-based-accounting with agg-rate-limit in a port scheduler policy, the policer or queue rate will be capped to a user-configured on-the-wire rate and the packet-byte-offset is not included; however, the offsets are applied to the statistics.

The no form of this command is used to remove per packet size modifications from the queue.

This command configures the IPv4 packet length value match criterion. The IPv4 packet length represents the total packet length including the IPv4 header and the payload.

This command configures the IPv6 packet length value match criterion. The IPv6 packet length represents the total packet length including the IPv6 header and the payload.

This command configures the packet rate on the ISA-AA when a packet rate alarm will be raised by the agent.

This command configures the packet rate on the ISA-AA when a packet rate alarm will be cleared by the agent.

The no form of this command reverts to the default.

This command enables debugging of received RTCP messages. The options for this command allow the user to filter only certain types of messages to appear in the debug traces.

This command configures a TCA for the counter capturing packet sanity hits for the specified SCTP filter. A packet sanity TCA can be created for traffic generated from the subscriber side of AA (from-sub) or for traffic generated from the network toward the AA subscriber (to-sub). The create keyword is mandatory when creating a TCA.

This command configures the maximum SNMP packet size generated by this node.

The no form of this command restores the default value.

This command specifies whether packet-too-big ICMP messages should be sent. When enabled, ICMPv6 packet-too-big messages are generated by this interface.

The no form of this command disables the sending of ICMPv6 packet-too-big messages.

This command configures the rate for Internet Control Message Protocol version 6 (ICMPv6) packet-too-big messages.

This command enables the system to send ICMPv6 PTB (Packet Too Big) messages on the private side and optionally specifies the rate.

With this command configured, the system sends PTB back if it received an IPv6 packet on the private side that is bigger than 1280 bytes and also exceeds the private MTU of the tunnel.

The ip-mtu command (under ipsec-tunnel or tunnel-template) specifies the private MTU for the ipsec-tunnel or dynamic tunnel.

The no form of this command reverts interval and message-count values to their default values.

This command configures the rate for ICMPv6 packet-too-big messages.

This command enables debugging transmitted RTCP packets.

This command specifies the RADIUS packet type filter of command debug router radius.

This command enables debugging for SRRP packets.

The no form of this command disables debugging.

This command enables or disables debugging for VRRP packets.

This command enables debugging for VRRP packets.

The no form of the command disables debugging.

This command decodes and logs all sent and received BGP packets in the debug log.

The no form of this command disables debugging.

This command enables debugging for all BMP packets.

The no form of the command disables debugging for all BMP packets.

This command enables debugging for RIP packets.

This command enables debugging for RIPng packets.

This command includes the admitted packet count in the AA subscriber's custom record and only applies to the 7750 SR.

The no form of this command excludes the admitted packet count.

This command includes the denied packet count in the AA subscriber's custom record and only applies to the 7750 SR.

The no form of this command excludes the denied packet count.

This command defines the amount by which the TWAMP Light packet is padded. TWAMP session controller packets are 27 bytes smaller than TWAMP session reflector packets. If symmetrical packet sizes in the forward and backward direction are required, the pad size must be configured to a minimum of 27 bytes.

The no form of this command removes all padding.

This command allows the operator to add an optional Pad TLV to PDU and increase the frame on the wire by the specified amount. Note that this command only configures the size of the padding added to the PDU, and does not configure the total size of the frame on the wire. Since the bit count for the length is a maximum of 255 (8bits) the maximum pad per pad-tlv is between 0, 2 and 257 (type 1B, Length 1B, Length 255). Only a single pad-tlv can be added.

The no form of this command removes the optional TLV.

This optional parameter specifies the amount of padding to add to the ICMP packet in bytes. The parameter is only applicable when the cpe-check option is used with the associated static route.

This command specifies the amount of padding to add to the ICMP packet in bytes. The parameter is only applicable when the cpe-check option is used with the associated static route.

This command allows the operator to increase the size of IP packet by padding the PDU.

The no form of the command reverts to the default.

This command configures the PADI authentication policy of this host.

This command configures the Access Concentrator name that is used in the PPPoE PADO message.

By default, the system name or if not configured, the chassis Serial Number is used.

This command configures the delay timeout before sending a PPPoE Active Discovery Offer (PADO).

This command configures the delay timeout before sending a PPP Active Discovery Offer (PADO) packet.

This command is used to allow or block the function of the pairing button. This can be used to block the accidental triggering of a pairing operation while there is already a paired device.

The actual behavior of the Bluetooth pairing is dependent on both this command and the power command.

If normal operation is to use the pairing button on the router and on the external device to initiate the Bluetooth connection, then set:

     config>system>bluetooth>power enabled-manual

     config>system>bluetooth>pairing-button enable

If normal operation is to only require the pairing to be initiated by the external device, then set:

     config>system>bluetooth>power enabled-automatic

     config>system>bluetooth>pairing-button disable

If normal operation is to not allow the local operator to connect without permission from the central management location, then set:

     config>system>bluetooth>power enabled-manual

     config>system>bluetooth>pairing-button disable

Then when a connection is desired, the central management station must change the configuration to one of the two options shown above for the time the local operator is connecting. The central management station can change the setting back to block local access after the operations is complete.

This command indicates that all members of the adjacency set must terminate on the same neighboring node. The system raises a trap if a user attempts to add an adjacency terminating on a neighboring node that differs from the existing members of the adjacency set. In addition, the system stops advertising the adjacency set in IS-IS and locally deprograms it.

By default, parallel adjacency sets are advertised in the IGP. The no-advertise option prevents an adjacency set from being advertised in the IGP. It is only allowed in CLI and SNMP if the parallel command is configured.

The no form of this command indicates that the adjacency set can include adjacencies to different next hop nodes.

This command indicates that all members of the adjacency set must terminate on the same neighboring node. The system raises a trap if a user attempts to add an adjacency terminating on a neighboring node that differs from the existing members of the adjacency set. In addition, the system stops advertising the adjacency set in IS-IS or OSPF and locally deprograms it.

By default, parallel adjacency sets are advertised in the IGP. The no-advertise option prevents an adjacency set from being advertised in the IGP. It is only allowed in CLI and SNMP if the parallel command is configured.

The no form of this command indicates that the adjacency set can include adjacencies to different next hop nodes.

This command specifies whether parameter-problem ICMP/ICMPv6 messages should be sent. When enabled, parameter-problem ICMP/ICMPv6 messages are generated by this interface.

The no form of this command disables the sending of parameter-problem ICMP/ICMPv6 messages.

This command configures the parameter-problem ICMPv4 messages that are generated by this interface.

The no form of this command disables the sending of parameter-problem ICMPv4 messages.

This command specifies whether parameter-problem ICMP messages should be sent. When enabled, parameter-problem ICMP messages are generated by this interface. The no form of this command disables the sending of parameter-problem ICMP messages.

This command specifies whether parameter-problem ICMP messages should be sent. When enabled, parameter-problem ICMP messages are generated by this interface.

The no form of this command disables the sending of parameter-problem ICMP messages.

This command specifies whether parameter-problem ICMPv6 messages should be sent. When enabled, parameter-problem ICMPv6 messages are generated by this interface.

The no form of this command disables the sending of parameter-problem ICMPv6 messages.

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

This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.

Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multi-service customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The orphaned state must generate a log entry and a trap message. The SAP which the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.

The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state and automatically returns to normal operation when the parent scheduler is available again.

When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.

The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. Once a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.

This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.

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 SAP/MSS 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.

This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.

Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multi-service customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The orphaned state must generate a log entry and a trap message. The SAP which the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.

The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state mentioned above and automatically return to normal operation when the parent scheduler is available again.

When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.

The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. Once a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.

This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.

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 SAP/MSS 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.

This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.

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 SAP/MSS 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.

This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.

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 SAP/MSS 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.

This command can be used to override the scheduler’s parent weight and cir-weight information. The weights apply to the associated level/cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.

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 SAP/MSS 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.

This command is used to define from where the tiered arbiter receives bandwidth. Both tier 1 and tier 2 arbiters default to parenting to the root arbiter. Tier 2 arbiters may be modified to parent to a tier 1 arbiter. The tier 1 arbiter parent cannot be changed.

The no form of this command is used to return the tiered arbiter to the default parenting behavior.

This command is used to create a child-to-parent mapping between each instance of the policer and either the root arbiter or a specific tiered arbiter on the object where the policy is applied. Defining a parent association for the policer causes the policer to compete for the parent policer’s available bandwidth with other child policers mapped to the policer control hierarchy.

Policer control hierarchies may be created on SAPs or on a subscriber or multiservice site context. To create a policer control hierarchy on an ingress or egress SAP context, a policer-control-policy must be applied to the SAP. When applied, the system will create a parent policer that is bandwidth limited by the policy’s max-rate value under the root arbiter. The root arbiter in the policy also provides the information used to determine the various priority-level discard-unfair and discard-all thresholds. Besides the root arbiter, the policy may also contain user-defined tiered arbiters that provide arbitrary bandwidth control for subsets of child policers that are either directly or indirectly parented by the arbiter.

When the QoS policy containing the policer with a parent mapping to an arbiter name exists on the SAP, the system will scan the available arbiters on the SAP. If an arbiter exists with the appropriate name, the policer to arbiter association is created. If the specified arbiter does not exist either because a policer-control-policy is not currently applied to the SAP or the arbiter name does not exist within the applied policy, the policer is placed in an orphan state. Orphan policers operate as if they are not parented and are not subject to any bandwidth constraints other than their own PIR. When a policer enters the orphan state, it is flagged as operationally degraded due to the fact that it is not operating as intended and a trap is generated. Whenever a policer-control-policy is added to the SAP or the existing policy is modified, the SAP's policer's parenting configurations must be reevaluated. If an orphan policer becomes parented, the degraded flag is cleared, and a resulting trap is generated.

For subscribers, the policer control hierarchy is created through the policer-control-policy applied to the sub-profile used by the subscriber. A unique policer control hierarchy is created for each subscriber associated with the sub-profile. The QoS policy containing the policer with the parenting command comes into play through the subscriber sla-profile, which references the QoS policy. The combining of the sub-profile and the sla-profile at the subscriber level provides the system with the proper information to create the policer control hierarchy instance for the subscriber. This functionality is available only for the 7450 ESS and 7750 SR.

Executing the parent command will fail if:

A policer with a parent command applied cannot be configured with stat-mode no-stats in either the QoS policy or as an override on an instance of the policer.

When a policer is successfully parented to an arbiter, the parent commands level and weight parameters are used to determine at what priority level and at which weight in the priority level that the child policer competes with other children (policers or other arbiters) for bandwidth.

The no form of this command is used to remove the parent association from all instances of the policer.

This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers, policers (at egress only), and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.

Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multiservice customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The SAP that the queue belongs to also depicts an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.

The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state and automatically returns to normal operation when the parent scheduler is available again.

When a parent scheduler is defined without specifying the weight parameter, the default is a weight of 1.

The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. When a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.

This command is used to create a child-to-parent mapping between each instance of the policer and either the root arbiter or a specific tiered arbiter on the object where the policy is applied. Defining a parent association for the policer causes the policer to compete for the parent policer’s available bandwidth with other child policers mapped to the policer control hierarchy.

Policer control hierarchies may be created on SAPs or on a subscriber or multiservice site context. To create a policer control hierarchy on an ingress or egress SAP context, a policer-control-policy must be applied to the SAP. When applied, the system will create a parent policer that is bandwidth limited by the policy’s max-rate value under the root arbiter. The root arbiter in the policy also provides the information used to determine the various priority level discard-unfair and discard-all thresholds. Besides the root arbiter, the policy may also contain user-defined tiered arbiters that provide arbitrary bandwidth control for subsets of child policers that are either directly or indirectly parented by the arbiter.

When the QoS policy containing the policer with a parent mapping to an arbiter name exists on the SAP, the system will scan the available arbiters on the SAP. If an arbiter exists with the appropriate name, the policer to arbiter association is created. If the specified arbiter does not exist either because a policer-control-policy is not currently applied to the SAP or the arbiter name does not exist within the applied policy, the policer is placed in an orphan state. Orphan policers operate as if they are not parented and are not subject to any bandwidth constraints other than their own PIR. When a policer enters the orphan state, it is flagged as operationally degraded due to the fact that it is not operating as intended and a trap is generated. Whenever a policer-control-policy is added to the SAP or the existing policy is modified, the SAP's policer's parenting configurations must be reevaluated. If an orphan policer becomes parented, the degraded flag is cleared and a resulting trap is generated.

For subscribers, the policer control hierarchy is created through the policer-control-policy applied to the sub-profile used by the subscriber. A unique policer control hierarchy is created for each subscriber associated with the sub-profile. The QoS policy containing the policer with the parenting command comes into play through the subscriber sla-profile that references the QoS policy. The combining of the sub-profile and the sla-profile at the subscriber level provides the system with the proper information to create the policer control hierarchy instance for the subscriber. This functionality is available only for the 7450 ESS and 7750 SR.

Executing the parent command will fail if:

A policer with a parent command applied cannot be configured with stat-mode no-stats in either the QoS policy or as an override on an instance of the policer.

When a policer is successfully parented to an arbiter, the parent commands level and weight parameters are used to determine at what priority level and at which weight in the priority level that the child policer competes with other children (policers or other arbiters) for bandwidth.

The no form of this command is used to remove the parent association from all instances of the policer.

This command defines an optional parent scheduler that further governs the available bandwidth given the queue aside from the queue’s PIR setting. When multiple schedulers, policers (at egress only), and/or queues share a child status with the parent scheduler, the weight or level parameters define how this queue contends with the other children for the parent’s bandwidth.

Checks are not performed to see if a scheduler-name exists when the parent command is defined on the queue. Scheduler names are configured in the config>qos>scheduler-policy>tier level context. Multiple schedulers can exist with the scheduler-name and the association pertains to a scheduler that should exist on the egress SAP as the policy is applied and the queue created. When the queue is created on the egress SAP, the existence of the scheduler-name is dependent on a scheduler policy containing the scheduler-name being directly or indirectly applied (through a multiservice customer site) to the egress SAP. If the scheduler-name does not exist, the queue is placed in the orphaned operational state. The queue will accept packets but will not be bandwidth limited by a virtual scheduler or the scheduler hierarchy applied to the SAP. The SAP that the queue belongs to must also depict an orphan queue status. The orphaned state of the queue is automatically cleared when the scheduler-name becomes available on the egress SAP.

The parent scheduler can be made unavailable due to the removal of a scheduler policy or scheduler. When an existing parent scheduler is removed or inoperative, the queue enters the orphaned state and automatically returns to normal operation when the parent scheduler is available again.

When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.

The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. When a parent association has been removed, the former child queue attempts to operate based on its configured rate parameter. Removing the parent association on the queue within the policy takes effect immediately on all queues using the SAP egress QoS policy.

This command defines an optional parent scheduler that is higher up the policy hierarchy. Only schedulers in tier levels 2 and 3 can have a parental association. When multiple schedulers, policers (at egress only), and/or queues share a child status with the scheduler on the parent, the weight or strict parameters define how this scheduler contends with the other children for the parent’s bandwidth. The parent scheduler can be removed or changed at any time and is immediately reflected on the schedulers created by association of this scheduler policy.

When a parent scheduler is defined without specifying weight or strict parameters, the default bandwidth access method is weight with a value of 1.

The no form of this command removes a child association with a parent scheduler. If a parent association does not currently exist, the command has no effect and returns without an error. When a parent association has been removed, the former child scheduler attempts to operate based on its configured rate parameter. Removing the parent association on the scheduler within the policy will take effect immediately on all schedulers with scheduler-name that have been created using the scheduler-policy-name.

This command overrides the scheduler’s parent weight and CIR weight information. The weights apply to the associated level or cir-level configured in the applied scheduler policy. The scheduler name must exist in the scheduler policy applied to the ingress or egress of the SAP or multi-service site.

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 SAP/MSS 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 the command returns the scheduler’s parent weight and CIR weight to the value configured in the applied scheduler policy.

This command determines the expected location of the parent schedulers for queues configured with a parent command within the sap-egress policy. All parent schedulers must be configured within a scheduler-policy applied at the location corresponding to the parent-location parameter.

If a parent scheduler name does not exist at the specified location, the queue will not be parented and will be orphaned.

The no form of this command reverts to the default.

This command determines the expected location of the parent schedulers for the tier 1 schedulers configured with a parent command within the scheduler policy. The parent schedulers must be configured within a scheduler policy applied at the location corresponding to the parent location parameter.

If a parent scheduler name does not exist at the specified location, the schedulers are not parented and are orphaned.

The configuration of parent-location and frame-based-accounting commands in a scheduler policy is mutually exclusive in to ensure consistency between the different scheduling levels.

The no form of this command reverts to the default.

This command determines the expected location of the parent schedulers for the tier 1 schedulers configured with a parent command within the scheduler-policy. The parent schedulers must be configured within a scheduler-policy applied at the location corresponding to the parent-location parameter.

If a parent scheduler name does not exist at the specified location, the schedulers will not be parented and will be orphaned.

The configuration of parent-location and frame-based-accounting in a scheduler policy is mutually exclusive in order to ensure consistency between the different scheduling levels.

The no form of this command reverts to the default.

This command creates the buffer allocation mapping between the associated class pool and the specified mid-pool. Use care when selecting a mid-pool in an active state (properly mapped to a root-pool with a non-zero allocation percentage). If a port-class pool is parented by an inactive mid-pool, the queues using the port-class pool are forced into an operational MBS setting of 0, causing all packet to be discarded. A port-class pool can be made inactive (no available buffers) by executing parent-mid-pool none in the port-class pool context.

The no form of the command reverts to the class-pool parenting value. For the standard port-class pools, this default is 1. For alternate port-class pools the default is none.

This command creates a buffer allocation mapping between the associated mid-pool mid-pool-id and the specified parent-root-pool root-pool-id. The specified root pool ID must have a non-zero allocation-weight or the command fails. After a mid-pool is successfully associated with a root-pool, the parent root-pool’s allocation-weight value cannot be set to zero.

When the root-pool-id is set to none, no buffers are assigned to the mid-tier pool.

The no form of the command reverts to the default.

This command specifies a 32-character string assigned to the operator by Barefruit. It is used by barefruit landing servers (applies to template # 1 only).

This command enables IS-IS participation in a specific flexible algorithm.

The router advertises its capability to participate in a specific flexible algorithm within the IS-IS router-capability TLV. Router participation in a flexible algorithm assumes that segment routing and, consequently the advertise-router-capability area is enabled. However, a router only advertises flexible algorithm participation when it can support the corresponding winning flexible algorithm definition. The flexible algorithm participation is not enabled by default.

The no form of this command disables participation for a particular flexible algorithm.

This command enables partitions within an ISA-AA group. When enabled, partitions can be created.

The no form of this command disables partitions within an ISA-AA group.

This command configures the partner down delay time. Since the DHCP lease synchronization failure can be caused by the failure of the intercommunication link (and not necessary the entire node), there is a possibility the redundant DHCP servers become isolated in the network. In other words, they can serve DHCP clients but they cannot synchronize the lease. This can lead to duplicate assignment of IP addresses, since the servers have configured overlapping IP address ranges but they are not aware of each other’s leases.

The purpose of the partner down delay is to prevent the IP lease duplication during the intercommunication link failure by not allowing new IP addresses to be assigned from the remote IP address range. This timer is intended to provide the operator with enough time to remedy the failed situation and to avoid duplication of IP addresses or prefixes during the failure.

During the partner-down-delay time, the prefix designated as remote is eligible only for renewals of the existing DHCP leases that have been synchronized by the peering node. Only after the sum of the partner-down-delay and the maximum-client-lead-time will the prefix designated as remote be eligible for delegation of the new DHCP leases. When this occurs, we say that the remote IP address range has been taken over.

It is possible to expedite the takeover of a remote IP address range so that the new IP leases can start being delegated from that range shortly after the intercommunication failure is detected. This can be achieved by configuring the partner-down-delay timer to 0 seconds, along with enabling the ignore-mclt-on-takeover CLI flag. Caution must be taken before enabling this functionality. It is safe to bypass safety timers (partner-down-delay + MCLT) only in cases where the operator is certain that the intercommunication between the nodes has failed due to the entire node failure and not due to the intercommunication (MCS) link failure. Failed intercommunication due to the nodal failure would ensure that only one node is present in the network for IP address delegation (as opposed to two isolated nodes with overlapping IP address ranges where address duplication can occur). For this reason, the operator must ensure that there are redundant paths between the nodes to ensure uninterrupted synchronization of DHCP leases.

In access-driven mode of operation, partner-down-delay has no effect.

The no form of this command reverts to the default.

This command enables the passive mode for the BGP neighbors.

The no form of this command disables the passive mode.

This command enables passive mode for the BGP group or neighbor.

When in passive mode, BGP will not attempt to actively connect to the configured BGP peers but responds only when it receives a connect open request from the peer.

The no form of this command used at the group level disables passive mode where BGP actively attempts to connect to its peers.

The no form of this command used at the neighbor level reverts to the value defined at the group level.

This command adds the passive attribute which causes the interface to be advertised as an IS-IS interface without running the IS-IS protocol. Normally, only interface addresses that are configured for IS-IS are advertised as IS-IS interfaces at the level that they are configured.

When the passive mode is enabled, the interface or the interface at the level ignores ingress IS-IS protocol PDUs and will not transmit IS-IS protocol PDUs.

The no form of this command removes the passive attribute.

This command adds the passive property to the OSPF interface where passive interfaces are advertised as OSPF interfaces but do not run the OSPF protocol.

By default, only interface addresses that are configured for OSPF are advertised as OSPF interfaces. The passive parameter allows an interface to be advertised as an OSPF interface without running the OSPF protocol.

While in passive mode, the interface ignores ingress OSPF protocol packets and does not transmit any OSPF protocol packets.

The no form of this command removes the passive property from the OSPF interface.

Enables/disables passive mode for the BGP group or neighbor.

When in passive mode, BGP will not attempt to actively connect to the configured BGP peers but responds only when it receives a connect open request from the peer.

The no form of this command used at the group level disables passive mode where BGP actively attempts to connect to its peers.

The no form of this command used at the neighbor level reverts to the value defined at the group level.

This command adds the passive attribute which causes the interface to be advertised as an IS-IS interface without running the IS-IS protocol. Normally, only interface addresses that are configured for IS-IS are advertised as IS-IS interfaces at the level that they are configured.

When the passive mode is enabled, the interface or the interface at the level ignores ingress IS-IS protocol PDUs and will not transmit IS-IS protocol PDUs.

The no form of this command removes the passive attribute.

This command adds the passive property to the OSPF interface where passive interfaces are advertised as OSPF interfaces but do not run the OSPF protocol.

By default, only interface addresses that are configured for OSPF will be advertised as OSPF interfaces. The passive parameter allows an interface to be advertised as an OSPF interface without running the OSPF protocol.

While in passive mode, the interface will ignore ingress OSPF protocol packets and not transmit any OSPF protocol packets.

Service interfaces defined in config>router>service-prefix are passive. All other interfaces are not passive.

The no form of this command removes the passive property from the OSPF interface.

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.

This command is used to define the Bluetooth pass key that is used during paring. This passkey must match in both devices attempting the pairing operation.

This command specifies a password type or configures password string for pap or chap. The pap and chap passwords are stored in a hashed format in the config files. The hash|hash2 optional keywords are used for config execution.

This command will only be interpreted if the local user database is connected directly to the PPPoE node under the VPRN/IES group interface. It is not used if the local user database is accessed by a local DHCP server.

The no form of this command reverts to the default.

This command configures the password between L2TP LAC and LNS

The no form of this command removes the password.

This command configures the password to be used for RADIUS authentication of data-triggered dynamic services.

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

This command sets a password that is sent with user-name in every RADIUS authentication request sent to the RADIUS server upon receipt of DHCP discover or request messages. If no password is configured, no password AVP is sent.

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

This command sets a password that is sent with user-name in every RADIUS authentication request sent to the RADIUS server upon receipt of DHCP discover or request messages. If no password is provided, an empty password is sent.

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

This command specifies the password that is used in the RADIUS access requests.

The no form of this command resets the password to the default which is an empty string.

This command specifies the password that the test account will use to send access requests to probe the RADIUS servers.

Commands in this context configure the passwords in the system.

This command creates the context to configure password management parameters.

This command specifies the password that is used in the RADIUS access requests.

The no form of this command resets the password to its default of ALU and will be stored using hash/hash2 encryption.

This command specifies the password that is used in the RADIUS access requests. It shall be specified as a string of up to 32 characters in length.

The no form of the command resets the password to its default of ALU and will be stored using hash/hash2 encryption.

This command configures the password for the X1 and X2 interfaces.

The no form of this command reverts to the default.