This command configures ingress counter parameters for this custom record.

The no form of this command reverts to the default.

This command configures ingress counter parameters for this custom record.

The no form of this command reverts all ingress counters to their default value.

This command defines the iSID value to be used in the test PBB header.

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

This command configures the IA-NA for the DHCPv6 client.

This command defines the type of IBGP multipath to use when adding BGP routes to the route table if the route resolving the BGP nexthop offers multiple next-hops.

The no form of this command disables the IBGP multipath load balancing feature.

This command enables IBGP multipath load balancing when adding BGP routes to the route table if the route resolving the BGP nexthop offers multiple nexthops.

The no form of this command disables the IBGP multipath load balancing feature.

This command enables the context to configure Internet Control Message Protocol (ICMP) parameters on a service.

This command enables the context to configure IPv4 Internet Control Message Protocol (ICMP) parameters.

This command enables access to the context to configure Internet Control Message Protocol (ICMP) parameters on a network IP interface. ICMP is a message control and error reporting protocol that also provides information relevant to IP packet processing.

This command enables ICMP debugging.

This command includes the extracted IPv4 ICMP packets for ip-src-monitoring. IPv4 ICMP packets will be subject to the per-source-rate of CPU protection policies.

This command configures test ICMP OAM parameters.

Configures matching on /ICMPv6 code field in the /ICMPv6 header of an IPv4 or IPv6 packet as a filter match criterion or configures matching on the ICMP code field in the ICMP header of an IPv4 packet as an exception filter match criterion. An entry containing Layer 4 non-zero match criteria will not match non-initial (2nd, 3rd, etc.) fragments of a fragmented packet since only the first fragment contains the Layer 4 information. Similarly an entry containing "icmp-code 0" match criterion, may match non-initial fragments when the Layer 4 header is not present in a packet fragment and other match criteria are also met.

The no form of the command removes the criterion from the match entry.

This command configures the ICMP code match condition.

The no form of this command reverts to the default.

This command configures matching on ICMP code field in the ICMP header of an IP packet as an IP filter match criterion.

Note: An entry containing Layer 4 match criteria will not match non-initial (2nd, 3rd, etc) fragments of a fragmented packet since only the first fragment contains the Layer 4 information.

The behavior of the icmp-code value is dependent on the configured icmp-type value, thus a configuration with only an icmp-code value specified will have no effect. To match on the icmp-code, an associated icmp-type must also be specified.

The no form of this command removes the criterion from the match entry.

This command configures an ICMP traceroute test.

This command configures the timeout applied to an ICMP query session.

This command configures an ICMP traceroute test.

This command enables the tunneling of ICMP reply packets over MPLS LSP at a LSR node as per RFC 3032.

The LSR part of this feature consists of crafting the reply ICMP packet of type=11- 'time exceeded', with a source address set to a local address of the LSR node, and appending the IP header and leading payload octets of the original datagram. The system skips the lookup of the source address of the sender of the label TTL expiry packet, which becomes the destination address of the ICMP reply packet. Instead, CPM injects the ICMP reply packet in the forward direction of the MPLS LSP the label TTL expiry packet was received from. The TTL of pushed labels should be set to 255.

The source address of the ICMP reply packet is determined as follows. The LSR uses the address of the outgoing interface for the MPLS LSP. With LDP LSP or BGP LSP multiple ECMP next-hops can exist and in such a case the first outgoing interface is selected. If that interface does not have an address of the same family (IPv4 or IPv6) as the ICMP packet, then the system address of the same family is selected. If one is not configured, the packet is dropped.

When the packet is received by the egress LER, it performs a regular user packet lookup in the data path in the GRT context for BGP shortcut, 6PE, and BGP label route prefixes, or in VPRN context for VPRN and 6VPE prefixes. It then forwards it to the destination, which is the sender of the original packet which TTL expired at the LSR.

If the egress LER does not have a route to the destination of the ICMP packet, it drops the packets.

The rate of the tunneled ICMP replies at the LSR can be directly or indirectly controlled by the existing IOM level and CPM levels mechanisms. Specifically, the rate of the incoming UDP traceroute packets received with a label stack can be controlled at ingress IOM using the distributed CPU protection feature. The rate of the ICMP replies by CPM can also be directly controlled by configuring a system wide rate limit for packets ICMP replies to MPLS expired packets which are successfully forwarded to CPM using the command 'configure system security vprn-network-exceptions'. While this command's name refers to VPRN service, this feature rate limits ICMP replies for packets received with any label stack, including VPRN and shortcuts.

The 7450 ESS, 7750 SR, and 7950 XRS implementation supports appending to the ICMP reply of type Time Exceeded the MPLS label stack object defined in RFC 4950. It does not include it in the ICMP reply type of Destination unreachable.

The new MPLS Label Stack object permits an LSR to include label stack information including label value, EXP, and TTL field values, from the encapsulation header of the packet that expired at the LSR node. The ICMP message continues to include the IP header and leading payload octets of the original datagram.

In order to include the MPLS Label Stack object, SROS implementation adds support of RFC 4884 which defines extensions for a multi-part ICMPv4/v6 message of type Time Exceeded.

The no form of command disables the tunneling of ICMP reply packets over MPLS LSP at a LSR node.

This command configures matching on the /ICMPv6 type field in the /ICMPv6 header of an IPv4 or IPv6 packet as a filter match criterion or configures matching on the ICMP type field in the ICMP header of an IPv4 packet as an exception filter match criterion. An entry containing Layer 4 non-zero match criteria will not match non-initial (2nd, 3rd, etc.) fragments of a fragmented packet since only the first fragment contains the Layer 4 information. Similarly an entry containing "icmp-type 0" match criterion, may match non-initial fragments when the Layer 4 header is not present in a packet fragment and other match criteria are also met.

The no form of the command removes the criterion from the match entry.

This command configures the ICMP type match condition.

The no form of this command reverts to the default.

This command configures matching on the ICMP or ICMPv6 type field in the ICMP or ICMPv6 header of an IPv4 or IPv6 packet as a network QoS match criterion.

An entry containing Layer 4 non-zero match criteria will not match non-initial (2nd, 3rd, etc.) fragments of a fragmented packet since only the first fragment contains the Layer 4 information. Similarly, an entry containing "icmp-type 0" match criterion, may match non-initial fragments when the Layer 4 header is not present in a packet fragment and other match criteria are also met.

The no form of the command removes the criterion from the match entry.

This command configures matching on ICMP type field in the ICMP header of an IP packet as an IP filter match criterion.

Note: An entry containing Layer 4 match criteria will not match non-initial (2nd, 3rd, etc) fragments of a fragmented packet since only the first fragment contains the Layer 4 information.

The no form of this command removes the criterion from the match entry.

This command configures ICMPv6 parameters for the interface.

This command enables the context to configure ICMPv6 parameters for the interface.

This command enables ICMPv6 debugging.

This command enables the ICMPv6 packet generation configuration context.

This command enables the ICMPv6 packet generation configuration context.

This command configures the timeout interval for ICMPv6 query mappings.

The no form of the command reverts the timeout interval to the default of 1 minute.

This command enables debugging for the specified service ID.

The no form of this command disables the debugging.

This command debugs commands for a specific service.

The no form of the command disables debugging.

This command displays statistics for a specific service, specified by the service-id, at the configured interval until the configured count is reached.

