4.9. IS-IS Configuration Command Reference

This command administratively disables an entity. When disabled, an entity does not change, reset, or remove any configuration settings or statistics.

The operational state of the entity is disabled as well as the operational state of any entities contained within. Many objects must be shut down before they may be deleted.

The no form of this command administratively enables an entity.

This command creates the context to configure the Intermediate-System-to-Intermediate-System (IS-IS) protocol instance.

The IS-IS protocol instance is enabled with the no shutdown command in the config>router>isis context. Alternatively, the IS-IS protocol instance is disabled with the shutdown command in the config>router>isis context.

IS-IS instances are shutdown when created, so that all parameters can be configured prior to the instance being enabled.

The no form of this command deletes the IS-IS protocol instance. Deleting the protocol instance removes all configuration parameters for this IS-IS instance.

This command enables and disables IS-IS to advertise only prefixes that belong to passive interfaces.

This command enables advertisement of a router's capabilities to its neighbors for informational and troubleshooting purposes. A TLV as defined in RFC 4971 advertises the TE Node Capability Descriptor capability.

The parameters (area and as) control the scope of the capability advertisements.

The no form of this command disables this capability.

This command enables the forwarding adjacency feature. With this feature, IS-IS or OSPF advertises an RSVP LSP as a link so that other routers in the network can include it in their SPF computations. The RSVP LSP is advertised as an unnumbered point-to-point link and the link LSP or LSA has no Traffic Engineering opaque sub-TLVs per RFC 3906.

The forwarding adjacency feature can be enabled independently from the IGP shortcut feature in CLI. If both igp-shortcut and advertise-tunnel-link options are enabled for a given IGP instance, then the advertise-tunnel-link will win.

When the forwarding adjacency feature is enabled, each node advertises a p2p unnumbered link for each best metric tunnel to the router-id of any endpoint node. The node does not include the tunnels as IGP shortcuts in SPF computation directly. Instead, when the LSA/LSP advertising the corresponding P2P unnumbered link is installed in the local routing database, then the node performs an SPF using it like any other link LSA or LSP. The link bidirectional check requires that a link, regular link or tunnel link, exists in the reverse direction for the tunnel to be used in SPF.

That the igp-shortcut option under the LSP name governs the use of the LSP with both the igp-shortcut and the advertise-tunnel-link options in IGP. In other words, the user can exclude a specific RSVP LSP from being used as a forwarding adjacency by entering the command config>router>mpls>lsp>no igp-shortcut.

The resolution and forwarding of IPv6 prefixes to IPv4 forwarding adjacency RSVP-TE LSP is supported.

IS-IS forwarding adjacency using the advertise-tunnel-link command is not supported in combination with the IS-IS link bundling and the IS-IS metric link quality adjustment features.

The no form of this command disables forwarding adjacency and disables the advertisement of RSVP LSP into IGP.

This command enables you to specify the MAC address to use for all L1 IS-IS routers. The MAC address should be a multicast address.

This command enables you to specify the MAC address to use for all Layer 2 IS-IS routers. The MAC address should be a multicast address.

This command was previously named the net network-entity-title command. The area-id command allows you to configure the area ID portion of NSAP addresses which identifies a point of connection to the network, such as a router interface, and is called a Network Service Access Point (NSAP). Addresses in the IS-IS protocol are based on the ISO NSAP addresses and Network Entity Titles (NETs), not IP addresses.

A maximum of three area addresses can be configured.

NSAP addresses are divided into three parts. Only the area ID portion is configurable.

The NET is constructed like an NSAP but the selector byte contains a 00 value. NET addresses are exchanged in hello and LSP PDUs. All net addresses configured on the node are advertised to its neighbors.

For Level 1 interfaces, neighbors can have different area IDs, but, they must have at least one area ID (AFI + area) in common. Sharing a common area ID, they become neighbors and area merging between the potentially different areas can occur.

For Level 2 (only) interfaces, neighbors can have different area IDs. However, if they have no area IDs in common, they become only Level 2 neighbors and Level 2 LSPs are exchanged.

For Level 1 and Level 2 interfaces, neighbors can have different area IDs. If they have at least one area ID (AFI + area) in common, they become neighbors. In addition to exchanging Level 2 LSPs, area merging between potentially different areas can occur.

If multiple area-id commands are entered, the system ID of all subsequent entries must match the first area address.

The no form of this command removes the area address.

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

This command sets an authentication check to reject PDUs that do not match the type or key requirements.

The default behavior when authentication is configured is to reject all IS-IS protocol PDUs that have a mismatch in either the authentication type or authentication key.

When no authentication-check is configured, authentication PDUs are generated and IS-IS PDUs are authenticated on receipt. However, mismatches cause an event to be generated and will not be rejected.

The no form of this command allows authentication mismatches to be accepted and generate a log event.

This command sets the authentication key used to verify PDUs sent by neighboring routers on the interface.

Neighboring routers use passwords to authenticate PDUs sent from an interface. For authentication to work, both the authentication key and the authentication type on a segment must match. The authentication-type command must also be included.

To configure authentication on the global level, configure this command in the config>router>isis context. When this parameter is configured on the global level, all PDUs are authenticated including the hello PDU.

To override the global setting for a specific level, configure the authentication-key command in the config>router>isis>level context. When configured within the specific level, hello PDUs are not authenticated.

The no form of this command removes the authentication key.

This command enables either simple password or message digest authentication or must go in either the global IS-IS or IS-IS level context.

Both the authentication key and the authentication type on a segment must match. The authentication-key statement must also be included.

Configure the authentication type on the global level in the config>router>isis context.

Configure or override the global setting by configuring the authentication type in the config>router>isis>level context.

The no form of this command disables authentication.

This command enables authentication of individual IS-IS packets of complete sequence number PDUs (CSNP) type.

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

This command enables the population of the extended TE Database (TE-DB) with the link-state information from a given IGP instance.

The extended TE-DB is used as a central point for importing all link-state information, link, node, and prefix, from IGP instances on the router or the vSROS controller of the NSP and to exporting it to BGP-LS on the router and to Java-VM proxy on the vSROS controller. This information includes the IGP, TE, and the SR information, prefix SID sub-TLV, adjacency SID sub-TLV, and router SR capability TLV.

The no form of this command disables database exportation.

This command configures the route tag for default route.

This command disables the IGP-LDP synchronization feature on all interfaces participating in the OSPF or IS-IS routing protocol. When this command is executed, IGP immediately advertises the actual value of the link cost for all interfaces which have the IGP-LDP synchronization enabled if the currently advertised cost is different. It will then disable IGP-LDP synchronization for all interfaces. This command does not delete the interface configuration. The no form of this command has to be entered to re-enable IGP-LDP synchronization for this routing protocol.

The no form of this command restores the default settings and re-enables IGP-LDP synchronization on all interfaces participating in the OSPF or IS-IS routing protocol and for which the ldp-sync-timer is configured.

This command enables the context for the configuration of entropy label capabilities for the routing protocol.

This command configures the ability to override any received entropy label capability advertisement. When enabled, the system assumes that all nodes for an IGP domain are capable of receiving and processing the entropy label on segment routed tunnels. This command can only be configured if entropy-label is enabled via the config>router>isis>segment-routing>entropy-label or config>router>ospf>segment-routing>entropy-label command.

The no form of this command disables the override. The system assumes entropy label capability for other nodes in the IGP instance if capability advertisements are received.

