1. Home
  2. Cisco Systems
  3. Eigrp strange issue

Eigrp strange issue

Hi all, I've got a strange issue with a 3620 which is an hub for 25 eigrp peers.

21 of 25 peers are connected trough gre tunnels, which are working quite well, but when the isp connection fails for a few seconds or when the router gets reloaded, these peers becomes eigrp neighbours but every 90 seconds disappears and reappers until I issue one or more times a "clear ip eigrp neighbours", at this time they reach a stable condition until the next connectivity issue. Here is a "sh ip eigrp neighbours" output when all goes right, the only difference in the bad output is the RTO that reaches 5000 for the gre peers router#sh ip eigrp ne IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 25 172.19.35.2 Tu35 14 00:25:34 112 672 0 52601 24 172.19.40.2 Tu40 11 00:25:35 109 654 0 19278 23 172.19.33.2 Tu33 13 00:25:35 122 732 0 102422 22 172.16.3.51 Fa0/0 14 00:25:35 22 200 0 47943 21 172.19.15.2 Tu15 10 00:25:35 140 840 0 12300 20 172.19.27.2 Tu27 12 00:25:35 116 696 0 12699 19 172.19.18.2 Tu18 11 00:25:36 122 732 0 2105 18 172.16.3.70 Fa0/0 14 00:25:36 23 200 0 16157 17 172.17.3.1 Fa0/1 11 00:25:36 12 200 0 18847 16 172.19.36.2 Tu36 14 00:25:36 77 462 0 102707 15 172.19.30.2 Tu30 14 00:25:36 92 552 0 10395 14 172.19.6.2 Tu6 11 00:25:37 112 672 0 102631 13 172.19.14.2 Tu14 14 00:25:37 73 438 0 111574 12 172.19.29.2 Tu29 14 00:25:37 116 696 0 62650 11 172.19.37.2 Tu37 14 00:25:38 128 768 0 10737 10 172.19.24.2 Tu24 13 00:25:38 134 804 0 14061 9 172.19.38.2 Tu38 14 00:25:38 103 618 0 76314 8 172.19.11.2 Tu11 12 00:25:38 116 696 0 95578 7 172.16.3.2 Fa0/0 11 00:25:38 24 200 0 16147 6 172.19.19.2 Tu19 10 00:25:38 129 774 0 42264 5 172.19.4.2 Tu4 14 00:25:39 74 444 0 7582 4 172.19.9.2 Tu9 11 00:25:39 133 798 0 11155 3 172.19.7.2 Tu7 11 00:25:39 137 822 0 84534 2 172.19.34.2 Tu34 13 00:25:39 68 408 0 44295 1 172.19.16.2 Tu16 10 00:25:39 145 870 0 49718 0 172.19.26.2 Tu26 12 00:25:39 120 720 0 11303

The other 4 peers never gets problems, at the remote peers side all seems ok. I tried 3 ios releases on the 3620 with bad luck, remote peers are a mix of

1601, 1720 and 1721. All releases are 12.3(16) or newer. Bye, Max.
Reply to
Tosh
Loading thread data ...

If you are not using them already, you may try implementing GRE keepalives to take those tunnels down hard when the ISP has an issue:

formatting link
Regards, Steve
formatting link

Reply to
www.networking-forum.com

This seems to me an eigrp issue, tunnel interfaces works well, since I can regularly ping each side of the tunnel, but eigrp seems to have some difficulty to make adjiacencies with peer after an isp issue or a reload? Do you think that keeping gre tunnels down until isp line comes up may solve the issue? Tnx, Tosh.

Reply to
Tosh
1 Are you having Stuck-In-Active (SIA) events ?

  1. Are the remote singled-homed to the one hub?

  2. Are you using the EIGRP stub feature on the remotes?

  1. Do you have internal logging configured on hub? logging buffer 10000 debug no logging console

Please post sh ip eigrp traffic sh ip eigrp nei detail

Reply to
Merv

If your remotes are not configured as stub, this could be part of your problem. A 3620 doesn't really have that much horsepower and EIGRP is very CPU intensive during convergence. Using stub will make that much better. For example a 7200 can only have about 150 EIGRP neighbors when not using stub, but can support well over 800 stub neighbors. 25 non-stub routers on a

3620 is probably near the edge, but other factors do apply. How big are the circuits between the routers and how many routes do you have? Are the other peers connected to any of the other peers?

Scott

Reply to
thrill5

Hi Merv, in response to your questions I give you some outputs, some complete, some with only relevant parts. At the time these outputs were capured the peer 172.19.9.2 was the only that showed the issue.

3620 outputs:

interface Tunnel19 bandwidth 4000 ip address 172.19.19.1 255.255.255.252 keepalive 10 3 tunnel source Loopback0 tunnel destination x.x.x.x tunnel key 3061963 . . router eigrp 100 redistribute static route-map redistat passive-interface ATM1/IMA1 passive-interface ATM1/IMA1.1 network 172.16.0.0 network 172.17.3.0 0.0.0.3 network 172.19.0.0 distribute-list 2 out FastEthernet0/0 distribute-list 1 out FastEthernet0/1 distribute-list 3 in FastEthernet0/1 distance eigrp 80 80 no auto-summary no eigrp log-neighbor-changes . . logging trap debugging logging facility local5 logging 172.16.3.40 logging 172.16.3.35

