IGP Migration: Moving from EIGRP to OSPF Without an Outage

Sooner or later somebody decides the network is moving from EIGRP to OSPF. Maybe a merger brought in a multi-vendor estate. Maybe the standards team decided on open protocols. Maybe an architect just likes link-state better. The reason does not matter. What matters is that you have to do it on a live network, and you are not allowed to drop a packet.

The good news is that this is a solved problem, and the technique is elegant: run both protocols side by side, let them both build complete routing information, then flip which one the routing table believes - one administrative distance command at a time. It is called ships in the night, and this article walks through it with real lab output showing zero packet loss at every stage. For the fundamentals, see the EIGRP guide and the OSPF guide.

Why not just redistribute?

The instinct is to redistribute between the two protocols during the transition. Resist it.

Redistribution during a migration means you have a temporary, multi-point, mutual redistribution boundary that moves around the network as you go - which is the single most dangerous configuration in routing. You would be introducing route feedback and AD races into a live network, deliberately, at the exact moment you can least afford surprises.

Ships in the night avoids redistribution entirely. The two protocols never talk to each other. They each carry a complete picture of the network independently, and the routing table simply chooses which picture to believe.

The four stages

The critical insight is that stage 3 is the only stage that changes forwarding, it changes it one router at a time, and it is instantly reversible. Everything else is preparation or cleanup.

Stage 1: baseline

From the lab. SPOKE1 reaching SPOKE2's loopback across the site LAN:

SPOKE1#show ip route 12.12.12.12
Routing entry for 12.12.12.12/32
  Known via "eigrp 100", distance 90, metric 1024640, type internal
  Routing Descriptor Blocks:
  * 10.1.1.12, from 10.1.1.12, via Ethernet0/1
      Route metric is 1024640, traffic share count is 1

SPOKE1#ping 12.12.12.12 source Loopback0 repeat 3
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 2/2/3 ms

EIGRP, AD 90, via Ethernet0/1. Write it down. That is what "correct" looks like, and it is what you will compare against after every stage.

Stage 2: build OSPF alongside

SPOKE1(config)#router ospf 10
SPOKE1(config-router)#router-id 11.11.11.11
SPOKE1(config-router)#network 10.1.1.0 0.0.0.255 area 0
SPOKE1(config-router)#network 11.11.11.11 0.0.0.0 area 0

Same on SPOKE2. Wait for the adjacency, then look:

SPOKE1#show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
12.12.12.12       1   FULL/DR         00:00:35    10.1.1.12       Ethernet0/1

SPOKE1#show ip ospf database router 12.12.12.12 | include Advertising|Link ID
  Advertising Router: 12.12.12.12
     (Link ID) Network/subnet number: 12.12.12.12
     (Link ID) Designated Router address: 10.1.1.12

OSPF is fully up. It knows about 12.12.12.12. It has run SPF and computed a path. And the routing table:

SPOKE1#show ip route 12.12.12.12
Routing entry for 12.12.12.12/32
  Known via "eigrp 100", distance 90, metric 1024640, type internal
  * 10.1.1.12, from 10.1.1.12, via Ethernet0/1

Completely unchanged. EIGRP's AD of 90 beats OSPF's 110, so the RIB never even considers the OSPF route. OSPF is running, converged, and holding a complete parallel view of the network - and it is having zero effect on forwarding.

This is the stage where you do all the real work. Get OSPF right across the entire estate. Fix the area design. Sort out the MTU mismatches, the network-type mismatches, the authentication. Let it sit for a week. Watch it. Every OSPF bug you find here is a bug you find with a working network underneath you.

What to check before moving on

• Every EIGRP adjacency has a matching OSPF adjacency. A link with EIGRP but no OSPF becomes a black hole the moment you flip. Compare show ip eigrp neighbors against show ip ospf neighbor on every router.
• Every prefix in the EIGRP topology is in the OSPF database. Something with a network statement under EIGRP but not under OSPF disappears at the flip. This is the number one cause of a failed migration.
• The OSPF paths are the paths you want. OSPF's cost metric will not naturally reproduce EIGRP's bandwidth-and-delay composite. Some paths will change. Find out which ones now, on paper, not during the change window.
• Passive interfaces are configured. Every interface that was passive in EIGRP must be passive in OSPF, or you will form adjacencies with things you did not intend to.

