IS-IS Areas

To support large-scale routing networks, IS-IS adopts a two-level structure in a routing domain. A large domain can be divided into areas. Figure 10-139 shows an IS-IS network. The entire backbone area covers all Level-2 routers in area 1 and Level-1-2 routers in other areas. Three types of routers on the IS-IS network are described as follows:

Figure 10-139 IS-IS topology

• Level-1 device

  A Level-1 device manages intra-area routing. It establishes neighbor relationships with only the Level-1 and Level-1-2 devices in the same area and maintains a Level-1 LSDB. The LSDB contains routing information in the local area. A packet to a destination beyond this area is forwarded to the nearest Level-1-2 device.

• Level-2 device

  A Level-2 device manages inter-area routing. It can establish neighbor relationships with all Level-2 devices and Level-1-2 devices, and maintains a Level-2 LSDB which contains inter-area routing information.

  All Level-2 routers form the backbone network of the routing domain. Level-2 neighbor relationships are set up between them. They are responsible for communications between areas. The Level-2 routers in the routing domain must be in succession to ensure the continuity of the backbone network. Only Level-2 routers can directly exchange data packets or routing information with the routers beyond the area.

• Level-1-2 device

  A device, which can establish neighbor relationships with both Level-1 devices and Level-2 devices, is called a Level-1-2 device. A Level-1-2 device can establish Level-1 neighbor relationships with Level-1 devices and Level-1-2 devices in the same area. It can also establish Level-2 neighbor relationships with Level-2 devices and Level-1-2 devices in other areas. Level-1 devices can be connected to other areas only through Level-1-2 devices.

  A Level-1-2 device maintains two LSDBs: a Level-1 LSDB and a Level-2 LSDB. The Level-1 LSDB is used for intra-area routing, whereas the Level-2 LSDB is used for inter-area routing.

  Level-1 devices in different areas cannot establish neighbor relationships. Level-1-2 devices can establish neighbor relationships with each other, regardless of the areas to which the devices belong.

In general, Level-1 devices are located within an area, Level-2 devices are located between areas, and Level-1-2 devices are located between Level-1 devices and Level-2 devices.

Interface level

A Level-1-2 device may need to establish only a Level-1 adjacency with one neighbor and establish only a Level-2 adjacency with another neighbor. In this case, you can set the level of an interface to control the setting of adjacencies on the interface. Specifically, only Level-1 adjacencies can be established on a Level-1 interface, and only Level-2 adjacencies can be established on a Level-2 interface.

Address Structure of IS-IS

In OSI, the NSAP is used to locate resources. The ISO adopts the address structure shown in Figure 10-140. An NSAP is composed of the Initial Domain Part (IDP) and the Domain Specific Part (DSP). IDP is the counterpart of network ID in an IP address, and DSP is the counterpart of the subnet number and host address in an IP address.

As defined by the ISO, the IDP consists of the Authority and Format Identifier (AFI) and Initial Domain Identifier (IDI). AFI specifies the address assignment mechanism and the address format; the IDI identifies a domain.

The DSP consists of the High Order DSP (HODSP), system ID, and NSAP Selector (SEL). The HODSP is used to divide areas; the system ID identifies a host; the SEL indicates the service type.

The lengths of the IDP and DSP are variable. The length of the NSAP varies from 8 bytes to 20 bytes.

Figure 10-140 IS-IS address structure

• Area address

  An IDP and HODSP of the DSP can identify a routing domain and the areas in a routing domain; therefore, the combination of the IDP and HODSP is referred to as an area address, equal to an area ID in OSPF. You are advised to avoid the situation where different Level-1 areas in the same routing domain have the same area address. The area addresses of routers in the same Level-1 area must be the same.

  A router generally requires only one area address, and the area addresses of all nodes in the same area must be the same. In the implementation of a device, an IS-IS process can be configured with a maximum of three area addresses to support seamless combination, division, and transformation of areas.

• System ID

  A system ID uniquely identifies a host or a router in an area. In the device, the length of the system ID is 48 bits (6 bytes).

  A router ID corresponds to a system ID. If a router uses the IP address (192.168.1.1) of Loopback 0 as its router ID, its system ID used in IS-IS can be obtained through the following steps:

  • Extend each part of the IP address 192.168.1.1 to 3 digits and add 0 or 0s to the front of the part that is shorter than 3 digits.

  • Divide the extended address 192.168.001.001 into three parts, with each part consisting of 4 decimal digits.

  • The reconstructed 1921.6800.1001 is the system ID.

  There are many ways to specify a system ID. Whichever you choose, ensure that the system ID uniquely identifies a host or a router.

  If the same system ID is configured for more than one device on the same network, network flapping may occur. To address this problem, IS-IS provides the automatic recovery function. With the function, if the system detects an IS-IS system ID conflict, it automatically changes the local system ID to resolve the conflict. The first two bytes of the system ID automatically changed by the system are Fs, and the last four bytes are randomly generated. For example, FFFF:1234:5678 is such a system ID. If the conflict persists after the system automatically changes three system IDs, the system no longer resolves this conflict.

• SEL

  The role of an SEL (also referred to as NSAP Selector or N-SEL) is similar to that of the "protocol identifier" of IP. A transport protocol matches an SEL. The SEL is "00" in IP.

• NET

  A Network Entity Title (NET) indicates the network layer information of an IS itself and consists of an area ID and a system ID. It does not contain the transport layer information (SEL = 0). A NET can be regarded as a special NSAP. The length of the NET field is the same as that of an NSAP, varying from 8 bytes to 20 bytes. For example, in NET ab.cdef.1234.5678.9abc.00, the area is ab.cdef, the system ID is 1234.5678.9abc, and the SEL is 00.

  In general, an IS-IS process is configured with only one NET. When areas need to be redefined, for example, areas need to be combined or an area needs to be divided into sub-areas, you can configure multiple NETs.

  A maximum of three area addresses can be configured in an IS-IS process, and therefore, you can configure only a maximum of three NETs. When you configure multiple NETs, ensure that their system IDs are the same.

  The routers in an area must have the same area address.

IS-IS Network Types

Related Concepts

DIS and Pseudo Node

A Designated Intermediate System (DIS) is an intermediate router elected in IS-IS communication. A pseudo node simulates a virtual node on a broadcast network and is not a real router. In IS-IS, a pseudo node is identified by the system ID and 1-byte circuit ID (a non-zero value) of a DIS.

The DIS is used to create and update pseudo nodes and generate the link state protocol data units (LSPs) of pseudo nodes. The routers advertise a single link to a pseudo node and obtain routing information about the entire network through the pseudo node. The router does not need to exchange packets with all the other routers on the network. Using the DIS and pseudo nodes simplifies network topology and reduces the length of LSPs generated by routers. When the network changes, fewer LSPs are generated. Therefore, fewer resources are consumed.

SPF Algorithm

The SPF algorithm, also named Dijkstra's algorithm, is used in a link-state routing protocol to calculate the shortest paths to other nodes on a network. In the SPF algorithm, a local router takes itself as the root and generates a shortest path tree (SPT) based on the network topology to calculate the shortest path to every destination node on a network. In IS-IS, the SPF algorithm runs separately in Level-1 and Level-2 databases.

Implementation

Establishment of IS-IS Neighbor Relationships

On different types of networks, the modes for establishing IS-IS neighbor relationships are different.

• Establishment of a neighbor relationship on a broadcast link

  Figure 10-141 Networking for a broadcast link
  
  

  Device A, Device B, Device C, and Device D are Level-2 routers. Device A is newly added to the broadcast network. Figure 10-142 demonstrates the process of establishing the neighbor relationship between Device A and Device B, the process of establishing the neighbor relationship between Device A and Device C or Device D is similar to that between Device A and Device B.

  Figure 10-142 Establishing a neighbor relationship on a broadcast link
  
  
  As shown in Figure 10-142, the process for establishing a neighbor relationship on a broadcast link consists of the following phases:

  • Device A broadcasts a Level-2 local area network (LAN) IS-to-IS Hello PDU (IIH). After Device B receives the IIH, Device B detects that the neighbor field in the IIH does not contain its media access control (MAC) address, and sets its neighbor status with Device A to Initial.
  • Device B replies a Level-2 LAN IIH to Device A. After Device A receives the IIH, Device A detects that the neighbor field in the IIH contains its MAC address, and sets its neighbor status with Device B to Up.
  • Device A sends a Level-2 LAN IIH to Device B. After Device B receives the IIH, Device B detects that the neighbor field in the IIH contains its MAC address, and sets its neighbor status with Device A to Up.

  DIS Election

  On a broadcast network, any two routers exchange information. If n routers are available on the network, n x (n - 1)/2 adjacencies must be established. Each status change of a router is transmitted to other routers, which wastes bandwidth resources. IS-IS resolves this problem by introducing the DIS. All routers send information to the DIS, which then broadcasts the network link status. Using the DIS and pseudo nodes simplifies network topology and reduces the length of LSPs generated by routers. When the network changes, fewer LSPs are generated. Therefore, fewer resources are consumed.

  A DIS is elected after a neighbor relationship is established. Level-1 and Level-2 DISs are elected separately. You can configure different priorities for DISs at different levels. In DIS election, a Level-1 priority and a Level-2 priority are specified for every interface on every router. A router uses every interface to send IIHs and advertises its priorities in the IIHs to neighboring routers. The higher the priority, the higher the probability of being elected as the DIS. If there are multiple routers with the same highest priority on a broadcast network, the one with the largest MAC address is elected. The DISs at different levels can be the same router or different routers.

  In the DIS election procedure, IS-IS is different from Open Shortest Path First (OSPF). In IS-IS, DIS election rules are as follows:

  • The router with the priority of 0 also takes part in the DIS election.
  • When a new router that meets the requirements of being a DIS is added to the broadcast network, the router is selected as the new DIS, which triggers a new round of LSP flooding.

• Establishment of a neighbor relationship on a P2P link

  The establishment of a neighbor relationship on a P2P link is different from that on a broadcast link. A neighbor relationship on a P2P link can be established in 2-way or 3-way mode, as shown in Table 10-67. By default, the 3-way handshake mechanism is used to establish a neighbor relationship on a P2P link.

  Table 10-67 Comparison between 2-way mode and 3-way mode

  Mode	Description	Advantages and Disadvantages	Reliability
  2-way mode	When a router receives an IIH, it unidirectionally sets up a neighbor relationship.	Disadvantages: The unstable link status causes the loss of complete sequence numbers protocol data units (CSNPs) that are sent once an adjacency is set up. As a result, the link state databases (LSDBs) of two neighboring routers are not synchronized during the LSP update period. If two or more links exist between two routers, an adjacency can still be set up when one link is Down and another is Up in the same direction. A router that fails to detect the faulty link may also forward packets over this link.	Low
  3-way mode	A neighbor relationship is established after IIHs are sent three times.	Advantages: A neighbor relationship is established only when both ends are Up. This mechanism ensures that packets are transmitted securely.	High

