11-12-2010 12:17 AM - edited 03-06-2019 02:00 PM
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?
11-12-2010 02:09 AM
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:
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
11-12-2010 03:19 AM
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!!!
11-12-2010 03:32 AM
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
11-12-2010 03:39 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide