This command configures the half-life decay time and the maximum period of time for which the port-up state can be suppressed.

The half-life and max-time values must be set at the same time and the ratio of max-time/half-life must be less than or equal to 49 and greater than or equal to 1.

This command configures the half-life parameter for the route damping profile.

The half life value is the time, expressed in minutes, required for a route to remain stable in order for the Figure of Merit (FoM) value to be reduced by one half; for example, if the half life value is 6 (minutes) and the route remains stable for 6 minutes, then the new FoM value is 3 (minutes). After another 3 minutes pass and the route remains stable, the new FoM value is 1.5 (minutes).

When the FoM value falls below the config>router>policy-options>damping reuse threshold, the route is once again considered valid and can be reused or included in route advertisements.

The no form of this command removes the half life parameter from the damping profile.

This command configures an EHS handler.

The no form of this command removes the specified EHS handler.

This command enables the inclusion of the hardware timestamp attributes.

The no form of the command excludes the hardware timestamp attributes.

This command assigns a global read and write algorithm for the system. When the hash algorithm is set, the system will read and write the phrase based on the chosen algorithm.

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

This command enables the use of the hash label on a VLL, VPRN or VPLS service bound to any MPLS type encapsulated SDP, as well as to a VPRN service that is using the auto-bind-tunnel with the resolution-filter set to any MPLS tunnel type. This feature is not supported on a service bound to a GRE SDP or for a VPRN service using the autobind mode with the gre option. This feature is also not supported on multicast packets forwarded using RSVP P2MP LSP or mLDP LSP in both the base router instance and in the multicast VPN (mVPN) instance. It is, however, supported when forwarding multicast packets using an IES/VPRN spoke-interface.

When this feature is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use as the value of the label field of the hash label. The egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).

To allow applications where the egress LER infers the presence of the hash label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the Hash Label. This means that the value of the hash label will always be in the range [524,288 - 1,048,575] and will not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label will not match a value in the reserved label range.

The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG spraying of packets locally on the ingress LER. Note, however, that for VLL services, the result of the hash is overwritten and the ECMP and LAG spraying will be based on service-id when ingress SAP shared queuing is not enabled. However, the hash label will still reflect the result of the hash such that an LSR can use it to perform fine grained load balancing of VLL pseudowire packets.

Packets generated in CPM and that are forwarded labeled within the context of a service (for example, OAM packets) must also include a Hash Label at the BoS and set the S-bit accordingly.

The TTL of the hash label is set to a value of 0.

The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS spoke-sdp or mesh SDP, or an IES/VPRN spoke interface by adding the signal-capability option. In this case, the decision whether to insert the hash label on the user and control plane packets by the local PE is solely determined by the outcome of the signaling process and can override the local PE configuration. The following are the procedures:

The no form of this command disables the use of the hash label.

This command enables the use of the hash label on a VLL, VPRN, or VPLS service bound to any MPLS type encapsulated SDP, as well as to a VPRN service using the auto-bind-tunnel with the resolution-filter set to any MPLS tunnel type. This feature is not supported on a service bound to a GRE SDP or for a VPRN service using the autobind mode with the gre option. This feature is also not supported on multicast packets forwarded using RSVP P2MP LSP or mLDP LSP in both the base router instance and in the multicast VPN (mVPN) instance. It is, however, supported when forwarding multicast packets using an IES/VPRN spoke-interface.

When this feature is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use as the value of the label field of the hash label. The egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to one (1).

To allow applications where the egress LER infers the presence of the hash label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the Hash Label. This means that the value of the hash label will always be in the range [524,288 - 1,048,575] and will not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label will not match a value in the reserved label range.

The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG spraying of packets locally on the ingress LER. Note, however, that for VLL services, the result of the hash is overwritten and the ECMP and LAG spraying will be based on service-id when ingress SAP shared queuing is not enabled. However, the hash label will still reflect the result of the hash such that an LSR can use it to perform fine grained load balancing of VLL pseudowire packets.

Packets generated in CPM and that are forwarded labeled within the context of a service (for example, OAM packets) must also include a Hash Label at the BoS and set the S-bit accordingly.

The TTL of the hash label is set to a value of 0.

The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS spoke-sdp or mesh-sdp, or an IES/VPRN spoke interface by adding the signal-capability option. In this case, the decision whether to insert the hash label on the user and control plane packets by the local PE is solely determined by the outcome of the signaling process and can override the local PE configuration. The following are the procedures:

The no form of this command disables the use of the hash label.

This command enables the use of the hash label on a VLL, VPLS, or VPRN service bound to any MPLS-type encapsulated SDP, as well as to a VPRN service using auto-bind-tunnel with the resolution-filter configures as any MPLS tunnel type. This feature is not supported on a service bound to a GRE SDP or for a VPRN service using the autobind mode with the gre option.

When this feature is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use as the value of the label field of the hash label. The egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to 1 to indicate that.

In order to allow for applications whereby the egress LER infers the presence of the hash label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the hash label. This means that the value of the hash label will always be in the range [524,288 to 1,048,575] and will not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label will not match a value in the reserved label range.

The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG spraying of packets locally on the ingress LER. For VLL services, the result of the hash is overwritten and the ECMP and LAG spraying will be based on service-id when ingress SAP shared queuing is not enabled. However, the hash label will still reflect the result of the hash such that an LSR can use it to perform fine grained load balancing of VLL pseudowire packets.

Packets that are generated in CPM and forwarded labeled within the context of a service (for example, OAM packets) must also include a hash label at the BoS and set the S-bit accordingly.

The TTL of the hash label is set to a value of 0.

The user enables the signaling of the hash-label capability under a VLL spoke-sdp, a VPLS spoke-sdp or mesh-sdp, or an IES/VPRN spoke interface by adding the signal-capability option. In this case, the decision whether to insert the hash label on the user and control plane packets by the local PE is solely determined by the outcome of the signaling process and can override the local PE configuration. The following are the procedures:

The no form of this command disables the use of the hash label.

This command enables the use of the hash label on a VLL, VPLS, or VPRN service bound to any MPLS-type encapsulated SDP as well as to a VPRN service using auto-bind-tunnel with the resolution-filter configured as any MPLS tunnel type. This feature is not supported on a service bound to a GRE SDP or for a VPRN service using the autobind mode with the gre option.

When this feature is enabled, the ingress data path is modified such that the result of the hash on the packet header is communicated to the egress data path for use as the value of the label field of the hash label. The egress data path appends the hash label at the bottom of the stack (BoS) and sets the S-bit to 1 to indicate that.

In order to allow for applications whereby the egress LER infers the presence of the Hash Label implicitly from the value of the label, the Most Significant Bit (MSB) of the result of the hash is set before copying into the Hash Label. This means that the value of the hash label will always be in the range [524,288 - 1,048,575] and will not overlap with the signaled/static LSP and signaled/static service label ranges. This also guarantees that the hash label will not match a value in the reserved label range.

The (unmodified) result of the hash continues to be used for the purpose of ECMP and LAG spraying of packets locally on the ingress LER. For VLL services, the result of the hash is overwritten and the ECMP and LAG spraying will be based on service-id when ingress SAP shared queuing is not enabled. However, the hash label will still reflect the result of the hash such that an LSR can use it to perform fine grained load balancing of VLL pseudowire packets.