The first screen displays the current statistics related to the service-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 allows the operator to include the sender-id TLV information that was specified under the config>eth>system>sender-id configuration for service MEPs and MIPs. When this option is present under the maintenance association, the specific MPs in the association includes the sender-id TLV information in ETH-CFM PDUs. MEPs include the sender-id TLV for CCM (not sub second CCM enabled MEPs), LBM/LBR, and LTM/LTR. MIPs includes this value in the LBR and LTR PDUs.

Note: LBR functions reflect all TLVs received in the LBM unchanged including the SenderID TLV. Transmission of the Management Domain and Management Address fields are not supported in this TLV.

This command enables the inclusion of the Sender ID TLV information specified under the config>eth>system>sender-id command for installed MEPs and MIPs. The inclusion of the Sender ID TLV is based on the configured value. The Sender ID TLV is supported for ETH-CC, ETH-LB, and ETH-LB PDUs.

Note: LBR functions reflect back all TLVs received in the LBM, unchanged, including the Sender ID TLV. Transmission of the Management Domain and Management Address fields are not supported in this TLV.

The no form of this command disables the inclusion of the Sender ID TLV.

This command specifies identification strings for the subscriber. This is useful when the server is centralized with Enhanced Subscriber Management (ESM) in a lower level in the network. These strings are parsed by a downstream Python script or they can be used literally if the strings-from-option option in the config>subscr-mgmt>sub-ident-policy context is set to this option number. In this case, the option number may be set to any allowed number (between 224 and 254 is suggested, as these are not dedicated to specific purposes). If the option number is not given, a default value of 254 is used. For PPPoE only, if the local user database is attached to the PPPoE node under the group interface and not to a local DHCP server, the strings are used internally so the option number is not used.

The no form of this command returns to the default.

This command defines the identifier for the MLFR bundle. The no form of this command resets the value to null.

This command defines the identifier for a frame-relay link when used in an MLFR bundle.

The no form of this command resets the value to null.

This command defines an identifier string to be used to advertise the Bluetooth module during pairing operations.

If there is no identifier specified by the user, the default is derived from the platform type, the CPM slot, and the serial number of the chassis.

For example, a device with a platform field of 7750, SR-12 chassis, and a CPM serial number of NS23456 would have a Bluetooth identifier of "7750-SR-12-CPM-A-NS23456." for the CPM in slot A.

The no form of the command resets the identifier back to the default.

This command specifies a match criteria that uses the peer’s identification initiator (IDi) as the input, only one IDi criteria can be configured for a given client entry. This command supports the following matching methods:

The no form of this command reverts to the default.

This command enables the Identification Initiator (IDi) type in the IPsec client matching process.

The no form of this command disables the IDi matching process.

This command configures the value that the HDLC TDM DS-0, E-1, E-3, DS-1, or DS-3 interface transmits during idle cycles. For ATM ports/channels/channel-groups, the configuration does not apply and only the no form is accepted.

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

This command when applied will filter out new incoming ANCP messages while the subscriber DSL-line-state is idle. The command takes effect at the time that it is applied. Existing subscribers already in idle state are not purged from the database.

The no form of this command reverts to the default.

This command when applied will filter out new subscriber’s ANCP messages from subscriber with “DSL-line-state” IDLE.

This command when applied will filter out new subscriber’s ANCP messages from subscriber with “DSL-line-state” IDLE.

This command defines the data pattern to be transmitted when the circuit emulation service is not operational or temporarily experiences under-run conditions. This command is only valid for cesopsn and cesopsn-cas circuit emulation services. It is blocked with a warning for unstructured (satop) circuit emulation services.

This command defines the signaling pattern to be transmitted when the circuit emulation service is not operational or temporarily experiences under-run conditions. This command is only valid for cesopsn-cas circuit emulation services. It is blocked with a warning for unstructured (satop) and basic cesopsn circuit emulation services.

This command configures the amount of time, in seconds, that the connection must remain idle before TCP keepalive probes are sent.

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

This command configures the period of time that an established tunnel with no active sessions persists before being disconnected.

Enter the no form of this command to maintain a persistent tunnel.

The no form of this command removes the idle timeout from the configuration.

This command defines the idle-timeout value.

The no form of this command reverts to the default.

This command specifies idle-timeout behavior for DSM UEs and UEs undergoing (ISA-based) portal authentication. This knob only specifies the desired action, idle-timeout is activated by RADIUS on a per-UE basis.

The no form of this command resets the idle-timeout to its default

This command configures the idle timeout for console, Telnet, SSH, and FTP sessions before the session is terminated by the system.

By default, each idle console, Telnet, SSH, or FTP session times out after 30 minutes of inactivity.

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

This command defines the action to be executed when the idle-timeout is reached. The action is performed for all hosts associated with the sla-profile instance.

The no form of this command reverts to the default.

This command creates or edits an IES service instance.

The ies command creates or maintains an Internet Ethernet Service (IES). If the service-id does not exist, a context for the service is created. If the service-id exists, the context for editing the service is entered.

IES services allow the creation of customer facing IP interfaces in the same routing instance used for service network core routing connectivity. IES services require that the IP addressing scheme used by the subscriber must be unique between it and other addressing schemes used by the provider and potentially the entire Internet.

While IES is part of the routing domain, the usable IP address space may be limited. This allows a portion of the service provider address space to be set aside for service IP provisioning, becoming administered by a separate but subordinate address authority. This feature is defined using the config router service-prefix command.

IP interfaces defined within the context of an IES service ID must have a SAP created as the access point to the subscriber network. This allows a combination of bridging and IP routing for redundancy purposes.

When a service is created, the customer keyword and customer-id must be specified and associates the service with a customer. The customer-id must already exist having been created using the customer command in the service context. Once a service has been created with a customer association, it is not possible to edit the customer association. The service must be deleted and recreated with a new customer association.

Once a service is created, the use of the customer customer-id is optional for navigating into the service configuration context. Attempting to edit a service with the incorrect customer-id specified results in an error.

Multiple IES services are created to separate customer owned IP interfaces. More than one IES service may be created for a single customer ID. More than one IP interface may be created within a single IES service ID. All IP interfaces created within an IES service ID belongs to the same customer.

By default, no IES service instances exist until they are explicitly created.

The no form of this command deletes the IES service instance with the specified service-id. The service cannot be deleted until all the IP interfaces defined within the service ID have been shut down and deleted.

This command configures which IES service interfaces' flow data is being sent to this collector.

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

This command enables the context to configure managed SAP IES and VPRN properties. VPRN services are supported on the 7750 SR only.

This command creates the context to configure or apply IP interface attributes such as administrative group (admin-group) or Shared Risk Loss Group (SRLG).

This command configures the MPLS-TP interface number for the MPLS interface. This is a 32-bit unsigned integer that is node-wide unique.

The if-num-validation command is used to enable or disable validation of the if-num in LSP Trace packet against the locally configured if-num for the interface over which the LSP Trace packet was received at the egress LER. This is because some third-party implementations may not perform interface validation for unnumbered MPLS-TP interfaces and instead set the if-num in the DSMAP TLV to 0. If the value is enable, the node performs the validation of the ingress and egress if-nums received in the LSP echo request messages that ingress on this MPLS-interface. It validates that the message arrives on the interface as identified by the ingress if-num, and is forwarded on the interface as identified by the egress if-num.

If the value is disable, no validation is performed for the ingress and egress if-nums received in the LSP echo request messages that ingress on this MPLS-interface.

