EIGRP and OSPF not ships in the night

Unanswered Question
Apr 28th, 2008


I am trying to migrate an EIGRP network to OSPF. I thought I would do this by enabling OSPF across the network with admin dist of 180, then drop the AD on the Area 0 routers to get OSPF working in the core, then do the same in the leaf areas. What I found was that when I droped the admin dist of OSPF to 80 on the core/area 0, OSPF was also active for all routes on the leaf areas, which was a surprise. I thought OSPF and EIGRP were ships in the night routing, so changing admin dist locally on one router, shouldn't affect the EIGRP routing on another router.

I give a specific example below.

R1---area 1---R2----area 0-----R3---area 2---R4----network10.1.1.0

1. EIGRP is running across all routers (with no redistribution)

2. Configure OSPF on all routers with areas as shown in diagram, with admin dist 180.

3. Check to confirm that all routes are still in EIGRP.

4. Set admin distance to 80 for OSPF on R2,R3.

At this stage I expect the route connected to R4 ( to be in OSPF on R2,R3, but in EIGRP on R1. What I find is that R1 has the route in OSPF.

Debugging shows that when I set the R2,R3 OSPF distance to 80, R1 says there has been a route change, it does the EIGRP DUAL query for the successor, but R2 says I don't have an EIGRP route in my main routing table for (the route is in OSPF), so R2 says I provide a successor, so R1 sets the route to an infinity metric and moves it to the DUAL passive state.

If this was true ships in the night routing, R2 would still have an EIGRP route in its local EIGRP routing table (not the main routing table) to reply to R1 with, it is just that this route is in the EIGRP table, but not in the main routing table. However R2 seems to check do I have a route, and is my EIGRP route in the main routing table, and if it is not in the main routing table, then don't respond to any EIGRP queries.

Has anyone seen this behavior before?

Is there any hidden command to make EIGRP and OSPF behave like ships in the night?



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (5 ratings)
royalblues Mon, 04/28/2008 - 07:04


EIGRP is actually behaving as it should

When you change the distance for ospf at R2, the routing table gets updated with the OSPF route

Now if you observe the eigrp topology closely, you should see that the FD would be shown as inaccessible at R2 (meaning that the route in the routing table is due to another routing protocol with a better admin distance). Since the FD is inaccessible at R2, R1 will not install the EIGRP route


ruwhite Mon, 04/28/2008 - 07:17

You need to remember that EIGRP is a distance-vector protocol, if it's not installing a route in the routing table, it won't advertise the route, and it keeps the route in the local topo table with an infinite distance. There's a bog out to have a nerd knob make it so EIGRP can advertise routes which are in the local table, and in the local routing table, but that EIGRP isn't installing the route.

This explains EIGRP's behavior in this case.



ipotts Mon, 04/28/2008 - 08:20

Hello guys,

Thank you very much.

I had always been told that EIGRP and OSPF were ships in the night routing, but it looks like that is not the case, since EIGRP makes decisions based on whether its route is the route in the main routing table or not, creating a dependency between EIGRP and OSPF.

Russ, can you please tell me the command to activate the nerd knob to disable this behaviour?

Best Regards,


ruwhite Tue, 04/29/2008 - 17:26

There's no current command to activate it. :-( If you shoot me an email, I'll see if there's a way for you to track the state of the request, etc. I'm not certain there is--I might have to do some work to make it "trackable," since I think it's in a state right now where it's not visible to the outside world.



ipotts Wed, 04/30/2008 - 00:02

Thank you very much for your expert help,




This Discussion