Eigrp strange issue

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:

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.

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

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

Scott

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.

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

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

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

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...

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.

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

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

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.