This command assigns an existing MCAC interface policy to this MSAP policy.

The no form of this command removes the MCAC interface policy association.

This command assigns existing MCAC interface policy to this interface. MCAC interface policy is not supported with MLD-snooping, therefore executing the command in the mld-snooping contexts will return an error.

The no form of this command removes the MCAC interface policy association.

This command assigns existing an MCAC interface policy to this interface.

The no form of this command removes the MCAC interface policy association.

This command assigns an existing MCAC interface policy to the interface.

The no form removes the MCAC interface policy association.

This command creates an MCAC interface policy and enables the context to configure parameters for the policy.

The no form of this command deletes the MCAC interface policy.

This command specifies the sending of average inter-frame delay variation for a specified direction.

The no form of this command deletes the specified average direction.

Note: All directions can be specified if all directions are important for reporting. However, only enable those directions that are required.

This command sets mcast reporting dest debug filtering options and applies only to the 7750 SR.

This command specifies whether IGMP protocol information should be synchronized with the multi-chassis peer.

This command enters the context to configure IGMP parameters.

The no form of this command disables IGMP.

This command enables the Internet Group Management Protocol (IGMP) context. When the context is created, the IGMP protocol is enabled.

The Internet Group Management Protocol (IGMP) is used by IPv4 systems (hosts and routers) to report their IP multicast group memberships to neighboring multicast routers. An IP multicast router can be a member of one or more multicast groups, in which case it performs both the “multicast router part” of the protocol which collects the membership information needed by its multicast routing protocol, and the “group member part” of the protocol which informs itself and other neighboring multicast routers of its memberships.

The no form of the command disables the IGMP instance. To start or suspend execution of IGMP without affecting the configuration, use the no shutdown command.

This command includes the extracted IPv4 IGMP packets for ip-src-monitoring. IPv4 IGMP packets will be subject to the per-source-rate of CPU protection policies.

This command enables the context to configure IGMP host tracking parameters.

This command enables the context to configure IGMP host tracking parameters.

This command enters the context to configure IGMP host tracking parameters.

This command enters the context to configure IGMP host tracking parameters.

This command enters the context to configure IGMP host tracking parameters.

This command configures an IGMP policy.

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

This command will enable IGMP processing per subscriber host. Without this command IGMP states will not be maintained per subscriber hosts. The referenced policy is defined under the configure>subscr-mgmt context and can be only applied via the sub-profile.

The referenced policy contains entries such as:

The no form of this command reverts to the default.

This command enables the Internet Group Management Protocol (IGMP) snooping context.

This command enables the context to configure Internet Group Management Protocol (IGMP) snooping parameters.

This command specifies whether IGMP snooping information should be synchronized with the multi-chassis peer.

This command enables the Internet Group Management Protocol (IGMP) snooping context.

This command configures IGMP snooping attributes for I-VPLS.

This command enables and configures IGMP-snooping debugging.

This command enables the Internet Group Management Protocol (IGMP) snooping context.

This command configures IS-IS to ignore the attached bit on received Level 1 LSPs to disable installation of default routes.

This command configures IS-IS to ignore the attached bit on received Level 1 LSPs to disable installation of default routes.

This command specifies the L2TP AVPs that should be ignored in L2TP session control.

The no form of this command reverts to the default.

This command enables the default route when performing a uRPF check.

The no form of this command disables the default route.

This command configures the uRPF check (if enabled) to ignore default routes for purposes of determining the validity of incoming packets. By default, default routes are considered eligible.

When this command is enabled for a subscriber host, the do-not-fragment (DF) bit in the IPv4 header for frames egressing the subscriber interface is ignored, the frames are fragmented according the applicable egress MTU. The DF bit is reset for frames that are fragmented.

This command applies to PPPoE PTA and L2TP LNS frames only. It is not applicable for L2TP LAC frames.

This command enables the ignore-df-bit flag that ignores the do-not-fragment (DF) bit for frames egressing the WLAN-GW group interface and fragments the frame according to the applicable egress MTU. The DF bit is reset for the frames that are fragmented.

The no form of this command causes the router to fragment a packet larger than the MTU if the DF bit is set to 0 and drops the packet if the DF bit is set to 1.

This command specifies whether to ignore the DN bit for OSPF LSA packets for this instance of OSPF on the router. When enabled, the DN bit for OSPF LSA packets are ignored.

The no form of this command does not ignore the DN bit for OSPF LSA packets.

When the ignore-efm-state command is configured, any failure in the protocol state machine (discovery, configuration, timeout, loops, and so on) does not impact the state of the port. There is only be a protocol warning message on the port. If this optional command is not configured, the port state is affected by any existing EFM-OAM protocol fault condition.

This command specifies that for this VPRN instance, ISIS will ignore LSP packets with errors. When enabled, IS-IS LSP errors will be ignored and the associated record will not be purged.

This command enables ISIS to ignore the ATT bit and therefore suppress the installation of default routes.

The no form of this command specifies that ISIS will not ignore LSP errors.

This command sets the filter entry action to ignore-match, as a result this filter entry is ignored and not programmed in hardware.

With this flag enabled, the remote IP address or prefix can be taken over immediately upon entering the PARTNER-DOWN state of the intercommunication link, without having to wait for the Maximum Client Lead Time (MCLT) to expire. By setting this flag, the lease times of the existing DHCP clients, while the intercommunication link is in the PARTNER-DOWN state, will still be reduced to the MCLT over time and all new lease times are set to MCLT. This behavior remains the same as originally intended for MCLT.

Some deployments require that the remote IP address/prefix range starts delegating new IP addresses and prefixes upon the failure of the intercommunication link, without waiting for the intercommunication link to transition from the COMM-INT state into the PARTNER-DOWN state and the MCLT to expire while in PARTNER-DOWN state.

This can be achieved by enabling the ignore-mclt-on-takeover flag and by configuring the partner-down-delay to 0.

Enabling this functionality must be exercised with caution. One needs to keep in mind that the partner-down-delay and MCLT timers were originally introduced to prevent IP address duplication in cases where DHCP redundant nodes transition out-of-sync due to the failure of intercommunication link. These timers (partner-down-delay and MCLT) would ensure that during their duration, the new IP addresses and prefixes are delegated only from one node, the one with local IP address-range/prefix. This causes the new IP address delegation to be delayed and the service is impacted.

If it can be assured that the intercommunication link is always available, then the DHCP nodes would stay in sync and the two timers would not be needed. Therefore, it is important that in this mode of operation, the intercommunication link is well protected by providing multiple paths between the two DHCP nodes. The only event that should cause intercommunication link to fail is the entire nodal failure. This failure is acceptable since in this case only one DHCP node is available to provide new IP addresses and prefixes.

The no form of this command reverts to the default.

This command specifies that IS-IS ignores links with narrow metrics when wide-metrics support has been enabled.

The no form of this command specifies that IS-IS does not ignore these links.

This command specifies that IS-IS will ignore links with narrow metrics when wide-metrics support has been enabled.

The no form of this command specifies that IS-IS will not ignore these links.

This command instructs BGP to disregard the resolved distance to the BGP next-hop in its decision process for selecting the best route to a destination. When configured in the config>router>bgp>best-path-selection context, this command applies to the comparison of two BGP routes with the same NLRI learned from base router BGP peers. When configured in the config>service>vprn context, this command applies to the comparison of two BGP-VPN routes for the same IP prefix imported into the VPRN from the base router BGP instance. When configured in the config>service>vprn>bgp>best-path-selection context, this command applies to the comparison of two BGP routes for the same IP prefix learned from VPRN BGP peers.

