routing loop in route redistribution.

[prashantdwivedi]

Hi,

can any body explain me what is routing looping in route distribution.especillay when we redistribute route between RIP and OSPF.and how to  prvent it?

[Peter Paluch]

Hello,

Routing loops in redistribution are actually caused by the loss of original information about a reachable network including its original metric and topological presence. When redistributing, you are actually taking a knowledge about an existence of particular network from one protocol and you are injecting it into a different protocol but you are losing several details about the network in the process. As a result, a routing protocol may start trusting an incorrect information and ultimately form a loop.

Consider the picture I have attached. Let's have three routers, R1, R2 and R3. Assume that the RIP is run on links between R1/R2 and R1/R3. In addition, R2 and R3 run OSPF on their common link (you may assume that there are other routers attached to R2 and R3 which are not displayed at the exhibit but which speak only OSPF). Now consider the following sequence of steps:

1. R1 learns about a network X via RIP with the metric of 9
2. R1 forwards this network via RIP to R2 and R3 with the metric of 10. Both R2 and R3 will use R1 as the next hop towards network X.
   
3. R2 is configured for redistribution from RIP to OSPF. So, R2 redistributes the network X from RIP into OSPF and sends it to R3 with the metric of, say, 2000.
4. R3 now has two sources of information about the network X - RIP and OSPF. Because the OSPF uses administrative distance of 110, it is more trustworthy than RIP, and R3 replaces the RIP-learned network X in its routing table with the redistributed OSPF route, pointing back towards R2.
5. R3 is configured for redistribution from OSPF to RIP, and it therefore redistributes the network X from OSPF back to RIP with a metric of, say, 2.
6. R1 now learns about the network X from R3, and because the metric is smaller, it updates its routing table and starts pointing to R3 as the next  hop.
7. What we now have is a permanent routing loop: R1 points to R3, R3 to R2 and R2 back to R1.

This problem was actually caused because a route was taken from a routing protocol with a higher AD, put into protocol with a lower AD and then got reinjected into the original protocol with the higher AD. Here, a RIP-learned route was taken into OSPF on R2, and reinjected into RIP on R3. The R3 will not revert to using the RIP-learned route via R1 directly because the RIP is less trustworthy (because of its AD=120) than OSPF (AD=110).

The solution is to never readvertise a network back into the routing protocol from which it originally came from. This can be done by using route tagging, filtering, or modifying administrative distances.

You are welcome to ask furhter. This example was slightly artificial to show how the routing loop can be created. In real life, similar redistributions are configured and apparently do not exhibit routing loops but that is because of a generally fortunate timing of events in the network. There is still a possibility of a race condition but I don't want to get too complex right now.

Best regards,

Peter

[prashantdwivedi]

thanks Peter,,

well i have also read somewhere by reducing metric value which is hop count in case of RIP and COST in case of OSPF.we can prevent loop..

is that true?if yes then how?

Thanks a lot indeed!!!

[Jon Marshall]

Prashant

Please take a moment to read the following document -

https://supportforums.cisco.com/docs/DOC-8052

it's concerning using the rating system to mark questions as helpful and/or resolved. Using the rating system is a way of -

1) marking posts as helpful so others can easier find helpful content

2) showing appreciation for the help you receive as all people on these forums volunteer their time and expertise freely.

Many thanks

Jon

[Peter Paluch]

Hello,

well i have also read somewhere by reducing metric value which is hop 
count in case of RIP and COST in case of OSPF.we can prevent loop..

Reducing metric? I don't believe that reducing metric is the solution - actually, it was precisely the reduced metric of the networ X that created this routing loop. If you have a look on the same example you should be able to see that if the R3 redistributed all routes from OSPF to RIP with the seed metric of at least 10 then the routing loop for network X would not be created because R1 would not modify its routing table to mistakenly point back to R3.

The opposite would be more true - to increase the metric when redistributing netowrks in such a way that the route to the network X, originated in RIP and being redistributed back to RIP, is so costly that it does not make any sense to traverse the OSPF domain.

The problem is that various networks have various metrics and it can be very difficult to define a single metric for redistribution that is high enough to make all these double-redistributed routes appear as being too costly. Even if you locate such metric and configure it in the redistribution, you have to note it applies to all redistributed networks, disregarding their original metric. I can always come up with a network whose original internal metric is higher that the one you have configured in the redistribution, and the routing loop will come back.

Therefore, we are looking for a solution that guarantees loop-free operation under all circumstances and for all networks with both low and high cost, and the only reasonable solution is a dilligent filtering of routes when performing two-way redistribution.

Best regards,

Peter