This command configures export routing policies that determine the routes exported from the routing table to IS-IS.

If no export policy is defined, non IS-IS routes are not exported from the routing table manager to IS-IS.

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 export commands are issued, the last command entered overrides the previous command. A maximum of five policy names can be specified.

If an aggregate command is also configured in the config>router context, then the aggregation is applied before the export policy is applied.

Routing policies are created in the config>router>policy-options context.

The no form of this command removes the specified policy-name or all policies from the configuration if no policy-name is specified.

This command configures the maximum number of routes (prefixes) that can be exported into IS-IS from the route table. After the maximum is reached, a warning log message is sent and additional routes are ignored.

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

This command enables the context to configure the IS-IS parameters for flexible algorithm participation.

This command enables the context to configure for an IS-IS flexible algorithm.

A maximum of five unique flexible algorithms can be configured on a router across all configured IS-IS instances. The supported range for segment routing, algorithms is [128-255]. In each IS-IS flexible algorithm configuration context, the IS-IS instance participation can be either enabled or disabled, and it configures the advertising of a locally configured flexible algorithm definition.

When flexible algorithm is enabled in an IS-IS instance, it is enabled for all levels (Level 1 and Level 2) and the IS-IS instance is enabled.

The no form of this command removes the IS-IS flexible algorithm configuration context.

This command enables the advertisement of a locally configured flexible algorithm definition.

A locally defined Flexible Algorithm Definition (FAD) is only advertised if the FAD is administratively enabled. A router can advertise only a single locally defined FAD by using the fad-name as reference anchor.

The winning FAD used by a router must be consistent with the winning FAD on all other routers. This avoids routing loops and traffic blackholing. The winning FAD is selected using a tie-breaker algorithm that first selects the highest advertised FAD priority and next the highest system Id.

The no form of this command removes the advertisement of a flexible algorithm definition.

This command enables the advertisement of flexible algorithm aware loop free alternates (LFAs).

The flexible algorithm LFA configuration (for example, LFA, remote-LFA or TI-LFA) slaves the loopfree-alternate configuration for base SPF algorithm 0.

LFAs are administratively disabled for flexible alogrithms in which IS-IS is participating. LFAs must be explicitly enabled using the loopfree-alternates command.

The no form of this command disables LFAs for the specific flexible algorithm in which the router is participating.

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

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

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

This command enables IS-IS flexible algorithms. If it is enabled with the no shutdown command the router starts supporting the flexible algorithms IGP LSDB extensions. Flexible algorithm IGP LSDB extensions are by default not enabled.

The no form of this command enables the router to support flexible algorithms.

This command enables IS-IS graceful restart (GR) to minimize service interruption. When the control plane of a GR-capable router fails or restarts, the neighboring routers (GR helpers) temporarily preserve IS-IS forwarding information. Traffic continues to be forwarded to the restarting router using the last known forwarding tables. If the control plane of the restarting router becomes operationally and administratively up within the grace period, the restarting router resumes normal IS-IS operation. If the grace period expires, then the restarting router is presumed inactive and the IS-IS topology is recalculated to route traffic around the failure.

The no form of this command disables graceful restart and removes the graceful restart configuration from the IS-IS instance.

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

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

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

This command 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 context to configure the resolution of IGP IPv4 prefix families, IGP IPv6 prefix families, SR-ISIS IPv4 tunnel families, SR-ISIS IPv6 tunnel families, and SR-OSPF IPv4 tunnel families using IGP shortcuts.

The resolution node is introduced to provide flexibility in the selection of the tunnel types for each of the IP prefix and SR tunnel families.

The IPv4 family option causes the IS-IS or OSPF SPF to include the IPv4 IGP shortcuts in the IP reach calculation of IPv4 nodes and prefixes. RSVP-TE or SR-TE LSPs terminating on a node identified by its router ID can be used to reach IPv4 prefixes owned by this node or for which this node is the IPv4 next hop.

The IPv6 family option causes the IS-IS or OSPFv3 SPF to include the IPv4 IGP shortcuts in the IP reach calculation of IPv6 nodes and prefixes. RSVP-TE or SR-TE LSPs terminating on a node identified by its router ID can be used to reach IPv6 prefixes owned by this node or for which this node is the IPv6 next-hop. The resolution of IPv6 prefixes is supported in OSPFv3 and in both IS-IS MT=0 and MT=2.

The IS-IS and OSPFv3 IPv6 routes resolved to IPv4 IGP shortcuts are used to:

In the data path, a packet for an IPv6 prefix has a label stack that consists of the IPv6 Explicit-Null label value of 2 at the bottom of the label stack followed by the label stack of the IPv4 RSVP-TE LSP.

There is no default behavior for IPv4 prefixes to automatically resolve to RSVP-TE or SR-TE LSPs used as IGP shortcuts by only enabling the igp-shortcut context. Instead, the user must enable the ipv4 family or ipv6 family and set the resolution to the value of rsvp-te to select the RSVP-TE tunnel type, or to the value of sr-te to select the SR-TE tunnel type.

Setting the resolution to the any value means that IGP selects the tunnels used as IGP shortcuts according to the TTM preference for the tunnel type. The RSVP-TE LSP type is of higher priority than the SR-TE LSP type.

An IP prefix of family=ipv4 or family= ipv6 always resolves to a single type of tunnel rsvp-te or sr-te. Rsvp-te type is preferred if both types are allowed by the prefix family resolution and both types exist in the set of tunnel next-hops of the prefix. The feature does not support mixing tunnel types per prefix.

If resolution for the IPv4 or IPv6 family is set to disabled, the corresponding prefixes are resolved to IP next-hops in the multicast routing table.

The srv4 family enables the resolution of SR-OSPF IPv4 tunnels and SR-ISIS IPv4 tunnels in MT=0 over RSVP-TE IPv4 IGP shortcuts. A maximum of 32 ECMP tunnel next-hops can be programmed for an SR-OSPF or an SR-ISIS IPv4 tunnel.

The srv6 family enables the resolution of SR-ISIS IPv6 tunnels in MT=0 over RSVP-TE IPv4 IGP shortcuts. A maximum of 32 ECMP tunnel next-hops can be programmed for an SR-ISIS IPv6 tunnel.

One or more RSVP-TE LSPs can be selected if resolution=match-family-ip and the corresponding IPv4 or IPv6 prefix resolves to RSVP-TE LSPs.

Note: An SR tunnel cannot resolve to SR-TE IGP shortcuts.

If resolution for the SRv4 or SRv6 tunnel family is set to disabled, the corresponding tunnels are resolved to IP next-hops in the multicast routing table.

To enable (disable) IGP shortcuts in the IGP instance, the user must perform a shutdown or no shutdown in the igp-shortcut context.

This command enables the context to configure the resolution of IGP IPv4 prefix family, IGP IPv6 prefix family, SR-ISIS IPv4 tunnel family, and SR-ISIS IPv6 tunnel family using IGP shortcuts.

This command configures resolution mode in the resolution of the IP prefix or SR tunnel family using IGP shortcuts.

This command enables the context to configure the subset of tunnel types which can be used in the resolution of the IP prefix or SR tunnel family using IGP shortcuts.

This command selects the RSVP-TE tunnel type in the resolution of the IP prefix or SR tunnel family using IGP shortcuts.

