This command enables matching on Layer 2 tunnels.

The no form of this command disables matching on Layer 2 access points, unless no other tunnel type specifier is configured.

This command enables matching on UEs in a Layer 2 wholesale state.

The no form of this command disables matching on UEs in a Layer 2 wholesale state, unless all state matching is disabled.

This command enables the context to configure Layer 2 Access Points in WLAN Gateway Group-Interfaces.

This command adds a specific SAP where Layer-2 WLAN-GW aggregation is performed. The following SAPs are supported.

This command can be repeated multiple times to create multiple Layer-2 access points.

The no form of this command removes the Layer-2 access point. This is only allowed if the l2-ap SAP is shutdown.

This command configures the contents of the auto-generated subscriber ID when the ipoe-sub-id-key command is set to include sap-id and the def-sub-id command is configured with use-auto-id. The VLANs must be configured so that the subscriber ID length is not exceeded.

This command can include either the SAP or the SAP + AP delimiting tags.

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

This parameter specifies the number of AP identifying VLAN tags for an AP. This is the default value that can be overridden per SAP. This value should at least be equal to the number of VLANs configured in the SAP or enabling a SAP will fail.

A SAP VLAN is explicitly configured, for example l2-ap 1/1/1:25. Other VLANs on the same port can still be used in other contexts.

The number of VLAN tags Epiped to WLAN-GW IOM equal the l2-ap-encap-type minus the encaps of the SAP. Upon receipt of a packet these VLANs is stored as a Layer 2 tunnel identifier, and are only used in context of WLAN-GW.

The no form of this command sets the default value.

This command enters the context to configure parameters specific to Layer 2-aware NAT.

This command enters the “l2-aware” context for configuration specific to Layer 2-aware NAT.

This command creates NAT static port forwards for L2 aware subscribers. The ESM subscriber must be present in the system before this command is executed. The no form of the command deletes NAT static port forwards for L2 aware subscribers.

This command configures the L2-Aware NAT inside IP address to be assigned via DHCP on WLAN-GW ISA.

If the from-pool parameter is specified instead of an IPv4 address, a unique address is allocated to each UE. The pool used is managed by the dhcpv4-nat pool manager, configured under the same subscriber interface. This option is only available when auth-on-dhcp is also configured.

The no form of this command reverts to the default.

This command enables bypassing NAT for packets pertaining to L2-Aware hosts and matching this entry. This action is only applicable to L2-Aware NAT subscribers and it must be configured together with action forward. Traffic identified in the match condition bypasses L2-Aware NAT. A common use case is to bypass NAT for on-net destinations (within the customer network).

Traffic that is not classified for bypass is automatically diverted to L2-Aware NAT, unless it is explicitly configured in the IP filter to be dropped.

For selective NAT bypass to take effect, in addition to the IP filter configuration, the L2-Aware NAT subscriber must be specifically enabled for selective bypass via the allow-bypass configuration option in the NAT CLI node in the SLA profile.

The no form of this command automatically diverts traffic to L2-Aware NAT, unless it is explicitly configured in the IP filter to be dropped.

This command configures a Layer-2-Aware subscriber source.

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

This command enables matching on a Layer 2 access point with a specified C-VLAN.

The no form of this command disables matching on a C-VLAN.

This command filters Layer 2 IP flow data from being sent to the associated collector.

The no form of this command removes the filter, allowing Layer 2 IP flow data to be sent to the associated collector.

This command enables matching on a Layer 2 access point with a specified S-VLAN.

The no form of this command disables matching on an S-VLAN.

This command configures a NAT policy to be used with a Layer 2 outside service instead of a Layer 3 outside service. This command and the pool command are mutually exclusive.

This command enables matching on Layer 2 access points active on the specified SAP.

The no form of this command disables matching on the SAP.

This command specifies the VPLS service used for L2 wholesale. When such a service is configured no other configuration is allowed under the vlan-range.

The no form of this command removes the L2 wholesale service, this is only allowed if the l2-service node is shut down.

This command enables Layer 2 Protocol Tunneling (L2PT) termination on a specified SAP or spoke-SDP. L2PT termination is supported only for STP BPDUs. PDUs of other protocols are discarded.

This feature can be enabled only if STP is disabled in the context of the specified VPLS service.

The no form of this command reverts to the default.

This command enables Layer 2 Protocol Tunneling (L2PT) termination on a given SAP or spoke SDP. L2PT termination will be supported only for STP BPDUs. PDUs of other protocols will be discarded.

This feature can be enabled only if STP is disabled in the context of the given VPLS service.

This command enables the context to configure L2TP parameters for the host.

This command enables the context to configure L2TP parameters. L2TP extends the PPP model by allowing Layer 2 and PPP endpoints to reside on different devices interconnected by a packet-switched network.

This command sets debugging for L2TP packets.

The no form of this command removes the settings of debugging for L2TP packet.

This command enables L2TP.

The no form of this command disables L2TP.

This command enables PPP L2TP event debug.

This command enables matching on L2TP tunnels.

The no form of this command disables matching on L2TP tunnels, unless no other tunnel type specifier is configured.

This command enters the context to configure L2TP parameters. L2TP extends the PPP model by allowing Layer 2 and PPP endpoints to reside on different devices interconnected by a packet-switched network.

This command causes the associated header to be defined as an L2TP header template and enables the context to define the L2TP parameters.

This command configures an L2TP accounting policy.

The no form of this command removes the policy-name from the configuration.

This command configures the maximum number of L2TP LNS sessions per SLA profile instance or per subscriber.

The no form of this command removes the maximum number of L2TP LNS sessions limit.

This command enables the inclusion of the L2TPv2 session ID into the load-balancing hash algorithm to induce more variation and better load distribution over available links and next-hops.

The no form of this command disables the inclusion of the session-id.

This command configures the maximum number of L2TP LTS sessions per SLA profile instance or per subscriber.

The no form of this command removes the maximum number of L2TP LTS sessions limit.

This command configures the maximum number of L2TP sessions per SLA profile instance or per subscriber.

The no form of this command removes the maximum number of L2TP sessions limit.

This command sets the tunnel-id range that is used to allocate a new tunnel-id for a tunnel for which multi-chassis redundancy is configured to this MCS peer.

The no form of this command reverts to the default.

This command enables the context to configure L2TPv3 parameters.

This command enables the context to configure L2TPv3 spoke SDPs for Epipe services.

This command enables the context to configure an RX/TX cookie for L2TPv3 egress spoke SDP or for the remote-source ingress spoke SDP.

This command creates the configuration context to define the L2TPv3 tunnel parameters.

The no form of this command deletes the L2TPv3 configuration context.

This command enables matching on tunnels with L2W UEs.

The no form of this command disables matching on L2W UEs, unless UE state matching is disabled altogether.

This command configures a Layer 3 multi-chassis ring.

The no form of this command reverts to the default.

This command configures system-wide Layer 4 load balancing. The configuration at the system level can enable or disable load balancing based on Layer 4 fields. If enabled, the Layer 4 source and destination port fields will be included in hashing calculation for TCP/UDP packets.

The hashing algorithm addresses finer spraying granularity where many hosts are connected to the network.

To address more efficient traffic distribution between network links (forming a LAG group), a hashing algorithm extension takes into account L4 information (that is, src/dst L4-protocol port).

The hashing index can be calculated according to the following algorithm:

This algorithm will be used in all cases where IP information in per-packet hashing is included (refer to "Traffic Load Balancing Options" in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide). However, the Layer 4 information (TCP/UDP ports) will not be used for fragmented packets.

This command enables debugging for LDP Label packets.

The no form of the command disables the debugging output.

This command defines the MPLS value to be used in the MPLS header.

The no form of this command removes the label value.

This command enables debugging for the specified RIB-API label.

This command monitors the egress statistics of the specified RIB-API label.

This commands enables the context to configure the allocation of MPLS labels to specific BGP routes.

