5. IS-IS
This chapter provides information about configuring the Intermediate System-to-Intermediate System (IS-IS) protocol.
Topics in this chapter include:
5.1. Overview of IS-IS
IS-IS is an interior gateway protocol (IGP), similar to OSPF, that is used within large autonomous systems (ASs). IS-IS is a link-state protocol. Each IS-IS router maintains an identical database (called the link-state database, topological database, or routing information database [RIB]) of the AS, including information about the local state of each router (for example, its usable interfaces and reachable neighbors).
IS-IS-TE (IS-IS with traffic engineering extensions) is used to advertise reachability information and traffic engineering information such as available bandwidth.
The 7705 SAR also supports multiple instances of IS-IS (MI-IS-IS).
Entities within IS-IS include networks, intermediate systems, and end systems. In IS-IS, a network is an autonomous system (AS), or routing domain, with intermediate systems and end systems. A router, such as the 7705 SAR, is an intermediate system. Intermediate systems send, receive, and forward protocol data units (PDUs). End systems are network devices (or hosts) that send and receive PDUs but do not forward them.
Intermediate system and end system protocols allow routers and nodes to identify each other. IS-IS sends out link-state updates (called link-state PDUs, or LSPs) periodically throughout the network so that each router can maintain current network topology information.
IS-IS uses a cost metric that represents the status of a link, and (optionally) the bandwidth of the interface, in an algorithm that determines the best route to a destination. This algorithm is called the Shortest Path First (SPF), or Dijkstra, algorithm. Routing decisions are made using the link-state information. IS-IS evaluates topology changes and, if necessary, performs SPF recalculations.
When the best route to a particular destination is determined, the route information is sent to the routing table manager (RTM). The RTM may contain more than one best route to a destination from multiple protocols. Because metrics from different protocols are not comparable, the RTM uses the concept of preference to select the best route. The route with the lowest preference value is selected.
The best routes from the RTM are then added to the forwarding table (also known as the forwarding information base [or FIB]). All forwarding decisions are based on the information in the forwarding database.
The forwarding (or dropping) of packets is controlled by filters applied to the interface and route policies applied to the IS-IS protocol. Refer to the 7705 SAR Router Configuration Guide for information on filters and route policies.
The following major IS-IS features are supported:
5.1.1. IS-IS Areas (Two-level Hierarchy)
IS-IS can subdivide an autonomous system into areas to simplify the calculation of routes and minimize the size of IP routing tables. When an AS is divided into areas, each IS-IS router in an area must maintain an identical link-state database of the area topology, but routes from other areas can be summarized. Sometimes one “default” route can be used to represent many different routes. The topology is hidden from routing devices in other areas, which minimizes the size of the link-state database and reduces IS-IS link-state PDUs (LSPs). See Route Redistribution and Summarization.
IS-IS uses a two-level hierarchy when dividing an AS into smaller areas. A system logically belongs to one area. Level 1 routing is performed within an area. Level 2 routing is performed between areas. A 7705 SAR can be configured as a level 1 router, level 2 router, or level 1/2 router.
Figure 10 shows an example of an IS-IS topology.
Level 1 routers know the topology in their area, including all routers and end systems in their area, but do not know the identity of routers or destinations outside of their area. Level 1 routers forward traffic with destinations outside of their area to a level 1/2 router in their area.
Sometimes, the shortest path to an outside destination is not through the closest level 1/2 router, or the only level 1/2 router to forward packets out of an area is not operational. In order to avoid such cases, route leaking provides a mechanism to leak level 2 routes to level 1 routers to provide routing information regarding inter-area routes. Therefore, a level 1 router has more options to forward packets. For more information about route leaking, see Configuring Leaking.
Figure 10: IS-IS Topology
Level 2 routers know the level 2 topology and know which addresses are reachable by each level 2 router. Level 2 routers do not need to know the topology within any level 1 area, except if the level 2 router is also a level 1 router within a single area. By default, only level 2 routers can exchange PDUs or routing information directly with external routers located outside the routing domain.
Table 47 describes the router types (or intermediate systems) within IS-IS.
Table 47: IS-IS Intermediate Systems
Intermediate System | Description |
Level 1 | Maintains a link-state database of other routers that reside in the same area (local area) Exchanges topology information for the local area Routing is performed within the area, based on the area ID portion of the ISO address (see ISO Network Addressing) If the destination address is in the area (area ID is equal), routers forward the packets to the level 1 router that is advertising the destination address, based on the system ID If the destination address is not in the area (area ID is not equal), routers forward the packet to the nearest level 1/2 router in the local area |
Level 2 | Resides within an area but connects to other level 2 routers in multiple areas in a backbone mesh Maintains a link-state database of other level 2 routers and of the level 1/2 routers in each local area Exchanges topology information between areas Routing is performed between areas based on the area address |
Level 1/2 | Acts as an area border router with links to the level 2 backbone as well as to the level 1 routers within its area Maintains two link-state databases – a level 1 link-state database of the routers in the local area and a level 2 link-state database of the backbone and any level 1/2 routers Exchanges topology information within the local area and between areas Routing is performed within and between areas If the destination address is in the area (area ID is equal), routers use the level 1 database to forward the packets to the level 1 router that is advertising the destination address, based on the system ID If the destination address is not in the area (area ID is not equal), routers use the level 2 database to forward the packet based on the area ID |
5.1.2. ISO Network Addressing
IS-IS uses ISO network addresses. There are two types of network addresses:
- Network Service Access Point (NSAP)NSAP addresses identify a point of connection to the network, such as a router interface. Each NSAP represents a service that is available at that node. An end system can have multiple NSAP addresses; the addresses differ only by the last byte (called the n-selector). In addition to having multiple services, a single node can belong to multiple areas.
- Network Entity Title (NET)NET addresses identify network layer entities or processes instead of services. Structurally, an NET is identical to an NSAP address but has an n-selector of 00. Most end systems have one NET. Intermediate systems (routers) can have up to three NETs, differentiated by the area ID.
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 that identifies the area to which the router belongs. This field includes the Authority and Format Identifier (AFI) as the first (most significant byte) and the area identifier.
- system ID – A 6-byte system identifier. This value is not configurable. The system ID is derived from the system or router ID and uniquely identifies the router.
- selector ID – A 1-byte selector identifier that is always 00 for an NET. This value is not configurable.
The area ID portion of the NET can be manually configured with 1 to 13 bytes. If fewer than 13 bytes are entered, the rest of the field is padded with zeros.
5.1.3. Neighbors and Adjacencies
IS-IS routers discover their neighbors by exchanging Hello PDUs. Neighbors are routers that have an interface to a common network/area. In a broadcast-supported topology, one router sends Hello packets to a multicast address and receives Hello packets in return. In non-broadcast topologies, unicast Hello packets are used.
Because all routing devices on a common network must agree on certain parameters, these parameters are included in Hello packets. Differences in these parameters can prevent neighbor relationships from forming.
A level 1 router will not become a neighbor with a node that does not have a common area address. However, if a level 1 router has area addresses A, B, and C, and a neighbor has area addresses B and D, the level 1 router will accept the other node as a neighbor because address B is common to both routers.
When Hello packets have been successfully exchanged, the neighbors are considered to be adjacent.
Within an area, level 1 routers exchange link-state PDUs (LSPs) that identify the IP addresses reachable by each router. Each router has one LSP that contains information about that router; included in each LSP can be zero or more IP addresses, subnet masks, and metric combinations. Each level 1 router is manually configured with the IP address, subnet mask, and metric combinations that are reachable on each interface.
Level 2 routers exchange LSPs that include a complete list of IP addresses, subnet masks, and metrics specifying all the IP addresses that are reachable in their area. Level 2 routers can also report external reachability information, corresponding to addresses reachable by routers in other routing domains or autonomous systems.
Routers with common area addresses form level 1 adjacencies. Routers with no common NET addresses form level 2 adjacencies, if they are capable. See Figure 11.
Level 2 adjacencies are formed with other level 2 nodes whose area addresses do not overlap. If the area addresses do not overlap, the link is considered by both routers to be level 2 and only level 2 LSPs flow on the link.
Figure 11: Using Area Addresses to Form Adjacencies
5.1.3.1. Designated Routers
In multi-access broadcast networks, such as Ethernet networks, with at least two attached routers, a designated router can be elected. The IS-IS protocol refers to the designated router as the designated intermediate system (DIS).
The concept of a designated router was developed in order to avoid the formation of adjacencies between all attached routers. Without a designated router, the area would be flooded with link-state PDUs (LSPs)—a router would send LSPs to all its adjacent neighbors, and each in turn would send LSPs to all their neighbors, and so on. This would create multiple copies of the same LSP on the same link.
The designated router reduces the number of adjacencies required because each router forms an adjacency only with the designated router. Only the designated router sends LSPs in multicast format to the rest of the network, reducing the amount of routing protocol traffic.
In IS-IS, a broadcast subnetwork with multiple connected routers is considered to be a pseudonode. The pseudonode has links to each of the routers and each of the routers has a single link to the pseudonode (rather than links to each of the other routers). LSPs are generated on behalf of the pseudonode by the DIS.
The DIS has two tasks:
- create and update the pseudonode LSP
- flood the LSP over the LAN
The DIS is automatically elected based on the interface priority of the router and/or if it has the highest MAC address of all routers in the LAN. If all interface priorities are the same, the router with the highest subnetwork point of attachment (SNPA) is selected. The SNPA is the MAC address on a LAN.
Every IS-IS router interface is assigned both a level 1 priority and a level 2 priority. If a new router starts up in the LAN and has a higher interface priority, the new router preempts the original DIS and becomes the new DIS. The new DIS purges the old pseudonode LSP and floods a new set of LSPs.
Because different priorities can be set according to level 1 or level 2 routing, there can be two different routers in an Ethernet LAN that are DIS-designated. One DIS supports all level 1 routers, and the other DIS supports all level 2 routers on that segment.
The DIS generates the pseudonode LSP. The DIS reports all LAN neighbors (including itself) in the pseudonode link-state PDU (LSP). All LAN routers communicate with the pseudonode via their LSPs. The pseudonode reduces the number of adjacencies by having all physical devices exchange information only with the pseudonode. Each router listens for updates to the pseudonode and updates its individual topology according to those updates.
 | Note:
|
5.1.3.2. IS-IS Packet Types
Table 48 describes the packet types used by IS-IS to exchange protocol information.
Table 48: IS-IS Packet Types
Packet Type | Description |
Hello PDUs | Routers with IS-IS enabled send Hello PDUs to IS-IS-enabled interfaces to discover neighbors and establish adjacencies. |
Link-state PDUs (LSPs) | LSPs contain information about the state of adjacencies to neighboring IS-IS systems and are used to build the link-state database. LSPs are flooded periodically throughout an area. Level 1 and level 2 LSPs are supported. |
Complete sequence number PDUs (CSNPs) | In order for all routers to maintain the same information (synchronize), CSNPs inform other routers that some LSPs might be outdated or missing from their database. CSNPs contain a complete list of all LSPs in the current IS-IS database. Level 1 and level 2 CSNPs are supported. |
Partial sequence number PDUs (PSNPs) | PSNPs are used to request missing LSPs and acknowledge that an LSP was received. Level 1 and level 2 PSNPs are supported. |
When a change takes place, IS-IS sends only the changed information, not the whole topology information or whole link-state database. From the topological database, each router constructs a tree of shortest paths with itself as root (that is, runs the Dijkstra algorithm). IS-IS distributes routing information between routers belonging to a single AS.
To summarize:
- Hello PDUs are sent over the IS-IS-enabled interfaces to discover neighbors and establish adjacencies.
- IS-IS neighbor relationships are formed if the Hello PDUs contain information that meets the criteria for forming an adjacency.
- Routers can build a link-state PDU based upon their local interfaces that are configured for IS-IS and prefixes learned from other adjacent routers.
- Routers flood LSPs to the adjacent neighbors except the neighbor from which they received the same LSP. The link-state database is constructed from these LSPs.
- A Shortest Path Tree (SPT) is calculated by each router, and from this SPT the routing table is built.
5.1.4. Metrics
IS-IS uses a cost metric that represents the status of a link in an algorithm to determine the best route to a destination. This algorithm is called the Shortest Path First (SPF), or Dijkstra, algorithm. Routing decisions are made using the link-state information. IS-IS evaluates topology changes and, if necessary, performs SPF recalculations.
To calculate the lowest cost to reach a destination, each configured level on each interface must have a cost. The costs for each level on an interface may be different.
In IS-IS, if the metric is not configured, the default cost 10 is used, regardless of the actual capacity of the link. By default, IS-IS does not use reference bandwidth in the calculation, unlike OSPF.
5.1.5. Authentication
Protocol authentication protects against malicious attacks on the communications between routing protocol neighbors. These attacks could either disrupt communications or inject incorrect routing information into the system’s routing table. The use of authentication keys can help to protect routing protocols from these types of attacks.
All IS-IS protocol exchanges can be authenticated. This guarantees that only trusted routers can participate in autonomous system routing.
Authentication must be explicitly configured and can be done using two separate mechanisms:
- configuration of an explicit authentication key and algorithm using the authentication-key and authentication-type commands
- configuration of an authentication keychain using the auth-keychain command
Either the authentication-key command or the auth-keychain command can be used by IS-IS, but both cannot be supported at the same time. If both commands are configured, the auth-keychain configuration will be applied and the authentication-key command will be ignored.
By default, authentication is not enabled on an interface.
5.1.5.1. Authentication Key
For explicit authentication keys, IS-IS supports plain text (simple password) and Message Digest 5 (MD5) authentication.
When authentication is enabled on a link, a text string password must be configured. Neighbor IS-IS routers must supply the password in all IS-IS packets they send to an interface.
Plain text authentication includes the password in each IS-IS packet sent on a link.
MD5 authentication is more secure than plain text authentication. MD5 authentication uses the password as an encryption key. Routers in the same routing domain must be configured with the same key. When the MD5 hashing algorithm is used for authentication, MD5 is used to verify data integrity by creating a 128-bit message digest from the data input that is included in each packet. The packet is transmitted to the router neighbor and can only be decrypted if the neighbor has the correct password.
The following authentication commands can be configured in the IS-IS global and IS-IS level contexts:
- authentication-key – configures the authentication password used to verify IS-IS protocol packets
- authentication-type – enables authentication and specifies the type of authentication to be used, either password or message digest
The following Hello PDU authentication commands can be configured in the IS-IS interface and IS-IS interface level contexts:
- hello-authentication-key – configures the authentication password for Hello PDUs
- hello-authentication-type – enables Hello authentication and specifies the type of authentication to be used, either password or message digest
5.1.5.2. Authentication Keychains
The keychain mechanism allows for the creation of keys used to authenticate IS-IS communications. Each keychain entry defines the authentication attributes to be used in authenticating IS-IS messages from remote peers or neighbors; the entry must include at least one key entry to be valid. The keychain mechanism also allows authentication keys to be changed without affecting the state of the IS-IS adjacencies and supports stronger authentication algorithms than plain text and MD5.
Keychains are configured in the config>system>security>keychain context. For more information about configuring keychains, refer to the 7705 SAR System Management Guide, “TCP Enhanced Authentication and Keychain Authentication”.
The authentication keychain is then associated with IS-IS in the global or level contexts with the auth-keychain command. The Hello authentication keychain is associated with IS-IS in the global, interface, or interface level contexts with the hello-auth-keychain 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 must be supported by IS-IS.
IS-IS supports the following authentication algorithms:
- clear text password
- HMAC-MD5
- HMAC-SHA-1
- HMAC-SHA-256
Keychain errors are handled as follows.
- If a keychain exists but there are no active key entries with an authentication type that matches the type supported by IS-IS, inbound IS-IS packets will not be authenticated and will be discarded and no outbound IS-IS packets will be sent.
- If a keychain exists but the last key entry has expired, a log entry will be raised indicating that all keychain entries have expired.IS-IS protocol requires that the protocol not revert to an unauthenticated state and requires that the old key not be used; therefore, when the last key has expired, all traffic will be discarded.
5.1.6. Route Redistribution and Summarization
5.1.6.1. Redistribution
Route redistribution is the taking of routes from one protocol and sending them to another protocol. The 7705 SAR supports the redistribution of static routes into OSPF and IS-IS and the redistribution of routes between IS-IS levels. The routes can be redistributed as level 1, level 2, or level 1/2 routes, depending on the level capability of the IS-IS router.
Multi-instance IS-IS (MI-IS-IS) supports route redistribution:
- to and from any other routing protocol
- to and from any other IS-IS instance
Route redistribution involves the use of routing policies. For information on routing policies, refer to the 7705 SAR Router Configuration Guide, “Route Policies”. To configure route redistribution, see Redistributing External IS-IS Routers.
5.1.6.2. Summarization
IS-IS IPv4 route summarization allows users to create aggregate IPv4 addresses that include multiple groups of IPv4 addresses for a given IS-IS level. Routes redistributed from other routing protocols can also be summarized.
IS-IS route summarization helps to reduce the size of the link-state database and the routing table. It also helps to reduce the chance of route flapping, which may occur when a router alternately advertises a destination network via one route then another route in quick sequence (or advertises a route as unavailable then available again).
5.1.7. IS-IS-TE Extensions
IS-IS traffic engineering (TE) extensions enable the 7705 SAR to include traffic engineering information in the algorithm in order to calculate the best route to a destination. IS-IS-TE extensions are used by MPLS traffic engineering; that is, RSVP-TE. The traffic information includes:
- maximum reservable bandwidth
- unreserved bandwidth
- available bandwidth
- link administration groups (or link colors)
- SRLGs
- TE metrics
5.1.8. Unnumbered Interfaces
IS-IS supports unnumbered point-to-point interfaces with both Ethernet and PPP encapsulations.
Unnumbered interfaces borrow the address from other interfaces such as system, loopback, or another numbered interface, and use it as the source IP address for packets originated from the interface.
This feature supports both dynamic and static ARP for unnumbered interfaces to allow interworking with unnumbered interfaces that may not support dynamic ARP.
An unnumbered interface has IPv4 capability and is used only in cases where IPv4 is active (IPv4-only and mixed IPv4/IPv6 environments). When configuring an unnumbered interface, the interface specified for the unnumbered interface (system or other) must have an IPv4 address. As well, the interface type for the unnumbered interface will automatically be point-to-point.
The unnumbered option can be used in IES and VPRN access interfaces, as well as in a network interface with MPLS support.
5.1.9. Multi-Instance IS-IS (MI-IS-IS)
The 7705 SAR routers support multiple IS-IS instances. There is one default (base) instance. The remaining (non-default) instances must be specified with an isis-instance value.
The default (base) and non-default MI-IS-IS instances use the following MAC addresses:
- default instance, as per the ISO 10589 standard:
- 01-80-C2-00-00-14 for all level 1 routers (AllL1IS)
- 01-80-C2-00-00-15 for all level 2 routers (AllL2IS)
- non-default instances, as per the RFC 6822 standard:
- 01-00-5E-90-00-02 for all level 1 routers (AllL1MI-ISs)
- 01-00-5E-90-00-03 for all level 2 routers (AllL2MI-ISs)
Note: On the 7705 SAR, all non-default instances use the same MAC address for routers at the same level, which is different multicast MAC address from the base instance. The non-default MAC address is not user-configurable and is permanently set.
All IS-IS instances on a 7705 SAR populate the same router information base (RIB).
To use the same router interface in more than one IS-IS instance, use the iid-tlv-enable command. When the iid-tlv-enable command is issued, the instance ID (IID) is included in all IS-IS PDUs so that the far-end router knows which instance will receive the packet.
5.1.10. IPv6 Support
IS-IS for IPv6 routing supports two modes: single topology (native) and multi-topology. The 7705 SAR supports native mode only. In native mode, IPv6 routing information is exchanged within IS-IS using the following TLVs contained in the LSP:
- IPv6 reachability TLV
- IPv6 interface address TLV
For detailed information, see RFC 5308, Routing IPv6 with IS-IS.
IPv4 and IPv6 routing can be run at the same time in an area. However, because one SPF calculation is performed per level to compute the routes, the IPv4 and IPv6 topologies must be the same. That is, both IPv4 and IPv6 addresses must be configured on all router interfaces in an area; otherwise, traffic may be blackholed. For example, if the SFP calculation includes a link that is not configured with an IPv6 address, IPv6 traffic will be blackholed over that link.
5.2. Bidirectional Forwarding Detection (BFD) for IS-IS
BFD is a simple protocol for detecting failures in a network. BFD uses a “hello” mechanism that sends control messages periodically to the far end and receives periodic control messages from the far end. BFD can detect device, link, and protocol failures.
When BFD is enabled on an IS-IS interface, the state of the interface is tied to the state of the BFD session between the local node and remote (far-end) node. BFD is implemented in asynchronous mode only (similar to a heartbeat message), meaning that neither end responds to control messages; rather, the messages are sent in the interval configured at each end.
If the configured number of consecutive BFD missed messages is reached, the link is declared down and IS-IS takes the appropriate action (for example, generates a link-state PDU (LSP) against the failed link or reroutes around the failed link).
Due to the lightweight nature of BFD, the frequency of BFD packets can be relatively high (up to 10 per second); therefore, it can detect failures faster than other detection protocols, making it ideal for use in applications such as mobile transport.
5.3. LDP and IP Fast Reroute (FRR) for IS-IS Prefixes
LDP Fast Reroute (FRR) provides local protection for an LDP FEC by precalculating and downloading a primary and a backup NHLFE for the FEC to the LDP FIB. The primary NHLFE corresponds to the label of the FEC received from the primary next hop as per the standard LDP resolution of the FEC prefix in the RTM. The backup NHLFE corresponds to the label received for the same FEC from a Loop-Free Alternate (LFA) next hop.
LDP FRR improves convergence in case of a local link or node failure in the network, by using the label-FEC binding received from the LFA next hop to forward traffic for a given prefix as soon as the primary next hop is not available. This means that a router resumes forwarding LDP packets to a destination prefix using the backup path without waiting for the routing convergence.
IP Fast Reroute (FRR) protects against link or node failures in an IP network by precalculating a backup route to use when the primary next hop is not available. Both routes are populated in the RTM. IP FRR uses an LFA backup next hop to forward in-transit and CSM-generated IP packets as soon as the primary next-hop failure is detected and the backup is invoked. This means that a node resumes forwarding IP packets to a destination prefix without waiting for the routing convergence.
Refer to RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates, for more information on LFAs.
Refer to the 7705 SAR MPLS Guide “LDP Fast Reroute (FRR)” for more information on LDP FRR and to the 7705 SAR Router Configuration Guide, “IP Fast Reroute (FRR)” for more information on IP FRR.
LFAs are supported on IPv4 IS-IS prefixes and on inter-level IS-IS prefixes. LFAs are also supported on IPv4 and IPv6 OSPF prefixes, VPN IPv4 OSPF prefixes, and on inter-area OSPF prefixes. For information on LFA support for OSPF prefixes, see LDP and IP Fast Reroute (FRR) for OSPF Prefixes.
IP FRR also provides an LFA backup next hop for the destination prefix of a GRE tunnel used in an SDP or in VPRN auto-bind.
5.3.1. LFA Calculations
In addition to performing the Shortest Path First (SPF) calculation of the primary next hop, IS-IS must calculate a backup next hop for all prefixes used by LDP to resolve FECs and for all prefixes used by IP to forward packets. The backup next hops are calculated to provide single link or node protection and to guarantee that when a failure occurs, forwarding traffic through the backup next hop will not result in a loop. These backup next hops are called Loop-Free Alternates (LFAs).
In general, in order to calculate LFAs for a specific destination (D), a router must know the following information:
- the shortest-path distance from the calculating router (source) to the destination (SP(S,D))
- the shortest-path distance from the router’s IS-IS neighbors to the destination (SP(N,D))
- the shortest-path distance from the router’s IS-IS neighbors to itself (SP(N,S))
A neighbor (N) can provide an LFA only if:
SP(N,D) < SP(N,S) + SP(S,D)
This is known as loop-free criterion.
Figure 12 shows an example of a backup route resulting in a micro-loop. In the example, PE-1 uses PE-2 as its next hop to reach PE-3. The total cost to reach PE-3 via PE-2 is 9. If the link between PE-1 and PE-2 fails, PE-1 can try to use PE-4 as its next hop to reach PE-3. However, the metric between PE-4 and PE-3 is 30. From the perspective of PE-4, forwarding traffic via the PE-1 and PE-2 path to PE-3 is more viable, as the cost is 17 (8 + 5 + 4) versus the direct link cost of 30. Therefore, if PE-1 forwards the traffic to PE-4 in order to reach PE-3, PE-4 forwards it back to PE-1, creating a micro-loop, until the routing protocols converge and declare the link between PE-1 and PE-2 to be down. PE-4 would then be forced to take the direct PE-3 link to reach PE-3 as there is no other alternative. Because PE-4 does not meet the loop-free criterion, it cannot be used as a valid LFA.
Figure 12: Backup Routes Resulting in Micro-loops
Figure 13 shows an example of an LFA backup route. In this example, PE-1 again uses PE-2 as its next hop to reach PE-3. The total cost to reach PE-3 via PE-2 is 9. If the link between PE-1 and PE-2 fails, PE-1 can use PE-4 to reach PE-3. From the perspective of PE-4, the direct route to PE-3 is a viable route, as the cost is 3 versus the cost of forwarding traffic via PE-1 (17). Using the direct route does not cause micro-loops and meets the loop-free criterion; therefore, PE-4 can be used as a valid LFA.
Figure 13: LFA Backup Route
5.3.1.1. Selection Algorithm
For a point-to-point interface, if SPF finds multiple LFA next hops for a given primary next hop, the selection algorithm is as follows:
- SPF will pick the node-protect type over the link-protect type.
- If there is more than one LFA next hop within the selected type, it will pick one based on the least cost.
- If there is more than one LFA next hop with the same cost, SPF will select the first one. This is not a deterministic selection and will vary for each SPF calculation.
For a broadcast interface, a node-protect LFA is not necessarily a link-protect LFA if the path to the LFA next hop goes over the same pseudonode as the primary next hop. Similarly, a link-protect LFA may not guarantee link protection if it goes over the same pseudonode as the primary next hop.
When SPF finds multiple LFA next hops for a given primary next hop, the selection algorithm is as follows:
- The algorithm splits the LFA next hops into two sets:
- the first set consists of LFA next hops that do not go over the pseudonode used by the primary next hop
- the second set consists of LFA next hops that do go over the pseudonode used by the primary next hop
- If there is more than one LFA next hop in the first set, it will pick the node-protect type over the link-protect type.
- If there is more than one LFA next hop within the selected type, it will pick one based on the least cost.
- If there is more than one LFA next hop with the same cost, SPF will select the first one from the remaining set. This is not a deterministic selection and will vary for each SPF calculation.
- If no LFA next hop results from step 4, SPF will rerun steps 2 to 4 using the second set.
| Note: A node-protect LFA that does not guarantee link protection can still be selected as a last resort; as well, a link-protect LFA that does not guarantee node protection can still be selected as a last resort. |
Both the calculated primary next hop and LFA next hop for a given prefix are programmed into the RTM.
5.3.1.2. LFA Configuration
To enable LFA for IS-IS prefixes, enter the following command at the IS-IS instance level:
config>router>isis>loopfree-alternate
Next, enable FRR for LDP and/or IP by entering the following commands:
config>router>ldp>fast-reroute
config>router>ip-fast-reroute
These commands instruct the IS-IS SPF algorithm to precalculate a primary next hop and LFA next hop for every learned prefix, in order to provide FRR to LDP FEC packets and/or IP packets.
To exclude all interfaces within a specific IS-IS level or to exclude a specific IP interface from being included in the LFA SPF calculation, enter the following commands:
config>router>isis>level>loopfree-alternate-exclude
config>router>isis>interface>loopfree-alternate-exclude
If IGP shortcuts are also enabled, any LSPs with a destination address in that IS-IS level are not included in the LFA SPF calculation.
If an interface is excluded from the LFA SPF in IS-IS, it is excluded in both level 1 and level 2.
5.3.2. IGP Shortcuts (RSVP-TE Tunnels)
Micro-loops, especially in ring topologies, are typically unavoidable. As the number of nodes in a ring increases, the chance of micro-loops occurring also increases. In cases where a valid directly connected next hop cannot be ensured, remote LFAs can be used. Remote LFAs are non-directly connected LFA next hops that are reached via IGP shortcuts.
IGP shortcuts are an MPLS functionality where LSPs are treated like physical links within IGPs; that is, LSPs can be used for next-hop reachability. If an RSVP-TE LSP is used as a shortcut by OSPF or IS-IS, it is included in the SPF calculation as a point-to-point link for both primary and LFA next hops. It can also be advertised to neighbors so that the neighboring nodes can also use the links to reach a destination via the advertised next hop.
IGP shortcuts can be used to simplify remote LFA support and simplify the number of LSPs required in a ring topology.
IGP shortcut functionality provides two options:
- LFA-protect optionThis option allows an LSP to be included in both the main SPF and the Loop-Free Alternate (LFA) SPF algorithm. For a given prefix, the LSP can be used either as a primary next hop or as an LFA next hop, but not both. If the main SPF calculation selects a tunneled primary next hop for a prefix, the LFA SPF calculation will not select an LFA next hop for this prefix and the protection of this prefix will rely on the RSVP LSP FRR protection.If the main SPF calculation selects a direct primary next hop, the LFA SPF calculation will select an LFA next hop for this prefix but will prefer a direct LFA next hop over a tunneled LFA next hop.
- LFA-only optionThis option allows an LSP to be included in the LFA SPF algorithm only, which means that the introduction of IGP shortcuts does not affect the main SPF decision. For a given prefix, the main SPF calculation always selects a direct primary next hop. The LFA SPF calculation will select an LFA next hop for this prefix but will prefer a direct LFA next hop over a tunneled LFA next hop.
5.3.2.1. Selection Algorithm
If there are multiple LFA next hops for a primary next hop, the selection algorithm is as follows:
- The algorithm splits the LFA next hops into two sets:
- the first set consists of direct LFA next hops
- the second set consists of tunneled LFA next hops after excluding the LSPs that use the same outgoing interface as the primary next hop
- The algorithm continues with the first set if it is not empty; otherwise, it continues with the second set.
- If the second set is used, the algorithm selects the tunneled LFA next hop whose endpoint corresponds to the node advertising the prefix:
- if more than one tunneled next hop exists, it selects the one with the lowest LSP metric
- if more than one tunneled next hop still exists, it selects the one with the lowest tunnel ID
- if none is available, it continues with rest of the tunneled LFAs in the second set
- Within the selected set, the algorithm splits the LFA next hops into two sets:
- the first set consists of LFA next hops that do not go over the pseudonode used by the primary next hop
- the second set consists of LFA next hops that go over the pseudonode used by the primary next hop
- If there is more than one LFA next hop in the selected set, it will pick the node-protect type over the link-protect type.
- If there is more than one LFA next hop within the selected type, it will pick one based on the least total cost for the prefix. For a tunneled next hop, that means the LSP metric plus the cost of the LSP endpoint to the destination of the prefix.
- If there is more than one LFA next hop within the selected type in the first set (ECMP is configured), it will select the first direct next hop from the remaining set. This is not a deterministic selection and will vary for each SPF calculation.
- If there is more than one LFA next hop within the selected type in the second set (ECMP is configured), it will pick the tunneled next hop with the lowest cost from the endpoint of the LSP to the destination prefix. If there remains more than one next hop, it will pick the tunneled next hop with the lowest tunnel ID.
5.3.2.2. Forwarding Adjacency
The forwarding adjacency feature allows IS-IS to advertise an RSVP-TE LSP as a link so that other routers in the network can include it in the SPF calculations. The RSVP-TE is advertised as an unnumbered point-to-point link and the link-state PDU (LSP) has no traffic engineering opaque sub-TLVs as per RFC 3906, Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels.
The forwarding adjacency feature can be enabled independently from the IGP shortcut feature. If both features are enabled for a given IS-IS instance, forwarding adjacency takes precedence.
When forwarding adjacency is enabled, each node advertises a point-to-point 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 the SPF calculation directly. Instead, when the LSP advertising the corresponding point-to-point unnumbered link is installed in the local routing database, the node performs an SPF calculation using the link like any other link LSP. The link bidirectional check requires that a regular link or tunnel link exist in the reverse direction for the tunnel to be used in SPF calculations.
5.3.2.3. IGP Shortcut Configuration
To enable the use of IGP shortcuts by IS-IS, enter the following command at the IS-IS instance level:
config>router>isis>rsvp-shortcut
To enable forwarding adjacency, enter the following command at the IS-IS instance level:
config>router>isis>advertise-tunnel-link
To enable the use of an RSVP-TE LSP by IS-IS as a shortcut or as a forwarding adjacency for resolving IGP routes, enter the following command:
config>router>mpls>lsp>igp-shortcut
When the rsvp-shortcut or advertise-tunnel-link option is enabled at the IS-IS instance level, all RSVP-TE LSPs originating on this node are eligible by default as long as the destination address of the LSP, as configured with the config>router> mpls>lsp>to command, corresponds to a router ID of a remote node. A specific LSP can be excluded from being used as a shortcut or forwarding adjacency with the no form of the igp-shortcut command.
5.3.3. LFA SPF Policies
An LFA SPF policy allows the user to apply specific criteria to the selection of a LFA backup next hop for a subset of prefixes that resolve to a specific primary next hop. The 7705 SAR supports the following LFA SPF policy constraints:
- admin group
- shared risk link group (SRLG)
- protection type
- next-hop type
A route next-hop policy template must first be created under the global router context. The template contains criteria for the policies in the preceding list.
The template is then applied to prefixes protected by LFA. Each instance of IS-IS can apply the same policy template to one or more prefixes and interfaces. If a template is modified, IS-IS re-evaluates it for any changes and, if necessary, schedules a new LFA SPF to recalculate the LFA next hop for any prefixes associated with the template.
As a related feature, prefixes that match a prefix entry in a prefix policy can be excluded from the LFA SPF calculation. If a prefix is excluded, it is not included in the LFA SPF calculation, regardless of its priority. Prefix policies are created with the config>router>policy-options>prefix-list command (for information on prefix lists, refer to the 7705 SAR Router Configuration Guide, “Route Policies”.
5.3.3.1. LFA SPF Policy Configuration
To create a route next-hop policy template, enter the following command:
config>router>route-next-hop-policy template
Configure the template with policy constraints for the items in the preceding list.
| Note: To configure constraints for admin groups and SRLG groups, these groups must already be created in the config>router>if-attribute>admin-group and config>router>if-attribute>srlg-group contexts. |
Next, apply the template to IS-IS interfaces by entering the following command:
config>router>isis>interface>lfa-policy-map>route-nh-template
The template is applied to all prefixes using the specified interface name.
Optionally, exclude prefixes in a prefix policy from the LFA SPF calculation by entering the following command:
config>router>isis>loopfree-alternate-exclude prefix-policy
5.4. IS-IS Configuration Process Overview
Figure 14 shows the process to provision basic IS-IS parameters.
Figure 14: IS-IS Configuration Process
5.5. Configuration Notes
5.5.1. General
- IS-IS must be enabled on each participating 7705 SAR.
- There are no default network entity titles.
- There are no default interfaces.
- By default, 7705 SAR routers are assigned a level 1/2 capability.
5.5.2. Reference Sources
For information on supported IETF drafts and standards, as well as standard and proprietary MIBs, refer to Standards and Protocol Support.