This command selects the SR-TE tunnel type in the resolution of the IP prefix or SR tunnel family using IGP shortcuts.

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

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

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

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

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

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

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

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 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 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 creates the context to configure an IS-IS interface.

When an area is defined, the interfaces belong to that area. Interfaces cannot belong to separate areas.

When the interface is a POS channel, the OSINCP is enabled when the interface is created and removed when the interface is deleted.

The no form of this command removes IS-IS from the interface.

The shutdown command in the config>router>isis>interface context administratively disables IS-IS on the interface without affecting the IS-IS configuration.

This command enables the use of bidirectional forwarding detection (BFD) to control IPv4 adjacencies. By enabling BFD on an IPv4 or IPv6 protocol interface, the state of the protocol interface is tied to the state of the BFD session between the local node and the remote node. The parameters used for the BFD are set by the BFD command under the IP interface. This command must be given separately to enable/disable BFD for both IPv4 and IPv6.

The no form of this command removes BFD from the associated adjacency.

This command configures the time interval, in seconds, to send complete sequence number (CSN) PDUs from the interface. IS-IS must send CSN PDUs periodically.

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

This command enables a non-MI capable router to establish an adjacency and operate with a router in a non-zero instance. If the router does not receive IID-TLVs, it will establish an adjacency in a single instance. Instead of establishing an adjacency in the standard instance 0, the router will establish an adjacency in the configured non-zero instance. The router will then operate in the configured non-zero instance so that it appears to be in the standard instance 0 to its neighbor. This feature is supported on point-to-point interfaces, broadcast interfaces are not supported.

This feature must be configured on the router connected to non-MI capable routers and on all other SR OS routers in the area, so that they receive non-MI LSPs in the correct instance and not in the base instance.

The no form of this command disables the functionality so that the router can only establish adjacencies in the standard instance 0.

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

This command enables hello authentication on the interface.

The no form of this command disables hello authentication on the interface.

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

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

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

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

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

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

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

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

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

The no form of this command disables hello authentication.

This command configures the IS-IS interface type as either broadcast or point-to-point.

Use this command to set the interface type of an Ethernet link to point-to-point to avoid having to carry the designated IS-IS overhead if the link is used as a point-to-point.

If the interface type is not known at the time the interface is added to IS-IS and subsequently the IP interface is bound (or moved) to a different interface type, then this command must be entered manually.

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

This command allows a static value to be assigned to an IPv4 adjacency SID in IS-IS segment routing.

The label option specifies that the value is assigned to an MPLS label.

The no form of this command removes the adjacency SID.

This command allows a static value to be assigned to an IPv6 adjacency SID in IS-IS segment routing.

The label option specifies that the value is assigned to an MPLS label.

The no form of this command removes the adjacency SID.

This command disables IS-IS IPv4 multicast routing for the interface.

The no form of this command enables IS-IS IPv4 multicast routing for the interface.

This command assigns a node SID index or label value to the prefix representing the primary address of an IPv4 network interface of type loopback. Only a single node SID can be assigned to an interface. The secondary address of an IPv4 interface cannot be assigned a node SID index and does not inherit the SID of the primary IPv4 address.

The command fails if the network interface is not of type loopback or if the interface is defined in an IES or a VPRN context. Also, assigning the same SID index or label value to the same interface in two different IGP instances is not allowed within the same node.

The value of the label or index SID is taken from the range configured for this IGP instance. When using the global mode of operation, a new segment routing module checks that the same index or label value cannot be assigned to more than one loopback interface address. When using the per-instance mode of operation, this check is not required since the index and thus label ranges of the various IGP instance are not allowed to overlap.

The clear-n-flag option allows the user to clear the N-flag (node-sid flag) in an IS-IS prefix SID sub-TLV originated for the IPv4 prefix of a loopback interface on the system.

By default, the prefix SID sub-TLV for the prefix of a loopback interface is tagged as a node SID, meaning that it belongs to this node only. However, when the user wants to configure and advertise an anycast SID using the same loopback interface prefix on multiple nodes, you must clear the N-flag to assure interoperability with third party implementations, which may perform a strict check on the receiving end and drop duplicate prefix SID sub-TLVs when the N-flag is set.

The SR OS implementation is relaxed on the receiving end and accepts duplicate prefix SIDs with the N-flag set or cleared. SR OS will resolve to the closest owner, or owners if ECMP is configured, of the prefix SID according to its cost.

This command disables IS-IS IPv6 multicast routing for the interface.

The no form of this command enables IS-IS IPv6 multicast routing for the interface.

This command assigns a node SID index or label value to the prefix representing the primary address of an IPv6 network interface of type loopback. Only a single node SID can be assigned to an IPv6 interface. When an IPv6 interface has multiple global addresses, the primary address is always the first one in the list, as displayed by the interface info command.

The command fails if the network interface is not of loopback type or if the interface is defined in an IES or a VPRN context. Assigning the same SID index/label value to the same interface in two different IGP instances is not allowed within the same node.

The value of the label or index SID is taken from the range configured for this IGP instance. When using the global mode of operation, a new segment routing module checks that the same index or label value cannot be assigned to more than one loopback interface address. When using the per-instance mode of operation, this check is not required since the index and thus label ranges of the various IGP instance are not allowed to overlap.

The clear-n-flag option allows the user to clear the N-flag (node-sid flag) in an IS-IS prefix SID sub-TLV originated for the IPv6 prefix of a loopback interface on the system.

By default, the prefix SID sub-TLV for the prefix of a loopback interface is tagged as a node SID, meaning that it belongs to this node only. However, when the user wants to configure and advertise an anycast SID using the same loopback interface prefix on multiple nodes, you must clear the N-flag to assure interoperability with third-party implementations, which may perform a strict check on the receiving end and drop duplicate prefix SID sub-TLVs when the N-flag is set.

The SR OS implementation is relaxed on the receiving end and accepts duplicate prefix SIDs with the N-flag set or cleared. SR OS will resolve to the closest owner, or owners if ECMP is configured, of the prefix SID according to its cost.

This command disables IS-IS IPv6 unicast routing for the interface.

By default, IPv6 IPv6 unicast on all interfaces is enabled. However, IPv6 unicast routing on IS-IS is in effect when the config>router>isis>ipv6-routing mt command is configured.

The no form of this command enables IS-IS IPv6 unicast routing for the interface.

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 enables router advertisement capabilities.

The no form of this command disables router advertisement capabilities.

This command enables BIER capabilities.

The no form of this command disables BIER capabilities.

This command assigns a BIER template to an IS-IS level.

The no form of this command removes templates from the IS-IS level.

This command allows the user to prune the IGP link-state information of a specific IS-IS level from being exported into the extended TE-DB.

The no form of this command returns to the default behavior inherited from the database-export command at the IS-IS instance level.

This command configures the default metric to be used for the IS-IS interface in the IPv4 multicast topology (MT3).

The no form of this command deletes the specified default metric and reverts to using the system default of 10.

This command configures the default metric to be used for the IS-IS interface in the IPv6 multicast topology (MT4).

The no form of this command deletes the specified default metric and reverts to using the system default of 10.

This command specifies the default metric for IPv6 unicast.

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

This command specifies the configurable default metric used for all IS-IS interfaces on this level. This value is not used if a metric is configured for an interface.

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

This command configures the external route preference for the IS-IS level.

The external-preference command configures the preference level of either IS-IS level 1 or IS-IS level 2 external routes. By default, the preferences are as listed in the table below.