This command sets ECMP multipath parameters that apply only to the label IPv4 unicast address family. These settings override the values set by the maximum-paths command.

When multipath is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers equal to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth Extended Community).

To qualify as a multipath, a non-best route must meet the following criteria (some criteria are controlled by this command):

The no form of this command removes label-IPv4-specific overrides.

This command configures the add-paths capability for labeled-unicast IPv4 routes. By default, add-paths is not enabled for labeled-unicast IPv4 routes.

The maximum number of labeled-unicast paths per IPv4 prefix to send is the configured send-limit, which is a mandatory parameter. The capability to receive multiple labeled-unicast paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive keyword is not included in the command, receive capability is enabled by default.

The no form of this command disables add-paths support for labeled-unicast IPv4 routes, causing sessions established using add-paths for labeled-unicast IPv4 to go down and come back up without the add-paths capability.

This command sets ECMP multipath parameters that apply only to the label IPv4 unicast address family. These settings override the values set by the maximum-paths command.

When multipath is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers equal to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth Extended Community).

The no form of this command removes label-IPv4-specific overrides.

This command sets ECMP multipath parameters that apply only to the label unicast IPv6 address family. These settings override the values set by the maximum-paths command.

When multipath is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers equal to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth Extended Community).

To qualify as a multipath, a non-best route must meet the following criteria (some criteria are controlled by this command):

The no form of this command removes label-IPv6-specific overrides.

This command configures the add-paths capability for labeled-unicast IPv6 routes. By default, add-paths is not enabled for labeled-unicast IPv6 routes.

The maximum number of labeled-unicast paths per IPv6 prefix to send is the configured send-limit, which is a mandatory parameter. The capability to receive multiple labeled-unicast paths per prefix from a peer is configurable using the receive keyword, which is optional. If the receive keyword is not included in the command, receive capability is enabled by default.

The no form of this command disables add-paths support for labeled-unicast IPv6 routes, causing sessions established using add-paths for labeled-unicast IPv6 to go down and come back up without the add-paths capability.

This command sets ECMP multipath parameters that apply only to the label unicast IPv6 address family. These settings override the values set by the maximum-paths command.

When multipath is enabled, traffic to the destination is load-shared across a set of paths (BGP routes) that the BGP decision process considers equal to the best path. The actual distribution of traffic over the multiple paths may be equal or unequal (that is, based on weights derived from the Link Bandwidth Extended Community).

The no form of this command removes label-IPv6-specific overrides.

This command enables the context to configure advertised label IPv6 programming rules.

This command is used on transit routers when a static LSP is defined. The static LSP on the ingress router is initiated using the config router mpls static-lsp lsp-name command. An in-label can be associated with either a pop or a swap action, but not both. If both actions are specified, the last action specified takes effect.

The no form of this command deletes the static LSP configuration associated with the in-label.

This command controls the method by which service labels are allocated to routes exported by the VPRN as BGP-VPN routes. The vrf option selects service label per VRF mode while the next-hop option selects service label per next-hop mode.

The no form of this command sets the mode to the default mode of service label per VRF.

This command configures the route preference for routes learned from labeled-unicast peers.

This command can be configured at three levels:

The most specific value is used.

The lower the preference, the higher the chance of the route being the active route.

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

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 the route preference for routes learned from labeled-unicast peers.

This command can be configured at three levels:

The most specific value is used.

The lower the preference, the higher the chance of the route being the active route.

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

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 the TTL propagation for locally generated packets which are forwarded over a BGP label route in the Global Routing Table (GRT) context.

For IPv4 and IPv6 packets forwarded using a RFC 3107 label route in the global routing instance, including 6PE, the all value of the command enables TTL propagation from the IP header into all labels in the transport label stack. The none value reverts to the default mode which disables TTL propagation from the IP header to the labels in the transport label stack. This command does not have a no version.

The TTL of the IP packet is always propagated into the RFC 3107 label itself, and this command only controls the propagation into the transport labels, for example, labels of the RSVP or LDP LSP to which the BGP label route resolves and which are pushed on top of the BGP label.

If the BGP peer advertised the implicit-null label value for the BGP label route, the TTL propagation will not follow the configuration described, but will follow the configuration to which the BGP label route resolves:

RSVP LSP shortcut:

LDP LSP shortcut:

This feature does not impact packets forwarded over BGP shortcuts. The ingress LER operates in uniform mode by default and can be changed into pipe mode using the configuration of TTL propagation for RSVP or LDP LSP shortcut listed.

This command configures the TTL propagation for transit packets which are forwarded over a BGP label route in the Global Routing Table (GRT) context.

For IPv4 and IPv6 packets forwarded using a RFC 3107 label route in the global routing instance, including 6PE, the all value of the command enables TTL propagation from the IP header into all labels in the transport label stack. The none value reverts to the default mode which disables TTL propagation from the IP header to the labels in the transport label stack. This command does not have a no version.

The TTL of the IP packet is always propagated into the RFC 3107 label itself, and this command only controls the propagation into the transport labels, for example, labels of the RSVP or LDP LSP to which the BGP label route resolves and which are pushed on top of the BGP label.

If the BGP peer advertised the implicit-null label value for the BGP label route, the TTL propagation will not follow the configuration described, but will follow the configuration to which the BGP label route resolves.

RSVP LSP shortcut:

LDP LSP shortcut:

This feature does not impact packets forwarded over BGP shortcuts. The ingress LER operates in uniform mode by default and can be changed into pipe mode using the configuration of TTL propagation for the listed RSVP or LDP LSP shortcut.

This command enables the label stack size reduction for a SR-TE LSP or SR-TE LSP template.

At a high level, the label stack reduction algorithm attempts to replace a segment of a computed SR-TE LSP path with the farthest node SID on that path that results in using ECMP paths with links which still comply to the TE constraints of the LSP path.

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

This command enables the system to collect traffic statistics on the specified number of labels of the MPLS label stack.

The no form of this command disables the collecting of traffic statistics.

This command specifies configures the time interval (in s), LDP will delay for the withdrawal of FEC-label binding it distributed to its neighbors when FEC is de-activated. When the timer expires, LDP then sends a label withdrawal for the FEC to all its neighbors. This is applicable only to LDP IPv4 prefix FECs and is not applicable to pseudowires (service FECs).

When there is an upper layer (user of LDP) which depends of LDP control plane for failover detection then label withdrawal delay and tunnel-down-damp-time options must be set to 0.

An example is PW redundancy where the primary PW doesn’t have its own fast failover detection mechanism and the node depends on LDP tunnel down event to activate the standby PW.

This command enables the context to configure labeled route options for next-hop resolution.

This command configures the maximum number of L2TP LAC hosts per SLA profile instance or per subscriber.

The no form of this command removes the maximum number of L2TP LAC hosts limit.

This command specifies the LACP mode for aggregated Ethernet interfaces only. This command enables the LACP protocol. Per the IEEE 802.1ax standard, the Link Aggregation Control Protocol (LACP) provides a standardized means for exchanging information between Partner Systems on a link to allow their Link Aggregation Control instances to reach agreement on the identity of the Link Aggregation Group to which the link belongs, move the link to that Link Aggregation Group, and enable its transmission and reception functions in an orderly manner.

Note that if any of the parameters are omitted, the existing configuration is preserved. The default parameter values are used if a parameter is never explicitly configured.

This command configures the type of multiplexing machine control to be used in a LAG with LACP in active/passive modes.

The no form of this command disables multiplexing machine control.

This command configures the Link Aggregation Control Protocol (LACP) system priority on aggregated Ethernet interfaces. LACP allows the operator to aggregate multiple physical interfaces to form one logical interface.

This command enables LACP packet tunneling for the Ethernet port. When tunneling is enabled, the port will not process any LACP packets but will tunnel them instead. The port cannot be added as a member to a LAG group.

In this context, the lacp-tunnel command is supported for Epipe and VPLS services only.