LSDB Synchronization

IS-IS is a link-state protocol. An IS-IS router obtains first-hand information from other routers running link-state protocols. Every router generates information about itself, directly connected networks, and links between itself and directly connected networks. The router then sends the generated information to other routers through adjacent routers. Every router saves link state information without modifying it. Finally, every router has the same network interworking information, and LSDB synchronization is complete. The process of synchronizing LSDBs is called LSP flooding. In LSP flooding, a router sends an LSP to its neighbors and the neighbors send the received LSP to their neighbors except the router that first sends the LSP. The LSP is flooded among the routers at the same level. This implementation allows each router at the same level to have the same LSP information and keep a synchronized LSDB.

Route Calculation

When LSDB synchronization is complete and network convergence is implemented, IS-IS performs SPF calculation by using LSDB information to obtain the SPT. IS-IS uses the SPT to create a forwarding database (a routing table).

In IS-IS, link costs are used to calculate shortest paths. The default cost for an interface on a Huawei router is 10. The cost is configurable. The cost of a route is the sum of the cost of every outbound interface along the route. There may be multiple routes to a destination, among which the route with the smallest cost is the optimal route.

Level-1 routers can also calculate the shortest path to Level-2 routers to implement inter-area route selection. When a Level-1-2 router is connected to other areas, the router sets the value of the attachment (ATT) bit in its LSP to 1 and sends the LSP to neighboring routers. In the route calculation process, a Level-1 router selects the nearest Level-1-2 router as an intermediate router between the Level-1 and Level-2 areas.

IS-IS routes calculated using the SPF algorithm may bring about some problems. For example, too many routing entries slow down route lookup, or link usage is unbalanced. As a result, IS-IS routing cannot meet carriers' network planning and traffic management requirements.

Route Leaking

When Level-1 and Level-2 areas both exist on an IS-IS network, Level-2 routers do not advertise the learned routing information about a Level-1 area and the backbone area to any other Level-1 area by default. Therefore, Level-1 routers do not know the routing information beyond the local area. As a result, the Level-1 routers cannot select the optimal routes to the destination beyond the local area.

With route leaking, Level-1-2 routers can select routes using routing policies, or tags and advertise the selected routes of other Level-1 areas and the backbone area to the Level-1 area. Figure 10-144 shows the typical networking for route leaking.

• Device A, Device B, Device C, and Device D belong to area 10. Device A and Device B are Level-1 routers. Device C and Device D are Level-1-2 routers.

• Device E and Device F belong to area 20 and are Level-2 routers.

If Device A sends a packet to Device F, the selected optimal route should be Device A -> Device B -> Device D -> Device E -> Device F because its cost is 40 (10 + 10 + 10 + 10 = 40) which is less than that of Device A -> Device C -> Device E -> Device F (10 + 50 + 10 = 70). However, if you check routes on Device A, you can find that the selected route is Device A -> Device C -> Device E -> Device F, which is not the optimal route from Device A to Device F.

This is because Device A does not know the routes beyond the local area, and therefore, the packets sent by Device A to other network segments are sent through the default route generated by the nearest Level-1-2 device.

In this case, you can enable route leaking on the Level-1-2 devices (Device C and Device D). Then, check the route and you can find that the selected route is Device A -> Device B -> Device D -> Device E -> Device F.

Route Summarization

On a large-scale IS-IS network, links connected to devices within an IP address range may alternate between up and down. With route summarization, multiple routes with the same IP prefix are summarized into one route, which prevents route flapping, reduces routing entries and system resource consumption, and facilitates route management. Figure 10-145 shows the typical networking.

Figure 10-145 Typical networking for route summarization

• router A, router B, and router C use IS-IS to communicate with each other.

• Device A belongs to area 20, and Device B and Device C belong to area 10.

• Device A is a Level-2 router. Device B is a Level-1-2 router. Device C is a Level-1 router.

• Device B maintains Level-1 and Level-2 LSDBs and leaks the routes to three network segments (172.16.1.0/24, 172.16.2.0/24, and 172.16.3.0/24) from the Level-1 area to the Level-2 area. If a link fault causes the Device C interface with IP address 172.16.1.1/24 to frequently alternate between up and down, the state change is advertised to the Level-2 area, triggering frequent LSP flooding and SPF calculation on Device A. As a result, the CPU usage on Device A increases, and even network flapping occurs.

  If Device B is configured to summarize routes to the three network segments in the Level-1 area into route 172.16.0.0/22, the number of routing entries on Device B is reduced; in addition, the impact of link state changes in the Level-1 area on route convergence in the Level-2 area can be reduced.

Load Balancing

When multiple equal-cost routes are available on a network, you can configure IS-IS load balancing to improve link utilization and prevent network congestion caused by link overload. IS-IS load balancing evenly distributes traffic among multiple equal-cost paths. Figure 10-146 shows the typical networking for load balancing.

Figure 10-146 Typical networking for load balancing

• Device A, Device B, Device C, and Device D communicate with each other on an IP network using IS-IS.

• Device A, Device B, Device C, and Device D belong to area 10 and are Level-2 routers.

• If load balancing is not enabled, traffic on Device A is transmitted along the optimal route obtained using the SPF calculation. Consequently, traffic on different links is unbalanced. Enabling load balancing on Device A sends traffic to routerDevice D through routerDevice B and Device C. This transmission mode relieves the load on the optimal route.

Load balancing supports per-packet load balancing and per-flow load balancing. For details, see NE9000 Feature Description - IP Routing.

IS-IS supports not only intra-process load balancing, but also inter-process load balancing when equal-cost routes exist between different processes.

Administrative Tag

Administrative tags carry administrative information about IP address prefixes. When the cost type is wide, wide-compatible, or compatible and the prefix of the reachable IP address to be advertised by IS-IS has this cost type, IS-IS adds the administrative tag to the reachability type-length-value (TLV) in the prefix. In this manner, the administrative tag is advertised to the entire routing domain along with the prefix so that routes can be imported or filtered based on the administrative tag.

IS-IS Mesh Group

As defined in IS-IS, upon receipt of a new LSP, a router floods it. On a network with high connectivity and multiple P2P links, this causes repeated LSP flooding and wastes bandwidth resources. To prevent this problem, you can configure a mesh group to reduce bandwidth waste.

A mesh group consists of a group of interfaces. Interfaces in a mesh group flood the LSPs received from the local group only to the interfaces in other mesh groups and those that are not in any mesh group. In addition, interfaces in a mesh group use the CSNP and PSNP mechanisms to implement LSDB synchronization in the entire network segment.

link-group

In Figure 10-147, router A is dual-homed to the IS-IS network through router B and router C. The path router A -> router B is primary and the path router A -> router C is backup. The bandwidth of each link is 100 Gbit/s, and the traffic from Client is transmitted at 150 Gbit/s. In this situation, both links in the path router A -> router B or the path router A -> router C need to carry the traffic. If Link-a fails, Link-b takes over all the traffic. However, the bandwidth of Link-b is not sufficient to carry the traffic. As a result, traffic loss occurs.

To address this problem, configure link groups. You can add multiple links to a link group. If one of the links fails and the bandwidth of the other links in the group is not sufficient to carry the traffic, the link group automatically increases the costs of the other links to a configured value so that this link group is not selected. Then, traffic is switched to another link group.

Figure 10-147 IS-IS dual-homing access networking

Background

If the status of an interface carrying IS-IS services alternates between Up and Down, IS-IS neighbor relationship flapping occurs on the interface. During the flapping, IS-IS frequently sends Hello packets to reestablish the neighbor relationship, synchronizes LSDBs, and recalculates routes. In this process, a large number of packets are exchanged, adversely affecting neighbor relationship stability, IS-IS services, and other IS-IS-dependent services, such as LDP and BGP. IS-IS neighbor relationship flapping suppression can address this problem by delaying IS-IS neighbor relationship reestablishment or preventing service traffic from passing through flapping links.

Related Concepts

Flapping_event: reported when the status of a neighbor relationship on an interface last changes from Up to Init or Down. The flapping_event triggers flapping detection.

Flapping_count: number of times flapping has occurred.

Detect-interval: interval at which flapping is detected. The interval is used to determine whether to trigger a valid flapping_event.

Threshold: flapping suppression threshold. When the flapping_count exceeds the threshold, flapping suppression takes effect.

Resume-interval: interval used to determine whether flapping suppression exits. If the interval between two valid flapping_events is longer than the resume-interval, flapping suppression exits.

Implementation

Flapping detection

IS-IS interfaces start a flapping counter. If the interval between two flapping_events is shorter than the detect-interval, a valid flapping_event is recorded, and the flapping_count increases by 1. When the flapping_count exceeds the threshold, the system determines that flapping occurs, and therefore triggers flapping suppression, and sets the flapping_count to 0. If the interval between two valid flapping_events is longer than the resume-interval before the flapping_count reaches the threshold again, the system sets the flapping_count to 0 again. Interfaces start the suppression timer when the status of a neighbor relationship last changes to Init or Down.

The detect-interval, threshold, and resume-interval are configurable.

Flapping suppression

Flapping suppression works in either Hold-down or Hold-max-cost mode.

• Hold-down mode: In the case of frequent flooding and topology changes during neighbor relationship establishment, interfaces prevent neighbor relationships from being reestablished during the suppression period, which minimizes LSDB synchronization attempts and packet exchanges.
• Hold-max-cost mode: If the traffic forwarding path changes frequently, interfaces use the maximum cost of the flapping link during the suppression period, which prevents traffic from passing through the flapping link.

Flapping suppression can also work first in Hold-down mode and then in Hold-max-cost mode.

By default, the Hold-max-cost mode takes effect. The mode and suppression period can be changed manually.

When an interface enters the flapping suppression state, all neighbor relationships on the interface enter the state accordingly.

Exiting from flapping suppression

Interfaces exit from flapping suppression in the following scenarios:

• The suppression timer expires.
• The corresponding IS-IS process is reset.
• A command is run to exit from flapping suppression.
• Three Hello packets in which the padding TLV carries a sub-TLV with the value being 251 are sent consecutively to notify the peer device to forcibly exit flapping suppression.

Typical Usage Scenario

Basic scenario