A route can be learned by the router by different protocols, in which case, the costs are not comparable. When this occurs, the preference decides the route to use.

Different protocols should not be configured with the same preference, if this occurs the tiebreaker is dependent on the default preference table. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used. If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, then the decision of the route to use is determined by the configuration of the ecmp in the config>router context.

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

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

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

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

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

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

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

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

This command configures the IS-IS interface metric for IPv4 multicast.

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

This command configures the IS-IS interface metric for IPv6 multicast.

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

This command configures the IS-IS interface metric for IPv6 unicast.

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

This command sets the offset value for the IPv4 multicast address family. If the number of operational links drops below the oper-members threshold, the configured offset is applied to the interface metric for the IPv4 multicast topology.

The no form of this command reverts the offset value to 0.

This command sets the offset value for the IPv6 multicast address family. If the number of operational links drops below the oper-members threshold, the configured offset is applied to the interface metric for the IPv6 multicast topology.

The no form of this command reverts the offset value to 0.

This command configures the minimum value to which the remaining lifetime of the LSP is set. The value is a counter that decrements, in seconds, starting from the value in the received LSP (if not self-originated) or from lsp-lifetime seconds (if self-originated). When the remaining lifetime becomes zero, the contents of the LSP is purged. The remaining lifetime of an LSP is not changed when there is no lsp-minimum-remaining-lifetime value configured.

The configured value must be greater than or equal to the lsp-lifetime value.

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

This command configures the LSP MTU size. If the size value is changed from the default using CLI or SNMP, then IS-IS must be restarted in order for the change to take effect. This can be done by performing a shutdown command and then a no shutdown command in the config>router>isis context.

Note: Using the exec command to execute a configuration file to change the LSP MTU-size from its default value automatically restarts IS-IS for the change to take effect.

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

This command configures the preference level of either IS-IS Level 1 or IS-IS Level 2 internal routes. By default, the preferences are listed in the table below.

A route can be learned by the router by different protocols, in which case, the costs are not comparable. When this occurs, the preference is used to decide to which route will be used.

Different protocols should not be configured with the same preference, if this occurs the tiebreaker is per the default preference table as defined in the following table. If multiple routes are learned with an identical preference using the same protocol, the lowest cost route is used. If multiple routes are learned with an identical preference using the same protocol and the costs (metrics) are equal, then the decision what route to use is determined by the configuration of the ecmp in the config>router context.

This command configures the metric used for the level on the interface.

In order to calculate the lowest cost to reach a given destination, each configured level on each interface must have a cost. The costs for each level on an interface may be different.

If the metric is not configured, the default of 10 is used unless reference bandwidth is configured.

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

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

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

The no form of this command removes the passive attribute.

This command configures the priority of the IS-IS router interface for designated router election on a multi-access network.

This priority is included in hello PDUs transmitted by the interface on a multi-access network. The router with the highest priority is the preferred designated router. The designated router is responsible for sending LSPs with regard to this network and the routers that are attached to it.

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

This command enables authentication of individual IS-IS packets of partial sequence number PDU (PSNP) type.

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

If the pre-FEC error rate of the associated DWDM port crosses the configured sd-threshold, this offset-value is added to the IS-IS interface metric. This parameter is only effective if the interface is associated with a DWDM port and the sd-threshold value is configured under that port.

The no form of this command reverts the offset value to 0.

If the pre-FEC error rate of the associated DWDM port crosses the configured sf-threshold, this offset-value is added to the IS-IS interface metric. This parameter is only effective if the interface is associated with a DWDM port and the sf-threshold value is configured under that port.

The no form of this command reverts the offset value to 0.

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

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

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

This command 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 42 displays configuration combinations and the potential adjacencies that can be formed.

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

This command applies a route next-hop policy template to an OSPF or IS-IS interface.

When a route next-hop policy template is applied to an interface in IS-IS, it is applied in both level 1 and level 2. When a route next-hop policy template is applied to an interface in OSPF, it is applied in all areas. However, the command in an OSPF interface context can only be executed under the area in which the specified interface is primary and then applied in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command will fail.

If the user excluded the interface from LFA using the command loopfree-alternate-exclude, the LFA policy, if applied to the interface, has no effect.

Finally, if the user applied a route next-hop policy template to a loopback interface or to the system interface, the command will not be rejected, but it will result in no action being taken.

The no form of this command deletes the mapping of a route next-hop policy template to an OSPF or IS-IS interface.

This command configures the weighted ECMP load-balancing weight for an IS-IS interface. If the interface becomes an ECMP next hop for an IPv4 or IPv6 route, and all the other ECMP next hops are interfaces with configured (non-zero) load-balancing weights, then the traffic distribution over the ECMP interfaces is proportional to the weights. In other words, the interface with the largest load-balancing weight should receive the most forwarded traffic if weighted ECMP is applicable.

The no form of this command disables weighted ECMP for the interface and therefore effectively disables weighted ECMP for any IP prefix that has this interface as a next hop.

This command instructs IGP to not include a specific interface or all interfaces participating in a specific IS-IS level or OSPF area in the SPF LFA computation. This provides a way of reducing the LFA SPF calculation where it is not needed.

When an interface is excluded from the LFA SPF in IS-IS, it is excluded in both level 1 and level 2. When it is excluded from the LFA SPF in OSPF, it is excluded in all areas. However, the above OSPF command can only be executed under the area in which the specified interface is primary and once enabled, the interface is excluded in that area and in all other areas where the interface is secondary. If the user attempts to apply it to an area where the interface is secondary, the command will fail.

The no form of this command re-instates the default value for this command.

This command configures the interval at which LSPs are sent from the interface.To avoid overwhelming neighbors that have less CPU processing power with LSPs, the pacing interval can be configured to limit how many LSPs are sent at the interval. LSPs are sent in bursts at the interval up to the configured limit. If a value of 0 is configured, no LSPs are sent from the interface. The interval applies to all LSPs: LSPs generated by the router, and LSPs received from other routers.

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

Note: The IS-IS pacing interval is 100 milliseconds for values < 100 milliseconds, and 1 second for values ≥ 100 milliseconds. For example, a pacing interval of 2 milliseconds means that a maximum of 50 LSPs are sent in a burst at 100 millisecond intervals. The default pacing interval of 100 milliseconds means that a maximum of 10 LSPs are sent in a burst at 1 second intervals.

This command assigns an interface to a mesh group. Mesh groups limit the amount of flooding that occurs when a new or changed LSP is advertised throughout an area.

All routers in a mesh group should be fully meshed. When LSPs need to be flooded, only a single copy is received rather than a copy per neighbor.

To create a mesh group, configure the same mesh group value for each interface that is part of the mesh group. All routers must have the same mesh group value configured for all interfaces that are part of the mesh group.

To prevent an interface from flooding LSPs, the optional blocked parameter can be specified. Configure mesh groups carefully to avoid creating isolated islands that do not receive updates as (other) links fail.

The no form of this command removes the interface from the mesh group.

This command configures the minimum time between LSP PDU retransmissions on a point-to-point interface.

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

This command enables or disables adjacency SID protection by LFA and remote LFA.

While LFA and remote LFA Fast-Reroute (FRR) protection is enabled for all node SIDs and local adjacency SIDs when the user enables the loopfree-alternates option in IS-IS or OSPF at the LER and LSR, there are applications where the user wants traffic to never divert from the strict hop computed by CSPF for a SR-TE LSP. In that case, the user can disable protection for all adjacency SIDs formed over a given network IP interface using this command.