The no form of this command disables LACP packet tunneling for the Ethernet port.

This command specifies the interval signaled to the peer and tells the peer at which rate it should transmit.

This command enables LACP message transmission on standby links.

The no form of this command disables LACP message transmission. This command should be disabled for compatibility when using active/standby groups. This forces a timeout of the standby links by the peer. Use the no form if the peer does not implement the correct behavior regarding the lacp sync bit.

This command defines a LAG which is forming a redundant-pair for MC-LAG with a LAG configured on the given peer. The same LAG group can be defined only in the scope of 1 peer. In order MC-LAG to become operational, all parameters (lacp-key, system-id, system-priority) must be configured the same on both nodes of the same redundant pair.

The partner system (the system connected to all links forming MC-LAG) will consider all ports using the same lacp-key, system-id, system-priority as the part of the same LAG. In order to achieve this in MC operation, both redundant-pair nodes have to be configured with the same values. In case of the mismatch, MC-LAG is kept in oper-down status.

Note that the correct CLI command to enable MC LAG for a LAG in standby-signaling power-off mode is lag lag-id [remote-lag remote-lag-id]. In the CLI help output, the first three forms are used to enable MC LAG for a LAG in LACP mode. MC LAG is disabled (regardless of the mode) for a given LAG with no lag lag-id.

This command creates the context for configuring Link Aggregation Group (LAG) attributes.

A LAG can be used to group multiple ports into one logical link. The aggregation of multiple physical links allows for load sharing and offers seamless redundancy. If one of the links fails, traffic will be redistributed over the remaining links.

Note that all ports in a LAG group must have autonegotiation set to Limited or Disabled.

There are three possible settings for autonegotiation:

When autonegotiation is enabled on a port, the link attempts to automatically negotiate the link speed and duplex parameters. If autonegotiation is enabled, the configured duplex and speed parameters are ignored.

When auto-negotiation is disabled on a port, the port does not attempt to autonegotiate and will only operate at the speed and duplex settings configured for the port. Note that disabling auto-negotiation on gigabit ports is not allowed as the IEEE 802.3 specification for gigabit Ethernet requires gigabyte be enabled for far end fault indication.

If the config>port>ethernet autonegotiate limited keyword option is specified the port will autonegotiate but will only advertise a specific speed and duplex. The speed and duplex advertised are the speed and duplex settings configured for the port. One use for limited mode is for multi-speed gigabit ports to force gigabit operation while keeping auto-negotiation is enabled for compliance with IEEE 801.3.

The system requires that auto-negotiation be disabled or limited for ports in a LAG to guarantee a specific port speed.

LAG ID, ranging from 1 to 64, support up to 64 LAG members, and LAG ID above 64, support 32 LAG members.

The no form of this command deletes the LAG from the configuration. Deleting a LAG can only be performed while the LAG is administratively shut down. Any dependencies such as IP-Interfaces configurations must be removed from the configuration before issuing the no lag command.

This command enables debugging for LAG.

This command configures a lag-id associated to the Ethernet-Segment. When the Ethernet-Segment is configured as all-active, then only a lag or PW port can be associated to the Ethernet-Segment. When the Ethernet-Segment is configured as single-active, then a lag, port or sdp can be associated to the Ethernet-Segment. In either case, only one of the four objects can be configured in the Ethernet-Segment. A specified lag can be part of only one Ethernet-Segment.

This command binds the interface to a Link Aggregation Group (LAG)

The no form of this command removes the LAG id from the configuration.

This command monitors traffic statistics for Link Aggregation Group (LAG) ports. Statistical information for the specified LAG ID(s) displays at the configured interval until the configured count is reached.

The first screen displays the current statistics related to the specified LAG ID. The subsequent statistical information listed for each interval is displayed as a delta to the previous display. When the keyword rate is specified, the rate-per-second for each statistic is displayed instead of the delta.

Monitor commands are similar to show commands but only statistical information displays. Monitor commands display the selected statistics according to the configured number of times at the interval specified.

This command enables the context to configure eth-tunnel loadsharing parameters.

This command assigns a pre-configured lag link map profile to a SAP or network interface configured on a LAG or a PW port that exists on a LAG. Once assigned or de-assigned, the SAP or network interface egress traffic is re-hashed over LAG as required by the new configuration.

The no form of this command reverts the SAP/network interface to use per-flow, service or link hash as configured for the service/LAG.

This command assigns a pre-configured lag link map profile to a SAP/network interface configured on a LAG or a PW port that exists on a LAG. Once assigned/de-assigned, the SAP’s/network interface’s egress traffic will be re-hashed over LAG as required by the new configuration.

The no form of this command reverts the SAP/network interface to use per-flow, service or link hash as configured for the service/LAG.

This command assigns a pre-configured lag link map profile to a SAP/network interface configured on a LAG or a PW port that exists on a LAG. Once assigned/unassigned, the SAP/network interface egress traffic will be re-hashed over LAG as required by the new configuration.

The no form of this command reverts the SAP/network interface to use per-flow, service or link hash as configured for the service/LAG.

This command assigns a pre-configured lag link map profile to a SAP/network interface configured on a LAG or a PW port that exists on a LAG. Once assigned/de-assigned, the SAP/network interface egress traffic will be re-hashed over LAG as required by the new configuration.

The no form of this command reverts the SAP/network interface to use per-flow, service or link hash as configured for the service/LAG.

This command assigns a pre-configured LAG link map profile to a SAP or network interface configured on a LAG or a PW port that exists on a LAG. Once assigned, the SAP or network interface egress traffic will be re-hashed over LAG as required by the new configuration.

The no form of this command reverts the SAP or network interface to use per-flow, service or link hash as configured for the service or LAG.

This command assigns a preconfigured lag link map profile to a SAP/network interface configured on a LAG or a PW port that exists on a LAG. Once assigned/unassigned, the SAP/network interface egress traffic will be re-hashed over LAG as required by the new configuration.

The no form of this command reverts the SAP/network interface to use per-flow, service or link hash as configured for the service/LAG.

This command configures weight and class to be used on LAG egress when the LAG uses weighted per-link-hash by subscribers with the profile assigned. Subscribers using profile with lag-per-link-hash default configuration, inherit weight and class from the SAP configuration (1 and 1 respectively if none configured under SAP).

The no form of this command restores default configuration.

This command configures weight and class to this SAP to be used on LAG egress when the LAG uses weighted per-link-hash.

The no form of this command restores default configuration.

This command configures weight and class to this SAP to be used on LAG egress when the LAG uses weighted per-link-hash.

The no form of this command restores default configuration.

This command configures weight and class to this SAP to be used on LAG egress when the LAG uses weighted per-link-hash.

The no form of this command restores the default configuration.

This command configures weight and class to this interface to be used on LAG egress when the LAG uses weighted per-link-hash.

The no form of this command restores the default configuration (weight 1 class 1).

This command configures the bandwidth available both at the interface and bundle level when a specific number of ports in a LAG group fail.

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

This command creates the context to configure Link Aggregation Group (LAG) priority control events that monitor the operational state of the links in the LAG.

The lag-port-down command configures a priority control event. The event monitors the operational state of each port in the specified LAG. When one or more of the ports enter the operational down state, the event is considered to be set. When all the ports enter the operational up state, the event is considered to be clear. As ports enter the operational up state, any previous set threshold that represents more down ports is considered cleared, while the event is considered to be set.

Multiple unique lag-port-down event nodes can be configured within the priority-event node up to the maximum of 32 events.

The lag-port-down command can reference an arbitrary LAG. The lag-id does have to already exist within the system. The operational state of the lag-port-down event will indicate:

When the lag-id is created, or a port in lag-id becomes operationally up or down, the event operational state must be updated appropriately.