Packets that are generated in CPM and forwarded labeled within the context of a service (for example, OAM packets) must also include a Hash Label at the BoS and set the S-bit accordingly.

The TTL of the hash label is set to a value of 0.

The no form of this command disables the use of the hash label.

This command is used to configure the length of a mask that is to be combined with the group address before the hash function is called. All groups with the same hash map to the same RP. For example, if this value is 24, only the first 24 bits of the group addresses matter. This mechanism is used to map one group or multiple groups to an RP.

This command is used to configure the length of a mask that is to be combined with the group address before the hash function is called. All groups with the same hash map to the same RP. For example, if this value is 24, only the first 24 bits of the group addresses matter. This mechanism is used to map one group or multiple groups to an RP.

This command configures the length of a mask that is to be combined with the group address before the hash function is called. All groups with the same hash map to the same RP. For example, if this value is 24, only the first 24 bits of the group addresses matter. This mechanism is used to map one group or multiple groups to an RP.

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

This command controls the operational status of the LAG or the IGP cost based on the sum of the hash-weight values for the active links in the LAG.

The no form of this command disables the hash weight threshold.

This command configures the password hashing algorithm.

This command configures properties relating to requests received by the video interface for High Definition (HD) channel requests.

This command associates a head-end location with a statically-defined segment-routing policy. The head-end identifies the router that is the target to install the policy. This is a mandatory parameter for enabling the segment-routing policy.

To associate a static policy with the local router as head-end, the keyword local must be specified. The static policy is associated with another (non-local) router, if the head-end parameter is set to any IPv4 address. When a non-local, static segment routing policy that originates as a BGP route is imported into BGP, the configured head-end address is converted to an IPv4-address specific route-target extended community that is automatically added to the route.

The no form of this command removes the head-end association.

This command enables the context to configure header parameters.

The no form of this command deletes the associated header.

This command configures a TCA for the counter capturing hits for the GTP filter header sanity. A GTP filter header-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 sequence of headers for a packet to be launched by the OAM find-egress tool.

This command enables the context to configure health check parameters for the RADIUS server.

This command specifies that RADIUS, TACACS+, and LDAP servers are monitored for 3 seconds each at 30 second intervals. Servers that are not configured will have 3 seconds of idle time. If in this process a server is found to be unreachable, or a previously unreachable server starts responding, a trap will be sent based on the type of the server.

The no form of this command disables the periodic monitoring of the RADIUS, TACACS+, and LDAP servers. In this case, the operational status for the active server will be up if the last access was successful.

This command enables the context to configure parameters for transmitting PFCP Heartbeat Request messages to a PFCP peer.

This command configures the transmission interval for LMP Hello packets. The dead-interval specifies the period after which the IPCC is declared down if no Hello packets are received from the LMP peer.

This command enables debugging for GMPLS Hello packets.

The no form of the command disables debugging for GMPLS Hello packets.

This command configures the time interval to wait before declaring a neighbor down. The factor parameter derives the Hello interval.

The config>router>ldp>if-params>ipv6>hello and config>router>ldp>targ-session>ipv6>hello commands are not supported on the 7450 ESS.

Hold time is local to the system and sent in the Hello messages to the neighbor. Hold time cannot be less than three times the Hello interval. The hold time can be configured globally (applies to all LDP interfaces) or per interface. The most specific value is used.

When LDP session is being set up, the holddown time is negotiated to the lower of the two peers. Once an operational value is agreed upon, the Hello factor is used to derive the value of the Hello interval.

The no form of the command at the interface-parameters and targeted-session level sets the hello timeout and the hello factor to the default values.

The no form of the command, at the interface level, sets the hello timeout and the hello factor to the value defined under the interface-parameters level.

The no form of this command, at the peer level, sets the hello timeout and the hello factor to the value defined under the targeted-session level.

The session must be flapped for the new settings to operate.

This command enables debugging for LDP Hello packets.

The no form of the command disables the debugging output.

This command debugs Hello packets.

The no form of the command disables the debugging.

This command configures an authentication keychain to use for the protocol interface. The keychain allows the rollover of authentication keys during the lifetime of a session.

This command enables authentication of individual IS-IS Hello packets for the VPRN instance.

The no form of this command suppresses authentication of Hello packets.

This command enables authentication of individual IS-IS packets of HELLO type.

The no form of this command suppresses authentication of HELLO packets.

This command configures the authentication key (password) for Hello PDUs. Neighboring routers use the password to verify the authenticity of Hello PDUs sent from this interface. Both the Hello authentication key and the Hello authentication type on a segment must match. The hello-authentication-type must be specified.

To configure the Hello authentication key in the interface context use the hello-authentication-key in the config>router>isis>if context.

To configure or override the Hello authentication key for a specific level, configure the hello-authentication-key in the config>router>isis>if>level context.

If both IS-IS and hello-authentication are configured, Hello messages are validated using Hello authentication. If only IS-IS authentication is configured, it will be used to authenticate all IS-IS (including Hello) protocol PDUs.

When the Hello authentication key is configured in the config>router>isis>if context, it applies to all levels configured for the interface.

The no form of this command removes the authentication-key from the configuration.

This command configures the authentication key (password) for Hello PDUs. Neighboring routers use the password to verify the authenticity of Hello PDUs sent from this interface. Both the Hello authentication key and the Hello authentication type on a segment must match. The hello-authentication-type must be specified.

To configure the Hello authentication key in the interface context, use the hello-authentication-key in the config>router>isis>interface context.

To configure or override the Hello authentication key for a specific level, configure the hello-authentication-key in the config>router>isis>interface>level context.

If both IS-IS and hello-authentication are configured, Hello messages are validated using Hello authentication. If only IS-IS authentication is configured, it will be used to authenticate all IS-IS (including Hello) protocol PDUs.

When the Hello authentication key is configured in the config>router>isis>interface context, it applies to all levels configured for the interface.

The no form of this command removes the authentication-key from the configuration.

This command enables Hello authentication at either the interface or level context. Both the Hello authentication key and the Hello authentication type on a segment must match. The hello authentication-key statement must also be included.

To configure the Hello authentication type at the interface context, use hello-authentication-type in the config>router>isis>if context.

To configure or override the Hello authentication setting for a given level, configure the hello-authentication-type in the config>router>isis>if>level context.

The no form of this command disables Hello authentication.

This command enables Hello authentication at either the interface or level context. Both the Hello authentication key and the Hello authentication type on a segment must match. The hello authentication-key statement must also be included.

To configure the Hello authentication type at the interface context, use hello-authentication-type in the config>router>isis>interface context.

To configure or override the Hello authentication setting for a given level, configure the hello-authentication-type in the config>router>isis>interface>level context.

The no form of this command disables Hello authentication.

This command configures the time interval between two consecutive tunnel Hello messages. The Hello message is an L2TP control message sent by either peer of a LAC-LNS control connection. This control message is used as a keepalive for the tunnel.

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

This command specifies the value of the MLFR bundle T_HELLO timer. The timer controls the rate that Hello messages are sent. Following a period of T_HELLO duration, a Hello message is transmitted onto the bundle link.