The no form of this command (no ignore-nh-metric) restores the default behavior whereby BGP factors distance to the next-hop into its decision process.

This command enables the ability to ignore the operationally down status for service oper state calculation. An Epipe service does not transition to Oper State: Down when a SAP fails and when this optional command is configured under that specific SAP. Only a single SAP in an Epipe may have this optional command included. The command can be used in Epipes with or without EVPN enabled.

The no form of this command disables whether a service ignores the operationally down state of the SAP.

This command enables the Rapid Commit Option for DHCP6.

The no form of this command disables the Rapid Commit Option.

When the ignore-router-id command is present, and the current best path to a destination was learned from EBGP peer X with BGP identifier x and a new path is received from EBGP peer Y with BGP identifier y, the best path remains unchanged if the new path is equivalent to the current best path up to the BGP identifier comparison – even if y is less than x.

The no form of this command restores the default behavior of selecting the route with the lowest BGP identifier (y) as best.

When this command is enabled, the node ignores the standby-bit received from the TLDP peers for the specific spoke-SDP and performs internal tasks without taking it into account.

This command is present at the endpoint level and the spoke-SDP level. If the spoke-SDP is part of the explicit-endpoint, this setting cannot be changed at the spoke-SDP level. The existing spoke-SDP will become part of the explicit-endpoint only if the setting is not conflicting. The newly created spoke-SDP, which is a part of the specified explicit-endpoint, will inherit this setting from the endpoint configuration.

This command specifies if the IPv4 Type-of-Service (ToS) is ignored and the IPv6 traffic class bits set to zero.

If this command is disabled, the system copies the IPv4 ToS into the IPv6 traffic class.

This command specifies whether the IPv4 ToS is ignored and the IPv6 traffic class bits set to zero.

When disabled, the system copies the IPv4 ToS into the IPv6 traffic class.

The no form of the command recognizes the IPv4 ToS.

This command enables the use of a specific RSVP LSP by IS-IS and OSPF routing protocols as a shortcut or as a forwarding adjacency for resolving IGP routes.

When the igp-shortcut or the advertise-tunnel-link option is enabled at the IGP instance level, all RSVP LSPs originating on this node are eligible by default as long as the destination address of the LSP, as configured in config>router>mpls>lsp>to, corresponds to a router-id of a remote node.

The lfa-protect option allows an LSP to be included in both the main SPF and the Loop-Free Alternate (LFA) SPF. For a given prefix, the LSP can be used either as a primary next-hop or as an LFA next-hop, but not both. If the main SPF computation selected a tunneled primary next-hop for a prefix, the LFA SPF will not select an LFA next-hop for this prefix and the protection of this prefix will rely on the RSVP LSP FRR protection. If the main SPF computation selected a direct primary next-hop, then the LFA SPF will select an LFA next-hop for this prefix but will prefer a direct LFA next-hop over a tunneled LFA next-hop.

The lfa-only option allows an LSP to be included in the LFA SPF only such that the introduction of IGP shortcuts does not impact the main SPF decision. For a given prefix, the main SPF always selects a direct primary next-hop. The LFA SPF will select a an LFA next-hop for this prefix but will prefer a direct LFA next-hop over a tunneled LFA next-hop.

When the relative-metric option is enabled, IGP will apply the shortest IGP cost between the endpoints of the LSP plus the value of the offset (instead of the LSP operational metric) when computing the cost of a prefix which is resolved to the LSP. The offset value is optional and it defaults to zero. The minimum net cost for a prefix is one (1) after applying the offset. The TTM continues the show the LSP operational metric as provided by MPLS. In other words, applications such as LDP-over-RSVP (when IGP shortcut is disabled) and BGP and static route shortcuts will continue to use the LSP operational metric.

The relative-metric option is mutually exclusive with the lfa-protect or the lfa-only options. In other words, an LSP with the relative-metric option enabled cannot be included in the LFA SPF and vice-versa when the igp-shortcut option is enabled in the IGP.

Finally, the relative-metric option is ignored when forwarding adjacency is enabled in IS-IS or OSPF. In this case, IGP advertises the LSP as a point-to-point unnumbered link along with the LSP operational metric as returned by MPLS and capped to maximum link metric allowed in that IGP. Both the main SPF and the LFA SPFs will use the local IGP database to resolve the routes.

The no form of this command disables the use of a specific RSVP LSP by IS-IS and OSPF routing protocols as a shortcut or a forwarding adjacency for resolving IGP routes.

This command enables the use of an RSVP-TE or SR-TE shortcut for resolving IGP routes by OSPF or IS-IS routing protocols.

This command instructs IGP to include RSVP LSPs and SR-TE LSPs originating on this node and terminating on the router ID of a remote node as direct links with a metric equal to the metric provided by MPLS.

During the IP reach calculation to determine the reachability of nodes and prefixes, LSPs are overlaid and the LSP metric is used to determine the subset of paths that are equal lowest cost to reach a node or a prefix. If the user enabled the relative-metric option for this LSP, IGP will apply the shortest IGP cost between the endpoints of the LSP plus the value of the offset, instead of the LSP operational metric, when computing the cost of a prefix that is resolved to the LSP.

When a prefix is resolved to a tunnel next-hop, the packet is sent labeled with the label stack corresponding to the NHLFE of the RSVP-TE or SR-TE LSP, as well as the explicit-null IPv6 label at the bottom of the stack in the case of an IPv6 prefix. Any network event causing one or more IGP shortcuts to go down will trigger a full SPF computation, which may result in installing a new route over an updated set of tunnel next-hops and IP next-hops.

When igp-shortcut is enabled at the IGP instance level, all RSVP-TE and SR-TE LSPs originating on this node are eligible by default as long as the destination address of the LSP, as configured in config>router>mpls>lsp>to, corresponds to a router ID of a remote node. LSPs with a destination corresponding to an interface address or any other loopback interface address of a remote node are automatically not considered by IGP. The user can, however, exclude a specific RSVP-TE or SR-TE LSP from being used as a shortcut for resolving IGP routes by entering the config>router>mpls>lsp>no igp-shortcut command.

The SPF in IGP only uses RSVP LSPs as forwarding adjacencies, IGP shortcuts, or as endpoints for LDP-over-RSVP. These applications of RSVP LSPs are mutually exclusive at the IGP instance level. If two or more options are enabled in the same IGP instance, then forwarding adjacency takes precedence over the shortcut application, which takes precedence over the LDP-over-RSVP application.

The SPF in IGP uses SR-TE LSPs as IGP shortcuts only.

When ECMP is enabled on the system and multiple equal-cost paths exist for a prefix, the following selection criteria are used to pick up the set of tunnel and IP next-hops to program in the data path.

Note: Although ECMP is not performed across both the IP and tunnel next-hops, the tunnel endpoint may lie in one of the shortest IGP paths for that prefix. In that case, the tunnel next-hop is always selected as long as the prefix cost using the tunnel is equal or lower than the IGP cost.

