debugging EIGRP failure to install routes

[tato386]

I have two routers running EIGRP connected via a GRE tunnel.  One router,  which I will call router1 has over 50 routes learned from a BGP neighbor and is configured to redistribute BGP into EIGRP.  The other router2 only runs EIGRP.  The routers show each other as neighbors and don't seem to be flapping.  However router2 only shows a subset of the routes that routerA has.  When I look at the routes on router1 and also on the BGP router all the subnets that show up in router2 look identical in metrics and so on to the ones that don't show.  So why does router2 chose to install only a subset of all these routes?  I tried to use "show ip eigrp topology" but the output is very tough to understand.  This missing routes don't show in the topology output either.  What would cause router2 to install some routes and not others?

What can I do to troubleshoot this?

Thanks,

Diego 

[lgijssel]

This kind of behavior is often caused by a duplicate loopback.

Please verify there are no duplicate ip's used on R1 and R2.

regards,

Leo

[ashok_boin]

Hi Diego,

Can you please check with "sh ip eigrp top all-links" which lists all the routes on R2?

And also, have you configured any summarization on R1 towards R2? Is auto-summary enabled? These will suppress component subnets of summary.

For a lab note regarding EIGRP route summarization, you can have a loot at here which may help...

http://www.networkers-google.com/nwgoogle/Routing/EIGRP/All%20about%20EIGRP%20Route%20Sum1305799297.html

Regards...

-Ashok.

[Richard Burts]

Diego

If we had some additional information we might be able to give you better answers. For a start can you post the interface configuration of the interfaces and of the EIGRP processes.

HTH

Rick

Sent from Cisco Technical Support iPhone App

[tato386]

Its a fairly complicated configuration so I don't think anybody would want to go thru all that but here is more info.  The primary network is an MPLS based WAN with about 50 subnets.  We are running BGP accross the WAN and the MPLS routers also have an EIGRP process running to distribute the BGP learned routes to LAN attached routers and switches.  Subnets at all sites are using private class C such as 192.168.x.0.  Each site also has a VPN/GRE router as a backup link.  The GRE is configured as multipointGRE network with hub and spoke sites.  Currently there is no spoke-to-spoke traffic and all spoke-to-spoke traffic must go thru the hub GRE router.

When MPLS is up the BGP/MPLS routers have routes to all subnets.  When we check a GRE/VPN router is also shows all the subnets available via the MPLS because of the redistributon of BGP into EIGRP.  So far so good.

So now we shutdown a BGP link to see if the backup works. We check the GRE/VPN router at the hub site and it shows all subnets available  via BGP/MPLS except the down site which shows as being available over the GRE tunnel.  This would indicate that the hub-spoke link via GRE is up and the spoke can talk to the hub correctly and this is verified as working.

Now here comes the weird part.  The GRE/VPN router has routes to all other subnets yet at the spoke we only see 5 or 6 of the subnets.  What happened to the other 40 something subnets?  If I do a "show ip routes" at the hub GRE router subnets 1 thru 50 all show with the exact same metrics, (except for the local and down MPLS spoke subnet of course) all showing as available via the BGP network.  However at the spoke we only get a random smattering of subnets.

At this moment I am trying to compare the configs of the "good" routers to the "bad" routers to see if I see a difference but the way I see it if the route is available on the hub GRE/VPN router and this router is passing EIGRP to the spoke it should pass all availble routes not just some, no?  Note that there are no ACLs filtering out subnets.

I figure some debug or show command would tell my why some routes don't make it to the spoke but I haven't been able to figure it out.  I do now that "show ip eigrp neigh" shows the routers are talking and not flapping.  Also, "show ip eigrp topology all-links" shows a LOT of info but it is hard to interpret and the missing subnets don't show up there either.

Is it worth it to plug in the info of "show topology" to the output interpreter?  What other options do I have here?

Thanks,

Diego

[cadet alain]

