4.6. Configuring IS-IS with CLI
This section provides information to configure IS-IS using the command line interface.
4.6.1. IS-IS Configuration Overview
4.6.1.1. Router Levels
The router’s level capability can be configured globally and on a per-interface basis. The interface-level parameters specify the interface’s routing level. The neighbor capability and parameters define the adjacencies that are established.
IS-IS is not enabled by default. When IS-IS is enabled, the global default level capability is Level 1/2 which enables the router to operate as either a Level 1 and/or a Level 2 router with the associated databases. The router runs separate shortest path first (SPF) calculations for the Level 1 area routing and for the Level 2 multi-area routing to create the IS-IS routing table.
The level value can be modified on both or either of the global and interface levels to be only Level 1-capable, only Level 2-capable or Level 1 and Level 2-capable.
If the default value is not modified on any routers in the area, then the routers try to form both Level 1 and Level 2 adjacencies on all IS-IS interfaces. If the default values are modified to Level 1 or Level 2, then the number of adjacencies formed are limited to that level only.
4.6.1.2. Area Address Attributes
The area-id command specifies the area address portion of the NET which is used to define the IS-IS area to which the router will belong. At least one area-id command should be configured on each router participating in IS-IS. A maximum of three area-id commands can be configured per router.
The area address identifies a point of connection to the network, such as a router interface, and is called a network service access point (NSAP). The routers in an area manage routing tables about destinations within the area. The Network Entity Title (NET) value is used to identify the IS-IS area to which the router belongs.
NSAP addresses are divided into three parts. Only the Area ID portion is configurable.
- Area ID — A variable length field between 1 and 13 bytes long. This includes the Authority and Format Identifier (AFI) as the most significant byte and the area ID.
- System ID — A six-byte system identification. This value is not configurable. The system ID is derived from the system or router ID.
- Selector ID — A one-byte selector identification that must contain zeros when configuring a NET. This value is not configurable. The selector ID is always 00.
The following example displays ISO addresses in IS-IS address format:
MAC address 00:a5:c7:6b:c4:9049.0011.00a5.c76b.c490.00 IP address: 218.112.14.5 49.0011.2181.1201.4005.00
4.6.1.3. Interface Level Capacity
The level capability value configured on the interface level is compared to the level capability value configured on the global level to determine the type of adjacencies that can be established. The default level capability for routers and interfaces is Level 1/2.
Table 39 displays configuration combinations and the potential adjacencies that can be formed.
Table 39: Potential Adjacency
Global Level | Interface Level | Potential Adjacency |
L 1/2 | L 1/2 | Level 1 and/or Level 2 |
L 1/2 | L 1 | Level 1 only |
L 1/2 | L 2 | Level 2 only |
L 2 | L 1/2 | Level 2 only |
L 2 | L 2 | Level 2 only |
L 2 | L 1 | — |
L 1 | L 1/2 | Level 1 only |
L 1 | L 2 | — |
L 1 | L 1 | Level 1 only |
4.6.1.4. Route Leaking
Nokia’s implementation of IS-IS route leaking is performed in compliance with RFC 2966, Domain-wide Prefix Distribution with Two-Level IS-IS. As previously stated, IS-IS is a routing domain (an autonomous system running IS-IS) which can be divided into Level 1 areas with a Level 2-connected subset (backbone) of the topology that interconnects all of the Level 1 areas. Within each Level 1 area, the routers exchange link state information. Level 2 routers also exchange Level 2 link state information to compute routes between areas.
Routers in a Level 1 area typically only exchange information within the Level 1 area. For IP destinations not found in the prefixes in the Level 1 database, the Level 1 router forwards PDUs to the nearest router that is in both Level 1/Level 2 with the attached bit set in its Level 1 link-state PDU.
There are many reasons to implement domain-wide prefix distribution. The goal of domain-wide prefix distribution is to increase the granularity of the routing information within the domain. The routing mechanisms specified in RFC 1195 are appropriate in many situations and account for excellent scalability properties. However, in certain circumstances, the amount of scalability can be adjusted which can distribute more specific information than described by RFC 1195.
Distributing more prefix information can improve the quality of the resulting routes. A well-known property of default routing is that loss of information can occur. This loss of information affects the computation of a route based upon less information which can result in sub-optimal routes.
4.6.2. Basic IS-IS Configuration
For IS-IS to operate on the routers, IS-IS must be explicitly enabled, and at least one area address and interface must be configured. If IS-IS is enabled but no area address or interface is defined, the protocol is enabled but no routes are exchanged. When at least one area address and interface are configured, then adjacencies can be formed and routes exchanged.
To configure IS-IS, perform the following tasks:
- Enable IS-IS (specifying the instance ID of multi-instance IS-IS is to be enabled).
- If necessary, modify the level capability on the global level (default is level-1/2).
- Define area addresses.
- Configure IS-IS interfaces.
The following output displays IS-IS default values.
4.6.3. Common Configuration Tasks
To implement IS-IS in your network, you must enable IS-IS on each participating router.
To assign different level to the routers and organize your network into areas, modify the level capability defaults on end systems from Level 1/2 to Level 1. Routers communicating to other areas can retain the Level 1/2 default.
On each router, at least one area ID also called the area address should be configured as well as at least one IS-IS interface.
- Enable IS-IS.
- Configure global IS-IS parameters.
- Configure area addresses.
- Configure IS-IS interface-specific parameters.
4.6.4. Configuring IS-IS Components
Use the CLI syntax displayed in the following subsections to configure IS-IS components.
4.6.4.1. Enabling IS-IS
IS-IS must be enabled in order for the protocol to be active.
 | Caution: Careful planning is essential to implement commands that can affect the behavior of global and interface levels. |