hub#sh ip eigrp ne det IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num

4 172.19.9.2 Tu9 12 00:00:39 1 5000 4 118 Last startup serial 42362 Version 12.3/1.2, Retrans: 8, Retries: 6 Stub Peer Advertising ( CONNECTED ) Routes Suppressing queries UPDATE seq 179192 ser 40856-40885 Sent 34096 Sequenced UPDATE seq 179193 ser 40886-40915 Sequenced UPDATE seq 179194 ser 40916-42362 Sequenced UPDATE seq 179196 ser 42363-42363 Sequenced

hub#sh ip eigrp top det IP-EIGRP Topology Table for AS(100)/ID(85.44.245.129)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status . . P 172.16.9.0/24, 1 successors, FD is 13465600, U, serno 42363, refcount 1, anchored via 172.19.9.2 (13465600/281600), Tunnel9 P 172.17.8.0/30, 1 successors, FD is 307200, tag is 1, serno 40905 via 172.17.3.1 (307200/281600), FastEthernet0/1 P 172.19.9.0/30, 1 successors, FD is 13440000, serno 40997 via Connected, Tunnel9

Note: 172.16.9.0 is the network announced by 172.19.9.2 peer

hub#sh ip eigrp ne IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num

4 172.19.9.2 Tu9 14 00:00:14 1 5000 4 140 25 172.19.35.2 Tu35 13 16:25:58 110 660 0 52744 24 172.19.40.2 Tu40 14 16:25:58 115 690 0 19421 23 172.19.33.2 Tu33 10 16:25:58 93 558 0 102565 22 172.16.3.51 Fa0/0 14 16:25:58 107 642 0 48363 21 172.19.15.2 Tu15 14 16:25:58 137 822 0 12443 20 172.19.27.2 Tu27 13 16:25:59 96 576 0 12842 19 172.19.18.2 Tu18 11 16:25:59 144 864 0 2248 18 172.16.3.70 Fa0/0 14 16:25:59 105 630 0 16299 17 172.17.3.1 Fa0/1 13 16:25:59 106 636 0 18990 16 172.19.36.2 Tu36 11 16:25:59 110 660 0 102850 15 172.19.30.2 Tu30 10 16:26:00 100 600 0 10538 14 172.19.6.2 Tu6 11 16:26:00 103 618 0 102774 13 172.19.14.2 Tu14 14 16:26:00 101 606 0 111717 12 172.19.29.2 Tu29 12 16:26:01 116 696 0 62793 11 172.19.37.2 Tu37 12 16:26:01 118 708 0 10880 10 172.19.24.2 Tu24 12 16:26:01 112 672 0 14204 9 172.19.38.2 Tu38 14 16:26:01 112 672 0 76457 8 172.19.11.2 Tu11 10 16:26:01 113 678 0 95721 7 172.16.3.2 Fa0/0 11 16:26:01 105 630 0 16289 6 172.19.19.2 Tu19 10 16:26:02 143 858 0 42407 5 172.19.4.2 Tu4 14 16:26:02 102 612 0 7725 3 172.19.7.2 Tu7 11 16:26:02 167 1002 0 85035 2 172.19.34.2 Tu34 11 16:26:02 115 690 0 44814 1 172.19.16.2 Tu16 12 16:26:02 131 786 0 49861 0 172.19.26.2 Tu26 14 16:26:02 121 726 0 11446

1601 remote peer outputs:

interface Tunnel9 bandwidth 4000 ip address 172.19.9.2 255.255.255.252 keepalive 10 3 tunnel source Loopback0 tunnel destination y.y.y.y tunnel key 3061963 . . router eigrp 100 passive-interface Serial0.1 network 172.16.0.0 network 172.19.0.0 distribute-list 1 out Tunnel9 no auto-summary eigrp stub connected

remote#sh ip eigrp ne IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num

0 172.19.9.1 Tu9 13 00:00:10 479 2874 0 180317

Strange enough are the SRTT and RTO values, since I can ping both peers with an rtt of approx.60ms. I noted that the bandwidth value in the tunnel interfaces was quite high, so I adjusted the values from 4000 to 1000 and the issue disappeared, does it make some sense or is it only fate? Tnx, Tosh.

"Merv" ha scritto nel messaggio news: snipped-for-privacy@u72g2000cwu.googlegroups.com...

Reply to
Maxximo

Hi Scott, as you can see in the reply I sent to Merv, all the gre peers are configured as stub, only the remaining 3 peers are not configured as stub because is not applicable (2 of them are transit peers and the last is redistributed by bgp so the stub info is lost). Tnx, Tosh.

Reply to
Maxximo

The interface bandwidth setting is actually quite important.

EIGRP will use up to 50 percent of the bandwidth of a link, as defined by the bandwidth interface configuration command.

see the interface command "ip bandwidth-percent eigrp "

BTW It is good that you are using EIGRP stub feature in your network

Reply to
Merv

Also did you adjust the tunnel bandwidth on each of the remote routers ?

Reply to
Merv

Actually I've adjusted the bandwidth value only on the router that had the issue this morning, I've planned to do it on the other remotes asap. It's a little too early to say that, but the situation seems to be stable now, I'm confident for the issue to be solved this way, Can you think of any other cause for this issue? Thanks a lot, Tosh.

Reply to
Tosh

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.