In Figure 10-148, the traffic forwarding path is Device A -> Device B -> Device C -> Device E before a link failure occurs. After the link between Device B and Device C fails, the forwarding path switches to Device A -> Device B -> Device D -> Device E. If the neighbor relationship between Device B and Device C frequently flaps at the early stage of the path switchover, the forwarding path will be switched frequently, causing traffic loss and affecting network stability. If the neighbor relationship flapping meets suppression conditions, flapping suppression takes effect.

• If flapping suppression works in Hold-down mode, the neighbor relationship between Device B and Device C is prevented from being reestablished during the suppression period, in which traffic is forwarded along the path Device A -> Device B -> Device D -> Device E.
• If flapping suppression works in Hold-max-cost mode, the maximum cost is used as the cost of the link between Device B and Device C during the suppression period, and traffic is forwarded along the path Device A -> Device B -> Device D -> Device E.

Figure 10-148 Flapping suppression in a basic scenario

Single-forwarding path scenario

When only one forwarding path exists on the network, the flapping of the neighbor relationship between any two devices on the path will interrupt traffic forwarding. In Figure 10-149, the traffic forwarding path is Device A -> Device B -> Device C -> Device E. If the neighbor relationship between Device B and Device C flaps, and the flapping meets suppression conditions, flapping suppression takes effect. However, if the neighbor relationship between Device B and Device C is prevented from being reestablished, the whole network will be divided. Therefore, Hold-max-cost mode (rather than Hold-down mode) is recommended. If flapping suppression works in Hold-max-cost mode, the maximum cost is used as the cost of the link between Device B and Device C during the suppression period. After the network stabilizes and the suppression timer expires, the link is restored.

By default, the Hold-max-cost mode takes effect.

Figure 10-149 Flapping suppression in a single-forwarding path scenario

Broadcast scenario

In Figure 10-150, four devices are deployed on the same broadcast network using switches, and the devices are broadcast network neighbors. If Device C flaps due to a link failure, and Device A and Device B were deployed at different time (Device A was deployed earlier for example) or the flapping suppression parameters on Device A and Device B are different, Device A first detects the flapping and suppresses Device C. Consequently, the Hello packets sent by Device A do not carry Device C's router ID. However, Device B has not detected the flapping yet and still considers Device C a valid node. As a result, the DR candidates identified by Device A are Device B and Device D, whereas the DR candidates identified by Device B are Device A, Device C, and Device D. Different DR candidates result in a different DR election result, which may lead to route calculation errors. To prevent this problem in scenarios where an interface has multiple neighbors, such as on a broadcast, P2MP, or NBMA network, all neighbors on the interface are suppressed when the status of a neighbor relationship last changes to Init or Down. Specifically, if Device C flaps, Device A, Device B, and Device D on the broadcast network are all suppressed. After the network stabilizes and the suppression timer expires, Device A, Device B, and Device D are restored to normal status.

Figure 10-150 Flapping suppression on a broadcast network

Scenario of multi-level networking

In Figure 10-151, Device A, Device B, Device C, Device E, and Device F are connected on Level 1 (Area 1), and Device B, Device D, and Device E are connected on Level 2 (Area 0). Traffic from Device A to Device F is preferentially forwarded along an intra-area route, and the forwarding path is Device A -> Device B -> Device C -> Device E -> Device F. When the neighbor relationship between Device B and Device C flaps and the flapping meets suppression conditions, flapping suppression takes effect in the default mode (Hold-max-cost). Consequently, the maximum cost is used as the cost of the link between Device B and Device C. However, the forwarding path remains unchanged because intra-area routes take precedence over inter-area routes during route selection according to IS-IS route selection rules. To prevent traffic loss in multi-area scenarios, configure Hold-down mode to prevent the neighbor relationship between Device B and Device C from being reestablished during the suppression period. During this period, traffic is forwarded along the path Device A -> Device B -> Device D -> Device E -> Device F.

By default, the Hold-max-cost mode takes effect. The mode can be changed to Hold-down manually.

Figure 10-151 Flapping suppression in a multi-level scenario

Scenario with both LDP-IGP synchronization and IS-IS neighbor relationship flapping suppression configured

In Figure 10-152, if the link between PE1 and P1 fails, an LDP LSP switchover is implemented immediately, causing the original LDP LSP to be deleted before a new LDP LSP is established. To prevent traffic loss, LDP-IGP synchronization needs to be configured. With LDP-IGP synchronization, the maximum cost is used as the cost of the new LSP to be established. After the new LSP is established, the original cost takes effect. Consequently, the original LSP is deleted, and LDP traffic is forwarded along the new LSP.

LDP-IGP synchronization and IS-IS neighbor relationship flapping suppression work in either Hold-down or Hold-max-cost mode. If both functions are configured, Hold-down mode takes precedence over Hold-max-cost mode, followed by the configured link cost. Table 10-68 lists the suppression modes that take effect in different situations.

For example, the link between PE1 and P1 frequently flaps in Figure 10-152, and both LDP-IGP synchronization and IS-IS neighbor relationship flapping suppression are configured. In this case, the suppression mode is selected based on the preceding principles. No matter which mode (Hold-down or Hold-max-cost) is selected, the forwarding path is PE1 -> P4 -> P3 -> PE2.

Figure 10-152 Scenario with both LDP-IGP synchronization and IS-IS neighbor relationship flapping suppression configured

Scenario with both bit-error-triggered protection switching and IS-IS neighbor relationship flapping suppression configured

If a link has poor link quality, services transmitted along it may be adversely affected. If bit-error-triggered protection switching is configured and the bit error rate (BER) along a link exceeds a specified value, a bit error event is reported, and the maximum cost is used as the cost of the link, triggering route reselection. Consequently, service traffic is switched to the backup link. If both bit-error-triggered protection switching and IS-IS neighbor relationship flapping suppression are configured, they both take effect. Hold-down mode takes precedence over Hold-max-cost mode, followed by the configured link cost.

Scenario with both Link-bundle and IS-IS neighbor relationship flapping suppression configured

When the service traffic rate exceeds the capacity of the link, multiple links must be used. If one of the links between two devices is faulty, traffic is switched to another link. Because of limited forwarding capacity on the new link, excessive traffic is discarded. If the number of faulty links reaches the upper threshold, the maximum cost is used as the cost of all links in the link bundle to switch all service traffic to the backup nodes. When both link-bundle and neighbor relationship flapping suppression are configured, if the number of flapping links reaches the upper threshold, the maximum cost must be configured as the cost of all other links in the link bundle to prevent service loss caused by user traffic congestion. As shown in Figure 10-153, two parallel links exist between Device A and Device C. If Link 1 is faulty and Link 2 bears all service traffic, traffic loss occurs. If both link-bundle and neighbor relationship flapping suppression are configured and Link 1 flaps, the maximum cost must be configured for Link 2 to avoid service traffic congestion. Only the Hold-max-cost mode therefore can be configured for neighbor relationship flapping suppression to switch the traffic forwarding path to Device A->Device B->Device C.

Figure 10-153 Scenario with both Link-bundle and IS-IS neighbor relationship flapping suppression configured

I-SPF

In ISO 10589, the Dijkstra algorithm was adopted to calculate routes. When a node changes on the network, the algorithm recalculates all routes. The calculation requires a long time to complete and consumes a significant amount of CPU resources, reducing convergence speed.

I-SPF improves the algorithm. Except for the first time the algorithm is run, only the nodes that have changed rather than all nodes in the network are used in the calculation. The SPT generated using I-SPF is the same as that generated using the previous algorithm. This significantly decreases CPU usage and speeds up network convergence.

PRC

Similar to I-SPF, PRC calculates only routes that have changed. PRC, however, does not calculate the shortest path. It updates routes based on the SPT calculated by I-SPF.

In route calculation, a leaf represents a route, and a node represents a device. Either an SPT change or a leaf change causes a routing information change. The SPT change is irrelevant to the leaf change. PRC processes routing information as follows:

• If the SPT changes after I-SPF calculation, PRC calculates all the leaves only on the changed node.
• If the SPT remains unchanged after I-SPF calculation, PRC calculates only the changed leaves.

For example, if a new route is imported, the SPT of the entire network remains unchanged. In this case, PRC updates only the interface route for this node, thereby reducing the CPU usage.

PRC working with I-SPF further improves network convergence performance and replaces the original SPF algorithm.

On the NE9000, only I-SPF and PRC are used to calculate IS-IS routes.

LSP Fast Flooding

When an IS-IS device receives new LSPs from other devices, it updates the LSPs in the LSDB and periodically floods the updated LSPs based on a timer. Therefore, the synchronization of all LSDBs is slow.

LSP fast flooding can address this problem. With this function configured, when the router receives LSPs that can trigger route calculation or route update, the router makes its best efforts to flood these LSPs before route calculation is performed. This speeds up LSDB synchronization on the entire network. This flooding mode significantly speeds up the network-wide convergence speed.

LSP fast flooding is supported by default and does not need to be configured.

Intelligent Timer

Although the route calculation algorithm is improved, the long interval for triggering route calculation also affects the convergence speed. A millisecond-level timer can shorten the interval. Frequent network changes, however, also consume too much CPU resources. The SPF intelligent timer can quickly respond to a few external emergencies and avoid excessive CPU usage.

In most cases, an IS-IS network running normally is stable. The frequent changes on a network are rather rare, and IS-IS does not calculate routes frequently. Therefore, a short period (within milliseconds) can be configured as the first interval for route calculation. If the network topology changes frequently, the interval set by the intelligent timer increases with the calculation times to reduce CPU consumption.

The LSP generation intelligent timer is similar to the SPF intelligent timer. When the LSP generation intelligent timer expires, the system generates a new LSP based on the current topology. In the original implementation mechanism, a timer with a fixed interval is used, which cannot meet the requirements of fast convergence and low CPU usage at the same time. Therefore, the LSP generation timer is designed as an intelligent timer to respond to emergencies (for example, the interface goes Up or Down) quickly and speed up network convergence. In addition, when the network changes frequently, the interval for the intelligent timer becomes longer to reduce CPU consumption.

Terms

• Originating system

  The originating system is a device that runs the IS-IS protocol. A single IS-IS process advertises LSPs as virtual devices do, except that the originating system refers to a real IS-IS process.

• Normal system ID

  The normal system ID is the system ID of the originating system.

• Additional system ID

  The additional system ID, assigned by the network administrator, is used to generate additional or extended LSP fragments. A maximum of 256 additional or extended LSP fragments can be generated. Like a normal system ID, an additional system ID must be unique in a routing domain.

• Virtual system

  The virtual system, identified by an additional system ID, is used to generate extended LSP fragments. These fragments carry additional system IDs in their LSP IDs.

