EIGRP Neighbor Relationship Failure

[davidhvoss]

I have 2 routers that do not form an EIGRP neighbor relationship.

I am running EIGRP over a GRE tunnel. ROUTER A to ROUTER B.

ROUTER B is running passive interface for ROUTER A, so, as expected, no neighbor shows up in show ip eigrp neighbors.

ROUTER A does show ROUTER B in show ip eigrp nei, but only for 1:20 seconds. Then it times out and re-establishes again. The problem is, no traffic is passing between them (Q Cnt is at 44 and Seq is as 0). So, it appears at no time are they passing EIGRP data. It continues to cycle like this every 1:20 seconds.

There is full reachability between the two tunnels (pings tests work fine).

Is there something about running EIGRP over GRE that I'm missing here?

ROUTER A

SHOW IP EIGRP NEI

IP-EIGRP neighbors for process X

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

7 11.11.11.11 Tu500 11 00:00:12 1 5000 44 0

ROUTER A

interface Tunnel5

description to router B

ip address x.x.x.x y.y.y.y

service-policy output (drop after 256000)

ip tcp adjust-mss 1400

delay 100

keepalive 30 5

tunnel source Loopback101

tunnel destination y.y.y.y

end

ROUTER B

interface Tunnel44

description To ROUTER A

bandwidth 2500

ip address x.x.x.x y.y.y.y

ip tcp adjust-mss 1400

ip summary-address eigrp 20 x.x.x.x 255.255.0.0 5

ip summary-address eigrp 20 x.x.x.x 255.240.0.0 5

ip summary-address eigrp 20 x.x.x.x 255.0.0.0 5

delay 100

keepalive 10 5

tunnel source Loopback101

tunnel destination x.x.x.x

end

Any help would be appreciated. I've scoured Cisco.com.

[pkhatri]

Hi David,

Could you post your 'router eigrp' portion of the configs ?

Are the two tunnel interfaces on the routers configured to be in the same subnet ? EIGRP will drop any packets destined to an interface where the source address is not part of a subnet configured on that interface.

HTH,

Paresh

[thisisshanky]

Why is the keepalive set to 10 on one end and 30 on other. That could bring the tunnel down..

Also PKhatri is right, that you might be getting a lot of EIGRP neighbornot on same subnet error (if you turn loggin console on)

[Richard Burts]

On most media having mismatched keepalive timers will cause problems. It is my understanding of the way that keepalive works on GRE that a mismatch here probably does not cause problems. And the description of the problem indicated that ping works ok, did not mention the tunnel interface protocol going down or flapping. So I am inclined to think that the mismatched keepalive timers are not causing this issue, but agree with Sankar that you might want to adjust them so that they do match.

I suspect that the issue is in the statement in the original post that ROUTER B is running passive for ROUTER A. If B has a passive interface configured for its tunnel it will never respond to the HELLO packets from A. And on A if it never gets a response to its HELLO packets then a neighbor relationship will never form and no updates will be exchanged. Which sounds pretty much like the symptoms that are being described.

If my understanding of the original post is correct and ROUTER B does configure the tunnel interface as passive, then I suggest that you change this and let the tunnel interface become an active interface.

HTH

Rick

[mvalentine]

I can't tell from the info provided but it sounds like you have a recursive routing issue. The tunnel comes up when you learn the tunnel destinations via your routing protocol. The tunnel then comes up and eigrp exhanges routes, now the tunnel endpoint is learned ove the tunnel and it goes down. This cycle repeats itself over and over. You should add a distribution list that deny's the tunnel destination routes from entering/or leaving the tunnel interface.

[mvalentine]

I can't tell from the info provided but it sounds like you have a recursive routing issue. The tunnel comes up when you learn the tunnel destinations via your routing protocol. The tunnel then comes up and eigrp exhanges routes, now the tunnel endpoint is learned ove the tunnel and it goes down. This cycle repeats itself over and over. You should add a distribution list that deny's the tunnel destination route from entering/or leaving the tunnel interface.