Note that T_HELLO timer is also used during the bundle link add process as an additional delay before resending an ADD_LINK message to the peer bundle link when the peer bundle link does not answer as expected.

This command configures the interval in seconds between Hello messages issued on this interface at this level. This command is valid only for interfaces on control B-VPLS.

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

This command configures the interval in seconds between Hello messages issued on this interface at this level. This command is valid only for interfaces on control B-VPLS.

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

This command configures the interval between IS-IS Hello PDUs issued on the interface at this level. The hello-interval, along with the hello-multiplier, is used to calculate a hold time, which is communicated to a neighbor in a Hello PDU.

Note: The neighbor hold time is (hello multiplier × hello interval) on non-designated intermediate system broadcast interfaces and point-to-point interfaces and is (hello multiplier × hello interval / 3) on designated intermediate system broadcast interfaces. Hello values can be adjusted for faster convergence, but the hold time should always be > 3 to reduce routing instability.

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

This command configures the frequency at which PIM Hello messages are transmitted on this interface.

The no form of this command resets the configuration to the default value.

This command configures the interval between OSPF Hello messages issued on the interface, virtual link, or sham-link.

The Hello interval, in combination with the dead-interval, is used to establish and maintain the adjacency. Use this parameter to edit the frequency that Hello packets are sent.

Reducing the interval, in combination with an appropriate reduction in the associated dead-interval, allows for faster detection of link and/or router failures at the cost of higher processing costs.

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

This command configures the frequency at which PIM Hello messages are transmitted on this interface.

The no form of this command resets the configuration to the default value.

This command configures the RSVP Hello packet interval (in ms), towards the peer UNI-N node.

The no form of this command sets the hello-interval to the default value. A value of 0 disables RSVP Hellos.

This command configures the time interval between RSVP Hello messages.

RSVP Hello packets are used to detect loss of RSVP connectivity with the neighboring node. Hello packets detect the loss of neighbor far quicker than it would take for the RSVP session to time out based on the refresh interval. After the loss of the of number keep-multiplier consecutive Hello packets, the neighbor is declared to be in a down state.

The no form of this command reverts to the default value of the hello-interval. To disable sending hello messages, set the value to zero.

This command configures the frequency at which PIM Hello messages are transmitted on this interface.

The no form of this command resets the configuration to the default value.

This command configures the interval between OSPF Hellos issued on the interface or virtual link.

The Hello interval, in combination with the dead-interval, is used to establish and maintain the adjacency. Use this parameter to edit the frequency that Hello packets are sent.

Reducing the interval, in combination with an appropriate reduction in the associated dead-interval, allows for faster detection of link and/or router failures at the cost of higher processing costs.

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

This command configures the amount of time between Hello messages sent from the SR OS node to the remote manager.

This command configures the number of missing Hello PDUs from a neighbor SPB declares the adjacency down. This command is valid only for interfaces on control B-VPLS.

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

This command configures the number of missing Hello PDUs from a neighbor SPB declares the adjacency down. This command is valid only for interfaces on control B-VPLS.

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

This command configures the number of missing Hello messages from a neighbor before the router declares the adjacency down.

Note: The neighbor hold-time is (hello multiplier × hello interval) on point-to-point interfaces, and (hello multiplier × hello interval / 3) on broadcast interfaces. Hello values can be adjusted for faster convergence, but the hold-time should always be > 3 to reduce routing instability.

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

This command configures the multiplier to determine the holdtime for a PIM neighbor on this interface.

The hello-multiplier in conjunction with the hello-interval determines the holdtime for a PIM neighbor.

This command configures the multiplier to determine the holdtime for a PIM neighbor on this interface.

The hello-multiplier in conjunction with the hello-interval determines the holdtime for a PIM neighbor.

This command configures the multiplier to determine the holdtime for a PIM neighbor on this interface.

The hello-multiplier in conjunction with the hello-interval determines the holdtime for a PIM neighbor.

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

This command configures a Hello multiplier. The hello-multiplier, along with the hello-interval, is used to calculate a hold time, which is communicated to a neighbor in a Hello PDU.

The hold time is the time in which the neighbor expects to receive the next Hello PDU. If the neighbor receives a Hello within this time, the hold time is reset. If the neighbor does not receive a Hello within the hold time, it brings the adjacency down.

Note: The neighbor hold time is (hello multiplier × hello interval) on non-designated intermediate system broadcast interfaces and point-to-point interfaces and is (hello multiplier × hello interval / 3) on designated intermediate system broadcast interfaces. Hello values can be adjusted for faster convergence, but the hold time should always be > 3 to reduce routing instability.

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

This command enables the IS-IS Hello (IIH) message padding to ensure that IS-IS LSPs can traverse the link. When this option is enabled, IS-IS Hello messages are padded to the maximum LSP MTU value, which can be set with the lsp-mtu-size command.

The no form of this command disables IS-IS Hello message padding at this level. However, the router may still perform Hello padding if it was set at a higher level in the configuration. To ensure that Hello message padding is disabled, set all levels of configuration to no hello-padding.

This command enables IS-IS Hello (IIH) message padding to ensure that IS-IS LSPs can traverse the link. When this option is enabled, IS-IS Hello messages are padded to the maximum LSP MTU value, which can be set with the lsp-mtu-size command.

The no form of this command disables IS-IS Hello padding at this level. However, the router may still perform Hello padding if it was set at a higher level in the configuration. To ensure that Hello message padding is disabled, set all levels of configuration to no hello-padding.

This command enables the suppression of periodic targeted Hello messages between LDP peers once the targeted LDP session is brought up.

The config>router>ldp>targ-session>ipv6>hello-reduction command is not supported on the 7450 ESS.

