Redistribution

The following scenario shows two multi-protocol redistribution points in our topology: R1 pushing OSPF into RIP, and R3 pushing RIP into OSPF. Additionally, R9 distributes its own loopback into the RIP topology as part of an external route. Initially a loop will form preventing end to end reachability between R9 and R10 loopbacks, but through show commands, traceroute, and an understanding of protocol distance and metrics, we should be able to resolve any scenario where a routing loop forms via redistribution.

There can be numerous ways to solve such a scenario such as using route-maps with tagging, static routes, playing with seed metric, changing interface metric, changing route metrics and distance, or filtering the route altogether with an ACL or prefix-list.

This scenario solves the route loop issue by altering redistributed seed metric.

The topology:

• Each router in the topology has a loopback which is the router number, ex) R10 loopback of 10.10.10.10.
• Each Ethernet interface is 150.xx.xx.x where the first x of xx is the higher router number, ex) the connection between R9 and R10 is 150.97.97.0/24
• Both R1 and R3 loopback belong in the OSPF domain.
• R9 loopback is distributed into RIP as an external route with a seed metric of 6 (6 is arbitrary)
• R1 redistributes OSPF into RIP with default parameters
• R3 redistributes RIP into OSPF with default parameters

 

The Lowdown

With a simple ping test, the problem that is going to immediately arise here based on this configuration is that a routing loop will form. This might not be known right off the bat, and investigation into the routing issue would be required. However, a routing loop through redistribution for demonstration purposes was deliberately established so the fix for this can be implemented right away.

Since both R1 and R3 are involved in redistribution, R1 will learn RIP routes from R3. These RIP routes learned through OSPF are then redistributed back into RIP by R1.

How the route loop occurs: (it can help to draw such processes out by hand)

• R9 propagates 9.9.9.9 into the RIP domain with a seeded metric of 6 and a distance of 120
• R7 advertises this R3 and R6 and increments the metric to 7
• R6 shares this route to R1 with a metric of 8
• R3 on the other hand, redistributes this route into the OSPF domain with a distance of 110 and a default seed metric of 20
• R1 learns of this route through OSPF because of the lower AD, and inserts the OSPF route of 9.9.9.9 into its table.  The RIP learned route is tossed out because of the higher distance
• Because R1 is redistributing OSPF into RIP with a default seed metric of 1, it shares this route to R6 with the distance of 120 and the metric of 1.
• R6 learns of this redistributed route and shares it back to R7 with the metric of 2
• R7 again shares the route to R3 but with a metric of 3. The seeded route metric from R9 is thrown out because it is higher
• And effectively, we have a routing loop

The traceroute from R10 loopback to R9 loopback highlights the problem here: packets go from R10, to R3 on the switched interface (150.130.130.3), to R7, to R6, to R1, and then BACK to R3. With traceroute, the router that sends packets to a router which already received them is the problem router in the network.

The loop can be verified on the other routers involved in this process:

R1 is learning of this route through OSPF with a distance of 110 and a metric of 20.

Here, R6 relearns the route which it knew through R7 now through R1 with a metric of 1.

Given that the metric here for 9.9.9.9 was seeded with 1 from R1 vs. the seeded metric of 6 from R9, the 9.9.9.9 route is preferred through R6, and is learned from R6.

Lastly, the 9.9.9.9 is learned on R3 from R7 because the seeded metric by R1 is still lower than R9, route metric of 3 is shown here vs the 7 that would’ve been learned, and therefore the path with the lower metric is preferred. 

The Solution

The solution to fix this topology is to go to R1, our problem router, and redistribute OSPF routes into the RIP domain with an arbitrarily high seed metric.

In this case, a seed metric of 10 will suffice:

R1(config)#router rip
R1(config-router)#redistribute ospf 1 metric 10

Allowing RIP updates and routers to acknowledge the changes made, we can see the effects afterwards with an R10 traceroute:

Here, we can see R3 is still learning about 9.9.9.9 through R7, but with the proper metric to avoid the previous loop. Because R10 seeded the redistributed metric with 10, this will come around and reach R3 with a metric of 13, which is obviously higher than the metric of 7, the default seeded metric of 6 by R9.

R6 is learning about the 9.9.9.9 route from R7 here with a metric of 7 instead of R1 with a metric of 1, effectively avoiding the loop.

Lastly, R7 has inserted the 9.9.9.9 into its route table, the route learned from R9 with the seeded metric of 6, not the path through R6.

Loop has been avoided.

Reseeding the R1 redistributed OSPF routes into RIP with a metric of 10, which included the 9.9.9.9 route, made them less desirable than the R9 seeded metric of 6. A simple fix to what can otherwise be a tricky problem unless you know what to look for. AS mentioned, there can be numerous ways to eliminate the loop, but this solution dealt with seed metric.