Route redistribution and the loops it creates

Redistribution moves routes from one protocol into another. It is necessary during migrations and in multi-protocol networks, and it is the most reliable way to build a routing loop that takes a while to understand.

How the loop forms

Two routers both connect OSPF and EIGRP, and both redistribute in both directions. A route originating in OSPF is injected into EIGRP by router A. Router B learns it from EIGRP and injects it back into OSPF. Now OSPF has a route to its own prefix, learned externally, and depending on administrative distance it may prefer that copy over the original.

Traffic follows the wrong path, sometimes back where it came from. The network is stable, the protocols are behaving correctly, and the result is nonsense.

The controls

Route tags are the cleanest. Tag on the way out, refuse the tag on the way back in. Protocol-independent and self-documenting:

route-map OSPF-TO-EIGRP deny 10
 match tag 100
route-map OSPF-TO-EIGRP permit 20
 set tag 200

Prefix lists work when the set of routes is small and stable, and are clearer to read. Administrative distance can be adjusted so the native route always wins, but it is a blunt tool that surprises the next engineer.

Single point where possible

The simplest defence is to redistribute at one router only. You lose redundancy at that boundary, which may be unacceptable — but if it is acceptable, take it, because one redistribution point cannot form a loop.

Always set a metric

Redistributed routes have no natural metric in the receiving protocol. Some protocols discard routes with no metric, which is a silent failure that looks like redistribution not working at all.

Verify from the far end

After redistributing, check what the routes look like at the other side of the network, not at the boundary. The boundary always looks correct. The loop is visible two hops away, where a prefix appears as external when it should be internal.