The protection state of an adjacency SID is advertised in the B-FLAG of the IS-IS or OSPF Adjacency SID sub-TLV.

This command configures a route tag to the specified IP address of an interface.

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

The multicast RTM is used for Reverse Path Forwarding checks. This command controls which IS-IS topology is used to populate the IPv4 multicast RTM.

The no form of this command results in none of the IS-IS routes being populated in the IPv4 multicast RTM and would be used if multicast is configured to use the unicast RTM for the RPF check.

This command specifies whether this IS-IS instance supports IPv4.

The no form of this command disables IPv4 on the IS-IS instance.

The multicast RTM is used for Reverse Path Forwarding checks. This command controls which IS-IS topology is used to populate the IPv6 multicast RTM.

The no form of this command results in none of the IS-IS routes being populated in the IPv4 multicast RTM and would be used if multicast is configured to use the unicast RTM for the RPF check.

This command enables IPv6 routing.

The no form of this command disables support for IS-IS IPv6 TLVs for IPv6 routing.

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

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

This command specifies the IS-IS link group associated with this particular level of the interface.

This command adds a description string to the associated link-group. If the command is issued in the context of a link-group that already contains a description then the previous description string is replaced.

The no form of this command removes the description from the associated link-group.

This command adds or removes a link to the associated link-group. The interface name should already exist before it is added to a link-group.

The no form of this command removes the specified interface from the associated link-group.

This command sets the threshold for the minimum number of operational links for the associated link-group. If the number of operational links drops below this threshold, the configured offsets are applied. For example, oper-members=3. The metric of the member interfaces is increased when the number of interfaces is lower than 3.

The no form of this command reverts the oper-members limit to 1.

This command sets the threshold for the minimum number of operational links to return the associated link-group to its normal operating state and remove the associated offsets to the IS-IS metrics. If the number of operational links is equal to or greater than the configured revert-member threshold then the configured offsets are removed.

The no form of this command reverts the revert-members threshold back to the default which is equal to the oper-member threshold value.

This command sets the offset value for the IPv4 unicast address family. If the number of operational links drops below the oper-members threshold, the configured offset is applied to the interface metric.

The no form of this command reverts the offset value to 0.

This command sets the offset value for the IPv6 unicast address family. If the number of operational links drops below the oper-members threshold, the configured offset is applied to the interface metric for the IPv6 topology.

The no form of this command reverts the offset value to 0.

This command enables Loop-Free Alternate (LFA) computation by SPF for the IS-IS routing protocol.

When this command is enabled, it instructs the IGP SPF to attempt to pre-compute both a primary nexthop and an LFA next-hop for every learned prefix. When found, the LFA next-hop is populated into the routing table along with the primary next-hop for the prefix.

The user enables the remote LFA next-hop calculation by the IGP LFA SPF by appending the remote-lfa option. When this option is enabled in an IGP instance, SPF performs the remote LFA additional computation following the regular LFA next-hop calculation when the latter resulted in no protection for one or more prefixes which are resolved to a given interface.

Remote LFA extends the protection coverage of LFA-FRR to any topology by automatically computing and establishing/tearing-down shortcut tunnels, also referred to as repair tunnels, to a remote LFA node which puts the packets back into the shortest without looping them back to the node which forwarded them over the repair tunnel. The remote LFA node is referred to as PQ node. A repair tunnel can in theory be an RSVP LSP, a LDP-in-LDP tunnel, or a SR tunnel. In this feature, it is restricted to use SR repair tunnel to the remote LFA node.

The remote LFA algorithm is a per-link LFA SPF calculation and not a per-prefix like the regular LFA one. So, it provides protection for all destination prefixes which share the protected link by using the neighbor on the other side of the protected link as a proxy for all these destinations.

The Topology-Independent LFA (TI-LFA) further improves the protection coverage of a network topology by computing and automatically instantiating a repair tunnel to a Q node which is not in shortest path from the computing node. The repair tunnel uses shortest path to the P node and a source routed path from the P node to the Q node.

In addition, the TI-LFA algorithm selects the backup path which matches the post-convergence path. This helps the capacity planning in the network since traffic will always flow on the same path when transitioning to the FRR next-hop and then onto the new primary next-hop.

At a high level, the TI-LFA protection algorithm is searching for a candidate P-Q set separated with a number of hops such that the label stack size does not exceed the value of ti-lfa max-sr-frr-labels, on each of the post-convergence paths to each destination node or prefix D.

When the ti-lfa option is enabled in IS-IS, it provides TI-LFA node-protect or link-protect backup path in IS-IS MT=0 for an SR-ISIS IPV4/IPv6 tunnel (node SID and adjacency SID), for an IPv4 SR-TE LSP, and for LDP IPv4 FEC when the LDP fast-reroute backup-sr-tunnel option is enabled.

The max-sr-frr-labels parameter is used to limit the search for the TI-LFA backup next-hop:

When the node-protect command is enabled, the router will prefer a node-protect over a link-protect repair tunnel for a given prefix if both are found in the Remote LFA or TI-LFA SPF computations. The SPF computations may only find a link-protect repair tunnel for prefixes owned by the protected node. This node-protect backup protects against the failure of a downstream node in the path of the prefix of a node SID except for the node owner of the node SID.

The parameter max-pq-nodes in Remote LFA controls the maximum number of PQ nodes found in the LFA SPFs for which the node protection check is performed. The node-protect condition means the router must run the original Remote LFA algorithm plus one extra forward SPF on behalf of each PQ node found, potentially after applying the max-pq-cost parameter, to check if the path from the PQ node to the destination does not traverse the protected node. Setting this parameter to a lower value means the LFA SPFs will use less computation time and resources but may result in not finding a node-protect repair tunnel.

The no form of this command disables the LFA computation by IGP SPF.

This command enables IS-IS to attach Remote LFA specific information to RTM entries for use by other protocols. This command requires configure router isis lfa remote-lfa to be enabled. Currently only LDP makes use of this additional information.

The no form of this command disables IS-IS to attach Remote LFA specific information to RTM entries for use by other protocols.

This command provides the context for configuring a prefix policy for excluding specific prefixes in the LFA calculation by ISIS or OSPF.

This command excludes from LFA SPF calculation prefixes that match a prefix entry or a tag entry in a prefix policy.

The implementation already allows the user to exclude an interface in IS-IS or OSPF, an OSPF area, or an IS-IS level from the LFA SPF.

If a prefix is excluded from LFA, then it will not be included in LFA calculation regardless of its priority. The prefix tag will, however, be used in the main SPF.

This command specifies the name of the policy for the prefixes to exclude from the LFA SPF calculation in this IS-IS instance.

Note: Prefix tags are defined for the IS-IS protocol but not for the OSPF protocol.

The default action, when not explicitly specified by the user in the prefix policy, is a "reject". Thus, regardless if the user did or did not explicitly add the statement "default-action reject" to the prefix policy, a prefix that did not match any entry in the policy will be accepted into LFA SPF.

The no form of this command deletes the exclude prefix policy.

This command enables the use of the Remote LFA algorithm in the LFA SPF calculation for this ISIS instance.

The no form of this command disables the use of the Remote LFA algorithm in the LFA SPF calculation for this ISIS instance.