When one or more of the LAG composite ports enters the operationally down state or the lag-id is deleted or does not exist, the event is considered to be set. When an event transitions from clear to set, the set is processed immediately and must be reflected in the associated virtual router instances in-use priority value. As the event transitions from clear to set, a hold-set timer is loaded with the value configured by the events hold-set command. This timer prevents the event from clearing until it expires, damping the effect of event flapping. If the event clears and becomes set again before the hold-set timer expires, the timer is reset to the hold-set value, extending the time before another clear can take effect.

The lag-port-down event is considered to have a tiered event set state. While the priority impact per number of ports down is totally configurable, as more ports go down, the effect on the associated virtual router instances in-use priority is expected to increase (lowering the priority). When each configured threshold is crossed, any higher thresholds are considered further event sets and are processed immediately with the hold-set timer reset to the configured value of the hold-set command. As the thresholds are crossed in the opposite direction (fewer ports down then previously), the priority effect of the event is not processed until the hold-set timer expires. If the number of ports down threshold again increases before the hold-set timer expires, the timer is only reset to the hold-set value if the number of ports down is equal to or greater than the threshold that set the timer.

The event contains number-down nodes that define the priority delta or explicit value to be used based on the number of LAG composite ports that are in the operationally down state. These nodes represent the event set thresholds. Not all port down thresholds must be configured. As the number of down ports increase, the number-down ports-down node that expresses a value equal to or less than the number of down ports describes the delta or explicit priority value to be applied.

The no form of the command deletes the specific LAG monitoring event. The event can be removed at anytime. When the event is removed, the in-use priority of all associated virtual router instances must be reevaluated. The events hold-set timer has no effect on the removal procedure.

This command enables the router’s usage of the LAG so traffic for a given multicast stream destined to an IP interface using the LAG is sent only to the forwarding complex that owns the LAG link on which it will actually be forwarded.

Changing the value causes the PIM protocol to be restarted.

If this optimization is disabled, the traffic is sent to all forwarding complexes that own at least one link in the LAG.

The no form of this command causes the traffic to be sent to all the forwarding complexes that own at least one link in the LAG.

Note: Changes made for multicast hashing cause Layer 4 multicast traffic to not be hashed. This is independent of if lag-usage-optimization is enabled or disabled. Using this command and the mc-ecmp-hashing-enabled command on mixed port speed LAGs is not recommended, because some groups may be forwarded incorrectly.

This command enables the context to configure HLE parameters.

The no form of this command disables the vRGW parameters enabled in this context.

This command enables the context to configure HLE parameters.

The no form of this command disables the context.

This command enables the context to configure subscriber management vRGW home HLE parameters.

The no form of this command disables the context.

This command enables the system to include the HLE service’s bridge ID (Alc-Bridge-Id) in RADIUS accounting packets.

The no form of this command excludes the HLE service’s bridge ID (Alc-Bridge-Id) from RADIUS accounting packets.

This command enables the system to include the HLE host’s device type (Alc-HLE-Device-Type) in RADIUS accounting packets.

The no form of this command excludes the HLE host’s device type (Alc-HLE-Device-Type) from RADIUS accounting packets.

This command enables the system to include the HLE service’s EVPN route distinguisher (Alc-RD) in RADIUS accounting packets.

The no form of this command excludes the HLE service’s EVPN route distinguisher (Alc-RD) from RADIUS accounting packets.

This command enables the system to include the HLE service’s EVPN route target (Alc-RT) in RADIUS accounting packets.

The no form of this command excludes the HLE service’s EVPN route target (Alc-RT) from RADIUS accounting packets.

This command enables the system to include the HLE service’s EVPN VXLAN VNI (Alc-Vxlan-VNI) in RADIUS accounting packets.

The no form of this command excludes the HLE service’s EVPN VXLAN VNI (Alc-Vxlan-VNI) from RADIUS accounting packets.

This command configures the maximum response time used in group-specific queries sent in response to 'leave' messages, and is also the amount of time between two consecutive group-specific queries. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group.

The configured last-member-query-interval is ignored when fast leave is enabled on the SAP or SDP.

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

This command configures the maximum response time used in group-specific queries sent in response to leave messages, and is also the amount of time between two consecutive group-specific queries. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group.

The configured interval is ignored when fast-leave is enabled on the SAP or SDP.

The no form of this command reverts to the default.

This command configures the maximum response time used in group-specific queries sent in response to ‘leave’ messages, and is also the amount of time between 2 consecutive group-specific queries. This value may be tuned to modify the leave latency of the network. A reduced value results in reduced time to detect the loss of the last member of a group.

The configured last-member-query-interval is ignored when fast-leave is enabled on the SAP or SDP.

Specifies that at the termination of an SAA test probe, the calculated latency event value is evaluated against the configured rising and falling latency event thresholds. SAA threshold events are generated as required.

Once the threshold (rising/falling) is crossed, it is disabled from generating additional events until the opposite threshold is crossed. If a falling-threshold is not supplied, the rising- threshold is re-enabled when it falls below the threshold after the initial crossing that generated the event.

The configuration of latency event thresholds is optional.

The no form of this command disables the latency event.

This command enables the context to configure SHCV behavior parameters for IES and VPRN services.

This command specifies the format of the routable encapsulation to add to each copied packet. Layer 3 encapsulation takes precedence over Ethernet encapsulation configuration in an LI source. No changes are allowed to the Layer 3 encapsulation once a gateway is configured.

The no form of this command removes the routable encapsulation.

This command specifies the format of the routable encapsulation to add to each copied packet. Layer 3 encapsulation takes precedence over Ethernet encapsulation configuration in an LI source. No changes are allowed to the Layer 3 encapsulation after a gateway is configured.

The no form of this command disables Layer 3 encapsulation.

This command enables the MEP to process service activation streams encapsulated in ETH-CFM LBM frames that are directed to the MEP. The MEP will be allocated additional resources to rapidly respond to a high-speed stream of LBM messages. A MEP created with this option will not validate any TLVs, will not validate the ETH-LBM MAC Address, and will not increment or compute any loopback statistics. Statistical computation and reporting is the responsibility of the test head-end. The ETH-CFM level of the high speed ETH-LBM stream must match the level of a MEP configured with this command. It must not target any lower ETH-CFM level the MEP will terminate. When the service activation test is complete, the MEP may be returned to standard processing by removing this command. If there is available bandwidth, the MEP will respond to other ETH-CFM PDUs, such as ETH-DMM marker packets, using standard processing.

The interaction between this command and the tools perform service id service-id loopback eth command must be carefully considered. It is recommended that either the lbm-svc-act-responder or the tools perform service id service-id loopback eth command be used at any given time within a service. If both commands must be configured, and the target reflection point is the MAC Swap Loopback function, the inbound stream of data must not include ETH-CFM traffic that is equal to or lower than the domain level of any configured MEP which would otherwise extract and process the ETH-CFM message. If the reflection target is a MEP configured with the lbm-svc-act-responder option, the mode (ingress or egress) of the SAP or SDP specified with this tools command and the MEP direction (up or down) must match when the functions are enabled on the same reflection point, and the domain level of the inbound ETH-LBM must be the same as that of the MEP configured with the lbm-svc-act-responder option. At no time should the two functions be conflicting with each other along the path of the stream. This conflict would lead to unpredictable and possibly destabilizing situations.

The no form of this command reverts to MEP LBM standard processing.

This command enables the MEP to process service activation streams encapsulated in ETH-CFM LBM frames that are directed to the MEP. The MEP will be allocated additional resources to rapidly respond to a high-speed stream of LBM messages. A MEP created with this option will not validate any TLVs, will not validate the ETH-LBM MAC Address, and will not increment or compute any loopback statistics. Statistical computation and reporting is the responsibility of the test head-end. The ETH-CFM level of the high speed ETH-LBM stream must match the level of a MEP configured with this command. It must not target any lower ETH-CFM level the MEP will terminate. When the service activation test is complete, the MEP may be returned to standard processing by removing this command. If there is available bandwidth, the MEP will respond to other ETH-CFM PDUs, such as ETH-DMM marker packets, using standard processing.

