Strange EIGRP behavior

Ricky Sandhu · ‎03-08-2012

Hi everyone,

I am experiencing a somewhat strange behavior between 2 of my dmvpn spokes where they are not able to send an ICMP ping to each other however are able to ping to and from all other spokes on the network. Each of them also know about one another through EIGRP (see output below). There are no ACL's involved that block ICMP pings inside the network

R-Queens-1 172.18.24.1

R-Chicago-1 172.18.28.1

R-Queen-1#ping 172.18.28.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.18.28.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

R-24Queen-1#sh ip route 172.18.28.1

Routing entry for 172.18.28.0/24

Known via "eigrp 1", distance 90, metric 5120256, type internal

Redistributing via nhrp, eigrp 1

Last update from 10.10.201.28 on Tunnel1, 1d05h ago

Routing Descriptor Blocks:

* 10.10.201.28, from 10.10.201.1, 1d05h ago, via Tunnel1

Route metric is 5120256, traffic share count is 1

Total delay is 100010 microseconds, minimum bandwidth is 1000 Kbit

Reliability 255/255, minimum MTU 1400 bytes

Loading 11/255, Hops 2

R-24Queen-1#sh ip eigrp nei

EIGRP-IPv4 Neighbors for AS(1)

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

1 10.10.200.1 Tu0 12 1d05h 138 828 0 237919

0 10.10.201.1 Tu1 12 1d15h 12 200 0 46056

R-Chicago-1#sh ip route 172.18.24.1

Routing entry for 172.18.24.0/24

Known via "eigrp 1", distance 90, metric 5120512, type internal

Redistributing via eigrp 1

Last update from 10.10.201.1 on Tunnel1, 1d05h ago

Routing Descriptor Blocks:

* 10.10.201.1, from 10.10.201.1, 1d05h ago, via Tunnel1

Route metric is 5120512, traffic share count is 1

Total delay is 100020 microseconds, minimum bandwidth is 1000 Kbit

Reliability 255/255, minimum MTU 1400 bytes

Loading 255/255, Hops 3

R-Chicago-1#sh ip eigrp nei

EIGRP-IPv4 Neighbors for AS(1)

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

0 10.10.201.1 Tu1 12 4d23h 21 450 0 46061

I am running a continuos ping and after a few minutes I do get one odd reply from chicago but it starts to time out again for a few minutes.

Any help would be much appreciated.

lucentmoon · ‎03-08-2012

Can you do a traceroute from both spoke routers & a sh ip route for 28.1 & 24.1 on the router@ 10.10.201.1

Richard Burts · ‎03-08-2012

I am not sure what is going on and believe that there may be a clue in this:

* 10.10.201.28, from 10.10.201.1, 1d05h ago, via Tunnel1

Both routers agree that their neighbor is 10.10.201.1. But Queens believes that the next hop is 10.10.201.28. What is causing this? Perhaps you can post some information from 10.10.201.1 and/or 10.10.201.28 that would shed some light on this?

HTH

Rick

HTH

Rick

Ricky Sandhu · ‎03-08-2012

Hi Richard, I noticed that too however it shouldn't cause the problem. Basically each spoke has Tunnel0 and Tunnel1 both going over a single high speed connection but to two separate hubs.

Last octet on each tunnnel IP address corresponds to the 3rd octet on the VLAN IP.

In case of chicago router it is

Vlan IP: 172.18.28.1

Tunnel0: 10.10.200.28

Tunnel1: 10.10.201.28

Queens

Vlan IP: 172.18.24.1

Tunnel0: 10.10.200.24

Tunnel1: 10.10.201.28

One difference in Chicago is that currently Tunnel0 is shutdown and Tunnel1 is the only connection to the hub.

I also noticed that my spokes seem to prefer sending data over Tunnel0 interface. Below is an EIGRP topology output from Queens router. Notice how it's picked the hub on tunnel0 as the successer and tunnel1 the feasible successer.

R-Queen-1#sh ip eigrp top

EIGRP-IPv4 Topology Table for AS(1)/ID(1.1.1.24)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,

r - reply Status, s - sia Status

P 10.10.122.0/24, 1 successors, FD is 3842560

10.10.200.217 via 10.10.200.1 (3842560/2562560), Tunnel0

via 10.10.201.1 (3842816/2562816), Tunnel1

P 172.18.207.0/24, 1 successors, FD is 3840256

10.10.200.207 via 10.10.200.1 (3840256/2560256), Tunnel0

via 10.10.201.1 (3840512/2560512), Tunnel1

P 1.1.1.207/32, 1 successors, FD is 3968000

10.10.200.207 via 10.10.200.1 (3968000/2688000), Tunnel0

via 10.10.201.1 (3968256/2688256), Tunnel1

P 192.168.3.0/24, 1 successors, FD is 3840256

10.10.200.203 via 10.10.200.1 (3840256/2560256), Tunnel0

via 10.10.201.1 (3840512/2560512), Tunnel1

P 172.18.12.0/24, 1 successors, FD is 3840512

10.10.200.11 via 10.10.200.1 (3840512/2560512), Tunnel0

via 10.10.201.1 (3840768/2560768), Tunnel1

P 1.1.1.210/32, 1 successors, FD is 3968000

10.10.200.210 via 10.10.200.1 (3968000/2688000), Tunnel0

via 10.10.201.1 (3968256/2688256), Tunnel1

P 172.18.121.0/24, 2 successors, FD is 1600256

--More--

What I don't get is that each of these tunnels have the same source and both hub destinations are also located at the same location. Shouldn't the metric be same for both?

Ricky Sandhu · ‎03-08-2012

Hi Nicholas, here is the traceroutes

R-Queen-1#traceroute 172.18.28.1

Type escape sequence to abort.

Tracing the route to 172.18.28.1

1 * * *

2 * * *

3 * * *

4 * * *

5 * * *

R-Chicago-1#traceroute 172.18.24.1

Type escape sequence to abort.

Tracing the route to 172.18.24.1

1 10.10.201.1 16 msec 16 msec 20 msec

2 * * *

3 * * *

4 * * *

5 * * *

Sh ip route from 172.18.101.1

R-Q9-2#sh ip route 172.18.24.1

Routing entry for 172.18.24.0/24

Known via "eigrp 1", distance 90, metric 2560512, type internal

Redistributing via nhrp, eigrp 1

Last update from 172.18.123.2 on GigabitEthernet0/2, 1d13h ago

Routing Descriptor Blocks:

* 172.18.123.2, from 172.18.123.2, 1d13h ago, via GigabitEthernet0/2

Route metric is 2560512, traffic share count is 1

Total delay is 50020 microseconds, minimum bandwidth is 2000 Kbit

Reliability 255/255, minimum MTU 1400 bytes

Loading 255/255, Hops 2

R-Q9-2#sh ip route 172.18.28.1

Routing entry for 172.18.28.0/24

Known via "eigrp 1", distance 90, metric 3840256, type internal

Redistributing via nhrp, eigrp 1

Last update from 10.10.201.28 on Tunnel0, 1d23h ago

Routing Descriptor Blocks:

* 10.10.201.28, from 10.10.201.28, 1d23h ago, via Tunnel0

Route metric is 3840256, traffic share count is 1

Total delay is 50010 microseconds, minimum bandwidth is 1000 Kbit

Reliability 255/255, minimum MTU 1400 bytes

Loading 11/255, Hops 1