When both RSVP-TE and SR-TE IGP shortcuts are available, the IP reach calculation, in the unicast routing table, will first follow the above ECMP tunnel and IP next-hop selection rules when resolving a prefix over IGP shortcuts. After the set of ECMP tunnel and IP next-hops have been selected, the preference of tunnel type is then applied based on the user setting of the resolution of the family of the prefix. If the user enabled resolution of the prefix family to both RSVP-TE and SR-TE tunnel types, the TTM tunnel preference value is used to select one type for the prefix. In other words, an RSVP-TE LSP type is preferred to an SR-TE LSP type on a per-prefix basis.

The ingress IOM sprays the packets for this prefix over the set of tunnel next-hops and IP next-hops based on the hashing routine currently supported for IPv4 packets.

This feature provides IGP with the capability to populate the multicast RTM with the prefix IP next-hop when both the igp-shortcut and the multicast-import options are enabled in IGP. The unicast RTM can still make use of the tunnel next-hop for the same prefix. This change is made possible with the enhancement by which SPF keeps track of both the direct first hop and the tunneled first hop of a node which is added to the Dijkstra tree.

This command enables the use of an RSVP-TE or SR-TE shortcut for resolving IGP routes by OSPF or IS-IS routing protocols.

This command instructs IGP to include RSVP LSPs and SR-TE LSPs originating on this node and terminating on the router ID of a remote node as direct links with a metric equal to the metric provided by MPLS.

During the IP reach calculation to determine the reachability of nodes and prefixes, LSPs are overlaid and the LSP metric is used to determine the subset of paths that are equal lowest cost to reach a node or a prefix. If the user enabled the relative-metric option for this LSP, IGP will apply the shortest IGP cost between the endpoints of the LSP plus the value of the offset, instead of the LSP operational metric, when computing the cost of a prefix that is resolved to the LSP.

When a prefix is resolved to a tunnel next hop, the packet is sent labeled with the label stack corresponding to the NHLFE of the RSVP-TE or SR-TE LSP, as well as the explicit-null IPv6 label at the bottom of the stack in the case of an IPv6 prefix. Any network event causing one or more IGP shortcuts to go down will trigger a full SPF computation, which may result in installing a new route over an updated set of tunnel next-hops and IP next-hops.

When igp-shortcut is enabled at the IGP instance level, all RSVP-TE and SR-TE LSPs originating on this node are eligible by default as long as the destination address of the LSP, as configured in config>router>mpls>lsp>to, corresponds to a router ID of a remote node. LSPs with a destination corresponding to an interface address or any other loopback interface address of a remote node are automatically not considered by IGP. The user can, however, exclude a specific RSVP-TE or SR-TE LSP from being used as a shortcut for resolving IGP routes by entering the config>router>mpls>lsp>no igp-shortcut command.

The SPF in IGP only uses RSVP LSPs as forwarding adjacencies, IGP shortcuts, or as endpoints for LDP-over-RSVP. These applications of RSVP LSPs are mutually exclusive at the IGP instance level. If two or more options are enabled in the same IGP instance, then forwarding adjacency takes precedence over the shortcut application, which takes precedence over the LDP-over-RSVP application.

The SPF in IGP uses SR-TE LSPs as IGP shortcuts only.

When ECMP is enabled on the system and multiple equal-cost paths exist for a prefix, the following selection criteria are used to pick up the set of tunnel and IP next-hops to program in the data path.

Note: Although ECMP is not performed across both the IP and tunnel next-hops, the tunnel endpoint may lie in one of the shortest IGP paths for that prefix. In that case, the tunnel next hop is always selected as long as the prefix cost using the tunnel is equal or lower than the IGP cost.

When both RSVP-TE and SR-TE IGP shortcuts are available, the IP reach calculation, in the unicast routing table, will first follow the above ECMP tunnel and IP next hop selection rules when resolving a prefix over IGP shortcuts. After the set of ECMP tunnel and IP next-hops have been selected, the preference of tunnel type is then applied based on the user setting of the resolution of the family of the prefix. If the user enabled resolution of the prefix family to both RSVP-TE and SR-TE tunnel types, the TTM tunnel preference value is used to select one type for the prefix. In other words, the RSVP-TE LSP type is preferred to an SR-TE LSP type on a per-prefix basis.

The ingress IOM sprays the packets for this prefix over the set of tunnel next-hops and IP next-hops based on the hashing routine currently supported for IPv4 packets.

This feature provides IGP with the capability to populate the multicast RTM with the prefix IP next hop when both the igp-shortcut and the multicast-import options are enabled in IGP. The unicast RTM can still make use of the tunnel next hop for the same prefix. This change is made possible with the enhancement by which SPF keeps track of both the direct first hop and the tunneled first hop of a node which is added to the Dijkstra tree.

This command enables IS-IS multi-instance (MI) as described in draft-ietf-isis-mi-02. Multiple instances allow instance-specific adjacencies to be formed that support multiple network topologies on the same physical interfaces. Each instance has an LSDB, and each PDU contains a TLV identifying the instance and the topology to which the PDU belongs.

The iid-tlv-enable (based on draft-ietf-isis-mi-02) and standard-multi-instance (based on draft-ginsberg-isis-mi-bis-01) commands cannot be configured in the same instance, because the MAC addresses and PDUs in each standard are incompatible.

This command enables IS-IS multi-instance (MI) as described in draft-ietf-isis-mi-02. Multiple instances allows the formation of instance-specific adjacencies that support multiple network topologies on the same physical interfaces. Each instance has an LSDB, and each PDU contains a TLV that identifies the instance and the topology to which the PDU belongs.

The iid-tlv-enable (based on draft-ietf-isis-mi-02) and standard-multi-instance (based on draft-ginsberg-isis-mi-bis-01) commands cannot be configured in the same instance, because the MAC addresses and PDUs in each standard are incompatible.

The no form of this command disables IS-IS MI.

This command specifies the IKE authentication algorithm for the IKE transform

This command specifies the IKE encryption algorithm to be used in the IKE transform instance.

This command specifies one of either two modes of operation. IKE version 1 can support main mode and aggressive mode. The difference lies in the number of messages used to establish the session.

The no form of this command reverts to the default.

This command enables the context to configure an IKE policy.

The no form of this command

This command configures IKE policy for the gateway.

The no form of this command removes the IKE policy ID from the configuration.

This command specifies the PRF algorithm to use for IKE security association.

Note: If an authenticated encryption algorithm like AES-GCM is used for IKE encryption algorithm, same-as-auth cannot be used for ike-prf-algorithm.

This command specifies the IKE transform to be used in the IKE policy. Up to four IKE transforms can be specified. If multiple IDs are specified, the system selects an IKE transform based on the peer's proposal. If the system is a tunnel initiator, it uses the configured IKE transform to generate the SA payload.

This commands creates a new or enters an existing IKE transform instance. The IKE transform include following configuration for IKE SA:

The ike-transform-id is referenced in the ike-policy configuration.

This command sets the IKE version (1 or 2) that the ike-policy will use.

This command specifies the system, when deleting an IKEv1 phase 1 SA for which it was the responder, to send a delete notification to the peer. This command only applies when the configured ike-version 1. This command is ignored with IKE version 2.

The no form of this command reverts to the default.

This command enables IKEv2 protocol level fragmentation (RFC 7383). The specified MTU is the maximum size of IKEv2 packet.

This command creates an ILMI link PVCC by default on VPI/VCI 0/16. Deleting an ILMI link deletes the PVCC. ILMI is supported only on ATM interfaces on SONET/SDH paths.