To configure IS-IS on a router, enter the following command:
IS-IS also supports the concept of multi-instance IS-IS which allows separate instances of the IS-IS protocol to run independently of the SR OS router.
Separate instances are created by adding a different instance ID as the optional parameter to the config>router>isis command.
4.6.4.2. Modifying Router-Level Parameters
When IS-IS is enabled, the default level-capability is Level 1/2. This means that the router operates with both Level 1 and Level 2 routing. To change the default value in order for the router to operate as a Level 1 router or a Level 2 router, you must explicitly modify the level value.
If the level is modified, the protocol shuts down and restarts. Doing this can affect adjacencies and routes.
The level-capability value can be configured on the global level and also on the interface level. The level-capability value determines which level values can be assigned on the router level or on an interface-basis.
In order for the router to operate as a Level 1 only router or as a Level 2 only router, you must explicitly specify the level-number value.
- Select level-1 to route only within an area.
- Select level-2 to route to destinations outside an area, toward other eligible Level 2 routers.
To configure the router level, enter the following commands:
The following example displays the configuration:
4.6.4.3. Configuring ISO Area Addresses
Use the following CLI syntax to configure an area ID also called an address. A maximum of 3 area-id can be configured.
The following example configures the router’s area ID:
The following example displays the area ID configuration:
4.6.4.4. Configuring Global IS-IS Parameters
Commands and parameters configured on the global level are inherited to the interface levels. Parameters specified in the interface and interface-level configurations take precedence over global configurations.
The following example displays global-level IS-IS configuration command usage:
The following example displays the modified global-level configuration.
4.6.4.5. Migration to IS-IS Multi-Topology
To migrate to IS-IS multi-topology for IPv6, perform the following tasks:
Enable the sending/receiving of IPv6 unicast reachability information in IS-IS MT TLVs on all the routers that support MT.
Ensure that all MT routers have the IPv6 reachability information required by MT TLVs:
Configure MT TLVs for IPv6 SPF:
Verify IPv6 routes:
4.6.4.6. Configuring Interface Parameters
There are no interfaces associated with IS-IS by default. An interface belongs to all areas configured on a router. Interfaces cannot belong to separate areas. There are no default interfaces applied to the router’s IS-IS instance. You must configure at least one IS-IS interface in order for IS-IS to work.
To enable IS-IS on an interface, first configure an IP interface in the config>router> interface context. Then, apply the interface in the config>router>isis>interface context.
You can configure both the Level 1 parameters and the Level 2 parameters on an interface. The level-capability value determines which level values are used.
 | Note: For point-to-point interfaces, only the values configured under Level 1 are used regardless of the operational level of the interface. |
