Routing Loop Detection for Routes Imported to IS-IS

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.

Implementation

In Routing Loop Detection for Routes Imported to IS-IS, 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. 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 1 Typical networking of route import to IS-IS

The following uses route import from OSPF to IS-IS as an example to describe the process of routing loop detection and elimination:

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 eliminate the routing loop, IS-IS process 2 on DeviceD attaches a large cost to the route when redistributing it. However, because IS-IS has a higher preference than OSPF, 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, which eliminates the routing loop.
   

   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.

Usage Scenario

Figure 2 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 ASG1 and ASG2, routing loops can be quickly detected and eliminated.

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