9.9 Mutual Redistribution

Special care must be taken when performing mutual redistribution at two or more points due to discrepancies between seed metrics and the actual metric of the redistributed routing protocol. In this diagram:

… you see that R1 prefers the link to R2 because of the better bandwidth or bandwidth-related metric, but will hit the 10Mbps bottleneck further upstream. On the return path, the same is true, and a routing loop may appear.

In the previous example, seed metrics should be altered to mitigate risk of sub-optimal routing; the path from R1 to R3 should probably be preferred.

In the below example…

… RIPv2 advertises a route that is redistributed into OSPF. However, the hop count metric in RIP is lost upon redistribution, and OSPF’s administrative distance of 110 is superior to RIPv2’s AD of 120. The route is propagated throughout the OSPF area, from R2 to R1 via R5 and vice versa. The sub-optimal routing will become a routing loop if the redistributed hop-count from OSPF to RIPv2 is a seed metric that is more preferable to what RIPv2 is advertising internally in its process.

In the previous example, modification of administrative distances should be considered to prevent the routing loop, or at the very least, seed metrics should be modified in a way to prevent routing loops.

Risks of two-way redistribution:

1. Sub-optimal routing, where only part of the total cost is considered in routing decisions, as end-to-end path selection is unavailable;
2. Appearance of routing loops if certain routes are lost

To prevent routing loops in multi-point redistribution scenarios, adhere to the following guidelines:

1. Insert only internal routes from routing protocol A to B and vice versa
2. Tag routes in redistribution points. Perform filtering when redistributing routes.
3. Propagate metrics between routing protocols properly (though this in of itself will not prevent routing loops)
4. Use default routes to avoid two way redistribution scenarios if possible