Routing Loop Detection for Routes Imported to OSPFv3
Definition
OSPFv3 routes of one process can be re-distributed in another process through route import. If OSPFv3 routes are mutually imported between different processes on two devices, a routing loop may occur. In addition, routing loops may occur when OSPFv3 imports routes from BGP or IS-IS. IS-IS and BGP routes can be re-distributed in an OSPFv3 process after being imported. If OSPFv3 and another routing protocol import routes from each other between two devices, a routing loop may occur.
Related Concepts
Redistribute ID
OSPFv3 uses a router ID + process ID as a redistribution identifier. The redistribution identifiers of IS-IS and BGP are different from those of OSPFv3. To facilitate description, the redistribution identifiers of different protocols are all called Redistribute IDs.
Redistribute List
A Redistribute list consists of multiple Redistribute IDs.
Context
On the network shown in Figure 1, DeviceA, DeviceB, and DeviceC run OSPF process 1, DeviceF and DeviceG run OSPF process 2, and DeviceD and DeviceE run both processes. DeviceD and DeviceE are configured to import routes between OSPF processes 1 and 2. The routes distributed by OSPF process 1 are redistributed back to OSPF process 1 through OSPF process 2. As the costs of the newly distributed routes are smaller, they are preferentially selected, resulting in routing loops.
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 2, OSPF process 1 on DeviceA imports the static route 10.0.0.1 and floods a Type 5 AS-External-LSA in OSPF process 1. After receiving the LSA, OSPF process 1 on DeviceD and OSPF process 1 on DeviceE each calculate a route to 10.0.0.1, with the outbound interfaces being interface1 on DeviceD and interface1 on DeviceE, respectively, and the cost being 102. At this point, the routes to 10.0.0.1 in OSPF process 1 in the routing tables of DeviceD and DeviceE are active.
Phase 2
In Figure 3, OSPF process 2 on DeviceD and DeviceE is configured to import routes from OSPF process 1. Either no import route-policy is configured or the configured route-policy is improper. DeviceE is used as an example. In phase 1, the route to 10.0.0.1 in OSPF process 1 in the routing table of DeviceE is active. In this case, OSPF process 2 imports this route from OSPF process 1 and then floods a Type 5 AS-External-LSA in OSPF process 2. After receiving the LSA, OSPF process 2 on DeviceD calculates a route to 10.0.0.1, with the cost being 2, which is smaller than that (102) of the route calculated by OSPF 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 OSPF process 1 to the one calculated by OSPF process 2, and the outbound interface of the route is sub-interface2.1.
Phase 3
In Figure 4, after the route to 10.0.0.1 in OSPF process 2 on DeviceD becomes active, OSPF process 1 imports this route from OSPF process 2, and then generates and floods a Type 5 AS-External-LSA in OSPF process 1. After receiving the LSA, OSPF process 1 on DeviceE recalculates the route to 10.0.0.1, with the cost being 2, which is smaller than that (102) of the previously calculated route. As a result, the route to 10.0.0.1 in OSPF process 1 in the routing table of DeviceE is switched to the route (with the smaller cost) distributed by DeviceD, and the outbound interface is interface 2.
Phase 4
After the active route to 10.0.0.1 on DeviceE is updated, OSPF process 2 still imports the route from OSPF process 1 as the route remains active, and continues to advertise and update a Type 5 AS-External-LSA.
As a result, a stable routing loop is formed. Assuming that traffic is injected from DeviceF, Figure 5 shows the traffic flow when the routing loop occurs.
Implementation
Routing loop detection for OSPF inter-process mutual route import can resolve the routing loop 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 router ID and process ID of the device that redistributes the imported route. If the route is redistributed by multiple devices, the router IDs and process IDs of these devices are distributed through a Type 11 Opaque LSA. When receiving the Type 11 Opaque LSA, a route calculation device saves the router ID, process ID, and route information of the redistribution devices. When the route is imported by another process, the device checks whether the redistribution information of the route contains the router ID and process ID of the local process. If the information contains the router ID and process ID of the local process, the device determines that a routing loop occurs and distributes a large link cost in the AS-External-LSA for the imported route. This prevents other devices from selecting the route distributed by the local device, thereby resolving the routing loop.
The following uses the networking shown in Figure 6 as an example to describe how a routing loop is detected and resolved.
- After OSPF process 1 on DeviceD learns a route from DeviceB, OSPF process 2 imports the route from OSPF process 1. When distributing the imported route, OSPF process 2 on DeviceD distributes the router ID and process ID of OSPF process 2 through a Type 11 extended prefix Opaque LSA.
- Similarly, after learning a route from DeviceD, OSPF process 2 on DeviceE also saves the router ID and process ID distributed by OSPF process 2 on DeviceD in the routing table for route calculation.
- When redistributing the route imported from OSPF process 2, OSPF process 1 on DeviceE also distributes the router ID and process ID of OSPF process 1 on DeviceE through an Opaque LSA.
- After learning the route from DeviceE, OSPF process 1 on DeviceD saves the router ID and process ID distributed by OSPF process 1 on DeviceE in the routing table for route calculation.
- When OSPF process 2 on DeviceD imports the route from OSPF process 1, it detects that the redistribution information about the route contains its router ID and process ID. Therefore, it determines that a routing loop has occurred. Upon the routing loop detection, DeviceD reports an alarm to notify the network administrator. In addition, OSPF process 2 on DeviceD distributes a large link cost when distributing the imported route so that other devices preferentially select other paths after learning the route, thereby resolving the routing loop.
Usage Scenario
Figure 7 illustrates a typical seamless MPLS networking. 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. In this case, a routing loop may occur between AGG1 and AGG2, as the one that occurs between DeviceD and DeviceE in Figure 1. If routing loop detection for OSPF inter-process mutual route import is configured on AGG1 and AGG2, routing loops can be quickly detected and resolved.