The interaction between this command and the tools perform service id service-id loopback eth command must be carefully considered. It is recommended that either the lbm-svc-act-responder or the tools perform service id service-id loopback eth command be used at any given time within a service. If both commands must be configured, and the target reflection point is the MAC Swap Loopback function, the inbound stream of data must not include ETH-CFM traffic that is equal to or lower than the domain level of any configured MEP which would otherwise extract and process the ETH-CFM message. If the reflection target is a MEP configured with the lbm-svc-act-responder option, the mode (ingress or egress) of the SAP or SDP specified with this tools command and the MEP direction (up or down) must match when the functions are enabled on the same reflection point, and the domain level of the inbound ETH-LBM must be the same as that of the MEP configured with the lbm-svc-act-responder option. At no time should the two functions be conflicting with each other along the path of the stream. This conflict would lead to unpredictable and possibly destabilizing situations.

The no form of this command reverts to MEP LBM standard processing.

This command enables the MEP to process service activation streams encapsulated in ETH-CFM LBM frames that are directed to the MEP. The MEP will be allocated additional resources to rapidly respond to a high-speed stream of LBM messages. A MEP created with this option will not validate any TLVs, will not validate the ETH-LBM MAC Address, and will not increment or compute any loopback statistics. Statistical computation and reporting is the responsibility of the test head-end. The ETH-CFM level of the high speed ETH-LBM stream must match the level of a MEP configured with this command. It must not target any lower ETH-CFM level the MEP will terminate. When the service activation test is complete, the MEP may be returned to standard processing by removing this command. If there is available bandwidth, the MEP will respond to other ETH-CFM PDUs, such as ETH-DMM marker packets, using standard processing.

The interaction between this command and the tools perform service id service-id loopback eth command must be carefully considered. It is recommended that either the lbm-svc-act-responder or the tools perform service id service-id loopback eth command be used at any given time within a service. If both commands must be configured, and the target reflection point is the MAC Swap Loopback function, the inbound stream of data must not include ETH-CFM traffic that is equal to or lower than the domain level of any configured MEP which would otherwise extract and process the ETH-CFM message. If the reflection target is a MEP configured with the lbm-svc-act-responder option, the mode (ingress or egress) of the SAP or SDP specified with this tools command and the MEP direction (up or down) must match when the functions are enabled on the same reflection point, and the domain level of the inbound ETH-LBM must be the same as that of the MEP configured with the lbm-svc-act-responder option. At no time should the two functions be conflicting with each other along the path of the stream. This conflict would lead to unpredictable and possibly destabilizing situations.

The no form of this command reverts to MEP LBM standard processing.

This command applies only to a DS-1 port configured with a 'long' buildout (see the buildout command). Specify the number of decibels the transmission signal decreases over the line.

For 'short' buildout the following values are valid:

lboNotApplicable — Not applicable

For 'long' buildout the following values are valid:

The default for 'short' build out is 'NotApplicable' while the default for 'long' buildout is 'lbo0dB'.

This command enables the LCP Asynchronous Control Character Map (ACCM) configuration option. When enabled, the LCP ACCM configuration option is acknowledged during LCP negotiation between the LNS and the PPP client. The option is then ignored and no ACCM mapping is done.

By default, an L2TP tunnel inherits the configuration from the L2TP group CLI context.

The no form of this command disables the LCP ACCM configuration option.

This command configures checking the magic number field in LCP Echo-Request and LCP Echo-Reply messages.

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

This command enables the PPP session to stay established when an LCP peer magic number mismatch is detected.

By default, the PPP session is terminated when an LCP peer magic number mismatch is detected.

This command configures LDAP authentication parameters for the system.

The no form of this command de-configures the LDAP client from the SR OS.

This command configures the LDAP server name or description.

The no version of this command removes the LDAP server name.

This command selects the LDP tunnel type.

This command instructs BGP to search for an LDP LSP with a FEC prefix corresponding to the address of the BGP next hop.

The no form of this command removes the configuration.

This command enables setting the LDP type for the auto bind tunnel.

The ldp value instructs BGP to search for an LDP LSP with a FEC prefix corresponding to the address of the BGP next hop.

This command creates the context to configure an LDP parameters. LDP is not enabled by default and must be explicitly enabled (no shutdown).

To suspend the LDP protocol, use the shutdown command. Configuration parameters are not affected.

The no form of the command deletes the LDP protocol instance, removing all associated configuration parameters. The LDP instance must first be disabled with the shutdown command before being deleted.

Use this command to configure LDP debugging.

This command enables the use of LDP sourced tunnel entries in the TTM to resolve the associated static route next-hop.

This command enables LDP-signaled LSPs on MPLS-encapsulated SDPs.

In MPLS SDP configurations either one or more LSP names can be specified or LDP can be enabled. The SDP ldp and lsp commands are mutually exclusive except if the mixed-lsp-mode option is also enabled. If an LSP is specified on an MPLS SDP, then LDP cannot be enabled on the SDP. To enable LDP on the SDP when an LSP is already specified, the LSP must be removed from the configuration using the no lsp lsp-name command or the mixed-lsp-mode option is also enabled.

Alternatively, if LDP is already enabled on an MPLS SDP, then an LSP cannot be specified on the SDP. To specify an LSP on the SDP, the LDP must be disabled. The LSP must have already been created in the config>router>mpls context with a valid far-end IP address. The above rules are relaxed when the mixed-lsp option is enabled on the SDP.

This command monitors commands for the LDP instance.

This command selects LDP tunneling for next-hop resolution and specifies the LDP tunnels in the tunnel table corresponding to /32 IPv4 FECs and /128 IPv6 FECs.

This command configures an LSP so that it can be used by the IGP to calculate its SPF tree.

When the ldp-over-rsvp option is also enabled in ISIS or OSPF, the IGP provides LDP with all ECMP IP next-hops and tunnel endpoints that it considers to be the lowest cost path to its destination.

IGP provides only the endpoints which are the closest to the destination in terms of IGP cost for each IP next-hop of a prefix. If this results in more endpoints than the ECMP value configured on the router, it will further prune the endpoints based on the lowest router-id and for the same router-id, it will select lowest interface-index first.

LDP then looks up the tunnel table to select the actual tunnels to the endpoint provided by IGP and further limits the endpoint selection to the ones which are the closest to destination across all the IP next-hops provided by IGP for a prefix. For each remaining endpoint, LDP selects a tunnel in a round-robin fashion until the router ECMP value is reached. For each endpoint, only tunnels with the same lowest metric are candidates. If more than one tunnel qualifies, the selection begins with the lowest tunnel-id.

This command allows LDP over RSVP processing in IS-IS.

The no form of this command disables LDP over RSVP processing.

This command allows LDP-over-RSVP processing in this OSPF instance.

This command enables the resolution of IGP routes using LDP LSP across all network interfaces participating in the IS-IS and OSPF routing protocol in the system.

When LDP shortcut is enabled, LDP populates the routing table with next-hop entries corresponding to all prefixes for which it activated an LDP FEC. For a given prefix, two route entries are populated in the system routing table. One corresponds to the LDP shortcut next-hop and has an owner of LDP. The other one is the regular IP next-hop. The LDP shortcut next-hop always has preference over the regular IP next-hop for forwarding user packets and specified control packets over a given outgoing interface to the route next-hop.

All user and specified control packets for which the longest prefix match in RTM yields the FEC prefix will be forwarded over the LDP LSP.

When an IPv4 packet is received on an ingress network interface, a subscriber IES interface, or a regular IES interface, the lookup of the packet by the ingress forwarding engine will result in the packet being sent labeled with the label stack corresponding to the NHLFE of the LDP LSP when the preferred RTM entry corresponds to an LDP shortcut.

If the preferred RTM entry corresponds to an IP next-hop, the IPv4 packet is forwarded without a label.

