Multi-Protocol Redistribution: The CCIE Scenarios That Break Networks

Redistribution between two routing protocols at a single point is easy. Redistribution between two routing protocols at two points is where networks go to die, and it is the reason redistribution has such a fearsome reputation in the CCIE lab.

The failure is never dramatic. Nothing goes down. Adjacencies stay up. Routes are present everywhere you look. It is just that traffic is now taking a path you did not design, through a protocol you did not intend, and one of your routers is quietly re-injecting a route back into the protocol it originally came from. This article builds that failure for real in a CML lab, shows the exact output, and then fixes it. For the fundamentals, see IP routing and the EIGRP guide.

The two mechanisms that cause every redistribution failure

Only two things go wrong, and almost every redistribution disaster is one or both of them:

The AD table is the whole story, and it is worth having on the wall:

Stare at those two bold numbers. An EIGRP external route has AD 170. An OSPF route - any OSPF route, including an external - has AD 110. Which means: a route that has been redistributed into EIGRP will lose to the same route arriving via OSPF. Every time. Even if the EIGRP path is a single hop and the OSPF path goes round the houses.

That asymmetry is not a bug. EIGRP deliberately distrusts redistributed routes, and OSPF does not distinguish. But put the two together at two boundary points and it becomes a trap.

The lab: a genuinely broken network

A dual-hub DMVPN running EIGRP AS 100. Both hubs also connect to an OSPF domain (router R5). HUB1 additionally peers eBGP with R6 in AS 65010, which owns 10.60.60.0/24.

Both hubs do mutual EIGRP ↔ OSPF redistribution. HUB1 also redistributes BGP into both. This is exactly the configuration a well-meaning engineer produces when told "make everything reachable from everything".

! On BOTH hubs
router eigrp DMVPN
 address-family ipv4 unicast autonomous-system 100
  topology base
   redistribute ospf 1 metric 100000 100 255 1 1500
!
router ospf 1
 redistribute eigrp 100 subnets

! On HUB1 additionally
router eigrp DMVPN
 address-family ipv4 unicast autonomous-system 100
  topology base
   redistribute bgp 65001 metric 100000 100 255 1 1500
router ospf 1
 redistribute bgp 65001 subnets

Nothing goes down. Everything is reachable. And it is badly broken.

The evidence

HUB2 is one EIGRP hop from HUB1 across the DMVPN. HUB1 is one hop from R6. So HUB2 should reach 10.60.60.0/24 in two hops, over the tunnel. Instead:

HUB2#show ip route 10.60.60.0
Routing entry for 10.60.60.0/24
  Known via "ospf 1", distance 110, metric 1
  Tag 65010, type extern 2, forward metric 20
  Redistributing via eigrp 100
  Advertised by eigrp 100 metric 100000 100 255 1 1500
  Last update from 10.25.0.2 on Ethernet0/1, 00:00:05 ago
  Routing Descriptor Blocks:
  * 10.25.0.2, from 1.1.1.1, via Ethernet0/1

Every line of that is a problem:

• Known via "ospf 1", distance 110 - HUB2 is using the OSPF copy. HUB1 redistributed the BGP route into EIGRP, where it became an EIGRP external (AD 170). HUB1 also redistributed it into OSPF, where R5 picked it up and passed it to HUB2 as an O E2 (AD 110). 110 beats 170. OSPF wins.
• via Ethernet0/1, next hop 10.25.0.2 - that is R5, in the OSPF domain. HUB2 is sending traffic for a network that sits directly behind its EIGRP neighbour out through a completely different protocol domain and back.
• Redistributing via eigrp 100 - and this is the one that should make you cold. HUB2 is now taking that OSPF-learned route and injecting it back into EIGRP. The prefix has gone EIGRP → OSPF → EIGRP. It has been laundered. Its origin is lost. And it is now competing with the real route.

The rest of the OSPF table on HUB2 tells the same story:

HUB2#show ip route ospf | begin Gateway
O E2     6.6.6.6 [110/1] via 10.25.0.2, Ethernet0/1
O E2     10.60.60.0/24 [110/1] via 10.25.0.2, Ethernet0/1
O E2     10.99.1.0/24 [110/20] via 10.25.0.2, Ethernet0/1
O E2     10.99.3.0/24 [110/20] via 10.25.0.2, Ethernet0/1

Networks that live behind HUB1, one EIGRP hop away, being learned through OSPF via a router in a different domain. In a bigger topology this is exactly how you get a routing loop that only manifests under a specific failure - and how you get a 3 a.m. incident that nobody can reproduce.

The fix, part 1: route tags

A route tag is a 32-bit number carried with a route across redistribution boundaries. It is the passport stamp. Every boundary router stamps what it exports and refuses what comes back.

The scheme, applied identically on every boundary router:

! Going EIGRP -> OSPF: refuse anything that came FROM OSPF, and stamp the rest as "from EIGRP"
route-map EIGRP-TO-OSPF deny 10
 match tag 110
route-map EIGRP-TO-OSPF permit 20
 set tag 100

! BGP routes get their own stamp
route-map BGP-TO-OSPF permit 10
 set tag 65001

