skip to content

When migrating an enterprise from EIGRP to OSPF with both running and mutual redistribution at two border routers, how do you prevent routing feedback loops?

level: seniorimportance: should knowfreq 15%

answer

  1. routes coming back home
  2. mark where a route entered
  3. filter on the way back
  4. metrics do not translate
  5. route-source preference at the border

basics

~20 s

Tag each route where it is redistributed and refuse to redistribute it back: OSPF carries a 32-bit External Route Tag, EIGRP externals an administrative tag. Also seed metrics deliberately, migrate site by site and check route-source preference at the borders.

solid answer

~50 s

With two border routers redistributing both ways, a route learned in EIGRP can enter OSPF at one border, cross OSPF to the second border, and be redistributed back into EIGRP — a **feedback loop** that can produce loops or long, unstable paths. The standard defence is **route tagging**: when a border router redistributes EIGRP into OSPF it sets the AS-external-LSA's 32-bit **External Route Tag** (RFC 2328 A.4.5), and when redistributing OSPF into EIGRP it sets the EIGRP external route's **administrative tag** (RFC 7868 §5.4.1.2); each border denies redistributing a route whose tag says it came from the other protocol. Because neither protocol understands the other's metric, a **seed metric** must be chosen at each border. Finally, the border routers prefer routes by route source, not metric, so a re-injected external can beat the original; check that preference at both borders. Then move sites one by one.

go deeper

for a junior

Recall that redistribution copies routes between two routing protocols and that routes can loop back through a second border router.

for a middle

Explain how a route re-enters its original protocol, and how tags and deny filters on both borders stop it.

for a senior

Plan the migration: tagging from day one, consistent seed metrics, external metric type, the route-source preference at each border, and the order of site moves.

for a principal

Decide how long two IGPs may coexist, how much redistribution complexity the team can operate safely, and when to finish the migration rather than keep the island.

## Why migrations use mutual redistribution Moving an estate from EIGRP to OSPF in one maintenance window is rarely possible. The usual approach runs both protocols for weeks or months: migrated sites speak OSPF, unmigrated sites speak EIGRP, and **border routers** run both and **redistribute** in each direction so every site can reach every other. Two borders are used for redundancy, and that is exactly what creates the risk. ## How the feedback loop forms Take border routers **BR1** and **BR2**, both running EIGRP and OSPF, and an EIGRP site prefix 10.30.5.0/24. 1. BR1 learns 10.30.5.0/24 in EIGRP and redistributes it into OSPF as an AS-external-LSA. 2. That LSA floods through OSPF and reaches BR2. 3. BR2 redistributes OSPF into EIGRP, so it injects 10.30.5.0/24 back into EIGRP as an **external** route, with whatever seed metric it applies. 4. Depending on metrics and route-source preference, some EIGRP routers — or BR2 itself — may now prefer the path through BR2 back into OSPF and round to BR1. 5. If the original path fails, the stale copy circulating through the other protocol can keep the prefix alive and loop traffic until the routes age out. Each protocol's loop prevention works **only inside that protocol**. DUAL's feasibility condition proves loop-freedom among EIGRP routers, and SPF gives loop-free paths over OSPF's database; neither sees the path through the other protocol. ## Tagging breaks the loop Both protocols carry an opaque, operator-set tag with redistributed routes: | Protocol | Where the tag lives | Size | Meaning to the protocol | |---|---|---|---| | OSPF | **External Route Tag** in each AS-external-LSA (RFC 2328 A.4.5) | 32 bits | None; RFC 2328 says it is not used by OSPF itself and may be used between AS boundary routers | | EIGRP | **Administrative tag** in the external route (RFC 7868 §5.4.1.2, §6.8.3) | 32 bits | None; it is untouched by EIGRP so other border routers can filter on it | The policy, applied on **both** border routers: - When redistributing EIGRP into OSPF, set tag A. - When redistributing OSPF into EIGRP, set tag B. - When redistributing OSPF into EIGRP, **deny** anything carrying tag A; when redistributing EIGRP into OSPF, **deny** anything carrying tag B. - Apply the identical policy on both borders, so either border recognises a route the other injected. - Count or log denied routes during the migration; a sudden change means a site moved without the borders noticing. EIGRP's external route also records the **router ID of the redistributing router**, the **external protocol** (OSPF is value 6 in RFC 7868 §6.2) and the external metric, which helps when tracing where a route entered. ## Metrics do not translate An EIGRP composite metric built from bandwidth and delay means nothing as an OSPF interface cost, and vice versa, so each redistribution needs a **seed metric** chosen by policy (implementations apply different defaults, and some refuse to advertise without one). On the OSPF side, choose the external metric type: **Type 1** externals add the internal cost to the border router, while **Type 2** externals are compared first on the external metric and treated as greater than any internal path (RFC 2328 §2.3). Seed both borders consistently, or one border attracts all traffic. Finally, a border running both protocols picks between an EIGRP and an OSPF route for one prefix by **route-source preference** (administrative distance, a topic of its own), not by metric, so check on each border that a re-learned external never beats the original route. ## A migration sequence 1. Bring up OSPF across the core alongside EIGRP, with tagging and deny filters in place on both borders from the first day. 2. Migrate sites one by one; at each, enable OSPF, confirm the routes, then remove EIGRP from that site. 3. Watch for routes appearing in both protocols with a tag that should have been filtered. 4. When no EIGRP site remains, remove redistribution and then EIGRP itself. ## Checks before each site cutover - The site's prefixes appear as **internal** routes in exactly one protocol. - Both border routers choose the same exit for the site's prefixes. - No route carrying tag A appears in EIGRP, and no route carrying tag B appears in OSPF. - The OSPF external metric type and seed values match on both borders.

  • Why does the problem need two border routers, and does a single border remove it?
    A feedback loop needs a path out of one protocol and back in somewhere else. With one border, routes it redistributes cannot return through another router, so the loop disappears, but so does redundancy: that router becomes a single point of failure for all traffic between migrated and unmigrated sites.
  • Could route filtering by prefix list replace tags during the migration?
    It can, but every border would need a list of which prefixes live in which protocol, updated each time a site moves. Tags record where a route entered automatically, so the filters stay the same throughout the migration; that is why tagging is the usual choice.

saying these in an interview costs you the question

  • DUAL's feasibility condition keeps redistributed routes loop-free across both protocols.
  • Redistribution translates EIGRP metrics into equivalent OSPF costs automatically.
  • The OSPF External Route Tag is used by SPF to choose between paths.
  • Tagging on only one border router is enough to stop the feedback loop.
  • A border router compares the EIGRP and OSPF metrics to choose between them.