When ECMP is enabled and multiple equal-cost next-hops exit for the IGP route, the ingress forwarding engine will spray the packets for this route based on hashing routine currently supported for IPv4 packets. When the preferred RTM entry corresponds to an LDP shortcut route, spraying will be performed across the multiple next-hops for the LDP FEC. The FEC next-hops can either be direct link LDP neighbors or T-LDP neighbors reachable over RSVP LSPs in the case of LDP-over-RSVP but not both.

When the preferred RTM entry corresponds to a regular IP route, spraying will be performed across regular IP next-hops for the prefix.

The no form of this command disables the resolution of IGP routes using LDP shortcuts.

This command extends the LDP synchronization feature to a static route. When an interface comes back up, it is possible that a preferred static route using the interface as next-hop for a given prefix is enabled before the LDP adjacency to the peer LSR comes up on this interface. In this case, traffic on an SDP that uses the static route for the far-end address would be black-holed until the LDP session comes up and the FECs exchanged.

This option when enabled delays the activation of the static route until the LDP session comes up over the interface and the ldp-sync-timer configured on that interface has expired

This command extends the LDP synchronization feature to a static route. When an interface comes back up, it is possible that a preferred static route using the interface as next-hop for a given prefix is enabled before the LDP adjacency to the peer LSR comes up on this interface. In this case, traffic on an SDP that uses the static route for the far-end address would be black-holed until the LDP session comes up and the FECs exchanged.

This option when enabled delays the activation of the static route until the LDP session comes up over the interface and the ldp-sync-timer configured on that interface has expired

This command enables synchronization of an IGP and LDP. When a link is restored after a failure, the IGP sets the link cost to infinity and advertises it. The actual value advertised in OSPF is 0xFFFF (65535). The actual value advertised in IS-IS regular metric is 0x3F (63) and in IS-IS wide-metric is 0xFFFFFE (16777214). This feature is not supported on RIP interfaces.

If an interface belongs to both IS-IS and OSPF, a physical failure will cause both IGPs to advertise an infinite metric and to follow the IGP-LDP synchronization procedures. If only one IGP bounces on this interface or on the system, then only the affected IGP advertises the infinite metric and follows the IGP-LDP synchronization procedures.

Next, an LDP Hello adjacency is brought up with the neighbor. The LDP synchronization timer is started by the IGP when the LDP session to the neighbor is up over the interface. This is to allow time for the label-FEC bindings to be exchanged.

When the LDP synchronization timer expires, the link cost is restored and is readvertised. The IGP will announce a new best next hop and LDP will use it if the label binding for the neighbor’s FEC is available.

If the user changes the cost of an interface, the new value is advertised at the next flooding of link attributes by the IGP. However, if the LDP synchronization timer is still running, the new cost value will only be advertised after the timer expires. The new cost value will also be advertised after the user executes any of the following commands:

If the user changes the value of the LDP synchronization timer parameter, the new value will take effect at the next synchronization event. If the timer is still running, it will continue to use the previous value.

If parallel links exist to the same neighbor, then the bindings and services should remain up as long as there is one interface that is up. However, the user-configured LDP synchronization timer still applies on the interface that failed and was restored. In this case, the router will only consider this interface for forwarding after the IGP re-advertises its actual cost value.

The LDP Sync Timer State is not always synchronized across to the standby CPM. Therefore, after an activity switch, the timer state might not be same as it was on the previously active CPM.

If the end-of-lib option is configured, then the system will start the LDP synchronization timer as usual. If the LDP End of LIB Typed Wildcard FEC messages are received for every FEC type negotiated for a given session to an LDP peer for that IGP interface, the ldp-sync-timer is terminated early and the IGP link cost is restored. If the ldp-sync-timer expires before the LDP End of LIB messages are received for every negotiated FEC type, then the system will restore the IGP link cost. The end-of-lib option is disabled by default.

The no form of this command disables IGP-LDP synchronization and deletes the configuration.

This command allows the user to perform a single run of the LDP ECMP OAM tree trace to discover all ECMP paths of an LDP FEC.

This command creates the context to configure the LDP ECMP OAM tree trace which consists of an LDP ECMP path discovery and an LDP ECMP path probing features.

The no form of this command deletes the configuration for the LDP ECMP OAM tree discovery and path probing under this context.

This command enables debugging for OAM LDP treetrace.

The no form of this command disables the debugging.

This command enables debugging for IS-IS leaks.

The no form of the command disables debugging.

This command enables debugging for OSPF leaks.

This command associates up to four policies to control the leaking of GRT routes into the associated VPRN.

If a route is being evaluated and the action is accepted, then that route is subject leaking into an associated VPRN instance assuming the route is fully resolved and active.

This process creates the pool of routes that can be leaked. Within each VPRN a corresponding import-grt policy must be configured to import select routes into that specific VPRN instance.

The no form of this command removes all route leaking policy associations and effectively disables the leaking of GRT routes into associated VPRNs.

This command sets a maximum limit on the number of GRT routes that can be leaked into VPRNs.

The no form of this command resets the leak-export-limit to its default value of 5.

This command is used to specify route policies that control the importation of leak-eligible routes from the BGP RIB of another routing instance into the unlabeled-IPv4, unlabeled-IPv6, or labeled-IPv4 RIB of the base router. To leak a route from one routing instance to another, the origin and destination RIB types must be the same; for example, it is not possible to leak a route from an unlabeled-IPv4 RIB of a VPRN into the labeled-IPv4 RIB of the base router.

The leak-import command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine final action to accept or reject the route.

Only one of the 15 objects referenced by the leak-import command is allowed to be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters while the remaining 14 objects have a maximum length of 64 characters each.

When multiple leak-import commands are issued, the last command entered overrides the previous command.

When a leak-import policy is not specified, no BGP routes from other routing instances are leaked into the VPRN BGP RIB.

The no form of this command removes the policy association.

This command is used to specify route policies that control the importation of leak-eligible routes from the BGP RIB of another routing instance into the unlabeled-IPv4, unlabeled-IPv6, or labeled-IPv4 RIB of the base router. To leak a route from one routing instance to another, the origin and destination RIB types must be the same; for example, it is not possible to leak a route from an unlabeled-IPv4 RIB of a VPRN into the labeled-IPv4 RIB of the base router.

The leak-import command can reference up to 15 objects, where each object is either a policy logical expression or the name of a single policy. The objects are evaluated in the specified order to determine final action to accept or reject the route.

Only one of the 15 objects referenced by the leak-import command is allowed to be a policy logical expression consisting of policy names (enclosed in square brackets) and logical operators (AND, OR, NOT). The first of the 15 objects has a maximum length of 255 characters while the remaining 14 objects have a maximum length of 64 characters each.

When multiple leak-import commands are issued, the last command entered overrides the previous command.

When a leak-import policy is not specified, no BGP routes from other routing instances are leaked into the base router BGP RIB.

The no form of this command removes the policy association.

This command enables the sending of ARP or ND packets on the WLAN-GW GRE tunnel for certain events. The target IP address in the ARP/ND packet is the endpoint IP address of the AP. The ARP/ND response from the AP should contain the AP MAC, which subsequently can be reported in a called-station-id message. When enabled, a message will be sent for following events:

This configuration is ignored for L2-AP and L2TPv3 access.

This command controls whether the ARP or ND frames received on EVPN binds are used to learn dynamic ARP and ND entries in the ARP/ND table.

The no form of the command reverts to the default.

This command specifies when this system will learn the cookie from L2TP tunnels terminating on this interface. Learning the cookie means that the value of the octets 3-8 of the cookie is interpreted as an access point’s MAC address, and used as such, for example in the Called-Station-Id attribute of RADIUS Interim-Update messages.

This command configures the time to remember this lease and is applicable for unsolicited release conditions such as lease timeout if the lease-hold-time-for command is set to the default value no solicited-release and is additionally applicable for normal solicited releases from DHCP clients if the lease-hold-time-for command is set to solicited-release.

