Routes of an OSPF process can be imported to another OSPF process or the process of another protocol (such as IS-IS or BGP) for redistribution. However, if a device that performs such a route import is incorrectly configured, routing loops may occur. Routing loop detection for routes imported to OSPF supports routing loop detection and elimination.
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 information carried in the routes contains Redistribute IDs.
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 protocols 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.
In Routing Loop Detection for Routes Imported to OSPF, DeviceA, DeviceB, and DeviceC run BGP; DeviceF and DeviceG run OSPF; DeviceD and DeviceE run both BGP and OSPF. DeviceD imports BGP routes to OSPF, and DeviceE imports OSPF routes to BGP. The routes distributed by BGP on DeviceE are redistributed back to BGP through OSPF on DeviceD. As the costs of the routes newly distributed by DeviceD are smaller, they are preferentially selected by BGP, resulting in routing loops.
Routing loop detection for the routes imported by OSPF from another protocol can eliminate the routing loops in the preceding scenario. When distributing a Type 5 AS-External-LSA for an imported route, OSPF also uses a Type 11 extended prefix Opaque LSA to distribute to other devices the Redistribute ID of the device that redistributes the imported route. If the route is redistributed by different protocols through multiple devices, the Redistribute IDs of these protocols on the devices are distributed through a Type 11 extended prefix Opaque LSA. When receiving the Type 11 extended prefix Opaque LSA, a route calculation device saves the Redistribute ID and route information of the route redistribution device. When another process of the route calculation device imports the route, the device checks whether a routing loop occurs based on the Redistribute list of the route. If the device determines that a routing loop occurs, it attaches a large route cost to the AS-External-LSA for the imported route.
Routing Loop Detection for Routes Imported to OSPF is used to describe the process of routing loop detection and elimination.
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.
Figure 2 shows a typical intra-AS seamless MPLS network. If the OSPF process deployed at the access layer differs from that deployed at the aggregation layer, OSPF 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 routes imported to OSPF is configured on ASG1 and ASG2, routing loops can be quickly detected and eliminated.