When this feature is enabled, the target Hello adjacency is brought up by advertising the Hold-Time value the user configured in the “hello timeout” parameter for the targeted session. The LSR node will then start advertising an exponentially increasing Hold-Time value in the Hello message as soon as the targeted LDP session to the peer is up. Each new incremented Hold-Time value is sent in a number of Hello messages equal to the value of the argument factor, which represents the dampening factor, before the next exponential value is advertised. This provides time for the two peers to settle on the new value. When the Hold-Time reaches the maximum value of 0xffff (binary 65535), the two peers will send Hello messages at a frequency of every [(65535-1)/local helloFactor] seconds for the lifetime of the targeted-LDP session (for example, if the local Hello Factor is three (3), then Hello messages will be sent every 21844 seconds.

The LSR node continues to compute the frequency of sending the Hello messages based on the minimum of its local Hold-time value and the one advertised by its peer as in RFC 5036. Thus for the targeted LDP session to suppress the periodic Hello messages, both peers must bring their advertised Hold-Time to the maximum value. If one of the LDP peers does not, the frequency of the Hello messages sent by both peers will continue to be governed by the smaller of the two Hold-Time values.

When the user enables the Hello reduction option on the LSR node while the targeted LDP session to the peer is operationally up, the change will take effect immediately. In other words, the LSR node will start advertising an exponentially increasing Hold-Time value in the Hello message, starting with the current configured Hold-Time value.

When the user disables the Hello reduction option while the targeted LDP session to the peer is operationally up, the change in the Hold-Time from 0xffff (binary 65535) to the user configured value for this peer will take effect immediately. The local LSR will immediately advertise the value of the user configured Hold-Time value and will not wait until the next scheduled time to send a Hello to make sure the peer adjusts its local hold timeout value immediately.

In general, any configuration change to the parameters of the T-LDP Hello adjacency (modifying the Hello adjacency Hello Timeout or factor, enabling/disabling Hello reduction, or modifying Hello reduction factor) will cause the LSR node to trigger immediately an updated Hello message with the updated Hold Time value without waiting for the next scheduled time to send a Hello.

The no form of this command disables the Hello reduction feature.

This command configures the Spanning Tree Protocol (STP) Hello time for the Virtual Private LAN Service (VPLS) STP instance.

The Hello time parameter defines the default timer value that controls the sending interval between BPDU configuration messages by this bridge, on ports where this bridge assumes the designated role.

The active Hello time for the spanning tree is determined by the root bridge (except when the STP is running in RSTP mode, then the Hello time is always taken from the locally configured parameter).

The configured hello-time can also be used to calculate the forward delay. See auto-edge (config>service>vpls>sap>stp auto-edge, config>service>template>vpls-sap-template>stp auto-edge, config>service>vpls>spoke-sdp>stp auto-edge).

The no form of this command returns the Hello time to the default value.

This command configures the time period between SDP keepalive messages on the SDP-ID for the SDP connectivity monitoring messages.

The no form of this command reverts the hello-time seconds value to the default setting.

This command provides a brief description of the help system. The following information is shown:

This command disables helper support for IS-IS graceful restart (GR).

When graceful-restart is enabled, the router can be a helper (that is, the router is helping a neighbor to restart), a restarting router, or both. The router only supports helper mode. It will not act as a restarting router, because the high availability feature set already preserves IS-IS forwarding information such that this functionality is not needed. This command is a historical command and should not be disabled. Configuring helper-disable has the effect of disabling graceful restart, because the router only supports helper mode.

The no helper-disable command enables helper support and is the default when graceful restart is enabled.

This command disables helper support for OSPF graceful restart (GR).

When graceful-restart is enabled, the router can be a helper (meaning that the router is helping a neighbor to restart), a restarting router, or both. The router only supports helper mode. It will not act as a restarting router, because the high availability feature set already preserves OSPF forwarding information such that this functionality is not needed. This command is a historical command and should not be disabled. Configuring helper-disable has the effect of disabling graceful restart, because the router only supports helper mode.

The no helper-disable command enables helper support and is the default when graceful restart is enabled.

This command disables helper support for IS-IS graceful restart (GR).

When graceful-restart is enabled, the router can be a helper (meaning that the router is helping a neighbor to restart), a restarting router, or both. The router only supports helper mode. It will not act as a restarting router, because the high availability feature set already preserves IS-IS forwarding information so that this functionality is not needed. This command is a historical command and should not be disabled. Configuring helper-disable has the effect of disabling graceful restart, because the router only supports helper mode.

The no form of this command enables helper support and is the default when graceful restart is enabled.

This command disables helper support for OSPF graceful restart (GR).

When graceful-restart is enabled, the router can be a helper (meaning that the router is helping a neighbor to restart), a restarting router, or both. The router only supports helper mode. It will not act as a restarting router because the high availability feature set already preserves OSPF forwarding information so that this functionality is not needed. This command is a historical command and should not be disabled. Configuring helper-disable has the effect of disabling graceful restart because the router only supports helper mode.

The no form of this command enables helper support and is the default when graceful-restart is enabled.

This command overrides the restart-time advertised by a peer (in its GR capability) with a locally-configured value. This override applies only to AFI/SAFI that were included in the GR capability of the peer. The restart-time is always zero for AFI/SAFI not included in the GR capability. This command is useful if the local router wants to force LLGR phase to begin after a set time for all protected AFI/SAFI.

By default, the restart time for all AFI/SAFI in the GR capability is the value signaled by the peer.

This command overrides the restart-time advertised by a peer (in its GR capability) with a locally-configured value. This override applies only to AFI/SAFI that were included in the GR capability of the peer. The restart-time is always zero for AFI/SAFI not included in the GR capability. This command is useful if the local router wants to force LLGR phase to begin after a set time for all protected AFI/SAFI.

By default, the restart time for all AFI/SAFI in the GR capability is the value signaled by the peer.

This command overrides the LLGR stale-time advertised by a peer (in its LLGR capability) with a locally-configured value. When configured in the long-lived configuration context, helper-override-stale-time applies to all AFI/SAFI in the advertised LLGR capability except for any AFI/SAFI with a family-specific override. A family-specific override is configured with the helper-override-stale-time command in a family context.

By default, the LLGR stale-time for an AFI/SAFI is the value signaled by the peer in the corresponding AFI/SAFI part of the LLGR capability.

This command overrides the LLGR stale-time advertised by a peer (in its LLGR capability) with a locally-configured value. When configured in the long-lived configuration context, helper-override-stale-time applies to all AFI/SAFI in the advertised LLGR capability except for any AFI/SAFI with a family-specific override. A family-specific override is configured with the helper-override-stale-time command in a family context.

By default, the LLGR stale-time for an AFI/SAFI is the value signaled by the peer in the corresponding AFI/SAFI part of the LLGR capability.

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

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

This command enters the context to configure the queue high drop tail parameters. The high drop tail defines the queue depth beyond which in-profile packets will not be accepted into the queue and will be discarded.

This command enters the context to configure the queue high drop-tail parameters. The high drop tail defines the queue depth beyond which in-profile packets will not be accepted into the queue and will be discarded.

This command specifies the minimum lifetime of an entry that it could be synced across CPM.

The no form of this command reverts to the default.

This command specifies a high burst increase.

This command includes the high octets discarded count.

For queues with stat-mode v4-v6, this command includes the IPv4 octets discarded count instead.

The no form of this command excludes the high octets discarded count.

This command includes the high octets discarded count.

The no form of this command excludes the high octets discarded count.

This command includes the high octets offered count.

The no form of this command excludes the high octets offered count.

This command includes the high octets offered count.

The no form of this command excludes the high octets offered count.

This command includes the high packets discarded count.

For queues with stat-mode v4-v6, this command includes the IPv4 packets discarded count instead.

The no form of this command excludes the high packets discarded count.

This command includes the high packets discarded count.

The no form of this command excludes the high packets discarded count.

This command includes the high packets offered count.

The no form of this command excludes the high packets offered count.

This command includes the high packets offered count.

The no form of this command excludes the high packets offered count.

This command configures the value of the percentage of buffer space for the queue, used exclusively by high priority packets. The specified value overrides the default value for the context.

The priority of a packet can only be set in the SAP ingress QoS policy and is only applicable on the ingress queues for a SAP. The high-prio-only parameter is used to override the default value derived from the network-queue command.

The defined high-prio-only value cannot be greater than the MBS size of the queue. Attempting to change the MBS to a value smaller than the high priority reserve will generate an error and fail execution. Attempting to set the high-prio-only value larger than the current MBS size will also result in an error and fail execution.

The no form of this command returns high-prio-only to the size as configured in the QoS policy.

This command is used to configure the percentage of the policer’s PIR leaky bucket's MBS (maximum burst size) that is reserved for high-priority traffic. While the mbs value defines the policer’s high-priority violate threshold, the percentage value defined is applied to the mbs value to derive the bucket’s low-priority violate threshold. See the mbs command details for information about which types of traffic are associated with each violate threshold.

This command is used to configure the percentage of the policer’s PIR leaky bucket's MBS (maximum burst size) that is reserved for high-priority traffic. While the mbs value defines the policer’s high-priority violate threshold, the percentage value defined is applied to the mbs value to derive the bucket’s low-priority violate threshold. See the mbs command details for information on which types of traffic is associated with each violate threshold.

This command sets a time period that the current offered rate should be maintained for a child policer or queue when it is seen that the offered rate is decreasing. The offered measurement that triggers the hold time is used when the hold timer expires, unless a higher offered rate is seen in the interim. When a higher rate is observed, the hold timer is canceled and the higher offered rate is used immediately.

A possible reason to define a hold timer for an offered rate is to allow a child queue is to dampen the effects of a child with a fluctuating rate on the virtual scheduler. This works similar to the max-decrement in that the child holds on to bandwidth from the virtual scheduler in case it may be needed in the near future.

This parameter has no effect on an increase to the child’s offered rate. If the rate increase is above the change sensitivity, the new offered rate is immediately used.

When this command is not specified or removed, the virtual scheduler immediately reacts to measured decreases in offered load.

The no form of this command is used to remove any currently configured hold time for all child policers and queues associated with the policy. When the hold time is removed, any current hold timers for child policers are automatically canceled.

This command enables the high-priority RED slope context of an HSMDA slope policy. Within the high-slope context, the high-priority RED slope configuration commands defining the start of slope, end of slope, and maximum probability points may be executed.

For ingress, packets classified as priority high or profile in are mapped to the high-priority RED slope for queue congestion management.

At egress, packets received from ingress as in-profile, or that are reclassified to inplus-profile or in-profile at egress, are mapped to the high-priority RED slope for queue congestion management. In-profile is derived at ingress either from within-CIR profiling or from explicit profile in classification.

The high-slope context contains the commands and parameters for defining the high Random Early Detection (RED) slope graph. Each buffer pool supports a high RED slope for managing access to the shared portion of the buffer pool for in-profile packets.

The high-slope parameters can be changed at any time and the affected buffer pool high RED slopes will be adjusted appropriately.

The no form of this command restores the high slope configuration commands to the default values. If the commands within high-slope are set to the default parameters, the high-slope node will not appear in save config and show config output unless the detail parameter is present.

This command configures the high watermark value for the DNS IP cache. When the number of IP addresses stored in the cache crosses above this threshold, the system will generate a trap.

This command configures the high watermark and low watermark thresholds for the specified TCA.

This command enters the context to configure the queue highplus drop tail parameters. The highplus drop tail defines the queue depth beyond which inplus-profile packets will not be accepted into the queue and will be discarded.

This command enters the context to configure the queue highplus drop-tail parameters. The highplus drop tail defines the queue depth beyond which inplus-profile packets will not be accepted into the queue and will be discarded.

The highplus-slope context contains the commands and parameters for defining the highplus Random Early Detection (RED) slope graph. Each buffer pool supports a highplus RED slope for managing access to the shared portion of the buffer pool for inplus-profile packets.

The highplus-slope parameters can be changed at any time and the affected buffer pool highplus RED slopes will be adjusted appropriately.

The no form of this command restores the highplus slope configuration commands to the default values. If the commands within highplus-slope are set to the default parameters, the highplus-slope node will not appear in save config and show config output unless the detail parameter is present.

This command lists the last 30 commands entered in this session.

Re-execute a command in the history with the !n command, where n is the line number associated with the command in the history output.

Example:

Configure how many previous passwords a new password is matched against.

This command sets the high loss interval (HLI) threshold to be monitored and the associated thresholds using the counter of the specified direction. The aggregate is a function of summing forward and backward. This value is only used as a threshold mechanism and is not part of the stored statistics. If the optional clear clear-threshold parameter is not specified, the traffic crossing alarm is stateless. Stateless means the state is not carried forward to other measurement intervals. Each measurement interval is analyzed independently and regardless of any previous window. Each unique event can only be raised once within measurement interval. If the optional clear clear-threshold parameter is specified, the traffic crossing alarm uses stateful behavior. Stateful means each unique previous event state is carried forward to following measurement intervals. If a threshold crossing event is raised another is raised until a measurement interval completes and the clear threshold has not been exceeded. A clear event is raised under that condition.

The no form of this command removes the event threshold for frame loss ratio. The direction must be included with the no command.

This command allows High Loss Interval (HLI) and Consecutive High Loss Interval (CHLI) counters to increment regardless of availability. Without this command, HLI and CHLI counters can only increment during times of availability, which includes undetermined availability. During times of complete packet loss, the forward direction HLI is marked as high loss. The backward direction is not marked as high loss during times of complete packet loss.

The no form of this command configures HLI and CHLI counters to increment during times of availability only.

This command allows High Loss Interval (HLI) and Consecutive High Loss Interval (CHLI) counters to increment regardless of availability. Without this command, HLI and CHLI counters can only increment during times of availability, which includes undetermined availability. During times of complete packet loss, the forward direction HLI is marked as high loss. The backward direction is not marked as high loss during times of complete packet loss.

The no form of this command configures HLI and CHLI counters to increment during times of availability only.

This command configures the hold clear time for the event. The seconds parameter specifies the hold-clear time, the amount of time in seconds by which the effect of a cleared event on the associated virtual router instance is delayed.

The hold-clear time is used to prevent black hole conditions when a virtual router instance advertises itself as a master before other conditions associated with the cleared event have had a chance to enter a forwarding state.

This command configures the peak number of BPDUs that can be transmitted in a period of one second.

The no form of this command returns the hold count to the default value

This command determines the interval during which no new communication attempts is made to a RADIUS server that is marked down to prevent immediately overloading the server when it is starting up. The only exception is when all servers in the authentication policy are marked down; in that case they will all be used again to prevent failures on new client connections.

The no form of this command reverts to the default.

This command determines the interval during which no new communication attempts are made to a RADIUS server that is marked down to prevent immediately overloading the server when it is starting up. The only exception is when all servers in the authentication policy are marked down; in that case, they will all be used again to prevent failures on new client connections.

The no form of this command reverts to the default.

This command configures the minimum time period the SDP will remain in the operationally down state in response to SDP keepalive monitoring.

This parameter can be used to prevent the SDP operational state from “flapping” by rapidly transitioning between the operationally up and operationally down states based on keepalive messages.

When an SDP keepalive response is received that indicates an error condition or the max-drop-count keepalive messages receive no reply, the sdp-id will immediately be brought operationally down. If a keepalive response is received that indicates the error has cleared, the sdp-id will be eligible to be put into the operationally up state only after the hold-down-time interval has expired.

The no form of this command reverts the hold-down-time seconds value to the default setting.

This command configures the hold down timer for SR policy candidate paths.

This command is intended to prevent bouncing of the SR policy path state if one or more S-BFD sessions associated with segment lists flap and therefore cause the threshold to be repeatedly crossed in a short period of time. It is started when the number of up S-BFD sessions drops below the threshold. The SR policy path is not considered to be up again until the hold down timer has expired and the number of up S-BFD sessions equals or exceeds the threshold and the internal hold timer is not running.

Note: If the revert timer is also configured, then it is not started until after the number of S-BFD sessions that are up ≥ threshold and the hold down timer for the primary has expired.

The no form of this command reverts to the default.

This command configures the hold-multiplier for the GSMP connections in this group.

The no form of this command removes the multiplier value from the GSMP configuration.

This command configures the hold-multiplier for the GSMP connections in this group.

This command configures the hold-multiplier for the GSMP connections in this group.

The no form of this command removes the multiplier value from the configuration

This command specifies the interval that the standby node will wait for packets from the active node before assuming a redundant-neighbor node failure. This delay in switch-over operation is required to accommodate different factors influencing node failure detection rate, such as IGP convergence, or HA switch-over times and to prevent the standby node to act prematurely.

The no form of this command reverts to the default.

This command specifies the number of keep-alive intervals that the local node will wait for packets from the MC-EP peer before assuming failure. After this time interval passed the all the mc-endpoints configured under services will revert to single chassis behavior, activating the best local pseudowire.

The no form of this command sets the multiplier to default value

This command specifies the number of keep-alive intervals that the local node will wait for packets from the MC-EP peer before assuming failure. After this time interval passed the all the mc-endpoints configured under services will revert to single chassis behavior, activating the best local pseudowire.

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

This command specifies the number of keep-alive failures before the peer is considered to be down.

The no form of this command reverts to the default.

This command specifies the amount of time that must pass before the set state for a VRRP priority control event can transition to the cleared state to dampen flapping events. A flapping event continually transitions between clear and set.

The hold-set command is used to dampen the effect of a flapping event. The hold-set value is loaded into a hold-set timer that prevents a set event from transitioning to the cleared state until it expires.

Each time an event transitions between cleared and set, the timer is loaded and begins a countdown to zero. When the timer reaches zero, the event is allowed to enter the cleared state. Entering the cleared state is dependent on the object controlling the event, conforming to the requirements defined in the event itself. It is possible, on some event types, to have another set action reload the hold-set timer. This extends the amount of time that must expire before entering the cleared state.

Once the hold-set timer expires and the event meets the cleared state requirements or is set to a lower threshold, the current set effect on the virtual router instances in-use priority can be removed. As with lag-port-down events, this may be a decrease in the set effect if the clearing amounts to a lower set threshold.

The hold-set command can be executed at anytime. If the hold-set timer value is configured larger than the new seconds setting, the timer is loaded with the new hold-set value.

The no form of the command disables the hold timer so that event transitions are processed immediately.

This command configures the BGP hold time, expressed in seconds.

The BGP hold time specifies the maximum time BGP waits between successive messages (either keepalive or update) from its peer, before closing the connection.

Even though the router OS implementation allows setting the keepalive time separately, the configured keepalive timer is overridden by the hold-time value under the following circumstances:

If the specified hold-time is less than the configured keepalive time, then the operational keepalive time is set to a third of the hold-time; the configured keepalive time is not changed.

If the hold-time is set to zero, then the operational value of the keepalive time is set to zero; the configured keepalive time is not changed. This means that the connection with the peer is up permanently and no keepalive packets are sent to the peer.

The no form of this command reverts to the default.

This command holds the BRG object for the specified time. This applies when the connectivity verification fails or when the last host is removed and no connectivity-verification is enabled. Hold time does not apply to an explicit removal via the radius or clear commands.

The no form of this command disables the hold time.

This command configures the minimum time that a UE is held down after a failed authentication attempt.

The no form of this command reverts to the default.

This command configures the time for which egress shaping resources associated with a wlan-gw tunnel are held after the last subscriber on a tunnel is deleted.

This command configures the minimum time that a UE is held associated with its current Access Point (AP) before being associated with a new AP.

The hold time is used to prevent overwhelming the system with mobility triggers, by limiting the rate at which a UE can move from one AP to another while the system is very busy already.

This command configures the time for which an SAP is retained after the last session has been removed. Such SAPs can be forcefully removed using the idle-saps option in the clear>subscriber-mgmt>sap-template context.

The no form of this command reverts to the default.

This command specifies how much time can pass, in 100s of milliseconds, without receiving an advertise packet from the neighbor before the multi-chassis signaling link is considered not operational.

The hold-time is usually 3 times the value of the advertise-interval. The value of the advertise-interval is valid only for a multi-chassis APS as indicated by the value of neighbor IP address if it is not set to 0.0.0.0.

This command configures efm-oam operational transition dampening timers which reduce the number of efm-oam state transitions reported to upper layers.

This command configures port link dampening timers which reduce the number of link transitions reported to upper layer protocols. The hold-time value dampens interface transitions.

When an interface transitions from an up state to a down state, it is immediately advertised to the rest of the system if the hold-time down interval is zero, but if the hold-time down interval is greater than zero, interface down transitions are not advertised to upper layers until the hold-time down interval has expired. Likewise, an interface is immediately advertised as up to the rest of the system if the hold-time up interval is zero, but if the hold-time up interval is greater than zero, up transitions are not advertised until the hold-time up interval has expired.

For ESM SRRP setup, MCS synchronizes subscriber information between the two chassis. After a chassis recovers from a power reset/down, MCS immediately synchronizes all subscriber information at once. The longer the host list, the longer it will take to synchronize the chassis. In a fully populated chassis, it is recommended to allow at least 45 minutes for MCS synchronization. It is also recommended to hold the port down, facing the subscriber, on the recovering chassis for 45 minutes before it is allowed to forward traffic again.

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

This command configures SONET link dampening timers in 100s of milliseconds. This guards against reporting excessive interface transitions. This is implemented by not advertising subsequent transitions of the interface to upper layer protocols until the configured timer has expired.

Note: For APS configurations, the hold-time down and up default values are 100 ms and 500 ms respectively. If there is a large communication delay (time to exchange K1/K2 bytes) between the APS Controllers of the two endpoints of an APS link, it is highly suggested to increase the default hold-time down timer on the APS group port accordingly with the communication delay. See the config>port aps command for more information.

This command is supported by TDM satellite.

This command configures link dampening timers in 100s of milliseconds. This guards against reporting excessive interface transitions. This is implemented by not advertising subsequent transitions of the interface to upper layer protocols until the configured timer has expired.

This command is only supported on the m4-chds3-as, m12-chds3-as, and c4-ds3 MDAs.

This command specifies the timer, in tenths of seconds, which controls the delay between detecting that a LAG is down (all active ports are down) and reporting it to the higher levels.

A non-zero value can be configured, for example, when active/standby signaling is used in a 1:1 fashion to avoid informing higher levels during the small time interval between detecting that the LAG is down and the time needed to activate the standby link.

This command enables the dampening timer and applies to both types of provisioned SAPs – end-station and UNI. When a value is configured for the timer, it controls the delay between detecting that the last provisioned SAP in VPLS goes down and reporting it to the MVRP module. The CPM will wait for the time specified in the value parameter before reporting it to the MVRP module. If the SAP comes up before the hold-timer expires, the event will not be reported to MVRP module.

The non-zero hold-time does not apply for SAP transition from down to up, This kind of transition is reported immediately to MVRP module without waiting for hold-time expiration. Also this parameter applies only to the provisioned SAPs. It does not apply to the SAPs configured with the vpls-sap-template command. Also when end-station QinQ SAPs are present only the “no hold-time” configuration is allowed.

The no form of this command disables tracking of the operational status for the last active SAP in the VPLS. MVRP will stop declaring the VLAN only when the last provisioned customer (UNI) SAP associated locally with the service is deleted. Also MVRP will declare the associated VLAN attribute as soon as the first provisioned SAP is created in the associated VPLS instance, regardless of the operational state of the SAP.

This command configures the duration that allows the PIM-snooping switch to snoop all the PIM states in the VPLS. During this duration, multicast traffic is flooded in the VPLS. At the end of this duration, multicast traffic is forwarded using the snooped states.

When PIM snooping is enabled in VPLS, there is a period of time when the PIM snooping switch may not have built complete snooping state. The switch cannot build states until the routers connected to the VPLS refresh their PIM messages.

This parameter is applicable only if PIM snooping is enabled.

This command creates the CLI context to configure interface level hold-up and hold-down timers for the associated IP interface.

The up timer controls a delay for the associated IPv4 or IPv6 interface so that the system will delay the deactivation of the associated interface for the specified amount of time.

The down timer controls a delay for the associated IPv4 or IPv6 interface so that the system will delay the activation of the associated interface for the specified amount of time

This command configures the BGP hold time, expressed in seconds.

The BGP hold time specifies the maximum time BGP waits between successive messages (either keepalive or update) from its peer, before closing the connection. This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.

Even though the router OS implementation allows setting the keepalive (config>service>vprn>bgp keepalive, config>service>vprn>bgp>group keepalive, config>service>vprn>bgp>group>neighbor keepalive) time separately, the configured keepalive timer is overridden by the hold-time value under the following circumstances:

The no form of this command used at the global level reverts to the default value.

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

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

This command enables the context to configure hold time information.

This command configures the BGP hold time, expressed in seconds.

The BGP hold time specifies the maximum time BGP waits between successive messages (either keepalive or update) from its peer, before closing the connection. This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in group) or neighbor level (only applies to specified peer). The most specific value is used.