Principles

IS-IS LSP fragments are identified by the LSP Number field in their LSP IDs. The LSP Number field is 1 byte. Therefore, an IS-IS process can generate a maximum of 256 fragments. With fragment extension, more information can be carried.

Each system ID represents a virtual system, and each virtual system can generate 256 LSP fragments. In addition, another virtual systems can be configured. Therefore, an IS-IS process can generate more LSP fragments.

After a virtual system and fragment extension are configured, an IS-IS device adds the contents that cannot be contained in its LSPs to the LSPs of the virtual system and notifies other devices of the relationship between the virtual system and itself through a special TLV in the LSPs.

IS Alias ID TLV

Standard protocol defines a special Type-Length-Value (TLV): IS Alias ID TLV.

LSPs with fragment number 0 sent by the originating system and virtual system carry IS Alias ID TLVs to indicate the originating system.

Operation Modes

IS-IS devices can use the LSP fragment extension feature in the following modes:

Figure 10-154 Networking for IS-IS LSP fragment extension

• Mode-1

  Mode-1 is used when some devices on the network do not support LSP fragment extension.

  In this mode, virtual systems participate in SPF calculation. The originating system advertises LSPs containing information about links to each virtual system and each virtual system advertises LSPs containing information about links to the originating system. In this manner, the virtual systems function the same as the actual devices connected to the originating system on the network.

  Mode-1 is a transitional mode for earlier versions that do not support LSP fragment extension. In the earlier versions, IS-IS cannot identify Alias ID TLVs. Therefore, the LSP sent by a virtual system must look like a common IS-IS LSP.

  The LSP sent by a virtual system contains the same area address and overload bit as those in the common LSP. If the LSPs sent by a virtual system contain TLVs specified in other features, the TLVs must be the same as those in common LSPs.

  LSPs sent by a virtual system carry information of the neighbor (the originating system), and the carried cost is the maximum value minus 1. LSPs sent by the originating system carry information of the neighbor (the virtual system), and the carried cost is 0. This mechanism ensures that the virtual system is a node downstream of the originating system when other devices calculate routes.

  In Figure 10-154, Device B does not support LSP fragment extension; Device A supports LSP fragment extension in mode-1; Device A1 and Device A2 are virtual systems of Device A. Device A1 and Device A2 send LSPs carrying partial routing information of Device A. After receiving LSPs from Device A, Device A1, and Device A2, Device B considers there to be three devices at the peer end and calculates routes normally. Because the cost of the route from Device A to Device A1 or Device A2 is 0, the cost of the route from Device B to Device A is equal to that from Device B to Device A1.

• Mode-2

  Mode-2 is used when all the devices on the network support LSP fragment extension. In this mode, virtual systems do not participate in SPF calculation. All the devices on the network know that the LSPs generated by the virtual systems actually belong to the originating system.

  IS-IS working in mode-2 identifies IS Alias ID TLVs, which are used to calculate the SPT and routes.

  In Figure 10-154, Device B supports LSP fragment extension, and Device A supports LSP fragment extension in mode-2; Device A1 and Device A2 send LSPs carrying some routing information of Device A. After receiving LSPs from Device A1 and Device A2, Device B obtains IS Alias ID TLV and learns that the originating system of Device A1 and Device A2 is Device A. Device B then considers information advertised by Device A1 and Device A2 to be about Device A.

Whatever the LSP fragment extension mode, LSPs can be resolved. However, if LSP fragment extension is not supported, only LSPs in mode-1 can be resolved.

Process

After LSP fragment extension is configured, if information is lost because LSPs overflow, the system restarts the IS-IS process. After being restarted, the originating system loads as much routing information as possible. Any excessive information beyond the forwarding capability of the system is added to the LSPs of the virtual systems for transmission. In addition, if a virtual system with routing information is deleted, the system automatically restarts the IS-IS process.

Usage Scenario

If there are non-Huawei devices on the network, LSP fragment extension must be set to mode-1. Otherwise, these devices cannot identify LSPs.

Configuring LSP fragment extension and virtual systems before setting up IS-IS neighbors or importing routes is recommended. If IS-IS neighbors are set up or routes are imported first and the information to be carried exceeds the forwarding capability of 256 fragments before LSP fragment extension and virtual systems are configured, you have to restart the IS-IS process for the configurations to take effect.

Background

As networks develop, the demand for data, audio, and video services is growing, which imposes increasing requirements on IP network reliability. If an AMB/SMB switchover is performed on a device due to a maintenance operation or a single point of failure, routes may fail to converge, which may result in traffic loss or even a network breakdown. Non-stop routing (NSR) can address this problem and ensure uninterrupted forwarding of key services.

Related Concepts

• High availability (HA): supports data backup between the AMB and SMB.
• Non-stop forwarding (NSF): enables a node to use the GR mechanism to ensure uninterrupted transmission during an AMB/SMB switchover.
• NSR: allows a standby control plane to take over traffic from an active control plane if the active control plane fails, preventing the control planes of neighbors from detecting the fault.
• AMB and SMB: run control plane processes.

Implementation

With IS-IS NSR, IS-IS real-time data is synchronized between the AMB and SMB. After an AMB/SMB switchover is performed on a device, the SMB takes over services from the AMB, and neighbors are unaware of the local fault. After the switchover, the new AMB restores IS-IS immediately based on the synchronized IS-IS real-time data. Therefore, neighbors are unaware of the switchover as well. IS-IS NSR requires synchronization of the following data:

• All configuration data, such as information about neighbors, timer parameters, and process configurations.

• Dynamic data, such as the interface parameters and state, and information about neighbors and the link state database (LSDB).

For details about NSR, see Feature Description - Reliability.

Usage Scenario

NSR minimizes the impact of control plane faults and prevents route flapping on networks that require high reliability.

Benefits

NSR improves network reliability and ensures uninterrupted traffic forwarding.

Basic Principles

IS-IS TE is an extension of IS-IS intended to support MPLS TE. As defined in standard protocols, IS-IS TE uses LSPs to carry TE information to help MPLS implement the flooding, synchronization, and resolution of TE information. Then, IS-IS TE transmits the resolved TE information to the CSPF module. In MPLS TE, IS-IS TE plays the role of a porter. Figure 10-156 illustrates the relationships between IS-IS TE, MPLS TE, and CSPF.

Figure 10-156 Outline of relationships between MPLS TE, CSPF, and IS-IS TE

To carry TE information in LSPs, IS-IS TE defines the following TLVs in standard protocols:

• Extended IS reachability TLV

  This TLV replaces the IS reachability TLV and extends the TLV format using sub-TLVs. The implementation of the sub-TLVs in the TLV is the same as that of TLVs in LSPs. These sub-TLVs are used to carry TE information configured on physical interfaces.

  All sub-TLVs defined in standard protocols are supported.

  Table 10-71 Sub-TLVs defined in Extended IS reachability TLV

  Name	Type	Length (Byte)	Value
  Administrative Group	3	4	Administrative group
  IPv4 Interface Address	6	4	IPv4 address of a local interface
  IPv4 Neighbour Address	8	4	IPv4 address of a neighbor's interface
  Maximum Link Bandwidth	9	4	Maximum link bandwidth
  Maximum Reserved Link Bandwidth	10	4	Maximum reserved link bandwidth
  Unreserved Bandwidth	11	32	Unreserved bandwidth
  Traffic Engineering Default Metric	18	3	Default metric of TE
  Bandwidth Constraints sub-TLV	22	36	Sub-TLV of the bandwidth constraint.
  Min/Max Unidirectional Link Delay Sub-TLV	34	8	Minimum/Maximum unidirectional link delay

• Traffic Engineering router ID TLV

  The type of this TLV is 134, and this TLV carries a 4-byte router ID (MPLS LSR-ID). In MPLS TE, each device has a unique router ID.

• Extended IP reachability TLV

  This TLV replaces the IP reachability TLV and carries routing information. It extends the length of the route cost field to 4 bytes and carries sub-TLVs.

IS-IS TE consists of two procedures:

• Responding to MPLS TE configurations

  IS-IS TE functions only after MPLS TE is enabled.

  It updates the TE information in IS-IS LSPs based on MPLS TE configurations.

  It transmits MPLS TE configurations to the CSPF module.

• Processing TE information in LSPs

  It extracts TE information from IS-IS LSPs and transmits the TE information to the CSPF module.

Usage Scenario

IS-IS TE helps MPLS TE set up TE tunnels. In Figure 10-157, a TE tunnel is set up between Device A and Device C.

Figure 10-157 Networking for IS-IS TE

The configuration requirements are as follows:

• MPLS TE and MPLS TE CSPF are enabled on Device A.

• MPLS TE is enabled on Device B, Device C, and Device D.

• IS-IS and IS-IS TE are enabled on Device A, Device B, Device C, and Device D.

After the configurations are complete, IS-IS on Device A, Device B, Device C, and Device D sends LSPs carrying TE information configured on each device. Device A obtains the MPLS TE configurations of DeviceB, DeviceC, and DeviceD from the received LSPs. In this way, Device A obtains the TE information of the entire network. The CSPF module can use the information to calculate the path required by the tunnel.

Process

Once the metric style is changed, the IS-IS process restarts.

• If the metric style carried in sent packets is changed from narrow to wide:

  The information previously carried by TLV type 128, TLV type 130, and TLV type 2 is now carried by TLV type 135 and TLV type 22.

• If the metric style carried in sent packets is changed from wide to narrow:

  The information previously carried by TLV type 135 and TLV type 22 is now carried by TLV type 128, TLV type 130, and TLV type 2.

• If the metric style carried in sent packets is changed from narrow or wide to narrow and wide:

  The information previously carried in narrow or wide mode is now carried by TLV type 128, TLV type 130, TLV type 2, TLV type 135, and TLV type 22.

Usage Scenario

IS-IS wide metric is used to support IS-IS TE, and the metric style needs to be set to wide, compatible or wide compatible.

BFD Session Establishment and Deletion

• Conditions for establishing a BFD session

  • Global BFD is enabled on each device, and BFD is enabled on a specified interface or process.

  • IS-IS is configured on each device and enabled on interfaces.

  • Neighbors are Up, and a designated intermediate system (DIS) has been elected on a broadcast network.