This command enables node-protect in which the router prefers a node-protect over a link-protect repair tunnel for a given prefix if both are found in the Remote LFA or TI-LFA SPF computations. The SPF computations may only find a link-protect repair tunnel for prefixes owned by the protected node.

The no form of this command disables node-protect.

This command enables the use of the Topology-Independent LFA algorithm in the LFA SPF calculation for this ISIS instance.

The no form of this command disables the use of the Topology-Independent LFA algorithm in the LFA SPF calculation for this ISIS instance.

This command enables node-protect in which the router prefers a node-protect over a link-protect repair tunnel for a given prefix if both are found in the Remote LFA or TI-LFA SPF computations. The SPF computations may only find a link-protect repair tunnel for prefixes owned by the protected node.

The no form of this command disables node-protect.

This command sets the time, in seconds, the router wants the LSPs it originates to be considered valid by other routers in the domain.

Each LSP received is maintained in an LSP database until the lsp-lifetime expires unless the originating router refreshes the LSP. By default, each router refreshes its LSPs every 20 minutes (1200 seconds) so other routers will not age out the LSP.

The LSP refresh timer is derived from this formula: lsp-lifetime/2

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

This command configures the IS-IS LSP refresh timer interval. When configuring the LSP refresh interval, the value that is specified for lsp-lifetime must also be considered. The LSP refresh interval cannot be greater than 90% of the LSP lifetime.

The no form of this command reverts to the default (600 seconds), unless this value is greater than 90% of the LSP lifetime. For example, if the LSP lifetime is 400, then the no lsp-refresh-interval command will be rejected.

This command enables IS-IS multi-topology support.

This command enables support for the IPv4 topology (MT3) within the associate IS-IS instance.

The no form of this command disables support for the IPv4 topology (MT3) within the associated IS-IS instance.

This command enables support for the IPv6 topology (MT4) within the associate IS-IS instance.

The no form of this command disables support for the IPv6 topology (MT4) within the associated IS-IS instance.

This command enables multi-topology TLVs.

The no form of this command disables multi-topology TLVs.

This command enables the submission of routes into the multicast Route Table Manager (RTM) by IS-IS.

The no form of this command disables the submission of routes into the multicast RTM.

This command administratively sets the IS-IS router to operate in the overload state for a specific time period, in seconds, or indefinitely.

During normal operation, the router may be forced to enter an overload state due to a lack of resources. When in the overload state, the router is only used if the destination is reachable by the router and will not be used for other transit traffic.

If a time period is specified, the overload state persists for the configured length of time. If no time is specified, the overload state operation is maintained indefinitely.

The overload command is cleared from the configuration after a reboot if overload-on-boot is configured with or without a timeout value. To keep the IS-IS router in the overload state indefinitely after rebooting, configure overload-on-boot with no timeout value or configure the overload command with no overload-on-boot command.

The overload command can be useful in circumstances where the router is overloaded or used prior to executing a shutdown command to divert traffic around the router.

The max-metric parameter can be set to advertise transit links with the maximum metric of 0xffffffe (wide metrics) or 0x3f (regular metrics), instead of setting the overload bit when placing the router in overload.

The no form of this command causes the router to exit the overload state.

This command enables external routes that are exported with an IS-IS export policy to continue to be advertised when the router is in overload.

The no form of this command causes external routes to be withdrawn when the router is in overload.

This command enables inter-level routes that are exported with an IS-IS export policy to continue to be advertised when the router is in overload.

The no form of this command causes inter-level routes to be withdrawn when the router is in overload.

When the router is in an overload state, the router is used only if there is no other router to reach the destination. This command configures the IGP upon bootup in the overload state until one of the following events occur:

The no overload command does not affect the overload-on-boot function.

If no timeout is specified, IS-IS will go into overload indefinitely after a reboot. After the reboot, the IS-IS status will display a permanent overload state:

This state can be cleared with the config>router>isis>no overload command.

When specifying a timeout value, IS-IS will go into overload for the configured timeout after a reboot. After the reboot, the IS-IS status will display the remaining time the system stays in overload:

The overload state can be cleared before the timeout expires with the config>router>isis>no overload command.

The no form of this command removes the overload-on-boot functionality from the configuration.

Use the show router isis status command to display the administrative and operational state as well as all timers.

Enable use of Purge Originator Identification (POI) TLV for this IS-IS instance. The POI is added to purges and contains the system ID of the router that generated the purge, which simplifies troubleshooting and determining what caused the purge.

The no form of this command removes the POI functionality from the configuration.

This command enables IS-IS Prefix Attributes TLV support to exchange extended IPv4 and IPv6 reachability information. Extended reachability information is required for traffic engineering features using path computation element (PCE) or optimal route reflection.

The no form of this command removes the prefix-attributes-tlv configuration.

This command configures the maximum number of prefixes that IS-IS can learn, and use to protect the system from a router that has accidentally advertised a large number of prefixes. If the number of prefixes reaches the configured percentage of this limit, an SNMP trap is sent. If the limit is exceeded, IS-IS will go into overload.

The overload-timeout option controls the length of time that IS-IS is in the overload state when the prefix-limit is reached. The system automatically attempts to restart IS-IS at the end of this duration. If the overload-timeout forever option is used, IS-IS is not restarted automatically and stays in overload until the condition is manually cleared by the administrator. This is also the default behavior when the overload-timeout option is not configured.

The no form of this command removes the prefix-limit.

This command configures the reference bandwidth that provides the basis of bandwidth relative costing.

To calculate the lowest cost to reach a specific destination, each configured level on each interface must have a cost. If the reference bandwidth is defined, then the cost is calculated using the following formula:

cost = reference-bandwidth ÷ bandwidth

If the reference bandwidth is configured as 10 Gb (reference-bandwidth 10000000000), a 100 Mb/s interface has a default metric of 100. To configure metrics in excess of 63, wide metrics must be deployed (see wide-metrics-only in the config>router>isis context).

When a large reference-bandwidth value is configured, a metric calculation may result in a value higher than the supported protocol cost value. If this occurs, IS-IS automatically reverts to the maximum configurable cost metric.

If the reference bandwidth is not configured, then all interfaces have a default metric of 10.

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

This command enabled RIB prioritization for the IS-IS protocol and specifies the prefix list or IS-IS tag value that will be used to select the specific routes that should be processed through the IS-IS route calculation process at a higher priority.

The no rib-priority form of command disables RIB prioritization.

This command configures the router ID.

The no form of this command deletes the router ID.

This command enables the context to configure segment routing parameters within a given IGP instance.

Segment routing adds to IS-IS and OSPF routing protocols the ability to perform shortest path routing and source routing using the concept of abstract segment. A segment can represent a local prefix of a node, a specific adjacency of the node (interface or next-hop), a service context, or a specific explicit path over the network. For each segment, the IGP advertises an identifier referred to as Segment ID (SID).

When segment routing is used together with MPLS data plane, the SID is a standard MPLS label. A router forwarding a packet using segment routing will thus push one or more MPLS labels.

Segment routing using MPLS labels can be used in both shortest path routing applications and in traffic engineering applications. This feature implements the shortest path forwarding application.

After segment routing is successfully enabled in the IS-IS or OSPF instance, the router will perform the following operations:

When the user enables segment routing in a given IGP instance, the main SPF and LFA SPF are computed normally and the primary next-hop and LFA backup next-hop for a received prefix are added to RTM without the label information advertised in the prefix SID sub-TLV.