Even though the implementation allows setting the keepalive time separately, the configured keepalive timer is overridden by the hold-time value under the following circumstances:

The no form of this command used at the global level reverts to the default value.

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

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

This command configures hold-down timers to debounce signal failure conditions (lais, b2err-sf) and signal degrade conditions (b2err-sd) for Uni 1+1 Sig+Data APS switching mode (switching mode uni-1plus1).

The no version of this command resets the hold-down timer to the default value.

This command configures the hold-down dampening timer. It is equivalent to a hold-off timer.

This command configures the hold-up dampening timer. This can be used to provide additional dampening to the state of proactive CC BFD sessions.

This command specifies the amount of time that the ingress node holds before programming its data plane and declaring the LSP up to the service module. This occurs anytime the ingress node brings up an LSP path or switches traffic from a working path to another working path of the same LSP.

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

This command enables debugging for RIP holddowns.

This command enables debugging for RIPng holddowns.

This command specifies the length of time a neighbor considers the sending router to be operationally up.

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

This command configures the length of time, in seconds, that neighbors should consider the sending router to be operationally up. A local RP cannot be configured on a logical router.

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

This command configures the charging characteristics for home UE.

This command configures the local home directory for the user for both console (file commands and '>' redirection) and FTP access.

If the URL or the specified URL/directory structure is not present, then a warning message is issued and the default is assumed.