• Process of establishing a BFD session

  • P2P network

    After the conditions for establishing BFD sessions are met, IS-IS instructs the BFD module to establish a BFD session and negotiate BFD parameters between neighbors.

  • Broadcast network

    After the conditions for establishing BFD sessions are met and the DIS is elected, IS-IS instructs BFD to establish a BFD session and negotiate BFD parameters between the DIS and each device. No BFD sessions are established between non-DISs.

  On broadcast networks, devices (including non-DIS devices) of the same level on a network segment can establish adjacencies. In BFD for IS-IS, however, BFD sessions are established only between the DIS and non-DISs. On P2P networks, BFD sessions are directly established between neighbors.

  If a Level-1-2 neighbor relationship is set up between the devices on both ends of a link, the following situations occur:

  • On a broadcast network, IS-IS sets up a Level-1 BFD session and a Level-2 BFD session.
  • On a P2P network, IS-IS sets up only one BFD session.

• Process of tearing down a BFD session

  • P2P network

    If the neighbor relationship established between P2P IS-IS interfaces is not Up, IS-IS tears down the BFD session.

  • Broadcast network

    If the neighbor relationship established between broadcast IS-IS interfaces is not Up or the DIS is reelected on the broadcast network, IS-IS tears down the BFD session.

  If the configurations of dynamic BFD sessions are deleted or BFD for IS-IS is disabled from an interface, all Up BFD sessions established between the interface and its neighbors are deleted. If the interface is a DIS and the DIS is Up, all BFD sessions established between the interface and its neighbors are deleted.

  If BFD is disabled from an IS-IS process, BFD sessions are deleted from the process.

  BFD detects only the one-hop link between IS-IS neighbors because IS-IS establishes only one-hop neighbor relationships.

• Response to the Down event of a BFD session

  When BFD detects a link failure, it generates a Down event and informs IS-IS. IS-IS then suppresses neighbor relationships and recalculates routes. This process speeds up network convergence.

Usage Scenario

Dynamic BFD needs to be configured based on the actual network. If the time parameters are not configured correctly, network flapping may occur.

BFD for IS-IS speeds up route convergence through rapid link failure detection. The following is a networking example for BFD for IS-IS.

Figure 10-158 BFD for IS-IS

The configuration requirements are as follows:

• Basic IS-IS functions are configured on each device shown in Figure 10-158.

• Global BFD is enabled.

• BFD for IS-IS is enabled on Device A and Device B.

If the link between Device A and Device B fails, BFD can rapidly detect the fault and report it to IS-IS. IS-IS sets the neighbor status to Down to trigger an IS-IS topology calculation. IS-IS also updates LSPs so that Device C can promptly receive the updated LSPs from Device B, which accelerates network topology convergence.

Background

As networks develop, services such as Voice over IP (VoIP) and online video services require high-quality and real-time transmission. However, if a link fails, IS-IS must complete the following procedure before switching traffic to a new link: detect the fault, update LSPs, flood LSPs, calculate routes, and deliver route entries to the FIB. This is a lengthy process, and the associated traffic interruption is often longer than users can tolerate. As a result, real-time transmission requirements cannot be met.

IS-IS Auto FRR (Fast reroute) is dynamic IP FRR. An IGP pre-calculates a backup path based on the LSDBs on the entire network and saves the backup path in the forwarding table for traffic protection in the case of a fault. Because IP FRR helps implement fast route convergence, it becomes increasingly popular with carriers.

Currently, main FRR technologies include LFA, U-turn, Not-Via, TI-LFA, Remote-LFA, and MRT, among which IS-IS only supports LFA, TI-LFA, and Remote-LFA.

Related Concepts

LFA

LFA is an IP FRR technology that calculates the shortest path from the neighbor that can provide a backup link to the destination node based on the Shortest Path First (SPF) algorithm. Then, LFA calculates a loop-free backup link with the smallest cost based on the inequality:

Distance_opt (N, D) < Distance_opt (N, S) + Distance_opt (S, D), in which S, D, and N indicate the source node, destination node, and a node on the backup link, respectively, and Distance_opt (X, Y) indicates the shortest distance from node X to node Y.

P space

P space consists of the nodes through which the shortest path trees (SPTs) with the source node of a primary link as the root are reachable without passing through the primary link.

Extended P space

Extended P space consists of the nodes through which the SPTs with neighbors of a primary link's source node as the root are reachable without passing through the primary link.

Q space

Q space consists of the nodes through which the SPTs with the destination node of a primary link as the root are reachable without passing through the primary link.

PQ node

The nodes in both the extended P space and Q space are PQ nodes and are used as the destinations of protection tunnels in remote LFA.

Remote LFA

LFA FRR cannot be used to calculate backup links on some large-scale networks, especially on ring networks. Remote LFA FRR addresses this problem by calculating a PQ node and establishing a tunnel between the source node and the PQ node as a backup path. If the primary link fails, traffic can be automatically switched to the backup path, which improves network reliability.

When calculating an RLFA FRR backup path, a Huawei device calculates the extended P space by default.

TI-LFA

In some LFA FRR and RLFA scenarios, the extended P space and Q space neither intersect nor have direct neighbors. Consequently, no backup path can be computed, failing to meet reliability requirements. TI-LFA solves this problem by computing the extended P space, Q space, and post-convergence SPT based on the protected path, computing a scenario-specific repair list, and establishing an SR tunnel from the source node to a P node and then to a Q node to offer alternate next hop protection. If the protected link fails, traffic is automatically switched to the backup path, improving network reliability.

When computing a TI-LFA FRR backup path, Huawei devices compute the extended P space by default.

For more information about TI-LFA, see TI-LFA FRR.

IS-IS LFA Auto FRR

IS-IS Remote LFA Auto FRR

Similar to IS-IS LFA Auto FRR, Remote LFA is also classified as link protection or node-and-link protection. The following example shows how Remote LFA works to protect against link failures:

In Figure 10-161, traffic flows through PE1 -> P1 -> P2 -> PE2. To prevent traffic loss caused by a link fault between P1 and P2, Remote LFA calculates a PQ node (P4) and establishes an LDP tunnel between P1 and P4. If P1 detects a failure on the link between P1 and P2, P1 encapsulates packets into MPLS packets and forwards the MPLS packets to P4. After receiving the packets, P4 removes the MPLS label from them, searches its IP routing table for a next hop, and forwards the packets to the next hop. Finally, the packets reach their destination (PE2). This implements fast path switching and avoids traffic loss.

Figure 10-161 Networking for Remote LFA

IPv6 IS-IS Remote LFA Auto FRR protects IPv6 traffic and uses IPv4 LDP LSPs. The principle of IPv6 IS-IS Remote LFA Auto FRR is similar to that of IPv4 IS-IS Remote LFA Auto FRR.

IS-IS FRR in the Scenario Where Multiple Nodes Advertise the Same Route

IS-IS LFA FRR uses the SPF algorithm to calculate the shortest path to the destination node, with each neighbor that provides a backup link as the root node. The backup next hop is node-based, which applies to single-node routing scenarios, that is, scenarios where a route is received from only one node. With the diversification of networks, multi-node routing scenarios appear, where multiple nodes advertise the same route. Such scenarios do not meet single-node LFA conditions. As a result, the backup next hop cannot be calculated. IS-IS FRR for multi-node routing scenarios can address this problem by using a routing source to protect the primary routing source and improve network reliability.

Figure 10-162 IS-IS FRR in the scenario where multiple nodes advertise the same route

In Figure 10-162(a), the cost of the link between Device A and Device B is 5, whereas the cost of the link between Device A and Device C is 10. Both Device B and Device C advertise the route 10.1.1.0/24. IS-IS FRR is enabled on Device A. However, Device A cannot calculate the backup next hop of the route 10.1.1.0/24 because the LFA conditions in the scenario where each route is received from a single node cannot be met. To address this issue, IS-IS FRR for the scenario where multiple nodes advertise the same route can be used.

In Figure 10-162(b), a virtual node is simulated between Device B and Device C and is connected to Device B and Device C. The cost of the link from Device B or Device C to the virtual node is 0, whereas the cost of the link from the virtual node to Device B or Device C is the maximum value. After the virtual node advertises the route 10.1.1.0/24, Device A can use the LFA algorithm to calculate the backup next hop of the virtual node because the scenario where multiple nodes advertise the same route has been converted to the scenario where the route is received from only one node. Then the route 10.1.1.0/24 inherits the backup next hop from the virtual node. In this example, the primary link to the virtual node is the one from Device A to Device B, and the backup link is the one from Device A to Device C.

IS-IS ECMP FRR

Equal cost multi path (ECMP) evenly balances traffic over multiple equal-cost paths to the same destination.

If the ECMP FRR function is not supported in ECMP scenarios, no backup next hop can be calculated for primary links.

IS-IS ECMP FRR is enabled by default, and a backup next hop is calculated separately for each primary link, which enhances reliability in ECMP scenarios. With ECMP FRR, IS-IS pre-calculates backup paths for load balancing links based on the LSDBs on the entire network. The backup paths are stored in the forwarding table and are used for traffic protection in the case of link failures.

• In Figure 10-163, traffic is forwarded from Device A to Device D and is balanced among Link 1, Link 2, and Link 3. Backup paths of the three links are calculated based on ECMP FRR. For example, the backup paths of Link 1, Link 2, and Link 3 are Link 3, Link 3, and Link 2, respectively.

  • If the ECMP FRR function is not enabled in the load balancing scenario and Link 1 fails, traffic over Link 1 is randomly switched to Link 2 or Link 3, which affects service traffic management.
  • If the ECMP FRR function is enabled in the load balancing scenario and Link 1 fails, traffic over Link 1 is switched to Link 3 according to FRR route selection rules, which enhances service traffic management.
  Figure 10-163 Flexible selection of backup paths through IS-IS ECMP FRR
  

• In Figure 10-164, traffic is forwarded from Device A to Device D and is balanced between Link 1 and Link 2. Backup paths of the two links are calculated based on ECMP FRR. For example, the backup paths of Link 1 and Link 2 are both Link 3.

  • If the ECMP FRR function is not enabled in the load balancing scenario and Device B fails, Link 1 and Link 2 fail accordingly, leading to a traffic interruption.
  • If the ECMP FRR function is enabled in the load balancing scenario and Device B fails, Link 1 and Link 2 fail accordingly. However, traffic is switched to Link 3, which prevents the traffic interruption.
  Figure 10-164 Enhanced traffic protection through IS-IS ECMP FRR
  

IS-IS SRLG FRR

A shared risk link group (SRLG) is a set of links that share a common physical resource, such as an optical fiber. These links share the same risk level. If one of the links fails, all the other links in the SRLG may also fail.

On the network shown in Figure 10-165, traffic between Device A and Device B is balanced by Link 1 and Link 2.

IS-IS SRLG FRR prevents service interruptions in the scenario where links have the same risk of failure. Add Link1 and Link2 to the same SRLG group so that the device preferentially selects a link in a different SRLG group when calculating a backup path, reducing the possibility of network traffic interruption.