The no form of this command reverts to the default.

This command enables the context to configure lease-hold-time-for parameters which define additional types of lease or triggers that cause system to hold up leases.

The no form of this command reverts to the default.

This command enables the context to configure IPoE host parameters.

For VPLS, DHCP snooping must be explicitly enabled (using the snoop command) at all points where DHCP messages requiring snooping enter the VPLS instance (both from the DHCP server and from the subscribers). Lease state information is extracted from snooped DHCP ACK messages to populate lease state table entries for the SAP.

The optional number-of-leases parameter defines the number lease state table entries allowed.

If the number-of-leases parameter is omitted, only a single entry is allowed. Once the maximum number of entries has been reached, subsequent lease state entries are not allowed and subsequent DHCP ACK messages are discarded.

The retained lease state information representing dynamic hosts may be used to:

The no form of this command reverts to the default.

This command enables and disables dynamic host lease state management for VPLS SAPs. For VPLS, DHCP snooping must be explicitly enabled (using the snoop command) at all points where DHCP messages requiring snooping enter the VPLS instance (both from the DHCP server and from the subscribers). Lease state information is extracted from snooped DHCP ACK messages to populate lease state table entries for the SAP.

The optional number-of-entries parameter is used to define the number of lease state table entries allowed for this SAP or IP interface. If number-of-entries is omitted, only a single entry is allowed. Once the maximum number of entries has been reached, subsequent lease state entries are not allowed and subsequent DHCP ACK messages are discarded.

The retained lease state information representing dynamic hosts may be used to:

This command specifies the maximum number of DHCPv6 lease states allocated by the DHCPv6 relay function, allowed on this interface.

Optionally, by specifying route-populate parameter, system could:

These routes could be redistributed into IGP/BGP by using route-policy, following protocol types that could be used in “from protocol”:

This command specifies the maximum number of DHCPv6 lease states allocated by the DHCPv6 relay function, allowed on this interface.

Optionally, by specifying “route-populate” parameter, system could:

These routes could be redistributed into IGP/BGP by using route-policy, following protocol types that could be used in “from protocol”:

This command enables lease-query. If this is specified the dhcp6-client will retrieve any existing addresses when becoming active. The lease-query is performed for all of the configured servers

The no form of this command disables lease-query.

This command configures the time the client transitions to a rebinding state for a DHCP client.

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

This command configures the time the client transitions to a renew state for a DHCP client.

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

This command configures the amount of time that the DHCP server grants to the DHCP client permission to use a specific IP address.

The no form of this command removes the lease time parameters from the configuration.

This command defines the length of lease-time that is provided to DHCP clients. By default, the local-proxy-server always makes use of the lease time information provide by either a RADIUS or DHCP server.

The no form of this command disables the use of the lease-time command. The local-proxy-server will use the lease-time offered by either a RADIUS or DHCP server.

This command configures the amount of time that the DHCP server grants to the DHCP client permission to use a particular IP address.

The no form of this command removes the lease time parameters from the configuration.

This command configures the lease time, in seconds, to be used when allocating addresses from the pool. This time value should always be longer than the renew/rebind time.

The no form of this command reverts to the default.

This command enables the use of the least-fill path selection method for the computation of the path of this LSP.

When MPLS requests the computation of a path for this LSP, CSPF will find all equal cost shortest paths which satisfy the constraints of this path. Then, CSPF identifies the single link in each of these paths which has the least available bandwidth as a percentage of its maximum reservable bandwidth. It then selects the path which has the largest value of this percentage least available bandwidth figure. CSPF identifies the least available bandwidth link in each equal cost path after it has accounted for the bandwidth of the new requested path of this LSP.

CSPF applies the least-fill path selection method to all requests for a path, primary and secondary, of an LSP for which this option is enabled. The bandwidth of the path can be any value, including zero.

CSPF applies the least-fill criterion separately to each preemption priority in the base TE. A higher setup priority path can preemptively lower holding priority paths.

CSPF also applies the least-fill criterion separately to each Diff-Serv TE class if Diff-Serv TE is enabled on this node. A higher setup priority path can preemptively lower holding priority paths within a Class Type.

MPLS will re-signal and move the LSP to the new path in the following cases:

During a manual re-signaling of an LSP path, MPLS will always re-signal the path regardless of whether the new path is exactly the same or different than the current path and regardless of whether the metric of the new path is different or not from that of the current path.

During a timer-based re-signaling of an LSP path which has the least-fill option enabled, MPLS will only re-signal the path if the metric of the new path is different than the one of the current path.

The no form of this command deletes a specific node entry in this database.

This parameter is used in the least-fill path selection process. When comparing the percentage of least available link bandwidth across the sorted paths, whenever two percentages differ by less than the value configured as the least-fill-min-thresh, CSPF will consider them equal and will apply a random number generator to select the path among these paths

The no form of this command resets this parameter to its default value.

This parameter is used in the least-fill path selection method. During a timer-based re-signaling of an LSP path which has the least-fill option enabled, CSPF will first update the least-available bandwidth figure for the current path of this LSP. It then applies the least-fill path selection method to select a new path for this LSP. If the new computed path has the same cost as the current path, it will compare the least-available bandwidth figures of the two paths and if the difference exceeds the user configured optimization threshold, MPLS will generate a trap to indicate that a better least-fill path is available for this LSP. This trap can be used by an external SNMP based device to trigger a manual re-signaling of the LSP path since the timer-based re-signaling will not re-signal the path in this case. MPLS will generate a path update trap at the first MBB event which results in the re-signaling of the LSP path. This should clear the eligibility status of the path at the SNMP device.

The no form of this command resets this parameter to its default value.

This command enables debugging of the leave all state machine.

The no form of this command disables debugging of the leave all state machine.

This command controls the frequency with which the LeaveAll state machine generates LeaveAll PDUs. The timer is required on a per-Port, per-MRP Participant basis. The Leave All Period Timer is set to a random value, T, in the range LeaveAllTime<T<1.5*leave-all-time when it is started. Refer to IEEE 802.1ak-2007 section 10.7.4.3.

This command controls the period of time that the Registrar state machine will wait in the leave state before transitioning to the MT state when it is removed. An instance of the timer is required for each state machine that is in the leave state. The Leave Period Timer is set to the value leave-time when it is started.

A registration is normally in an “in” state where there is an MFIB entry and traffic is being forwarded. When a “leave all” is performed (periodically around every 10-15 seconds per SAP/SDP binding - see leave-all-time-below), a node sends a message to its peer indicating a leave all is occurring and puts all of its registrations in leave state.

The peer refreshes its registrations based on the leave all PDU it receives and sends a PDU back to the originating node with the state of all its declarations.

Refer to IEEE 802.1ak-2007 section 10.7.4.2.

This command enables legacy mode of advertising TE attributes.

The no form of this command disables legacy mode, but enables the per-application TE attribute advertisement for RSVP-TE.

This command provides for a global LDP knob to allow interoperability with legacy IPv4 LSR implementations which do not comply with the processing of Hello TLVs with the U-bit set. Specifically, this feature disables the following Hello TLVs:

This command applies only to a DS-1 port configured with a 'short' buildout. The length command configures the length of the line (in feet). For line lengths longer than 655 feet, configure the DS-1 port buildout as 'long'.

For 'long' buildout the following values are valid:

NotApplicable — Not applicable

For 'short' buildout the following values are valid:

The default for 'long' buildout is 'NotApplicable' while the default for 'short' buildout is '0 to 133'.

This command sets the number of lines on a screen.

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

This command is used to enable tunnel QoS mapping on all ingress network IP interfaces that the network-qos-policy-id is associated with. The command may be defined at any time after the network QoS policy has been created. Any network IP interfaces currently associated with the policy will immediately start to use the internal IP ToS field of any tunnel terminated IP routed packet received on the interface, ignoring any QoS markings in the tunnel portion of the packet.