The no form of this command removes the configured home directory.

This command specifies the node ID of the hops that the GMPLS LSP should traverse on its way to the egress UNI-C router.

The GMPLS LSP ingress and egress node IDs can be included as the first and the last hop. This is necessary when inter-operating with the Nokia 1830 PSS.

The no form of this command deletes hop list entries for the path. All of the GMPLS LSPs currently using the path are affected. Additionally, all services actively using these GMPLS LSPs are affected. The path must be shut down first in order to delete the hop from the hop list. The no hop hop-index command will not result in any action except a warning message on the console indicating that the path is administratively up.

This command specifies the hops that the LSP should traverse on its way to the egress router. When specified, the IP address can be the interface IP address, a loopback interface address, or the system IP address. If a loopback interface or the system IP address is specified then the LSP can choose the best available interface.

When an IPv6 hop is specified, the interface IP address must be a global unicast IPv6 address. A link-local address is not allowed and is rejected in the configuration if attempted.

Optionally, the LSP ingress and egress IP address can be included as the first and the last hop. A hop list can include the ingress interface IP address, the system IP address, and the egress IP address of any of the hops being specified.

When the sid-label parameter is specified, this command specifies an MPLS label value for a hop in the path of an SR-TE LSP. The label value implied by the SID is only used when the path is used by an SR-TE LSP.