This command enables debugging for ATM ILMI.

The no form of this command turns off ILMI and debugging.

This command enables the context to configure parameters for an Inverse Multiplexing over ATM (IMA) group. An IMA group is a collection of physical links bundled together and assigned to an ATM interface. IMA enables a high-speed channel that is composed of ATM cells to be transported as a number of lower-speed circuits. Then they are reassembled as the original high-speed ATM channel. This command is only valid for IMA bundles.

This command enables the inclusion of the IMEI in AA protocols as signaled in the incoming GTP setup message.

The no form of this command disables the inclusion of the attribute.

This command enables the inclusion of the IMEI AVP, as signaled in the incoming GTP setup message.

The no form of this command disables the inclusion of the AVP.

This command enables the use of the implicit null label. Use this command to signal the implicit null option for all LDP FECs for which this node is the egress LER.

The no form of this command disables the signaling of the implicit null label.

This command enables the use of the implicit null label.

Signaling the IMPLICIT NULL label value for all RSVP LSPs can be enabled for which this node is the egress LER. RSVP must be shutdown before being able to change this configuration option.

The egress LER does not signal the implicit null label value on P2MP RSVP LSPs. However, the Penultimate Hop Popping (PHP) node can honor a Resv message with the label value set to the implicit null.

The no form of this command disables the signaling of the implicit null label.

This command enables the use of the implicit null label over a specific RSVP interface.

All LSPs for which this node is the egress LER and for which the path message is received from the previous hop node over this RSVP interface will signal the implicit null label. This means that if the egress LER is also the merge-point (MP) node, then the incoming interface for the path refresh message over the bypass dictates if the packet will use the implicit null label or not. The same for a 1-to-1 detour LSP.

The user must shut down the RSVP interface before being able to change the implicit null configuration option.

The no form of this command returns the RSVP interface to use the RSVP level configuration value.

This command configures an MLD import policy.

The LUDB allows a list of up to 14 MLD import policies per host. The MLD policy also allows the configuration of an additional import policy, providing a total of 15 MLD import policies per host. The import policy inside the MLD policy is always applied last, which determines if the list is a black list or a white list. To configure an MLD white list, the import policies in the LUDB should all be allowed or forward entries and the import policy in the MLD policy should have a default action to deny all. To configure a black list, the import policies inside the LUDB should drop entries and the MLD policy import policy default action should be to forward all. The 15 import policies can be configured to be a mixed white and black list. Since it is difficult to control the order of the import policies within the LUDB, it is recommended to provision the import policy inside the MLD policy first for deterministic behavior.

The no form of this command removes the specified import policy.

This command specifies the import routing policy to be used for IGMP packets to be used on this SAP or SDP. Only a single policy can be imported on a SAP at any time.

The no form of this command removes the policy association from the SAP or SDP.

This command specifies the import policies to be used to control routes advertised to BGP neighbors. Route policies are configured in the config>router>policy-options context. When multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied.

The no form of this command removes all route policy names from the import list.

This command specifies the import policy to filter IGMP packets.

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

This command specifies the import routing policy to be used for IGMP packets to be used on this SAP or SDP. Only a single policy can be imported on a single SAP at any time.

The no form of this command removes the policy association from the SAP or SDP.

This command specifies the import routing policy to be used for IGMP packets to be used on this SAP or SDP. Only a single policy can be imported on a single SAP at any time.

The no form of this command removes the policy association from the SAP or SDP.

This command specifies the import routing policy to be used. Only a single policy can be imported at a time.

The no form of this command removes the policy association.

This command specifies the import routing policy to be used for IGMP packets to be used on this SAP or SDP. Only a single policy can be imported on a single SAP at any time.

The no form of this command removes the policy association from the SAP or SDP.

This command associates an import policy to filter IGMP packets.

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

This command specifies the import routing policy to be used for IGMP packets to be used on this SAP. Only a single policy can be imported on a single SAP at any time.

The no form of this command removes the policy association from the SAP.

This command is used to specify route policies that control the handling of inbound routes received from certain peers. Route policies are configured in the config>router>policy-options context.

This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in a peer-group) or neighbor level (only applies to the specified peer). The most specific level is used

The 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 the modifications of each route and the final action to accept or reject the route.

Only one of the 15 objects referenced by the import command can 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 import commands are issued, the last command entered overrides the previous command.

When an import policy is not specified, BGP routes are accepted by default.

The no form of this command removes the policy association.

This command imports a policy to filter IGMP packets.

The no form of this command removes the policy association from the IGMP instance.

This command associates an import policy to filter IGMP packets.

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

This command applies one or more (up to five) route polices as IS-IS import policies.

When a prefix received in an IS-IS LSP is accepted by an entry in an IS-IS import policy, it is installed in the routing table, if it is the most preferred route to the destination.

When a prefix received in an IS-IS LSP is rejected by an entry in an IS-IS import policy, it is not installed in the routing table, even if it has the lowest preference value among all the routes to that destination.

The flooding of LSPs is unaffected by IS-IS import policy actions.

The no form of this command removes all policies from the configuration.

This command specifies the import route policy to be used for determining which membership reports are accepted by the router. Route policies are configured in the config>router>policy-options context.

When an import policy is not specified, all the MLD reports are accepted.

The no form of this command removes the policy association from the MLD instance.

This command specifies the policies to import source active state from Multicast Source Discovery Protocol (MSDP) into source active list.

If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

If you configure an import policy at the global level, each individual peer inherits the global policy.

If you configure an import policy at the group level, each individual peer in a group inherits the group’s policy.

If you configure an import policy at the peer level, then policy only applies to the peer where it is configured.

The no form of this command removes all policies from the configuration.

This command specifies communities to be accepted from peers.

This command configures ABR import policies to filter OSPFv2 Type 3 Summary-LSAs or OSPFv3 Inter-Area-Prefix-LSA between areas, to only permit the specified routes from being imported into an area.

This command cannot be used in OSPF area 0.

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

This command applies one or more (up to five) route polices as OSPF import policies. When a prefix received in an OSPF LSA is accepted by an entry in an OSPF import policy it is installed in the routing table if it is the most preferred route to the destination. When a prefix received in an OSPF LSA is rejected by an entry in an OSPF import policy it is not installed in the routing table, even if it has the lowest preference value among all the routes to that destination. The flooding of LSAs is unaffected by OSPF import policy actions. This command only applies to the 7750 SR.

This command specifies the import route policy to be used for determining which routes are accepted from peers. Route policies are configured in the config>router>policy-options context. When an import policy is not specified, BGP routes are accepted by default.

The no form of this command removes the policy association from the IGMP instance.

This command configures import route policies to determine routes that will be accepted from RIP neighbors. If no import policy is specified, RIP accepts all routes from configured RIP neighbors. Import policies can be used to limit or modify the routes accepted and their corresponding parameters and metrics.

If multiple policy names are specified, the policies are evaluated in the order that they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

The no form of this command removes all policies from the configuration.

This command configures import route policies to determine which label bindings (FECs) are accepted from LDP neighbors. Policies are configured in the config>router>policy-options context.

If no import policy is specified, LDP accepts all label bindings from configured LDP neighbors. Import policies can be used to limit or modify the routes accepted and their corresponding parameters and metrics.

If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

The no form of this command removes all policies from the configuration.

This command applies the referenced IGMP policy (filter) to an interface subscriber or a group-interface. An IGMP filter is also known as a black/white list and it is defined under the config>router>policy-options.

When redirection is applied, only the import policy from the subscriber will be in effect. The import policy under the group interface is applicable only for IGMP states received directly on the SAP (AN in IGMP proxy mode).

The no form of the command removes the policy association from the IGMP instance.

This command specifies the import route policy to determine which membership reports are accepted by the router. Route policies are configured in the config>router>policy-options context.

When an import policy is not specified, all the MLD reports are accepted.

The no form of this command removes the policy association from the MLD instance.

This command specifies the policies to import source active state from Multicast Source Discovery Protocol (MSDP) into source active list.

If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

If an import policy is configured at the global level, each individual peer inherits the global policy.

If an import policy is configured at the group level, each individual peer in a group inherits the group’s policy.

If an import policy is configured at the peer level, then policy only applies to the peer where it is configured.

The no form of the command applies no import policies and all source active messages are allowed.

This command specifies the import route policy to be used. Route policies are configured in the config>router>policy-options context.

When an import policy is not specified, BGP routes are accepted by default. Up to five import policy names can be specified.

The no form of this command removes the policy association from the instance.

This command specifies the import routing policy to be used for IGMP packets. Only a single policy can be imported at a time.

The no form of the command removes the policy association.

This command converts an input file (key/certificate/CRL) to a system format file. The following list summarizes the formats supported by this command:

Note: If there are multiple objects with the same type in the input file, only the first object is extracted and converted.

This command specifies route policies that control the handling of inbound routes received from certain peers. Route policies are configured in the config>router>policy-options context.

This configuration parameter can be set at three levels: global level (applies to all peers), group level (applies to all peers in peer-group) or neighbor level (only applies to specified peer). The most specific level is used.

The 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 the modifications of each route and the final action to accept or reject the route.

Only one of the 15 objects referenced by the 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; the remaining 14 objects have a maximum length of 64 characters each.

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

When an import policy is not specified, BGP routes are accepted by default.

The no form of this command removes the policy association.

This command specifies up to five route polices as IS-IS import policies.

When a prefix received in an IS-IS LSP is accepted by an entry in an IS-IS import policy, it is installed in the routing table, if it is the most preferred route to the destination.

When a prefix received in an IS-IS LSP is rejected by an entry in an IS-IS import policy, it is not installed in the routing table, even if it has the lowest preference value among all the routes to that destination.

The flooding of LSPs is unaffected by IS-IS import policy actions.

The no form of this command removes all policies from the configuration.

This command applies one or more (up to 5) route polices as OSPF import policies. When a prefix received in an OSPF LSA is accepted by an entry in an OSPF import policy, it is installed in the routing table if it is the most preferred route to the destination. When a prefix received in an OSPF LSA is rejected by an entry in an OSPF import policy, it is not installed in the routing table, even if it has the lowest preference value among all the routes to that destination. The flooding of LSAs is unaffected by OSPF import policy actions. The no form of this command removes all policies from the configuration.

This command configures ABR import policies to filter OSPFv2 Type 3 Summary-LSAs or OSPFv3 Inter-Area-Prefix-LSA between areas, in order to only permit the specified routes from being imported into an area.

This command cannot be used in OSPF area 0.

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

This command configures import route policies to determine which routes are accepted from RIP neighbors. If no import policy is specified, RIP accepts all routes from configured RIP neighbors. Import policies can be used to limit or modify the routes accepted and their corresponding parameters and metrics.

If multiple policy names are specified, the policies are evaluated in the order they are specified. The first policy that matches is applied. If multiple import commands are issued, the last command entered will override the previous command. A maximum of five policy names can be specified.

The no form of the command removes all policies from the configuration.

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

The GRT route must have first been leaked by a leak-export policy defined under the config>router context. Then the route must match a route entry in the specified import-grt policy with an accept action. Refer to the IP Router Configuration Command Reference section in the 7750 SR Extensible Routing System Virtualized Service Router.

The no form of this command removes route leaking policy associations and disables the leaking of GRT routes into the local VPRN.

This command configures an import policy for mLDP FECs arriving on the node. This command does not work for self-generated mLDP FECs. The action of the policy will accept or reject the FEC. If the FEC is rejected, it will be kept but is not resolved.

The no form of this command removes all policies from the configuration.

This command enters the import-pmsi-routes context.

For option B, the leafs or ABR/ASBR that are not directly connected to the root have no visibility of the root. As such, for LDP to build the recursive FEC it needs to cache the MVPN PMSI AD routes, this command gives the user the ability to manually enable caching of MVPN PMSI AD routes internally in LDP for EVPN or MVPN inter-as or mvpn_no_export_community intra-as.

This command configures the import FEC prefix policy to determine which prefixes received from this LDP peer are imported and installed by LDP on this node. If resolved these FEC prefixes are then re-distributed to other LDP and T-LDP peers. A FEC prefix that is filtered out (deny) will not be imported. A FEC prefix that is filtered in (accept) will be imported.

If no import policy is specified, the node will import all prefixes received from this LDP/T-LDP peer. This policy is applied in addition to the global LDP policy and targeted session policy.

Policies are configured in the config>router>policy-options context. A maximum of five policy names can be specified. Peer address has to be the peer LSR-ID address.

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

This command configures the import route policy to determine which FEC prefix label bindings are accepted from targeted LDP neighbors into this node. A label binding that is filtered out (deny) will not be imported. A route that is filtered in (accept) will be imported.

If no import policy is specified, this node session will accept all bindings from configured targeted LDP neighbors. This policy is applied in addition to the global LDP policy.

Policies are configured in the config>router>policy-options context. A maximum of five policy names can be specified.

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

This command controls the import, in the tunnel table, of LDP tunnels to non-host prefixes. This command is only intended for importing tunnels; it cannot be used for preventing the import of any specific prefix and only non-host prefixes will be considered when evaluating this policy in this context. The LDP tunnels to these non-host prefixes must be created before they can be imported.

This command does not affect the automatic import of LDP tunnels to host prefixes.

The no version of this command removes all of the import policies and, by consequence, any tunnels to non-host prefixes from the tunnel table. If a non-host prefix tunnel is currently being used for forwarding, disabling this command may be service-impacting.

This command specifies the allowed format of imported certificates or keys in the cf3:/system-pki directory.

This command enables improved assert procedure on the PIM inclusive provider tunnel.

The no form of this command disables improved assert procedure.

This command enables improved assert processing on this interface. The PIM assert process establishes a forwarder for a LAN and requires interaction between the control and forwarding planes.

The assert process is started when data is received on an outgoing interface. This could impact performance if data is continuously received on an outgoing interface.

When enabled, the PIM assert process is done entirely on the control-plane with no interaction between the control and forwarding plane.

This command enables improved assert processing. The PIM assert process establishes a forwarder for a LAN and requires interaction between the control and forwarding planes. The assert process is started when data is received on an outgoing interface meaning that duplicate traffic is forwarded to the LAN until the forwarder is negotiated among the routers.

When the improved-assert command is enabled, the PIM assert process is done entirely in the control plane. The advantages are that it eliminates duplicate traffic forwarding to the LAN. It also improves performance since it removes the required interaction between the control and data planes.

Note: improved-assert is still fully interoperable with the RFC 4601, Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) and RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM), implementations. However, there may be conformance tests that may fail if the tests expect control-data plane interaction in determining the assert winner. Disabling the improved-assert command when performing conformance tests is recommended.

