GRE tunnel and Eigrp

[jtalbaugh]

Hope someone can help. Recently we've set up a GRE tunnel and I've had some trouble getting the routing to work.

EIGRP flaps with the following indication:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.21.75.1 (Tunnel

0) is down: retry limit exceeded

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.21.75.1 (Tunnel

0) is up: new adjacency

sh ip eigrp neigh on remote router shows a neighbor but I do not get a neigbor on the Core router?

Ive attached my configuration (Note I've changed IP address and masked slightly but all symbols can be substituted with like numbers.

Any help or direction would be appreciated.

[lejoe.thomas]

Hi James,

Even though you say you IP addresses are masked, I believe the tunnel destination on the core (10.**.200.75) does not match the tunnel source (10.**.20.75) on the remote router.

The remote router is sending hellos but not receiving any replies as indicated by sequence no 0 and Q Cnt.

If after correcting the addresses, the problem persists, check if any access-list is blocking eigrp traffic on the core. Alternatively you could post results of debug eigrp packets on both routers to help resolve the problem better.

HTH

Lejoe

[jtalbaugh]

Thanks lejoe for the response,

My goof on the attached doc. sorry for the confusion. should be 10.**.20.75. I did double check to make sure the infomation matched on both sides. The tunnel is up.

I will reattach the corrected document.

I will also look at attaching the debugs you requested as soon as possible.

[jtalbaugh]

Here is the corrected document.

[lejoe.thomas]

hi James,

Well the gre tunnel setup on the core router is fine.

The core router is indeed sending hellos to the remote router which why it is showing up on neighbors list on the remote router.

However the problem is that the remote router is sending hellos but not receiving acks for it from the core-router. The culprit here is route to the tunnel destination on the remote router.

When you put the tunnel destination on the remote router as the loopback 1 interface on the core router and added a static route to it on the remote router.

ip route 172.%%.200.1 255.255.255.255 FastEthernet0/1

Because your next hop on F0/1 probably does not know how to reach destination (172.%%.200.1), which happens to be loopback interface on core router, the hello packets from the remote-router to core is not delivered.

To resolve the problem, change the tunnel source on the core router to address to which it connects to it's next hop (172.%%.80.1), likewise make the modification for the tunnel destination on the remote router and things should work.

HTH

Lejoe

[Marcelo Martinez]

I saw the same case on a customer network.

Let me say you that in this case the ISP who blocked GRE encapsulation.

Check it with your link provider