Some strategies consist of hold down timers; poison reverse, split horizon, etc
However with all of these techniques human error can still prevail. as the previous post said the most common routing loop situations is when two way redistribution is implemented. Careful consideration is needed if two-way redistribution is used because of the risks it poses (routing loops). The correct way is to do one-way redistribution and default route out.
OSPF is quite good when it comes to routing loops.
it quite quickly converges (all routers have the same info) compared to distance vector protocols and loops are quickly identified. however loops generally occour in redistribution The safe way to avoid loops in redistributionof is to only redistribute one way.Your network should be designed heiraticly so if any redistribution occours only redistribute one way(from lowest network up) and default route out for the lower network.
In general, redistribution, network melts, and bad configuration are the causes of permanent routing loops. Temporary routing loops happen in almost all networks.
I think it's something of a myth that routing loops persist longer in a distance vector protocol than a link state protocol--from experience, it seems to me temporary loops will persist in both about the same amount of time.
In a distance vector environment no loops will occur (using Cisco deployments of rip/igrp) due to hold downs and split horizon. The only time networks will not be reachable (that exists) will be when the networks are converging due to a new link or a link going down. Thats where the technique of flash updates and route poisoning are used to speed up convergence
However in Link-state protocols, loops are calculated locally on the router & eliminated (SPF alga, SPF Tree).
Depending on the size and topology the results can vary for time to convergence from protocol to protocol. EIGRP I find the most efficient protocol to converge because of the use of the DUEL algorithm that isolate the update to that specific area of the network (only routers that need to change routes will be affected)
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...