This command creates an adjacency set. An adjacency set consists of one or more adjacency SIDs originating on this node. The constituent adjacencies may terminate on different nodes.

The no form of this command removes the specified adjacency set.

This command specifies the address family of an adjacency set in IS-IS.

The no form of this command reverts to the default.

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

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

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

This command allows a static SID value to be assigned to an adjacency set in IS-IS segment routing.

The label option specifies the value is assigned to an MPLS label.

The no form of this command removes the adjacency SID.

This command configures a timer to hold the ILM or LTM of an adjacency SID following a failure of the adjacency.

When an adjacency to a neighbor fails, IGP will withdraw the advertisement of the link TLV information as well as its adjacency SID sub-TLV. However, the LTN or ILM record of the adjacency SID must be kept in data path to maintain forwarding using the LFA or remote LFA backup for a period of time sufficient to allow the ingress LER and other routers which use this adjacency SID to activate a new path after IGP converges.

If the adjacency is restored before the timer expires, the timer is aborted as soon as the new ILM or LTN records are updated with the new primary and backup NHLFE information.

The no form of this command removes adjacency SID hold time.

This command enables exporting to an IGP instance the LDP tunnels for the purpose of stitching a SR tunnel to a LDP FEC for the same destination IPv4 /32 prefix.

In the SR-to-LDP data path direction, the SR mapping server provides a global policy for the prefixes corresponding to the LDP FECs the SR stitches to.

When this command is enabled in the segment-routing context of an IGP instance, IGP listens to LDP tunnel entries in the TTM. Whenever a LDP tunnel destination matches a prefix for which IGP received a prefix-SID sub-TLV from a mapping server, it instructs the SR module to program the SR ILM and to stitch it to the LDP tunnel endpoint. The LDP FEC can be resolved via a static route, a IS-IS instance, or an OSPF instance.

When an SR tunnel is stitched to a LDP FEC, packets forwarded will benefit from the protection of the LFA backup next-hop of the LDP FEC.

When resolving a node SID, IGP will prefer resolution of prefix SID received in a IP Reach TLV over a prefix SID received via the mapping server. In other words, the swapping of the SR ILM to a SR NHLFE is preferred over stitching it to a LDP tunnel endpoint.

It is recommended to enable the bfd-enable option on the interfaces in both LDP and IGP instance contexts to speed up the failure detection and the activation of the LFA/remote-LFA backup next-hop in either direction of the stitching.

This feature is limited to IPv4 /32 prefixes in both LDP and SR.

The no form of this command disables the exporting of LDP tunnels to the IGP instance.

This command configures the context for the Segment Routing mapping server feature in an IS-IS instance.

The mapping server feature allows the configuration and advertisement via IS-IS of the node SID index for IS-IS prefixes of routers which are in the LDP domain. This is performed in the router acting as a mapping server and using a prefix-SID sub-TLV within the SID/Label binding TLV in IS-IS.

The no form of this command deletes all node SID entries in the IS-IS instance.

This command configures the Segment Routing mapping server database in IS-IS.

The node SID index for one or a range of prefixes by specifying the first index value and optionally a range value can be entered. The default value for the range option is 1. Only the first prefix in a consecutive range of prefixes must be entered. The user can enter the first prefix with a mask lower than 32 and the SID or label binding TLV is advertised but the routers will not resolve these prefix SIDs and will instead originate a trap.

The IS-IS routers in the rest of the network that the flooding scope of the SID or label binding TLV is the entire domain by setting the S-flag can be indicated. In that case, a router receiving the TLV advertisement should leak it between ISIS levels. If leaked from level 2 to level 1, the D-flag must be set and once set the TLV cannot be leaked back into level 2. Otherwise, the S-flag is clear by default and the TLV must not be leaked by routers receiving the mapping server advertisement.

Note that the SR OS does not leak this TLV between IS-IS instances and does not support the multi-topology SID/Label Binding TLV format.

In addition, the user can specify the mapping server own flooding scope for the generated SID or label binding TLV using the level option. This option allows further narrowing of the flooding scope configured under the router IS-IS level-capability for a one or more SID or label binding TLVs if required. The default flooding scope of the mapping server is Layer 1 or Layer 2 which can be narrowed by what is configured under the router IS-IS level-capability.

The A-flag and M-flag are not supported by the mapping server feature. The mapping client ignores them.

Each time a prefix or a range of prefixes is configured in the SR mapping database in any routing instance, the router issues for this prefix, or range of prefixes, a prefix-SID sub-TLV within a ISIS SID or label binding TLV in that instance. The flooding scope of the TLV from the mapping server is determined as explained above. No further check of the reachability of that prefix in the mapping server route table is performed and no check if the SID index is duplicate with some existing prefix in the local IGP instance database or if the SID index is out of range with the local SRGB.

The no form of this command deletes the range of node SIDs beginning with the specified index value.

This command enables the context to configure a manual override of the Maximum Segment Depths (MSD) that is announced by the router.

This command provides the ability to override the announced MSD node Base MPLS Imposition (BMI). The MSD-BMI value announced by a router can be used by recipients to understand the number of MPLS labels that can be imposed inclusive of all service, transport, or special labels.

When override-bmi is not configured, the router announces the node maximum supported BMI assuming the most simple services and Layer 2 encapsulation.

The no form of this command reverts to the default.

This command provides the ability to override the announced MSD node Entropy Readable Label Depth (ERLD). It is useful for ingress LSRs to know each intermediate LSR's capability of reading the maximum label stack depth and performing EL-based load balancing.

When override-erld is not configured, then the router announces the node maximum supported ERLD assuming the most simple Layer 2 encapsulation.

The no form of this command reverts to the default.

This command enables, in the IGP instance, the micro-loop avoidance feature to prevent micro-loops from using Segment Routing (SR) loop-free tunnels for packets that are forwarded over SR IS-IS node SIDs.

When enabled, the behavior of the feature is triggered by the receipt of a single P2P link event:

IGP then performs the following procedures:

The no form of this command disables the micro-loop avoidance feature.

This command configures the prefix SID index range and offset label value for a given IGP instance.

The key parameter is the configuration of the prefix SID index range and the offset label value which this IGP instance will use. Since each prefix SID represents a network global IP address, the SID index for a prefix must be network-wide unique. Thus, all routers in the network are expected to configure and advertise the same prefix SID index range for a given IGP instance. However, the label value used by each router to represent this prefix; that is, the label programmed in the ILM can be local to that router by the use of an offset label, referred to as a start label:

Local Label (Prefix SID) = start-label + {SID index}

The label operation in the network becomes thus very similar to LDP when operating in the independent label distribution mode (RFC 5036, LDP Specification) with the difference that the label value used to forward a packet to each downstream router is computed by the upstream router based on advertised prefix SID index using the above formula.

There are two mutually exclusive modes of operation for the prefix SID range on the router. In the global mode of operation, the user configures the global value and this IGP instance will assume the start label value is the lowest label value in the SRGB and the prefix SID index range size equal to the range size of the SRGB. Once one IGP instance selected the global option for the prefix SID range, all IGP instances on the system will be restricted to do the same. The user must shutdown the segment routing context and delete the prefix-sid-range command in all IGP instances in order to change the SRGB. Once the SRGB is changed, the user must re-enter the prefix-sid-range command again. The SRGB range change will be failed if an already allocated SID index/label goes out of range.