This command restricts debugging to only data related to the specified IMSI. This command can be repeated multiple times, where only data for any of the specified IMSIs is debugged.

The no form of this command removes the filter for the specified IMSI. If the last IMSI filter is removed, all data is debugged again, but may be restricted by other filters.

This command configures a TCA for the counter capturing hits due to the GTP IMSI-APN filter.

This command specifies the context for configuring IMSI and APN filtering.

The gtpc-inspection command must be enabled before using this command.

This command applies only to the GTP packets that contain IMSI or APN information elements (IEs).

This command enables the context to configure control path parameters.

The no form of this command reverts to the default.

This command configures the label mapping associated with a forward path or reverse path of an MPLS-TP transit path to be configured.

The incoming label, outgoing label and outgoing interface must be configured, using the in-label, out-label and out-link parameters. If the out-link refers to a numbered IP interface, the user may optionally configure the next-hop parameter and the system will determine the interface to use to reach the configured next-hop, but will check that the user-entered value for the out-link corresponds to the link returned by the system. If they do not correspond, then the path will not come up.

This command configures the incoming label for the reverse path or the working path or the protect path of an MPLS-TP LSP. MPLS-TP LSPs are bidirectional, and so an incoming label value must be specified for each path.

This command includes the in-plus profile octets discarded count.

The no form of this command excludes the in-plus profile octets discarded count.

This command includes the in-plus profile octets forwarded count.

The no form of this command excludes the in-plus profile octets forwarded count.

This command includes the in-plus profile octets offered count.

The no form of this command excludes the in-plus profile octets offered count.

This command includes the in-plus profile packets discarded count.

The no form of this command excludes the in-plus profile packets discarded count.

This command includes the in-plus profile packets forwarded count.

The no form of this command excludes the in-plus profile packets forwarded count.

This command includes the in-plus profile packets offered count.

The no form of this command excludes the in-plus profile packets offered count.

This command includes the in-profile 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 in-profile octets discarded count.

This command includes the in-profile octets discarded count.

The no form of this command excludes the in-profile octets discarded count.

This command includes the in-profile octets discarded count.

The no form of this command excludes the in-profile octets discarded count.

This command includes the in-profile octets forwarded count. For queues with stat-mode v4-v6, this command includes the IPv4 octets forwarded count instead.

The no form of this command excludes the in-profile octets forwarded count.

This command includes the in-profile octets forwarded count.

The no form of this command excludes the in-profile octets forwarded count.

This command includes the in profile octets forwarded count.

The no form of this command excludes the in profile octets forwarded count.

This command includes the in profile octets offered count.

The no form of this command excludes the in-profile octets offered count.

This command includes the in-profile octets offered count.

The no form of this command excludes the in-profile octets offered count.

This command includes the in-profile 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 in-profile packets discarded count.

This command includes the in-profile packets discarded count.

The no form of this command excludes the in-profile packets discarded count.

This command includes the in-profile packets discarded count.

The no form of this command excludes the in-profile packets discarded count.

This command includes the in-profile packets forwarded count.

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

The no form of this command excludes the in-profile packets forwarded count.

This command includes the in-profile packets forwarded count.

The no form of this command excludes the in-profile packets forwarded count.

This command includes the in profile packets forwarded count.

The no form of this command excludes the in profile packets forwarded count.

This command includes the in profile packets offered count.

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

This command includes the in-profile packets offered count.

The no form of this command excludes the in-profile packets offered count.

This command is used in a SAP ingress QoS policy to define an explicit in-profile remark action for a forwarding class or subclass. While the SAP ingress QoS policy may be applied to any SAP, the remarking functions are only enforced when the SAP is associated with an IP or subscriber interface (in an IES or VPRN). When the policy is applied to a Layer 2 SAP (i.e., Epipe or VPLS), the remarking definitions are silently ignored.

In the case where the policy is applied to a Layer 3 SAP, the in-profile remarking definition will be applied to packets that have been classified to the forwarding class or subclass. It is possible for a packet to match a classification command that maps the packet to a particular forwarding class or subclass, only to have a more explicit (higher priority match) override the association. Only the highest priority match forwarding class or subclass association will drive the in-profile marking.

The in-remark command is only applicable to ingress IP routed packets that are considered in-profile. The profile of a SAP ingress packet is affected by either the explicit in-profile/out-of-profile definitions or the ingress policing function applied to the packet. Table 68 shows the effect of the in-remark command on received SAP ingress packets. Within the in-profile IP packet’s ToS field, either the six DSCP bits or the three precedence bits are remarked.

The no form of this command disables ingress remarking of in-profile packets classified to the forwarding class or subclass.

This command specifies the length of time, in seconds, that must elapse without a packet matching a flow before the flow is considered inactive.

The no form of this command resets the inactive flow timeout back to the default of 15 seconds.

Existing flows do not inherit the new inactive-flow-timeout value if this parameter is changed while cflowd is active. The inactive-flow-timeout value for a flow is set when the flow is first created in the active cache table and does not change dynamically.

This command enables auto removal of inactive transit subscribers. Periodically AA removes any inactive auto-created subscriber where an inactive sub is defined as having no active flows in the last period.

The no form of this command disables the auto removal of inactive transit subscribers.

This command configures the inactivity time out for all TWAMP-control connections. If no TWAMP control message is exchanged over the TCP connection for this duration of time the connection is closed and all in-progress tests are terminated.

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

This command configures the length of time to maintain stale state on the session reflector. Stale state is test data that has not been refreshed or updated by newly arriving probes for that specific test in a predetermined length of time. Any single reflector can maintain up state for a maximum of 12000 tests. If the maximum value is exceeded, the session reflector lacks memory to allocate to new tests.

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

This command specifies the time before an inactive host is removed.

The no form of this command reverts to the default.

The time the responder keeps a test active. Should the time between packets exceed this values within a test the responder will mark the previous test as complete. It will treat any new packets from a peer with the same test-id, source-mac and MEP-ID as a new test responding with the sequence number one.

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

This command, when the inband-collector-export-only command is enabled, allows only collectors that are reachable through inband interfaces and enables a higher flow export rate.

The no form of this command, the default, re-enables the use of the out-of-band management Ethernet port.

This command configures the maximum number of concurrent inbound FTP sessions.

This value is the combined total of inbound and outbound sessions.

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

This parameter limits the number of inbound Telnet and SSH sessions. A maximum of 30 telnet and ssh connections can be established to the router. The local serial port cannot be disabled.

Telnet and SSH maximum sessions can also use the combined total of both inbound sessions (SSH+Telnet). While it is acceptable to continue to internally limit the combined total of SSH and Telnet sessions to N, either SSH or Telnet sessions can use the inbound maximum sessions, if so required by the Operator.

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

The IP address configured by the user in the incl-mcast-orig-ip command is encoded in the originating-ip field of EVPN Inclusive Multicast Routes with tunnel type Ingress Replication (value 6), mLDP (2), and Composite IR and mLDP (130).

The configured address does not need to be reachable in the base router or have an interface in the base router. The originating-ip address is used solely for BGP route-key selection.

The originating-ip is never changed for Inclusive Multicast Routes with tunnel type AR (Assisted Replication, value 10).

The no version of the command withdraws the affected Inclusive Multicast Routes and re-advertises it with the default system-ip address in the originating-ip field.