Hi,

if the prefixes are not in the topology table that means they are not advertised by the eigrp neighbours.

Maybe you could try debug eigrp packet update on spoke and routers after resetting adjacencies.

Regards.

Alain.

[Richard Burts]

Diego

Thanks for the additional information. Now that we understand that the EIGRP network is running over multipoint GRE I wonder if your issue is EIGRP split horizon. Perhaps you could configure the EIGRP process on the hub router to disable EIGRP split horizon and see if the routes at the spoke change.

HTH

Rick

[tato386]

Rick,

I definitely have "no ip split-horizon eigrp" command on the tunnel interface of the hub router.  Remember, the problem is not that I don't get any routes.  I get routes, just not all the routes.  The hub router has routes to almost 50 class C, 192.168.x.0 subnets.  Only about a half-dozen show up at the spoke.  So the fact that those half-dozen show tells me that I have the hub and spoke interchanging routing information over EIGRP to some extent.

The mystery is that only a subset of the hub router's routing table shows at the spoke.  What is special or different about the half-dozen subnets that show at the spoke?  Conversely, what is wrong with the other subnets that do not show on the spoke?  All 50 subnets look the same on the hub so why the descrepancy at the spoke?

I am thinking about something like Alain is suggesting to see if I can catch the descrepancy between subnets.  I shy away from debug packet type stuff becomes sometimes the amount of data that you get is overwhelming and tough to decipher.  I thought there might be other, more efficient show commandas that could help.

Thanks,

Diego

[Richard Burts]

Diego

I do remember that the issue is that you have only a subset of the routes. And that is consistent with a split horizon problem. If some prefixes are learned from somewhere not on the multipoint GRE then they would be advertised over the GRE without problem while prefixes that are learned from the GRE would be suppressed.

But if you have configured no eigrp split-horizon then it is likely not a split horizon issue.

One suggestion would be that immediately after you stop the redistribution to do show ip eigrp event

This will show the most recent activity in EIGRP and might provide some insight into the problem.

HTH

Rick

[tato386]

Hey Rick,

Not sure I am following you here.  You want me to stop the redistribution at the BGP router then do a "show ip eigrp" event where?  At the hub VPN/GRE router?  Is that correct?

Thanks,

Diego

[Richard Burts]

Diego

In a previous post you describe:"

So now we shutdown a BGP link to see if the backup works. We check the  GRE/VPN router at the hub site and it shows all subnets available  via  BGP/MPLS except the down site which shows as being available over the  GRE tunnel."

That is when  I want you to do this. Yes I am suggesting doing it at the hub router (although there might be benefit in doing it at the spoke also).

And the command is "show ip eigrp event"

It is a hidden command and will not show up in on line help. But its output will reflect routing decision activity that happened recently in EIGRP.

HTH

Rick

[tato386]

Thanks Rick,

I will give it a shot and let you know.

Rgds,

Diego

[tato386]

Rick,

Looking at the output of the show ip eigrp event command seems to indicate that the routes do reach the spoke router.  However they are not installed due to "poison squashed" and also apparently due to "ignored route, inaccesible".  Does that make any sense to you?  The routes we are looking for are 192.168.1.0, 192.168.3.0, 172.30.1.0 and 172.30.3.0.  I have attached some files that might help.

Thanks,

Diego

[ashok_boin]

Hi Diego,

I guess the captures you have taken after stopping the redistribution from BGP into EIGRP which enabled the events to take out routes in EIGRP which were learnt through BGP earlier (setting the metric to infinite with 4294967295 which is working properly.

I think the events capture at Hub GRE/VPN router during the transition from Primary to Backup link at Spoke. I guess the Spoke GRE/VPN routers are first of all not getting the mentioned routers 192.168.1.0 and getting suppressed at EIGRP neighbor itself during the transition.

"debug eigrp packet update" at hub also may help.

Regards...

-Ashok.