Figure 10-165 Networking for IS-IS SRLG FRR

Priority-based Selection of a Backup Path for IS-IS Auto FRR

When selecting a backup path for IS-IS Auto FRR, a node-protection solution is preferentially selected. However, in actual network operation, the solution of selecting a backup path for IS-IS Auto FRR may need to be changed due to factors such as interface data capabilities or link costs.

Figure 10-166 Configuring the priority-based selection of a backup path for IS-IS Auto FRR

Scenario 1

In Figure 10-166, if the primary path is Link 1 (DeviceS -> DeviceE -> DeviceD), the backup path can be Link 2 (DeviceS -> DeviceE -> DeviceD) or Link 3 (DeviceS -> DeviceN-> DeviceD). The cost of Link 1, Link 2, and Link 3 are 10, 20, and 100, respectively. By default, Link 3 is preferentially selected as the backup path. To change the solution of selecting a backup path to smallest-cost path first, run the tiebreaker lowest-cost preference preference [ level-1 | level-2 | level-1-2 ] command. After the command is run, Link 2 is preferentially selected as the backup path.

Scenario 2

In Figure 10-166, if traffic is forwarded from Device S to Device E, it is balanced between Link 1 and Link 2 between Device S and Device E. Device S and Device N are connected through Link 3. The cost of Link 1, Link 2 and Link 3 are 10, 10, and 15 respectively. When selecting backup paths for load balancing links, Link 1 and Link 2 select each other as the backup path. To change the solution of selecting a backup path to non-load balancing path first, run the tiebreaker non-ecmp preference preference [ level-1 | level-2 | level-1-2 ] command. After the command is run, Link 3 is preferentially selected as the backup path.

Scenario 3

In Figure 10-166, if traffic is forwarded from Device S to Device E, it is balanced between Link 1 and Link 2. Device S and Device N are connected through Link 3. The cost of Link 1, Link 2, and Link 3 are all 10. If IS-IS LFA Auto FRR is enabled, it implements protection for Link 1 and Link 2. That is, the two links back up each other. If Link 1 and Link 2 have the same risk of failure, you can run the tiebreaker srlg-disjoint preference preference [ level-1 | level-2 | level-1-2 ] command to set the solution of selecting a backup path to SRLG-disjoint path first. In this case, the device preferentially selects Link 3 as the backup path. Before using this solution, run the isis srlg srlg-value command to add the links having the same risk of failure to an SRLG.

Scenario 4

Figure 10-167 Selecting the link with the maximum cost as the backup path for IS-IS Auto FRR

On the network shown in Figure 10-167, traffic is forwarded from Device S to Device E. The cost of Link 1 and Link 2 are 10 and 30, respectively, and the isis peer hold-max-cost command is run for Link 1. Device S and Device N are connected through Link 3, and Device N and Device E are directly connected. The costs of Link 3 and the link between Device N and Device E are both 10. In normal cases, the traffic from Device S to Device E is forwarded over Link 1, and the backup path is Link 3 (node protection is preferred). If Link 1 fails, the new primary path from Device S to Device E becomes Link 3, and the new backup path becomes Link 2. If Link 1 recovers after the undo showdown command is run, Link 1 advertises the maximum cost. In this case, to allow Link 1 to be selected as the backup path, run the tiebreaker hold-max-cost preference preference [ level-1 | level-2 | level-1-2 ] command.

Background

As the Internet develops, more data, voice, and video information are exchanged over the Internet. New services, such as e-commerce, online conferencing and auctions, video on demand, and distance learning, emerge gradually. The new services have high requirements for network security. Carriers need to prevent data packets from being illegally obtained or modified by attackers or unauthorized users. IS-IS authentication applies to the area or interface where packets need to be protected. Using IS-IS authentication enhances system security and helps carriers provide safe network services.

Related Concepts

Authentication Classification

Based on packet types, the authentication is classified as follows:

• Interface authentication: is configured in the interface view to authenticate Level-1 and Level-2 IS-to-IS Hello PDUs (IIHs).

• Area authentication: is configured in the IS-IS process view to authenticate Level-1 CSNPs, PSNPs, and LSPs.

• Routing domain authentication: is configured in the IS-IS process view to authenticate Level-2 CSNPS, PSNPs, and LSPs.

Based on the authentication modes of packets, the authentication is classified into the following types:

• Simple authentication: The authenticated party directly adds the configured password to packets for authentication. This authentication mode provides the lowest password security.

• MD5 authentication: uses the MD5 algorithm to encrypt a password before adding the password to the packet, which improves password security. For the sake of security, using the HMAC-SHA256 algorithm rather than the MD5 algorithm is recommended.

• Keychain authentication: further improves network security with a configurable key chain that changes with time.

• HMAC-SHA256 authentication: uses the HMAC-SHA256 algorithm to encrypt a password before adding the password to the packet, which improves password security.

Implementation

IS-IS authentication encrypts IS-IS packets by adding the authentication field to packets to ensure network security. After receiving IS-IS packets from a remote router, a local router discards the packets if the authentication passwords in the packets are different from the locally configured one. This mechanism protects the local router.

IS-IS provides a type-length-value (TLV) to carry authentication information. The TLV components are as follows:

• Type: indicates the type of a packet, which is 1 byte. The value defined by ISO is 10, whereas the value defined by IP is 133.

• Length: indicates the length of the authentication TLV, which is 1 byte.

• Value: indicates the authentication information, including authentication type and authenticated password, which ranges from 1 to 254 bytes. The authentication type is 1 byte:

  • 0: reserved
  • 1: simple authentication
  • 3: general authentication, and only HMAC-SHA256 authentication currently
  • 54: MD5 authentication
  • 255: private authentication

Interface Authentication

Authentication passwords for IIHs are saved on interfaces. The interfaces send authentication packets with the authentication TLV. Interconnected router interfaces must be configured with the same password.

Area Authentication

Every router in an IS-IS area must use the same authentication mode and have the same key chain.

Routing Domain Authentication

Every Level-2 or Level-1-2 router in an IS-IS area must use the same authentication mode and have the same key chain.

For area authentication and routing domain authentication, you can set a router to authenticate SNPs and LSPs separately in the following ways:

• A router sends LSPs and SNPs that carry the authentication TLV and verifies the authentication information of the LSPs and SNPs it receives.

• A router sends LSPs that carry the authentication TLV and verifies the authentication information of the LSPs it receives. The router sends SNPs that carry the authentication TLV and does not verify the authentication information of the SNPs it receives.

• A router sends LSPs that carry the authentication TLV and verifies the authentication information of the LSPs it receives. The router sends SNPs without the authentication TLV and does not verify the authentication information of the SNPs it receives.

• A router sends LSPs and SNPs that carry the authentication TLV but does not verify the authentication information of the LSPs and SNPs it receives.

Context

If network-wide IS-IS LSP deletion causes network instability, source tracing must be implemented as soon as possible to locate and isolate the fault source. However, IS-IS itself does not support source tracing. A conventional solution is to isolate nodes one by one until the fault source is located, but the process is complex and time-consuming and may compromise network services. To address this problem, enable IS-IS purge source tracing.

IS-IS purge source tracing is a Huawei proprietary protocol.

Related Concepts

• PS-PDU: packets that carry information about the node that floods IS-IS purge LSPs.

• CAP-PDU: packets used to negotiate the IS-IS purge source tracing capability between IS-IS neighbors.

• IS-IS purge source tracing port: UDP port number used to send and receive IS-IS purge source tracing packets. This UDP port number is configurable.

Fundamentals

IS-IS purge LSPs do not carry source information. If a device fails on the network, a large number of purge LSPs are flooded. Without a source tracing mechanism, nodes need to be isolated one by one until the faulty node is located, which is labor-intensive and time-consuming. IS-IS purge LSPs will trigger route flapping on the network, or even routes become unavailable. In this case, the device that floods the purge LSPs must be located and isolated immediately.

A solution that can meet the following requirements is required:

• 1. Information about the source that flooded the purge LSPs can be obtained when network routes are unreachable.

• 2. The method used to obtain source information must apply to all devices on the network and support incremental deployment, without compromising routing capabilities.

For requirement 1, IS-IS purge source tracing uses UDP to send and receive source tracing packets. These packets carry IS-IS LSP information purged by the faulty device and are flooded hop by hop along the IS-IS neighbor topology. After IS-IS purge source tracing packets are flooded, you can log in to any device that supports IS-IS purge source tracing to view information about the device that flooded the purge LSPs. This helps you quickly locate and isolate the faulty node.

For requirement 2, IS-IS purge source tracing forwards packets along UDP channels that are independent of the channels used to transmit IS-IS packets. In addition, source tracing does not affect the devices with the related UDP port disabled.

Capability Negotiation

Source tracing packets are transmitted over UDP. Devices listen for the UDP port and use it to send and receive source tracing packets. If a source tracing-capable device sends source tracing packets to a device that is source tracing-incapable, the former may be incorrectly identified as an attacker. Therefore, the source tracing capability needs to be negotiated between devices so that source tracing packets are exchanged between only source tracing-capable devices. In addition, source tracing capability negotiation is also required to enable a source tracing-capable device to send source tracing information on behalf of a source tracing-incapable device.

Source tracing capability negotiation depends on IS-IS neighbor relationships. Specifically, after an IS-IS neighbor relationship is established, the local device initiates source tracing capability negotiation based on the IP address of the neighbor.

PS-PDU Generation

If a fault source purges an LSP, it generates and floods a PS-PDU to all its source tracing neighbors.

If a device receives a purge LSP from a source tracing-incapable neighbor, the device generates and floods a PS-PDU to all its neighbors. If a device receives the same purge LSP (with the same LSP ID and sequence number) from more than one source tracing-incapable neighbor, the device generates only one PS-PDU.

PS-PDU flooding is similar to IS-IS LSP flooding.

Security Concern

A UDP port is used to send and receive source tracing packets. Therefore, the security of the port must be taken into consideration.

The source tracing protocol inevitably increases packet receiving and sending workload and intensifies bandwidth pressure. To minimize its impact on other protocols, the number of source tracing packets must be controlled.

• Authentication

  Source tracing is embedded in the IGP, inherits existing configuration parameters of the IGP, and uses authentication parameters of the IGP to authenticate packets.

• GTSM

  GTSM is a security mechanism that checks whether the time to live (TTL) value in each received IP packet header is within a pre-defined range.

  Source tracing packets can only be flooded as far as one hop. Therefore, GTSM can be used to check such packets by default. When a device sends a packet, it sets the TTL of the packet to 255. If the TTL is not 254 when the packet is received, the packet will be discarded.