That third point deserves emphasis. Metric equivalence is the thing that surprises people. EIGRP's composite metric weighs minimum bandwidth and cumulative delay. OSPF's cost is a simple sum of per-interface costs derived from bandwidth alone. Two paths that EIGRP ranked one way can rank the other way in OSPF. Model it, or set OSPF costs explicitly on the links that matter.

Stage 3: the flip

One command. On one router at a time.

router eigrp DMVPN
 address-family ipv4 unicast autonomous-system 100
  topology base
   distance eigrp 190 190

EIGRP internal and external both become AD 190, which is worse than OSPF's 110. The RIB re-evaluates, and:

SPOKE1#show ip route 12.12.12.12
Routing entry for 12.12.12.12/32
  Known via "ospf 10", distance 110, metric 11, type intra area
  Last update from 10.1.1.12 on Ethernet0/1, 00:00:13 ago
  Routing Descriptor Blocks:
  * 10.1.1.12, from 12.12.12.12, via Ethernet0/1
      Route metric is 11, traffic share count is 1

SPOKE1#ping 12.12.12.12 source Loopback0 repeat 3
!!!
Success rate is 100 percent (3/3), round-trip min/avg/max = 2/2/3 ms

Same next hop. Same interface. Different protocol. Zero packet loss.

That is the whole trick. The forwarding path did not change, because both protocols had already computed the same path. All that changed was which routing process the RIB listened to. The data plane never noticed.

Why distance eigrp 190 190 and not distance ospf

You could equally lower OSPF's distance below 90. Do not. Lowering OSPF's AD makes it beat things you did not intend - static routes at AD 1 are safe, but eBGP at 20 is not, and in a network with any BGP you have just created a new problem while solving an old one.

Raise the protocol you are leaving. Never lower the protocol you are arriving at. 190 is a good value: comfortably above OSPF's 110, comfortably below the 200 of iBGP and the 255 of "unusable".

Rollback

no distance eigrp 190 190. EIGRP returns to 90/170, and the routing table flips straight back. Same next hops, same zero loss. You can do this at 2 a.m. with a nervous change manager watching, and undo it in one line if a monitoring graph so much as twitches.

That reversibility is the reason this technique is worth learning properly. Every other approach to a protocol migration involves a moment where you cannot go back.

Stage 4: remove EIGRP

Only after every router has been flipped and verified. Not before. A network where half the routers prefer OSPF and half prefer EIGRP is still perfectly fine - both protocols have full information - but a network where some routers have removed EIGRP while others still rely on it is broken.

So the order is absolute:

1. Flip every router's AD.
2. Verify every router is now using OSPF (show ip route | include ^D should be empty everywhere).
3. Let it run. A day, a week - whatever your change process demands.
4. Then start removing EIGRP.

Removal itself is a non-event, because nothing has been using EIGRP for days.

Migration order

Which routers do you flip first?

The resource question

Running two IGPs at once doubles your control-plane cost: two neighbour tables, two topology databases, two sets of hellos, two SPF/DUAL computations. On modern hardware in a normal enterprise this is a non-issue - the numbers involved are trivially small.

On a heavily-loaded router with a very large topology, check show processes cpu sorted before and after stage 2. If it genuinely matters, migrate in smaller batches so fewer routers are dual-stacked at once. But do not let the theoretical cost push you into redistribution. The control-plane load is the price of a safe migration, and it is a bargain.

Key takeaways

• Never redistribute during a migration. Ships in the night avoids it entirely.
• Run both protocols simultaneously. EIGRP's AD of 90 beats OSPF's 110, so the new protocol has zero effect on forwarding until you say so.
• Stage 2 is where all the work happens - and it is completely safe. Get OSPF perfect while EIGRP is still driving.
• Before flipping: every EIGRP adjacency has an OSPF equivalent, every prefix is in the OSPF database, and you have modelled the paths that will change (they will not be identical - the metrics are computed differently).
• The flip is distance eigrp 190 190. One command, one router, instantly reversible with no distance eigrp 190 190.
• Raise the protocol you are leaving. Never lower the protocol you are arriving at - you will start beating BGP and static routes you did not mean to.
• Verified in the lab: the route changed from eigrp 100, distance 90 to ospf 10, distance 110, same next hop, same interface, 100% ping success throughout.
• Remove EIGRP only after every router has been flipped and verified. That step is a non-event by then.

That closes the expert EIGRP series. The full cluster indexes live on the EIGRP pillar guide and IP routing.