Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Strange EIGRP behavior

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.

4 REPLIES
New Member

Strange EIGRP behavior

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

Hall of Fame Super Silver

Strange EIGRP behavior

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

New Member

Re: Strange EIGRP behavior

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?

New Member

Strange EIGRP behavior

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

279
Views
0
Helpful
4
Replies