The no form of this command deletes hop list entries for the path. All the LSPs currently using this path are affected. Additionally, all services actively using these LSPs are affected. The path must be shutdown first in order to delete the hop from the hop list. The no hop hop-index command will not result in any action except a warning message on the console indicating that the path is administratively up.

This command configures each hop on an explicit path that can be used by one or more dynamic MS-PWs. It specifies the IP addresses of the hops that the MS-PE should traverse. These IP addresses can correspond to the system IP address of each S-PE, or the IP address on which the T-LDP session to a given S-PE terminates.

The no form of this command deletes hop list entries for the path. All the MS-PWs currently using this path are unaffected. Additionally, all services actively using these MS-PWs are unaffected. The path must be shutdown first in order to delete the hop from the hop list. The ‘no hop hop-index’ command will not result in any action, except for a warning message on the console indicating that the path is administratively up.

This command enables match on existence of Hop-by-Hop Options Extension Header in the IPv6 filter policy.

The no form of this command ignores Hop-by-Hop Options Extension Header presence/absence in a packet when evaluating match criteria of a given filter policy entry.

This command enables match on existence of Hop-by-Hop Options Extension Header in the IPv6 filter policy. This command applies to the 7750 SR and 7950 XRS.

The no form of this command ignores Hop-by-Hop Options Extension Header presence/absence in a packet when evaluating match criteria of a given filter policy entry.

For fast reroute, how many more routers a detour is allowed to traverse compared to the LSP itself. For example, if an LSP traverses four routers, any detour for the LSP can be no more than ten router hops, including the ingress and egress routers.

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

This command specifies the maximum number of hops that an LSP can traverse, including the ingress and egress routers. An LSP is not set up if the hop limit is exceeded. This value can be changed dynamically for an LSP that is already set up with the following implications.

If the new value is less than the current number of hops of the established LSP, the LSP is brought down. The software then tries to re-establish the LSP within the new hop-limit number. If the new value is equal to or greater than the current number hops of the established LSP, the LSP is not affected.