The following example displays the modified interface parameters:
The following example displays the global and interface-level configurations.
4.6.4.6.1. Example: Configuring a Level 1 Area
Interfaces are configured in the config>router>interface context, as shown in Figure 31.
Figure 31: Configuring a Level 1 Area
The following example displays the command usage to configure a Level 1 area.
4.6.4.6.2. Example: Modifying a Router’s Level Capability
In the previous example, ALA-A, ALA-B, and ALA-C are configured as Level 1 systems. Level 1 systems communicate with other Level 1 systems in the same area. In this example, ALA-A is modified to set the level capability to Level 1/2, as shown in Figure 32. Now, the Level 1 systems in the area with NET 47.0001 forward PDUs to ALA-A for destinations that are not in the local area.
Figure 32: Configuring a Level 1/2 Area
The following example displays the command usage to configure a Level 1/2 system.
4.6.4.7. Configuring IS-IS Link Groups
IS-IS Link-Groups allows the creation of an administrative grouping of multiple IS-IS member interfaces that should be treated as a common group for ECMP purposes. If the number of operational links in the link-group drops below the operational-member value, then all links associated with that IS-IS link group will have their interface metric increased by the configured offset amounts. As a result, IS-IS will then try to reroute traffic over lower cost paths.
After it is triggered, the higher metric will not be reset to the originally configured IS-IS interface metric values until the number of active interfaces in the link bundle reaches the configured revertive threshold (revert-members).
Prerequisite are the following:
- 1 or more interface members.
- A configured operational-member (oper-members) value.
- A configured revertive-member (revert-members) value.
- Configured offset values for the appropriate address families.
4.7. IS-IS Configuration Management Tasks
This section discusses IS-IS configuration management tasks.
4.7.1. Disabling IS-IS
The shutdown command disables the IS-IS protocol instance on the router. The configuration settings are not changed, reset, or removed.
To disable IS-IS on a router, enter the following commands:
4.7.2. Removing IS-IS
The no isis command deletes the IS-IS protocol instance. The IS-IS configuration reverts to the default settings.
To remove the IS-IS configuration enter the following commands:
4.7.3. Modifying Global IS-IS Parameters
You can modify, disable, or remove global IS-IS parameters without shutting down entities. Changes take effect immediately. Modifying the level capability on the global level causes the IS-IS protocol to restart.
The following example displays command usage to modify various parameters:
The following example displays the global modifications.
4.7.4. Modifying IS-IS Interface Parameters
You can modify, disable, or remove interface-level IS-IS parameters without shutting down entities. Changes take effect immediately. Modifying the level capability on the interface causes the IS-IS protocol on the interface to restart.
To remove an interface, issue the no interface ip-int-name command. To disable an interface, issue the shutdown command in the interface context.
The following example displays interface IS-IS modification command usage. For specific interface configuration and modification examples also see, Example: Configuring a Level 1 Area and Example: Modifying a Router’s Level Capability.
The following example displays the modified interface parameters.
4.7.5. Configuring Authentication using Keychains
The use of authentication mechanism is recommended to protect against malicious attack on the communications between routing protocol neighbors. These attacks could aim to either disrupt communications or to inject incorrect routing information into the systems routing table. The use of authentication keys can help to protect the routing protocols from these types of attacks. In addition, the use of authentication keychains provides the ability to configure authentication keys and make changes to them without affecting the state of the routing protocol adjacencies.
To configure the use of an authentication keychain within IS-IS, use the following steps:
- Configure an authentication keychain within the config>system>security context. The configured keychain must include at least on valid key entry, using a valid authentication algorithm for the IS-IS protocol.
- Associate the configure authentication keychain with IS-IS. Authentication keychains can be used to specify the authentication at the IS-IS global, and level context as well as for hello authentication at the interface and interface-level context.
The association of the authentication keychain is established through the auth-keychain keychain-name command at the global and level context. The hello authentication association is established through the hello-auth-keychain keychain-name command.
For a key entry to be valid, it must include a valid key, the current system clock value must be within the begin and end time of the key entry, and the algorithm specified in the key entry must be supported by the IS-IS protocol.
The IS-IS protocol supports the following algorithms:
- Clear text password (RFC 5304 and RFC 5310 formats)
- HMAC-MD5 (RFC 5304 and RFC 5310 formats)
- HMAC-SHA-1 (RFC 5310 format)
- HMAC-SHA-256 (RFC 5310 format)
The IS-IS key entry may also include the option parameter to determine how the IS-IS protocol encodes the authentication signature. The value of basic results in the use of RFC 5304 format. The default or a value of isis-enhanced results in using the RFC 5310 format.
Error handling:
- If a keychain exists but there are no active key entries with an authentication type that is valid for the associated protocol then inbound protocol packets will not be authenticated and discarded and no outbound protocol packets should be sent.
- If keychain exists, but the last key entry has expired, a log entry will be raised indicating that all keychain entries have expired. The IS-IS protocol requires that the protocol not revert to an unauthenticated state and requires that the old key is not to be used, therefore, after the last key has expired, all traffic will be discarded.
4.7.6. Configuring Leaking
IS-IS allows a two-level hierarchy to route PDUs. Level 1 areas can be interconnected by a contiguous Level 2 backbone. The Level 1 link-state database contains information only about that area. The Level 2 link-state database contains information about the Level 2 system and each of the Level 1 systems in the area. A Level 1/2 router contains information about both Level 1 and Level 2 databases. A Level 1/2 router advertises information about its Level 1 area toward the other Level 1/2 or Level 2 (only) routers.
Packets with destinations outside the Level 1 area are forwarded toward the closest Level 1/2 router which, in turn, forwards the packets to the destination area.
Sometimes, the shortest path to an outside destination is not through the closest Level 1/2 router, or, the only Level 1/2 system to forward packets out of an area is not operational. Route leaking provides a mechanism to leak Level 2 information to Level 1 systems to provide routing information regarding inter-area routes. Then, a Level 1 router has more options to forward packets.
Configure a route policy to leak routers from Level 2 into Level 1 areas in the config>router>policy-options>policy-statement context.
The following example shows the command usage to configure prefix list and policy statement parameters in the config>router context.
Next, apply the policy to leak routes from Level 2 info Level 1 systems on ALA-A.
After the policy is applied, create a policy to redistribute external IS-IS routes from Level 1 systems into the Level 2 backbone (see Redistributing External IS-IS Routers). In the config>router context, configure the following policy statement parameters:
4.7.7. Redistributing External IS-IS Routers
IS-IS does not redistribute Level 1 external routes into Level 2 by default. You must explicitly apply the policy to redistribute external IS-IS routes. Policies are created in the config>router>policy-options context. See Route Policies for more information.
The following example displays the policy statement configuration.
4.7.8. Specifying MAC Addresses for All IS-IS Routers
Specify the MAC address to use for all L1 or L2 IS-IS routers. The following example shows how to specify all L1 routers:
You can also specify the MAC address for all L2 IS-IS routers by using the all-l2isis command.
4.8. Configuring IS-IS for Flexible Algorithms
IGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or SR-based TE to enforce traffic over a path that is computed using different metrics or constraints than the shortest IGP path. The SR Flexible Algorithm (Flex-Algorithm) solution allows IGPs to compute constraint-based paths over the network. This section describes the use of SR prefix SIDs to compute a constraint topology and send packets along the constraint-based paths.
Using Flex-Algorithms can reduce the number of SR SIDs that must be imposed to send packets along a constrained path; this implementation simplifies the hardware capabilities of SR routing tunnel head-end devices.
The supported depth of the label stack is considered in an SR network when SR-TE tunnels or SR policies are deployed. In such tunnel policies, the packet source routing is based on the SR label stack pushed on the packet. The depth of the label stack that a router can push on a packet determines the complexity of the SR-TE tunnel construction that the router can support.
The SR Flex-Algorithm solution allows the creation of composed metrics based upon arbitrary parameters (for example, delay, link administrative group, cost, and so on) when using Flex-Algorithms. A network-wide set of composed topology constraints (also known as the Flexible Algorithm Definition (FAD)) creates an SR Flex-Algorithm topology. The IGP calculates the best path using constraint-based SPF and the FAD to create the best paths through the Flex-Algorithm topology.
With Flex-Algorithms, each Flex-Algorithm topology can send data flows along the most optimal constrained path toward its destination using a single label, which reduces the imposed label stack along.
Using this solution, backup path calculations (for example, Loop Free Alternate (LFA), Remote LFA (R-LFA) and Topology Independent LFA (TI-LFA)) can be constrained to the SR Flex-Algorithm topology during link failure.
Perform the following tasks to configure Flex-Algorithms using IS-IS.
4.8.1. Configuring the Flexible Algorithm Definition
To guarantee loop-free forwarding for paths that are computed for a specific Flex-Algorithm, all routers configured to participate in that Flex-Algorithm must agree on the FAD. The agreement ensures that routing loops and inconsistent forwarding behavior is avoided.
Each router that is configured to participate in a specific Flex-Algorithm must select the FAD based on standardized tie-breaking rules. This ensures consistent FAD selection in cases where different routers advertise different definitions for a specific Flex-Algorithm. The following tie-breaking rules apply.
- From the FAD advertisements in the area (including both locally generated advertisements and received advertisements), select the one with the highest priority value.
- If there are multiple FAD advertisements with the same priority, select one that originated from the router with the highest system ID.
A router that is not participating in a specific Flex-Algorithm is allowed to advertise the FAD for that specific Flex-Algorithm. Any change in the FAD may result in temporary disruption of traffic that is forwarded based on those Flex-Algorithm paths. The impact is similar to any other event that requires network-wide convergence.
If a node is configured to participate in a Flex-Algorithm, but the selected FAD includes calculation-type, metric-type, constraint, flag, or a sub-TLV that is not supported by the node, the node stops participation and removes any forwarding state associated with the Flex-Algorithm.
Use the following syntax to configure FADs.
The following is a sample configuration output for a basic FAD:
4.8.2. Configuring IS-IS Flex-Algorithm Participation
Up to five Flex-Algorithms in the range 128 to 255 can be configured for IS-IS. Use the participate command to configure participation for the specific algorithm. If a locally configured FAD exists, advertise this definition by using the advertise command. A router is not required to advertise a configured FAD to participate in a Flex-Algorithm.
If a Flex-Algorithm is enabled to participate or advertise the FAD, it is configured and active for all configured IS-IS areas.
Use the following syntax to configure Flex-Algorithms for IS-IS.
| Note: When a router participates in Flex-Algorithms, it will only advertise support for the Flex-Algorithm where the router can comply with the winning FAD, provided that at least one FAD exists for this algorithm. |
The following is a sample configuration output for Flex-Algorithm participation:
The following output is an example of IS-IS router capability when a FAD is advertised:
4.8.3. Configuring IS-IS Flex-Algorithm Prefix Node SID
The prefix node SID (IPv4 and/or IPv6) must be assigned for each participating Flex-Algorithm.
The Flex-Algorithm SIDs are allocated from the label block assigned to SR and configuring a special range is not required.
| Note: Flex-Algorithm node SIDs can be configured for IPv4 and/or IPv6 prefixes. |
Use the following syntax to configure the prefix node SIDs for IS-IS Flex-Algorithms.
The following is a sample configuration output for Flex-Algorithm prefix node SIDs:
The following output is an example of the Level 2 database of an advertised IS-IS:
4.8.4. Verifying Basic Flex-Algorithm Behavior
The creation of the segment routing Flex-Algorithm forwarding information results in the label forwarding tables on the router. On a Nokia router, it is possible to look both at the tunnel table and the routing table to understand the Flex-Algorithm path toward a destination prefix.
For example, algorithm 128 has been configured to use the delay metric, and consequently forwards traffic using the lowest delay through the network. In Figure 33, Node B is configured with IP address 10.20.1.2/32, the A-B path has the best default IGP metric, and the A-C-B path has the best delay.
Figure 33: Selecting the Lowest Delay Path
The following output is an example of the tunnel-table command:
The following output is an example of the detail option of the tunnel-table command:
The following output is an example of the route table with and without the Flex-Algorithm context:
The following output is an example of the detail option for the route table, with and without the Flex-Algorithm context:
4.8.5. Configuration and Usage Considerations for Flex-Algorithms
The following considerations must be taken into account when configuring and using Flex-Algorithms.
- IS-IS algorithms 128 to 255 can program only the tunnel table, while IS-IS for algorithm 0 can program both the tunnel and the IP routing tables. For operational simplicity, the show>router>isis>routes command displays the correct egress interface.
- To prevent the accidental creation of an overload of local FADs, the operator is only allowed to configure a maximum of 256 local FADs on a router.
- A router can participate in a maximum of five Flex-Algorithms. Each algorithm has the capability to advertise a single locally configured FAD.
- The SR OS implementation assumes that the participation of a specific flex-algo command includes its participation in Flex-Algorithms in all enabled IGP areas. For example, on an IS-IS Level 1 and Level 2 capable router (default router), the same FAD participates and is advertised on both levels. To advertise a FAD only at Level 1 or Level 2, the operator should configure a Level 1-only or Level 2-only router to advertise the FAD. Alternatively, an additional flex-algo can be used; for example, algorithm 129 in Level 1 and algorithm 128 in Level 2.
- All Flex-Algorithm participating nodes must advertise the locally used FADs and optionally advertise node participation when the winning FAD is supported.
- The winning FAD on a router is select ed based on the following tie-breaker:
- select the FAD with the highest priority
- select the FAD with the highest system ID
- If redundant, the local router does not support the winning FAD (because it is locally advertised or it is advertised by a remote router), the router should remove itself from the flex-algo topology by not advertising algorithm participation in the IS-IS router capability. In such a case, no path delay is computed and any prefix SID of that flex-algo is removed from the routing and tunnel tables.
- When the FAD selects a metric type, only links that include the same metric type in their attributes are considered for the flex-algo topology.
- Leaking of a FAD on an ABR is not supported.
- When advertising the FAD, the SR OS router always sets the M-flag, which forces the IS-IS routers to use Flex-Algorithm aware metrics for inter-area routing. The enforced M-flag ensures that the best ABR, according to the Flex-Algorithm, is selected to exit the area outside the local IGP area. Without the M-flag, the wrong ABR may be selected and cause routing loops or a traffic blackhole. This handling assumes that an ABR must advertise the IS-IS Flex-Algorithm prefix metric sub-TLV when leaking prefixes and associated SIDs.
- SR OS supports the Administrative Groups (AGs) as defined in RFC 5305. The following considerations apply:
- up to 32 link colors can be used
- Flex-Algorithm feature reuses the existing AGs in combination with application-specific TLV extensions
Note: Although the same AG can be used for Flex-Algorithm and LFA policies, Nokia recommends that AGs that are used for LFA policies should be avoided.
- SR OS provides the following limited Extended Administrative Group (EAG) support for Flex-Algorithm.
- The Nokia implementation supports only AG advertisement; EAG advertisement is not supported. The IS-IS TLV types used for an AG and an EAG are different.
- For backward compatibility, vendors may use only the first 32 colors in the EAG.
- If EAG is used to add a color on the links, the link attribute size can be 4 octets (or a multiple of 4 octets) long.
- The EAG for Flex-Algorithms is forwarded for appropriate ASLA encoding in accordance with draft-ietf-isis-te-app-14.txt.
- When an EAG ASLA link attribute is received, the SR OS router handles it as follows.SR OS provides limited EAG support and only parses EAGs that are 4 octets long. The EAG represents a traditional 4-octet AG to support backward compatibility.SR OS treats the ASLA-encoded EAG as opaque information when the EAG size is a multiple of 4 octets long (that is, 4, 8, and so on).Due to limited EAG support, a new trap is not sent if the AG and EAG link attributes are inconsistent. In such a case, the AG attributes are used in accordance with RFC 7308.
- The receipt of a Flex-Algorithm FAD that contains an include/exclude EAG ASLA link attribute is handled as follows.If the SR OS router receives a FAD where the AG TLV length is 4 octets, the FAD can be used for flex-algo and it is treated as an AG.If the SR OS router receives a FAD where the AG TLV length is greater than 4 octets and bits are set to 1 in the first 4 octets only (the remaining bits are set to 0), the FAD participates assuming that the AGs have been configured as a result of EAG backward compatibility.If the SR OS router receives a FAD where the length of the AG TLV is greater than 4 octets and has bits set to 1 beyond the first 32 bits, the router will block this FAD. SR OS does not support EAG bits beyond the first 32 bits.
- Flex-Algorithm uses the IS-IS unidirectional link delay sub-TLV as defined in RFC 8570. This delay is set through the static configuration.
- SR OS allows the user to enable and disable Flex-Algorithm Loop Free Alternate (LFA) paths.
- Operators can protect links and nodes using the LFA fast-convergence technology. If the primary path is constrained by a specific flex-algo topology, the LFA SPF calculation is executed within the flex-algo topology. This calculation identifies the correct LFA, R-LFA or TI-LFA bounded by this topology. Consequently, the constraints of a specific flex-algo topology are respected even during failure scenarios.
- Enabling or disabling the flex-algo dependent LFA, R-LFA, or TI-LFA is aligned with enabling the LFA within the router flex-algo context.
- A new configuration node LFA is added in the IGP parameter within the Flex-Algorithm configuration. The shutdown and no shutdown commands are also added to this node.
- The LFA parameter allows the user to disable or enable loopfree alternates for this flex-algo. The rlfa and tlfa parameters are received from algorithm 0.
- The Flex-Algorithm LFA exclude policy configuration is copied from the flex-algo 0 configuration.
- The Flex-Algorithm aware LFA may cause additional resource consumption (for example, in memory and in CPU).
- SR OS Flex-Algorithm support for LFA policies (for example, protection type, exclude and include groups) is restricted to SRLG. A template that is used by Flex-Algorithms excludes the following CLI commands:
- configure>router>route-next-hop-policy>template>exclude-group
- configure>router>route-next-hop-policy>template>include-group
- configure>router>route-next-hop-policy>template>nh-type
- configure>router>route-next-hop-policy>template>protection-type
- Interaction with SR-LDP mapping server
- Flex-Algorithms are not compatible with the SR-LDP mapping server. SR OS only supports mapping-server TLV with algorithm 0.
- Interaction with SR-TE policy
- Flex-Algorithms have no impact on how SR-TE LSPs are used. Applications that support the use of SR-TE LSPs continue to be supported. All SR-TE resolution mechanisms are supported.
- SR-TE changes as follows as a result of Flex-Algorithm support.
- When an SR-TE path is constructed through manual router configuration or received from the PCE, the sequence of SR-TE SIDs may include one or more Flex-Algorithm prefix node SIDs.
- At the SR-TE head-end router, the sequenced SR-TE label stack (the sequence of SIDs) is imposed upon the payload and the packet is forwarded using the NHLFE from the top label or SID.
- Validity of a specific SR-TE LSP is the same as without Flex-Algorithm support.
- Interaction with SR policies
- Similar to SR-TE LSPs, SR policies are only influenced by Flex-Algorithms due to construction of the segment list. The segment list may be constructed using one or more Flex-Algorithm prefix node label SIDs. All applications capable of using SR policies will have opaque awareness if a segment list is constructed using Flex-Algorithm labels or SIDs.
- Flex-Algorithm and adjacency SID protection
- During fast-reroute process, local repair of the links to reach the Q-node from the P-node will be determined by the sub-topology defined by the Flex-Algorithm. Therefore, the used link will include the correct AGs and so on.
- However, the adj-sid backup is based upon algo=0, since adj-sids are not advertised using a Flex-Algorithm. Consequently, there is a risk to violate the Flex-Algorithm if the related link breaks while it is in use as backup for a Flex-Algorithm path. This Flex-Algorithm SLA break can be avoided if adj-sids are configured with no backup capability.
- Duplicate SID handling
- IS-IS uses the first learned remote SID and generates a trap for duplicate entries.
- Interaction with IGP shortcut and forwarding adjacency features
- To select the optimal shortest path within a constrained topology, Flex-Algorithm paths are carefully crafted using the constraints specified in the FAD. If the constrained topology includes logical RSVP-TE links that conceal FAD constraints, the Flex-Algorithm may send traffic wrongly over out-of-profile physical links.
- To avoid the use of Flex-Algorithm in the range of 128 to 255, which causes data plane traffic to be sent over tunnels that hide physical link properties, the following features are not supported:
- SR-LDP stitching
- IGP shortcut
- forwarding adjacency; forwarding adjacencies are not considered in the flex-algo topology.
- Multi-level area Flex-Algorithms are supported with the following limitations.To enable the Flex-Algorithm backups or unnumbered interfaces capability on an IS-IS router in the network, all routers in the network must be configured as either level-1 or level-2 routing capability.Therefore, all routers in the IS-IS network must be configured using the configure>router>isis>level-capability>level-1 or configure>router>isis>level-capability>level-2 commands before one of the following commands can be configured on the Flex-Algorithm enabled router:
- configure>router>interface>unnumbered
- configure>router>isis>flexible-algorithms>flex-algo>loopfree-alternates
- Interaction with EVPN servicesFlex-Algorithm cannot be deployed if the following command is configured on the node:
- configure>router>bgp>family>evpn
- Flex-Algorithm considerations regarding anycast SIDFlex-Algorithm cannot be deployed on a node where the following CLI commands are configured on the node:
- configure>router>isis>interface>ipv4-node-sid>index>clear-n-flag
- configure>router>isis>interface>ipv4-node-sid>label>clear-n-flag
- configure>router>isis>interface>ipv6-node-sid>index>clear-n-flag
- configure>router>isis>interface>ipv6-node-sid>label>clear-n-flag
- Relationship between Flex-Algorithm and algorithm 0 configurationA configured router with Flex-Algorithm should also advertise an algo 0 SID by using one of the following commands:
- configure>router>isis>interface>ipv4-node-sid
- configure>router>isis>interface>ipv6-node-sid
- Considerations for IES service interfacesFlex-Algorithm cannot not be deployed on a node if IS-IS is enabled on an IES interface. IS-IS is enabled on an IES node using the following commands:
- configure>service>ies>interface X
- configure>service>isis>interface X
- Interaction of Flex-Algorithm aware nodes and FAD flags-TLVWhen Flex-Algorithms are enabled, SR OS advertises FAD flags-TLV in IGP to signal the mandatory use of Flex-Algorithm aware performance metrics for optimal SPF path calculation. For correct Flex-Algorithm operation, it is expected that Flex-Algorithm aware nodes support FAD flags-TLV interpretation.