Hi all,

I'm having some trouble with running EIGRP over an unencrypted GRE tunnel. On one end I have a 6500 with a Sup32 (R1) and on the other end a 2821 (R2).

The tunnel configuration is very simplistic (obviously I've pulled our IPs from the config):

R1

  interface Tunnel0
   ip address 172.29.29.1 255.255.255.252
   ip nat outside
   ip tcp adjust-mss 1400
   tunnel source 1.1.1.1
   tunnel destination 2.2.2.2
   tunnel key 1
  end

R2

  interface Tunnel0
   ip address 172.29.29.2 255.255.255.252
   ip nat outside
   ip virtual-reassembly
   ip tcp adjust-mss 1400
   tunnel source 2.2.2.2
   tunnel destination 1.1.1.1
   tunnel key 1
  end

With the tunnel up, I can ping both sides with a latency of 30ms consistently without issue.

The EIGRP configuration is equally simple (again, pulled our IPs from the config):

R1

  router eigrp 100
   network 3.3.3.0 0.0.0.255
   network 4.4.4.0 0.0.0.255
   network 172.29.29.0 0.0.0.3
   no auto-summary

R2

  router eigrp 100
   network 5.5.5.0 0.0.0.255
   network 6.6.6.0 0.0.0.255
   network 172.29.29.0 0.0.0.3
   no auto-summary

Now, while this works in that the EIGRP adjacency is formed and the routes for the other networks are properly exchanged, the latency on the pings over the GRE tunnel go nuts - up to 800ms, with lots of dropped packets (which results in Goodbyes being received and dropped adjacency, which results in my BGP flapping which is ultimately what I'm doing with these routes on the other side).

The weird thing is - sometimes this doesn't happen and it will run for hours at 30ms with everything running sweet and then for no apparent reason it will go nuts.

If I disable the EIGRP propagation over the GRE tunnel (ie 'no network 172.29.29.0') the latency returns to normal immediately.

The CPU usage of of the 6500 never peaks above 25% and the 2821 never about 10%.

I've read about recursive routing with EIGRP if you are learning the tunnel destinations, but that's not the case for me the - the tunnel source and destinations are static ISP assigned link addresses, while the routes I'm propagating are portable BGP ranges.

None of the debugging I've enabled has given me a clue, except that the EIGRP hold timer expires on the 6500 while the latency is really high. I've tried increasing the hold/hello timers on both sides and while that limits the number of EIGRP downs it doesn't change the huge latency or dropped packets across the tunnel.

Ideas? Any help is appreciated.

Regards,
Johan