The config>router>mpls>lsp>primary-p2mp-instance>hop-limit command is not supported on the 7450 ESS.

The no form of this command returns the parameter to the default value.

This optional command overrides the config>router>mpls>lsp lsp-name>hop-limit command. This command specifies the total number of hops that an LSP traverses, including the ingress and egress routers.

This value can be changed dynamically for an LSP that is already set up with the following implications:

If the new value is less than the current hops of the established LSP, the LSP is brought down. MPLS then tries to re-establish the LSP within the new hop-limit number. If the new value is equal or more than the current hops of the established LSP then the LSP will be unaffected.

The no form of this command reverts the values defined under the LSP definition using the config>router>mpls>lsp lsp-name>hop-limit command.

This command creates an IPoE or PPP host entry in the local user database. A host entry in the local user database is matched based on the specified match-list criteria and an optional mask that is applied to the host-identification parameters.

A default host entry can be created without host-identification parameters which is used when no other host entries match. Note that creating a default host entry also requires a match-list to be specified.

The no form of this command removes the host entry from the local user database.

This command creates a static subscriber host for the SAP. Static subscriber hosts may be used by the system for various purposes. Applications within the system that make use of static host entries include anti-spoof, ARP reply agent and source MAC population into the VPLS forwarding database.

Multiple static hosts may be defined on the SAP. Each host is identified by either a source IP address, a source MAC address or both a source IP and source MAC address. Every static host definition must have at least one address defined, IP or MAC.

Static hosts can exist on the SAP even with anti-spoof and ARP populate features disabled. When enabled, each feature has different requirements for static hosts.

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

This command creates a static subscriber host for the SAP. Static subscriber hosts may be used by the system for various purposes. Applications within the system that make use of static host entries include anti-spoof filters and ARP cache population.

Multiple static hosts may be defined on the SAP. Each host is identified by either a source IP address, a source MAC address or both a source IP and source MAC address. Every static host definition must have at least one address defined, IP or MAC.

Static hosts can exist on the SAP even with anti-spoof and ARP populate features disabled. When enabled, each feature has different requirements for static hosts.

anti-spoof – When enabled, this feature uses static and dynamic host information to populate entries into an anti-spoof filter table. The anti-spoof filter entries generated will be of the same type as specified in the anti-spoof type parameter. If the SAP anti-spoof filter is defined as ip, each static host definition must specify an IP address. If the SAP anti-spoof filter is defined as ip-mac, each static host definition must specify both an IP address and MAC address. If definition of a static host is attempted without the appropriate addresses specified for the enabled anti-spoof filter, the static host definition fails.

arp-populate – When enabled, this feature uses static and dynamic host information to populate entries in the system ARP cache.

Attempting to define a static subscriber host that conflicts with an existing DHCP Lease State Table entry fails.

Use the no form of this command to remove a static entry from the system. The specified ip-address and mac-address must match the host’s exact IP and MAC addresses as defined when it was created. When a static host is removed from the SAP, the corresponding anti-spoof entry and/or ARP cache entry is also removed.

This command enables the context to configure DHCP host parameters.

This command creates a static host for the SAP. Applications within the system that make use of static host entries include anti-spoof, and source MAC population into the VPLS forwarding database.

Multiple static hosts can be defined on the SAP. Each host is identified by a source IP address, a source MAC address, or both a source IP and source MAC address. When anti-spoof in enabled on the SAP, the host information will be populated into the SAP’s anti-spoof table, allowing ingress packets matching the entry access to the SAP. When the MAC address exists in the host definition, the MAC address is populated into the VPLS forwarding database and associates it with the SAP. The static host definition overrides any static MAC entries using the same MAC and prevents dynamic learning of the MAC on another interface.

Defining a static host identical to an existing static host has no effect and will not generate a log or error message.

Every static host definition must have at least one address defined, IP or MAC.

Static hosts may exist on the SAP even with anti-spoof and arp-populate (VPRN) features disabled. When enabled, each feature has different requirements for static hosts.

This command enables debugging for the IGMP host.

The no form of the command disables debugging.

This command enables per-host accounting. In host accounting mode, the acct-session-id is generated per host. This acct-session-id is uniformly included in all accounting messages (START/INTERIM-UPDATE/STOP) and it can be included in RADIUS Access-Request message.

Accounting counters are based on the queue counters and as such are aggregated for all host sharing the queues within an sla-profile instance (non HSMDA) or a subscriber (HSMDA). CoA and LI is supported based on the acct-session-id of the host.

The no form of this command reverts to the default.

This command enables subscriber host connectivity verification on a given VPLS SAP or within a VPLS service.

This tool will periodically scan all known hosts (from dhcp-state) and perform a UC ARP request. The subscriber host connectivity verification will maintain state (connected vs. not-connected) for all hosts.

The no form of this command reverts to the default.

This command enables subscriber host connectivity verification on a given SAP within a service. This tool periodically scans all known hosts (from dhcp-state) and perform UC ARP requests. The subscriber host connectivity verification maintains state (connected versus. not-connected) for all hosts.

The no form of this command reverts to the default.

This command enables subscriber host connectivity verification for all hosts on this interface. This tool will periodically scan all known hosts (from dhcp-state) and perform a UC ARP request. The subscriber host connectivity verification will maintain state (connected vs. not-connected) for all hosts.

This command enables subscriber host connectivity verification for all hosts on this interface. This tool periodically scans all known hosts (from dhcp-state) and perform UC ARP requests. The subscriber host connectivity verification maintains state (connected vs. not-connected) for all hosts.

The no form of this command reverts to the default.

This command enables subscriber host connectivity verification on a given SAP within a service.

This tool will periodically scan all known hosts and perform a UC ARP request. The subscriber host connectivity verification will maintain state (connected as opposed to not-connected) for all hosts.

This command enables Subscriber Host Connectivity Verification (SHCV) debugging.

The no form of the command disables the SHCV debugging.

This command triggers the host connectivity verification checks and applies only to the 7450 ESS and 7750 SR.

This command enables the context to configure host identification parameters.

This command specifies a prefix list host IP address as a match criterion for the route policy-statement entry.

This command specifies the parameters used in host identification for lockout on a given SAP or capture SAP.

no host-key – include (MAC address, Circuit-Id, Remote-Id)

host-key mac – include MAC address only

“host-key mac” should be used in DHCPv4 scenarios where Circuit-Id and Remote-Id are changed with “dhcp option action replace” configuration: a host lockout context is created with the replaced Circuit-Id/Remote-Id; with the default host-key (including Circuit-Id and Remote-Id), lockout does not kick in on the original trigger packet when it is retransmitted by the client.

Changing the host-key to mac should be used with care: all hosts with the same MAC address on a given SAP or capture SAP are identified as a single host with respect to host-lockout.

This command cannot be changed when the host-lockout-policy is referenced (configured under a SAP context).

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

This command configures the maximum number of ARP hosts.

The no form of this command reverts to the default.

This command configures the maximum number of ARP hosts.

This command enables the context to configure host limits per SLA profile instance or per subscriber.

The no form of this command removes the host limit configuration.