• CPU-CAR

  The NP module on interface boards can check the packets to be sent to the CPU for processing and prevent the main control board from being overloaded by a large number of packets that are sent to the CPU.

  The source tracing protocol needs to apply for an independent CAR channel and has small CAR values configured.

Typical Scenarios

Scenario where all nodes support source tracing

Assume that all nodes on the network support source tracing and DeviceA is the fault source. In this scenario, the fault source can be accurately located. Figure 10-168 shows the networking.

Figure 10-168 Scenario where all nodes support source tracing

All nodes on the network support source tracing and DeviceA is the fault source.

When DeviceA purges an IGP packet, it floods a source tracing packet that carries DeviceA information and brief information about the IGP packet. Then the source tracing packet is flooded on the network hop by hop. After the fault occurs, maintenance personnel can log in to any node on the network to locate DeviceA, which keeps sending purge LSPs, and isolate DeviceA from the network.

Scenario where source tracing-incapable nodes are not isolated from source tracing-capable nodes

All nodes on the network except DeviceC support source tracing, and DeviceA is the faulty source. In this scenario, PS-PDUs can be flooded on the entire network, and the fault source can be accurately located. Figure 10-169 shows the networking.

Figure 10-169 Scenario where source tracing-incapable nodes are not isolated from source tracing-capable nodes

When DeviceA purges an IGP packet, it floods a source tracing packet that carries DeviceA information and brief information about the IGP packet. Then the source tracing packet is flooded on the network hop by hop. When DeviceB and DeviceE negotiate the source tracing capability with DeviceC, they find that DeviceC does not support source tracing. After DeviceB receives the PS-PDU from DeviceA, DeviceB sends the packet to DeviceD, but not to DeviceC. After receiving the purge LSP from DeviceC, DeviceE finds that DeviceC does not support source tracing and then generates a PS-PDU which carries information about the advertisement source (DeviceE), purge source (DeviceC), and the purged LSP, and floods the PS-PDU on the network.

After the fault occurs, maintenance personnel can log in to any node on the network except DeviceC to locate the faulty node. Two possible faulty nodes can be located in this case: DeviceA and DeviceC, and they both sends the same purge LSP. In this case, DeviceA takes precedence over DeviceC when the maintenance personnel determine the most probable fault source. After DeviceA is isolated, the network recovers, ruling out the possibility that DeviceC is the fault source.

Scenario where source tracing-incapable nodes are isolated from source tracing-capable nodes

Assume that all devices except DeviceC and DeviceD support source tracing and DeviceA is the fault source. In this scenario, PS-PDUs cannot be flooded on the entire network. The fault source locating is complicated. Figure 10-170 shows the networking.

Figure 10-170 Scenario where source tracing-incapable nodes are isolated from source tracing-capable nodes

When DeviceA purges an IS-IS LSP, it floods a PS-PDU that carries node A information and brief information about the LSP. However, the PS-PDU sent by DeviceA can only reach DeviceB because DeviceC and DeviceD do not support IS-IS purge source tracing.

During source tracing capability negotiation, DeviceE and DeviceF find that DeviceC and DeviceD do not support source tracing, respectively. After receiving the purge LSP from DeviceC, DeviceE generates and floods a PS-PDU on behalf of DeviceC. Similarly, after receiving the purge LSP from DeviceD, DeviceF generates and floods a PS-PDU on behalf of DeviceD.

After the fault occurs, maintenance personnel can locate the fault source (DeviceA) directly if they log in to DeviceA or DeviceB. After DeviceA is isolated, the network recovers. However, if the personnel log in to DeviceE, DeviceF, DeviceG, or DeviceH, they will find that DeviceE claims DeviceC to be the fault source and DeviceF claims DeviceD to be the fault source. If the personnel then log in to DeviceC or DeviceD, they will find that the purge LSP was sent by DeviceB, and was not generated by DeviceC or DeviceD. If the personnel then log in to DeviceB, they will determine that DeviceA is the fault source. After DeviceA is isolated, the network recovers.

Context

Deploying multiple topologies for different services on a physical network can address these problems. IS-IS MT transmits MT information through new TLVs in IS-IS packets. Users can deploy multiple logical topologies based on IP protocols or service types supported by links so that SPF calculations are performed independently in different topologies, which improves network usage.

If an IPv4 or IPv6 BFD session is Down in a topology on a network enabled with MT, neighbors of the IPv4 or IPv6 address family will be affected.

Related Concepts

IS-IS MT allows multiple route selection subsets to be deployed on a versatile network infrastructure and divides a physical network into multiple logical topologies, where each topology performs its own SPF calculations.

IS-IS MT, an extension of IS-IS, allows multiple topologies to be applied to IS-IS. IS-IS MT complies with standard protocols and transmits multi-topology information using new TLVs in IS-IS packets. Users can deploy multiple logical topologies on a physical network. Each topology performs its own SPF calculations and maintains its own routing table. Traffic of different services, including the traffic transmitted in different IP topologies, has its own optimal forwarding path.

The MT ID configured on an interface identifies the topology bound to the interface. One or more MT IDs can be configured on a single interface.

Reverse path forwarding (RPF) check: After receiving a packet, a device searches its unicast routing table, MBGP routing table, MIGP routing table, and multicast static routing table based on the packet source and selects an optimal route from these routing tables as the RPF route. If the interface that the packet arrives at is the same as the RPF interface, the packet passes the RPF check and is forwarded. Otherwise, the RPF check fails and traffic is interrupted.

Implementation

IS-IS MT uses MT IDs to identify different topologies. Each Hello packet or LSP sent by a router carries one or more MT TLVs of the topologies to which the source interface belongs. If the router receives from a neighbor a Hello packet or LSP that carries only some of the local MT TLVs, the router assumes that the neighbor belongs to only the default IPv4 topology. On a point-to-point (P2P) link, an adjacency cannot be established between two neighbors that share no common MT ID. On broadcast links, adjacencies can still be established between neighbors even if they do not share the same MT ID.

Figure 10-171 shows the MT TLV format.

Figure 10-171 MT TLV format

Background

On a network where multicast and a unidirectional TE tunnel are deployed, if the TE tunnel is configured with IGP Shortcut, IS-IS uses an MPLS TE tunnel that is up to perform SPF calculation. In this case, the outbound interface of the route calculated by IS-IS may be a TE tunnel interface rather than a physical interface. As a result, the routers spanned by the TE tunnel cannot detect multicast packets and may discard multicast data packets, affecting network reliability. Figure 10-174 shows the networking.

Figure 10-174 Conflict between multicast and a unidirectional TE tunnel

Client and Server exchange multicast packets as follows:

1. Client sends a Report message to DeviceA, requesting to join a multicast group. Upon receipt, DeviceA sends a Join message to DeviceB.

2. When the Join message reaches DeviceB, DeviceB selects TE-Tunnel1/0/0 as the Reverse Path Forwarding (RPF) interface and forwards the message to DeviceC through Interface 2 based on an MPLS label.

3. Because the Join message is forwarded based on an MPLS label, DeviceC does not create a multicast forwarding entry. As the penultimate hop of the MPLS forwarding, DeviceC removes the MPLS label and forwards the Join message to DeviceD through Interface2.

4. After DeviceD receives the Join message, it generates a multicast forwarding entry in which the upstream and downstream interfaces are Interface1 and Interface2, respectively. DeviceD then sends the Join message to DeviceE. Then the shortest path tree is established.

5. When DeviceD receives traffic from the multicast source, DeviceD sends traffic to DeviceC. Because DeviceC has not created a forwarding entry for the traffic, the traffic is discarded. As a result, multicast services are interrupted.

IS-IS local multicast topology (MT) can address this problem.

Related Concepts

IS-IS local MT is a mechanism that enables the routing management (RM) module to create a separate multicast topology on the local device so that protocol packets exchanged between devices are not erroneously discarded. When the outbound interface of the route calculated by IS-IS is an IGP Shortcut-enabled TE tunnel interface, IS-IS local MT calculates a physical outbound interface for the route. This mechanism resolves the conflict between multicast and a TE tunnel.

The TE tunnel described in this section is IGP Shortcut-enabled.

Implementation

Figure 10-175 Local MT networking

Usage Scenario

IS-IS local MT prevents multicast services from being interrupted on networks, which allows multicasting and has an IGP Shortcut-enabled TE tunnel.

Benefits

Local MT resolves the conflict between multicast and a TE tunnel and improves multicast service reliability.

IS-IS PDU Formats

Nine types of IS-IS protocol data units (PDUs) are available for processing control information. Each PDU is identified by a 5-digit type code. IS-IS has three major types of PDUs: Hello PDUs, Link State PDUs (LSPs), and Sequence Number PDUs (SNPs). Table 10-73 shows the mapping between PDUs and type values.

The first eight bytes in all IS-IS PDUs are public. Figure 10-176 shows the IS-IS PDU format.

Figure 10-176 IS-IS PDU format

Hello Packet Format

LSP Format

LSPs are used to exchange link-state information. There are two types of LSPs: Level-1 and Level-2. Level-1 IS-IS transmits Level-1 LSPs. Level-2 IS-IS transmits Level-2 LSPs. Level-1-2 IS-IS can transmit both Level-1 and Level-2 LSPs.

Level-1 and Level-2 LSPs have the same format, as shown in Figure 10-179.

The main fields are as follows:

• ATT: Attached bit

  ATT is generated by a Level-1-2 router to identify whether the originating router is connected to other areas. When a Level-1 router receives a Level-1 LSP with ATT as 1 from a Level-1-2 router, the Level-1 router generates a default route destined for the Level-1-2 router so that data can be transmitted to other areas.

  Although ATT is defined in both the Level-1 LSP and Level-2 LSP, it is set only in the Level-1 LSP only by the Level-1-2 router.

• OL: LSDB overload

  LSPs with the overload bit are still flooded on networks, but the LSPs are not used when routes that pass through a device configured with the overload bit are calculated. That is, after a device is configured with the overload bit, other devices ignore the device when performing the SPF calculation except for the direct routes of the device.

• IS Type: type of the IS-IS generating the LSP

  IS Type is used to specify whether the IS-IS type is Level-1 or Level-2 IS-IS. The value 01 indicates Level-1; the value 11 indicates Level-2.

SNP Format

Related Concepts

Redistribute ID

IS-IS uses a system ID as a redistribution identifier, OSPF and OSPFv3 use a router ID + process ID as a redistribution identifier, and BGP uses a VrfID + random number as a redistribution identifier. For ease of understanding, the redistribution identifiers of different protocols are all called Redistribute IDs. When routes are distributed, the extended TLVs carried in the routes contain Redistribute IDs.