In the per-instance mode of operation, the user partitions the SRGB into non-overlapping sub-ranges among the IGP instances. The user thus configures a subset of the SRGB by specifying the start label value and the prefix SID index range size. All resulting net label values (start-label + index} must be within the SRGB or the configuration will be failed. Furthermore, the code checks for overlaps of the resulting net label value range across IGP instances and will strictly enforce that these ranges do not overlap. The user must shutdown the segment routing context of an IGP instance in order to change the SID index/label range of that IGP instance using the prefix-sid-range command. In addition, any range change will be failed if an already allocated SID index/label goes out of range. The user can however change the SRGB on the fly as long as it does not reduce the current per IGP instance SID index/label range defined with the prefix-sid-range. Otherwise, the user must shutdown the segment routing context of the IGP instance and delete and re-configure the prefix-sid-range command.

This command configures the MTU of all SR tunnels within each IGP instance.

The MTU of a SR tunnel populated into TTM is determined like in the case of an IGP tunnel; for example, LDP LSP, based on the outgoing interface MTU minus the label stack size. Remote LFA can add, at most, one more label to the tunnel for a total of two labels. There is no default value for this command. If the user does not configure an SR tunnel MTU, the MTU is determined by IGP as explained below.

The MTU of the SR tunnel in bytes is then determined as follows:

SR_Tunnel_MTU = MIN {Cfg_SR_MTU, IGP_Tunnel_MTU- (1+frr-overhead)*4}

Where:

Cfg_SR_MTU is the MTU configured by the user for all SR tunnels within a given IGP instance using the above CLI. If no value was configured by the user, the SR tunnel MTU will be determined by the IGP interface calculation explained next.

IGP_Tunnel_MTU is the minimum of the IS-IS or OSPF interface MTU among all the ECMP paths or among the primary and LFA backup paths of this SR tunnel.

frr-overhead is set to 1 if segment-routing and remote-lfa options are enabled in the IGMP instance. Otherwise, it is set to 0.

The SR tunnel MTU is dynamically updated anytime any of the above parameters used in its calculation changes. This includes when the set of the tunnel next-hops changes or the user changes the configured SR MTU or interface MTU value.

This command configures the TTM preference of SR tunnels created by the IGP instance. This is used in the case of BGP shortcuts, VPRN auto-bind, or BGP transport tunnel when the new tunnel binding commands are configured to the any value which parses the TTM for tunnels in the protocol preference order. The user can choose to either go with the global TTM preference or list explicitly the tunnel types they want to use. When they list the tunnel types explicitly, the TTM preference will still be used to select one type over the other. In both cases, a fallback to the next preferred tunnel type is performed if the selected one fails. Also, a reversion to a more preferred tunnel type is performed as soon as one is available.

The segment routing module adds to TTM a SR tunnel entry for each resolved remote node SID prefix and programs the data path with the corresponding LTN with the push operation pointing to the primary and LFA backup NHLFEs.

The default preference for SR tunnels in the TTM is set lower than LDP tunnels but higher than BGP tunnels to allow controlled migration of customers without disrupting their current deployment when they enable segment routing. The following is the setting of the default preference of the various tunnel types. This includes the preference of SR tunnels based on shortest path (referred to as SR-ISIS and SR-OSPF).

The global default TTM preference for the tunnel types is as follows:

The default value for SR-ISIS or SR-OSPF is the same regardless if one or more IS-IS or OSPF instances programmed a tunnel for the same prefix. The selection of a SR tunnel in this case will be based on lowest IGP instance-id.

This command enables IS-IS multi-instance (MI) as described in draft-ginsberg-isis-mi-bis-01. 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. A single topology is supported in each instance, so the instance-specific topology identifier (ITID) is set to 0 and cannot be changed.

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

The no form of this command removes the standard-multi-instance configuration.

This command enables strict checking of address families (IPv4 and IPv6) for IS-IS adjacencies. When enabled, adjacencies will not come up unless both routers have exactly the same address families configured. If there is an existing adjacency with unmatched address families, it will be torn down. This command is used to prevent black-holing traffic when IPv4 and IPv6 topologies are different. When disabled (no strict-adjacency-check) a BFD session failure for either IPv4 or Ipv6 will cause the routes for the other address family to be removed as well.

When disabled (no strict-adjacency-check), both routers only need to have one common address family to establish the adjacency.

This command creates summary-addresses.

This command configures IS-IS to suppress setting the attached bit on originated Level 1 LSPs to prevent all L1 routers in the area from installing a default route to it.

This command configures the IS-IS system ID. The system ID has a fixed length of 6 octets; it is determined using the following preference:

The system ID is integral to IS-IS; therefore, for the system-id command to take effect, the IS-IS instance must be shutdown and then no shutdown. This will ensure that the configured and operational system ID are always the same.

The no form of this command removes the system ID from the configuration. The router ID is used when no system ID is specified.

This command configures the IS-IS timer values.

This command customizes LSP generation throttling. Timers that determine when to generate the first, second and subsequent LSPs can be controlled with this command. Subsequent LSPs are generated at increasing intervals of the second lsp-wait timer until a maximum value is reached.

Note: The timer granularity is 10 ms if the value is less than 500 ms, and 100 ms if the value is greater than or equal to 500 ms. Timer values are rounded down to the nearest granularity, for example a configured value of 550 ms is internally rounded down to 500 ms.

This command defines the maximum interval between two consecutive SPF calculations in milliseconds. Timers that determine when to initiate the first, second and subsequent SPF calculations after a topology change occurs can be controlled with this command.

Subsequent SPF runs (if required) will occur at exponentially increasing intervals of the spf-second-wait interval. For example, if the spf-second-wait interval is 1000, then the next SPF will run after 2000 milliseconds, and then next SPF will run after 4000 milliseconds, etc., until it reaches the spf-wait value. The SPF interval will stay at spf-wait value until there are no more SPF runs scheduled in that interval. After a full interval without any SPF runs, the SPF interval will drop back to spf-initial-wait.

Note: The timer granularity is 100 ms. Timer values are rounded down to the nearest granularity, for example a configured value of 550 ms is internally rounded down to 500 ms.

This command enables this IS-IS instance to advertise TE link attributes for RSVP-TE and SR-TE enabled interfaces.

This command enables the context for configuring advanced traffic-engineering options.

The no form of this command deletes the context.

This command enables the context to configure advertisement of the TE attributes of each link on a per-application basis. Two applications are supported in SR OS: RSVP-TE and SR-TE.

The legacy mode of advertising TE attributes that is used in RSVP-TE is still supported but it can be disabled by using the no legacy command, which also enables per-application TE attribute advertisement for RSVP-TE.

The no form of this command deletes the context.

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 enables the advertisement of IPv6 TE in the IS-IS instance. When this command is enabled, traffic engineering behavior with IPv6 TE links is enabled. This IS-IS instance automatically begins advertising the new RFC 6119 IPv6 and TE TLVs and sub-TLVs.

The no form of this command disables IPv6 TE in this ISIS instance.

This command allows one IGP to import its routes into RPF RTM while another IGP imports routes only into the unicast RTM. Import policies can redistribute routes from an IGP protocol into the RPF RTM (the multicast routing table). By default, the IGP routes are not imported into RPF RTM, thus, an import policy must be explicitly configured.