! Going OSPF -> EIGRP: refuse anything that came from EIGRP or BGP, stamp the rest as "from OSPF"
route-map OSPF-TO-EIGRP deny 10
 match tag 100 65001
route-map OSPF-TO-EIGRP permit 20
 set tag 110

Read those out loud and the logic is airtight. A route that originated in EIGRP is tagged 100 on the way into OSPF. When it reaches the second boundary router and tries to come back into EIGRP, the OSPF-TO-EIGRP map sees tag 100 and denies it. It cannot come home. The loop is structurally impossible, on every boundary router, forever.

Pick tag values that mean something. Using 100 for "originated in EIGRP AS 100" and 110 for "originated in OSPF" makes the config self-documenting, and the engineer who inherits it in three years will thank you.

The fix, part 2: fix the AD race

Tags stop the feedback. They do not, by themselves, fix the fact that OSPF's AD 110 beats EIGRP-external's 170, so the boundary router still prefers the wrong copy of a route it can see both ways.

Make OSPF externals less trusted than EIGRP externals:

router ospf 1
 distance ospf external 175

Now: EIGRP external (170) < OSPF external (175). The boundary router prefers the route it learned over the protocol the route actually lives in.

Note this only changes external OSPF routes. Intra-area and inter-area OSPF routes keep their AD of 110, which is right - those are native OSPF routes and OSPF should be trusted for them.

The complete fix

router ospf 1
 redistribute eigrp 100 subnets route-map EIGRP-TO-OSPF
 redistribute bgp 65001 subnets route-map BGP-TO-OSPF
 distance ospf external 175
!
router eigrp DMVPN
 address-family ipv4 unicast autonomous-system 100
  topology base
   redistribute ospf 1 metric 100000 100 255 1 1500 route-map OSPF-TO-EIGRP

And HUB2, on the same lab, with the same topology:

HUB2#show ip route 10.60.60.0
Routing entry for 10.60.60.0/24
  Known via "eigrp 100", distance 170, metric 77312000
  Tag 65010, type external
  Last update from 10.0.0.1 on Tunnel0, 00:00:16 ago
  Routing Descriptor Blocks:
  * 10.0.0.1, from 10.0.0.1, via Tunnel0
      Hops 1

One hop. Over the tunnel. Straight to HUB1. The route is back where it belongs.

HUB2#show ip route ospf | begin Gateway
O        5.5.5.5 [110/11] via 10.25.0.2, Ethernet0/1
O        10.5.0.0/30 [110/20] via 10.25.0.2, Ethernet0/1
O        10.50.50.1/32 [110/11] via 10.25.0.2, Ethernet0/1
O E2     10.99.1.0/24 [175/20] via 10.25.0.2, Ethernet0/1
O E2     10.99.3.0/24 [175/20] via 10.25.0.2, Ethernet0/1

Native OSPF routes still at AD 110. Externals now at 175. And 6.6.6.6 and 10.60.60.0/24 have vanished from the OSPF table entirely - the tag filter refused to let them back in.

The EIGRP topology table even preserves the true origin:

HUB2#show ip eigrp topology 10.60.60.0/24 | include External|Originating
        Originating router is 1.1.1.1
      External data:
        External protocol is BGP, external metric is 0

The rules

1. Tag on export, filter on import. On every boundary router, without exception. One router missing the filter re-opens the loop, and it will only bite you during a failure.
2. Know your AD table. Specifically: EIGRP external is 170, OSPF is 110, and that means an EIGRP route that has been round the houses will beat the real one. This is the single most common cause of "why is traffic going that way?"
3. Never redistribute without a route-map. Even if the route-map is empty today, having it there means the day you need to filter something you are not changing the structure of the config under pressure.
4. Always set a metric. Redistribution into EIGRP without a metric silently drops every route (EIGRP has no default metric for redistributed routes). Redistribution into OSPF without subnets silently drops every non-classful prefix. Both are silent, both are total.
5. Redistribute at as few points as possible. Two-point mutual redistribution is where all of this pain comes from. If you can do it at one point, do it at one point. If you need two for redundancy, tag rigorously.
6. Draw the topology before you type. Mark every boundary router. Trace every prefix's path through every protocol. The bugs are visible on paper long before they are visible in a routing table.

Key takeaways

• Every redistribution disaster is route feedback, an AD race, or both.
• EIGRP external = AD 170. OSPF = AD 110. A route redistributed into EIGRP loses to the same route arriving via OSPF, however absurd the path.
• We reproduced it: HUB2 reached a network behind its directly-adjacent EIGRP neighbour by going out through a different protocol domain, and then re-injected it back into EIGRP.
• Fix it with tags (stamp on export, deny on import, on every boundary router) and AD (distance ospf external 175 so the native protocol wins).
• Redistribution into EIGRP without a metric drops everything. Redistribution into OSPF without subnets drops everything non-classful. Silently, both times.
• Fewer redistribution points is always better. Two-point mutual redistribution demands rigour, not optimism.

Next: migrating from EIGRP to OSPF without an outage. The full cluster index lives on the EIGRP pillar guide.