This attribute provides the ability to ignore the network ingress QoS mapping of a terminated tunnel containing an IP packet that is to be routed to a base router or VPRN destination. This is advantageous when the mapping for the tunnel QoS marking does not accurately or completely reflect the required QoS handling for the IP routed packet. When the mechanism is enabled on an ingress network IP interface, the IP interface will ignore the tunnel’s QoS mapping and derive the internal forwarding class and profile based on the precedence or DiffServ Code Point (DSCP) values within the routed IP header ToS field compared to the Network QoS policy defined on the IP interface.

The default state is not to enforce tunnel termination IP routed QoS override within the network QoS policy.

The no form of this command removes tunnel termination IP routed QoS override from the network QoS policy and all ingress network IP interfaces associated with the policy.

This command allows a CIDR shortest match hit on a route prefix that contains the IP route prefix associated with the route unknown priority event.

The less-specific command modifies the search parameters for the IP route prefix specified in the route-unknown priority event. Specifying less-specific allows a CIDR shortest match hit on a route prefix that contains the IP route prefix.

The less-specific command eases the RTM lookup criteria when searching for the prefix/mask-length. When the route-unknown priority event sends the prefix to the RTM (as if it was a destination lookup), the result route table prefix (if a result is found) is checked to see if it is an exact match or a less specific match. The less-specific command enables a less specific route table prefix to match the configured prefix. When less-specific is not specified, a less specific route table prefix fails to match the configured prefix. The allow-default optional parameter extends the less-specific match to include the default route (0.0.0.0).

The no form of the command prevents RTM lookup results that are less specific than the route prefix from matching.

This command configures levels and their associated bandwidth for multicast CAC policy on an interface.

The no form of this command reverts to the default.

This command overrides the maximum and CIR rate parameters for a specific priority level on the port or channel’s port scheduler instance. When the level command is executed for a priority level, the corresponding priority level command in the port-scheduler-policy associated with the port is ignored.

The override level command supports the keyword max for the rate and cir parameter. When executing the level override command, at least the rate or cir keywords and associated parameters must be specified for the command to succeed.

The no form of this command removes the local port priority level rate overrides. Once removed, the port priority level will use the port scheduler policies level command for that priority level.

This command creates the context to configure SPB Level 1 or Level 2 area attributes. This is IS-IS levels. Only Level 1 can be configured.

A Level 1 adjacency can be established only with other Level 1 B-VPLS. A Level 2 adjacency can be established only with other Level 2 B-VPLS. Currently there is no support for level 1 and level 2 in the same instance of SPB.

This command enters the context to configure SPB level information.

This command configures levels and their associated bandwidth for multicast CAC policy on this interface.

This command configures interface levels and associated bandwidth for multicast CAC policy.

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

This command creates the context to configure IS-IS Level 1 or Level 2 area attributes.

A router can be configured as a Level 1, Level 2, or Level 1-2 system. A Level 1 adjacency can be established if there is at least one area address shared by this router and a neighbor. A Level 2 adjacency cannot be established over this interface.

Level 1/2 adjacency is created if the neighbor is also configured as Level 1/2 router and has at least one area address in common. A Level 2 adjacency is established if there are no common area IDs.

A Level 2 adjacency is established if another router is configured as Level 2 or a Level 1/2 router with interfaces configured as Level 1/2 or Level 2. Level 1 adjacencies are not established over this interface.

To reset global and/or interface level parameters to the default, the following commands must be entered independently:

level> no hello-authentication-key level> no hello-authentication-type level> no hello-interval level> no hello-multiplier level> no metric level> no passive level> no priority

This command configures the syslog message severity level threshold. All messages with severity level equal to or higher than the threshold are sent to the syslog target host.

Only a single threshold level can be specified. If multiple levels are entered, the last level entered will overwrite the previously entered commands.

This command configures the amount of bandwidth available within a given bundle for MC traffic for a specified level. The amount of allowable BW for the specified level is expressed in kb/s and this can be defined for up to eight different levels.

If no bandwidth is defined for a given level then no limit is applied.

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

This command configures an explicit within-CIR bandwidth limit and a total bandwidth limit for each port scheduler’s priority level. To understand how to set the level rate and CIR parameters, a basic understanding of the port-level scheduler bandwidth allocation mechanism is required. The port scheduler takes all available bandwidth for the port or channel (after the max-rate and any port egress-rate limits have been accounted for) and offers it to each of the eight priority levels twice.

The first pass is called the within-CIR pass and consists of providing the available port bandwidth to each of the 8 priority levels, starting with level 8 and moving down to level 1. Each level takes the offered load and distributes it to all child members that have a port-parent cir-level equal to the current priority level. (Any child with a cir-weight equal to 0 is skipped in this pass.) Each child may consume bandwidth up to the child’s frame-based within-CIR offered load. The remaining available port bandwidth is then offered to the next lower priority level until level 1 is reached.

The second pass is called the above-CIR pass and consists of providing the remaining available port bandwidth to each of the eight priority levels a second time. Again, each level takes the offered load and distributes it to all child members that have a port-parent level equal to the current priority level. Each child may consume bandwidth up to the remainder of the child’s frame-based offered load (some of the offered load may have been serviced during the within-CIR pass). The remaining available port bandwidth is then offered to the next priority level until level 1 is again reached.

If the port scheduling policy is using the default orphan behavior (orphan-override has not been configured on the policy), the system then takes any remaining port bandwidth and allocates it to the orphan queues and scheduler on priority level 1. In a non-override orphan state, all orphans are attached to priority level 1 using a weight of 0. The zero weight value causes the system to allocate bandwidth equally to all orphans based on each orphan queue or scheduler’s ability to use the bandwidth. If the policy has an orphan-override configured, the orphans are handled based on the override commands parameters in a similar fashion to properly parented queues and schedulers.

The port scheduler priority level command rate keyword is used to optionally limit the total amount of bandwidth that is allocated to a priority level (total for the within-CIR and above-CIR passes). The cir keyword optionally limits the first pass bandwidth allocated to the priority level during the within-CIR pass.

When executing the level command, at least one of the optional keywords, rate or cir, must be specified. If neither keyword is included, the command will fail.

If a previous explicit value for rate or cir exists when the level command is executed, and either rate or cir is omitted, the previous value for the parameter is overwritten by the default value and the previous value is lost.

The configured priority level rate limits may be overridden at the egress port or channel using the egress-scheduler-override level priority-level command. When a scheduler instance has an override defined for a priority level, both the rate and cir values are overridden even when one of them is not explicitly expressed in the override command. For instance, if the cir kilobits per second portion of the override is not expressed, the scheduler instance defaults to not having a CIR rate limit for the priority level even when the port scheduler policy has an explicit CIR limit defined.

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

This command configures the syslog message severity level threshold. All messages with severity level equal to or higher than the threshold are sent to the syslog target host.

Only a single threshold level can be specified. If multiple levels are entered, the last level entered will overwrite the previously entered commands.

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

This command creates the context to configure IS-IS Level 1 or Level 2 area attributes.

A router can be configured as a Level 1, Level 2, or Level 1-2 system. A Level 1 adjacency can be established if there is at least one area address shared by this router and a neighbor. A Level 2 adjacency cannot be established over this interface.

Level 1/2 adjacency is created if the neighbor is also configured as Level 1/2 router and has at least one area address in common. A Level 2 adjacency is established if there are no common area IDs.

A Level 2 adjacency is established if another router is configured as Level 2 or a Level 1/2 router with interfaces configured as Level 1/2 or Level 2. Level 1 adjacencies will not be established over this interface.

To reset global and/or interface level parameters to the default, the following commands must be entered independently:

This command specifies the ISIS route level as a match criterion for the entry.

This command configures the routing level for an instance of the IS-IS routing process.

An IS-IS router and an IS-IS interface can operate at Level 1, Level 2 or both Level 1 and 2.

Table 77 displays configuration combinations and the potential adjacencies that can be formed.