Redistribute List

A Redistribute list may consist of multiple Redistribute IDs. Each Redistribute list of BGP contains a maximum of four Redistribute IDs, and each Redistribute list of any other routing protocol contains a maximum of two Redistribute IDs. When the number of Redistribute IDs exceeds the corresponding limit, the old ones are discarded according to the sequence in which Redistribute IDs are added.

Cause (IS-IS Inter-Process Mutual Route Import)

On the network shown in Figure 10-182, DeviceA, DeviceB, and DeviceC run IS-IS process 1, DeviceF and DeviceG run IS-IS process 2, and DeviceD and DeviceE run both processes. DeviceD and DeviceE are configured to import routes between IS-IS processes 1 and 2. The routes distributed by IS-IS process 1 are re-distributed back to IS-IS process 1 through IS-IS process 2. As the costs of the newly distributed routes are smaller, they are preferentially selected, resulting in routing loops.

Figure 10-182 Typical network diagram of IS-IS inter-process mutual route import

Take DeviceA distributing route 10.0.0.1/32 as an example. A stable routing loop is formed through the following process:

Phase 1

On the network shown in Figure 10-183, IS-IS process 1 on DeviceA imports the static route 10.0.0.1, generates an LSP carrying the prefix of this route and floods the LSP in IS-IS process 1. After receiving the LSP, IS-IS process 1 on DeviceD and IS-IS process 1 on DeviceE each calculate a route to 10.0.0.1, with the outbound interface being interface1 on DeviceD and interface1 on DeviceE, respectively, and the cost being 110. At this point, the routes to 10.0.0.1 in IS-IS process 1 in the routing tables of DeviceD and DeviceE are active.

Figure 10-183 Phase 1

Phase 2

In Figure 10-184, DeviceD and DeviceE are configured to import routes from IS-IS process 1 to IS-IS process 2. Either no route-policy is configured for the import or the configured route-policy is improper. DeviceE is used as an example. In phase 1, the route to 10.0.0.1 in IS-IS process 1 in the routing table of DeviceE is active. In this case, IS-IS process 2 imports this route from IS-IS process 1, generates an LSP carrying the prefix of this route, and floods the LSP in IS-IS process 2. After receiving the LSP, IS-IS process 2 on DeviceD calculates a route to 10.0.0.1, with the cost being 10, which is smaller than that (110) of the route calculated by IS-IS process 1. As a result, the active route to 10.0.0.1 in the routing table of DeviceD is switched from the one calculated by IS-IS process 1 to the one calculated by IS-IS process 2, and the outbound interface is sub-interface 2.1.

Figure 10-184 Phase 2

Phase 3

In Figure 10-185, after the route to 10.0.0.1 in IS-IS process 2 on DeviceD becomes active, IS-IS process 1 imports this route from IS-IS process 2, generates an LSP carrying the prefix of this route, and floods the LSP in IS-IS process 1. After receiving the LSP, IS-IS process 1 on DeviceE recalculates the route to 10.0.0.1, with the cost being 10, which is smaller than that (110) of the previously calculated route. As a result, the route to 10.0.0.1 in IS-IS process 1 in the routing table of DeviceE is switched to the route (with the smaller cost) advertised by DeviceD, and the outbound interface is interface 2.

Figure 10-185 Phase 3

Phase 4

After the active route to 10.0.0.1 on DeviceE is updated, IS-IS process 2 still imports the route from IS-IS process 1 as the route remains active, and continues to advertise/update an LSP.

As a result, a stable routing loop is formed. Assuming that traffic is injected from DeviceF, Figure 10-186 shows the traffic flow when the routing loop occurs.

Figure 10-186 Traffic flow when a routing loop occurs

Implementation (IS-IS Inter-Process Mutual Route Import)

Routing loop detection for IS-IS inter-process mutual route import can resolve the routing loop in the preceding scenario.

When distributing a TLV (with the type value of 135 or 235) for an imported route, IS-IS also uses a sub-TLV (with the type value of 10) of the TLV (with the type value of 135 or 235) to distribute to other devices the Redistribute ID of the device that re-distributes the imported route. If the route is re-distributed by multiple devices, a maximum of two Redistribute IDs of these devices are distributed through the sub-TLV (with the type value of 10) of the TLV (with the type value of 135 or 235). After receiving the sub-TLV, a route calculation device saves the Redistribute IDs of the re-distribution devices along with the route. When the route is imported by another process, the device checks whether the re-distribution information of the route contains the Redistribute ID of the local process. If the information contains the Redistribute ID of the local process, the device determines that a routing loop occurs and distributes a large route cost in the TLV (with the type value of 135 or 235) for the imported route. This prevents other devices from selecting the route distributed by the local device, thereby resolving the routing loop.

Figure 10-187 Typical networking of route import to IS-IS

The following uses the networking shown in Figure 10-187 as an example to describe how a routing loop is detected and resolved.

1. DeviceD learns the route distributed by DeviceB through IS-IS process 1 and imports the route from IS-IS process 1 to IS-IS process 2. When distributing the imported route, IS-IS process 2 on DeviceD distributes the Redistribute ID of IS-IS process 2 through the sub-TLV (with the type value of 10) of the TLV (with the type value of 135 or 235). Similarly, IS-IS process 2 on DeviceE learns the route distributed by DeviceD and saves the Redistribute ID distributed by IS-IS process 2 on DeviceD to the routing table during route calculation.
2. When re-distributing the route imported from IS-IS process 2, IS-IS process 1 on DeviceE also distributes the Redistribute ID of IS-IS process 1 on DeviceE through the sub-TLV (with the type value of 10) of the TLV (with the type value of 135 or 235).
3. After learning the route from DeviceE, IS-IS process 1 on DeviceD saves the Redistribute ID distributed by IS-IS process 1 on DeviceE in the routing table during route calculation.
4. When importing the route from IS-IS process 1 to IS-IS process 2, DeviceD finds that the re-distribution information of the route contains its own Redistribute ID, considers that a routing loop is detected, and reports an alarm. IS-IS process 2 on DeviceD distributes a large cost when distributing the imported route so that other devices preferentially select other paths after learning the route. This prevents routing loops.

Cause (Mutual Route Import Between IS-IS and OSPF)

In Figure 10-188, DeviceA, DeviceB, and DeviceC run IS-IS process 1; DeviceD, DeviceE, DeviceF, and DeviceG run IS-IS process 2; in addition, DeviceB, DeviceC, DeviceD, and DeviceE run an OSPF process. DeviceB imports routes of IS-IS process 1 to OSPF, DeviceD imports OSPF routes to IS-IS process 2, and DeviceE imports routes of IS-IS process 2 to OSPF. Improper route import configurations may cause routing loops. For example, if DeviceD preferentially selects routes learned from DeviceE, a routing loop occurs between DeviceD and DeviceE. The following part describes how the routing loop is detected and resolved. Routing loop detection for routes imported to IS-IS and routing loop detection for routes imported to OSPF are enabled by default and do not need to be manually configured.

Figure 10-188 Typical networking of route import from OSPF to IS-IS

Implementation (Mutual Route Import Between IS-IS and OSPF)

The following uses the networking shown in Figure 10-188 as an example to describe how a routing loop is detected and resolved.

1. DeviceA distributes its locally originated route 10.1.1.1/24 to DeviceB through IS-IS process 1. DeviceB imports the route from IS-IS process 1 to OSPF and adds the Redistribute ID of OSPF on DeviceB to the route when distributing the route through OSPF.
2. After learning the Redistribute list carried in the route advertised by DeviceB, OSPF on DeviceD saves the Redistribute ID of OSPF on DeviceB to the routing table during route calculation. After DeviceD imports this route from OSPF to IS-IS process 2, DeviceD redistributes the route through IS-IS process 2. In the redistributed route, the extended TLV contains the Redistribute ID of IS-IS process 2 on DeviceD and the Redistribute ID of OSPF on DeviceB. After learning the Redistribute list carried in the route advertised by DeviceD, IS-IS process 2 on DeviceE saves the Redistribute list in the routing table during route calculation.
3. After DeviceE imports this route from IS-IS process 2 to OSPF, DeviceE redistributes the route through OSPF. The redistributed route carries the Redistribute ID of OSPF on DeviceE and the Redistribute ID of IS-IS process 2 on DeviceD. The Redistribute ID of OSPF on DeviceB has been discarded from the route. DeviceD learns the Redistribute list carried in the route distributed by DeviceE and saves the Redistribute list in the routing table. When importing the OSPF route to IS-IS process 2, DeviceD finds that the Redistribute list of the route contains its own Redistribute ID, considers that a routing loop is detected, and reports an alarm. To resolve the routing loop, IS-IS process 2 on DeviceD distributes a large route cost when redistributing the route. However, because IS-IS has a higher preference than OSPF ASE, DeviceE still prefers the route learned from DeviceD through IS-IS process 2. As a result, the routing loop is not eliminated. The route received by DeviceE carries the Redistribute ID of OSPF on DeviceE and the Redistribute ID of IS-IS process 2 on DeviceD.
4. When importing the route from IS-IS process 2 to OSPF, DeviceE finds that the Redistribution information of the route contains its own Redistribute ID, considers that a routing loop is detected, and reports an alarm. To resolve the routing loop, OSPF on DeviceE distributes a large route cost when redistributing the route. In this case, DeviceD prefers the route distributed by DeviceB. As such, the routing loop is resolved.

   When detecting a routing loop upon route import between processes of the same protocol, the device increases the cost of the corresponding route. As the cost of the delivered route increases, the optimal route in the IP routing table changes. In this way, the routing loop is eliminated.

   In the case of inter-protocol route import, if a routing protocol with a higher preference detects a routing loop, although this protocol increases the cost of the corresponding route, the cost increase will not render the route inactive. As a result, the routing loop cannot be eliminated. If the routing protocol with a lower preference increases the cost of the corresponding route, this route competes with the originally imported route during route selection. In this case, the routing loop can be eliminated.

Application Scenario

Figure 10-189 shows a typical intra-AS seamless MPLS network. If the IS-IS process deployed at the access layer differs from that deployed at the aggregation layer, IS-IS inter-process mutual route import is usually configured on AGGs so that routes can be leaked between the access and aggregation layers. As a result, a routing loop may occur between AGG1 and AGG2. If routing loop detection for IS-IS inter-process mutual route import is configured on AGG1 and AGG2, routing loops can be quickly detected and eliminated.

Figure 10-189 Routing protocol deployment on the intra-AS seamless MPLS network