EIGRP neighbors flapping through GRE tunnel

[santipongv]

I have 7 remote locations connect to our main site through IPSec VPN. I also have GRE tunnel established between remote locations and our main site. EIGRP neighbor is established through GRE tunnel. Lately, EIGRP neighbors have been flapping more frequent. Internet service did not go down at the remote sites when EIGRP flapped. Any thoughts of what might be causing this problem?

Jan 22 13:59:30.489: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 192.168.62.81 (Tunnel7) is down: holding time expired

Jan 22 13:59:31.081: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 192.168.62.73 (Tunnel6) is down: holding time expired

Jan 22 13:59:31.369: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 192.168.62.57 (Tunnel2) is down: holding time expired

Jan 22 13:59:32.565: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 192.168.62.65 (Tunnel4) is down: Interface Goodbye received

Jan 22 13:59:33.721: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 192.168.62.25 (Tunnel1) is down: holding time expired

Jan 22 13:59:33.986: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 192.168.62.85 (Tunnel8) is down: Interface Goodbye received

Jan 22 13:59:34.142: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 192.168.62.45 (Tunnel3) is down: holding time

Thank you.

[royalblues]

This may mostly be due to to recursive routing problem over the tunnel interfaces

Make sure your tuunnel Destiantion and source are not learned via EIGRP

Have a look here for more information

http://www.cisco.com/warp/public/105/gre_flap.html

HTH

Narayan

[mounir.mohamed]

As my friend mentioned this is one of the reasons behind such flaps, but for clarity please share your configurations.

Best Regards,

Mounir Mohamed

[smitty6504]

Have you tried adjusting your hello timers? You might want to debug EIGRP on both sides and post them.

[Richard Burts]

The recursive routing theory is a good suggestion given the lack of detail in the original post, but almost certainly not the explanation. I am running a bunch of IPSec/GRE tunnels with EIGRP as the routing protocol and I see the same type of neighbor flapping - and I know in my case that it is not a recursive routing problem.

We did find that adjusting the EIGRP timers (make them longer) reduces the incidence but does not solve the problem.

I have not gotten a much better theory of the problem beyond the possibility that packet loss may be dropping enough EIGRP hellos to provoke the timeouts. I would be very curious to know if anyone else has experienced this and has found an explanation for it.

HTH

Rick

[santipongv]

I am not quite conviced that recursive routing is the culprit since I am not getting "%TUN-5-RECURDOWN" error messages. I will provide the config shortly.

[santipongv]

R1-VPN#

!

interface Tunnel2

description IPSEC Tunnel endpoint to Chan-PRI-Tunnel2

bandwidth 768

ip address 192.168.62.57 255.255.255.252

ip authentication mode eigrp 200 md5

ip authentication key-chain eigrp 200 secure-chain

ip tcp adjust-mss 1300

keepalive 10 3

cdp enable

tunnel source Loopback2

tunnel destination 192.168.62.33

crypto map Shaftervpn

end

ip route 0.0.0.0 0.0.0.0 192.168.62.58

Hub#

!

interface Tunnel2

description R1-VPN-Tunnel

bandwidth 1544

ip address 192.168.62.58 255.255.255.252

ip authentication mode eigrp 200 md5

ip authentication key-chain eigrp 200 secure-chain

ip tcp adjust-mss 1300

keepalive 10 3

cdp enable

tunnel source Loopback2

tunnel destination 192.168.62.32

ip route 192.168.162.254 255.255.255.255 192.168.62.57

[Richard Burts]

Santipong

Thank you for posting the tunnel configuration. There are a couple of things that may be worth commenting about (though I am not sure that they are related to the issue of EIGRP neighbor flapping):

- I am surprised at the static default route in R1-VPN (ip route 0.0.0.0 0.0.0.0 192.168.62.58) which uses the IP address of the other end of the tunnel as the next hop. Since the tunnel destination is tunnel destination 192.168.62.33 it would appear that the tunnel destination is reached through the tunnel. This is the classic definition of the recursive routing problem with GRE tunnels. Is there perhaps another static route for the tunnel end point that you did not post?

- I am surprised to see the crypto map assigned to the tunnel interface rather than the physical interface. What version of code is this router running? In older versions of code it was necessary to configure the crypto map on both the physical and the tunnel interface. But that changed and it now needs to be only on the physical interface. Perhaps you are running a version that needs both. But if not, then I have seen some strange behaviors that seems to relate to having the map on the tunnel when it did not need to be.

- I am a bit puzzled by the static route on the Hub router. It obviously is some host address reached via the GRE tunnel. But what is it? And are there other static routes defined on this router?

HTH

Rick

[santipongv]

Rick,

1.

ip route 0.0.0.0 0.0.0.0 192.168.62.58

ip route 0.0.0.0 0.0.0.0 192.168.182.1 240 <== ISDN Backup

ip route 192.168.62.33 255.255.255.255 10.255.255.5 <== Firewall Interface (Physical path)

2.

12.4(13d)

3.

It is the Loopback0 IP address of the R1-VPN

[Richard Burts]

Santipong

1) Having the primary static default route point to the next hop over the tunnel seems to invite the recursive routing problem since any unknown destination will be routed through the tunnel - I worry that the router will attempt to get to the tunnel destination through the tunnel.

Having a floating static through ISDN backup does not make it much better.

2) 12.4(13d) is certainly recent. Is there any reason to have the crypto map on the tunnel?

Is the crypto map also on the physical interface (which you have not included in what you posted)?

I highly recommend that you remove the crypto map from the tunnel interface.

3) Did you really mean loopback2 instead of loopback0? If so pointing the tunnel destination as being reachable via the next hop of the remote tunnel interface is another invitation to the recursive routing problem.

If not what is loopback0 and how does it relate to this question?

HTH

Rick

[santipongv]

Rick,

I have updated configurations on both ends as shown below. Please advise.

R1-VPN#

!

interface Tunnel2

description IPSEC Tunnel endpoint to Hub-Tunnel2

bandwidth 768

ip address 192.168.62.57 255.255.255.252

ip authentication mode eigrp 200 md5

ip authentication key-chain eigrp 200 secure-chain

ip tcp adjust-mss 1300

keepalive 10 3

cdp enable

tunnel source Loopback2

tunnel destination 192.168.62.33

crypto map Shaftervpn <== I will remove this statement

interface Loopback2

description Loopback for VPN IPSEC Tunnel termination from Hub

ip address 192.168.62.32 255.255.255.255

no ip redirects

no ip unreachables

no ip proxy-arp

ip route-cache flow

interface Loopback0

ip address 192.168.162.254 255.255.255.252

no ip redirects

no ip proxy-arp

ip route 0.0.0.0 0.0.0.0 192.168.62.58

ip route 0.0.0.0 0.0.0.0 192.168.182.1 240 <== ISDN Backup

ip route 192.168.62.33 255.255.255.255 10.255.255.5 <== Firewall Interface (Physical path)

Hub#

!

interface Tunnel2

description R1-VPN-Tunnel

bandwidth 1544

ip address 192.168.62.58 255.255.255.252

ip authentication mode eigrp 200 md5

ip authentication key-chain eigrp 200 secure-chain

ip tcp adjust-mss 1300

keepalive 10 3

cdp enable

tunnel source Loopback2

tunnel destination 192.168.62.32

!

interface Loopback2

description R1-VPN

ip address 192.168.62.33 255.255.255.255

no ip redirects

no ip unreachables

no ip proxy-arp

ip route 192.168.162.254 255.255.255.255 192.168.62.57

Regards,

Santi

[Richard Burts]

Santi

I believe that this is better. I still would like to see the crypto map statement removed from the tunnel on the R1-VPN. And the Hub static route that you show is to loopback 0 but the tunnel is using loopback 2. There should be a route to loopback 2 that does not involve traffic going through the tunnel. Is there other routing information for loopback 2 on R1-VPN that we are not seeing?

HTH

Rick

[santipongv]

Rick,

I will remote crypto map statement from the tunnel interface on the R1-VPN. As for Hub, route to loopback 2 is learned via eigrp. There is no other static route statement. With these configuration statements, do you still believe that I am experiencing "recusive routing"?

Regards,

Santi

[Richard Burts]

Santi

I am slightly concerned that you are learning the loopback 2 address (the tunnel destination) via EIGRP since this is one of the steps to the recursion problem. And I believe that it would be somewhat better if there were a static route on the Hub for the loopback 2 on R1-VPN. But I do not believe that you are experiencing recursion on the tunnel interface. If you were experiencing that there would be error messages about it in the log. And the tunnel interface would go down and then come back up instead of just having the EIGRP neighbor relationship down and up.

As I said in my first post in this thread, I believe that the symptoms that you describe are not due to recursion on the tunnel. I believe that they are due to something else. But I am not clear what the something else is. Having cleaned up some parts of your configuration, I would be curious to know if your symptoms change any?

HTH

Rick

[santipongv]

Rick,

We have similar set up at other locations, I removed crypto map statement from Tunnel interface. I am still experiencing similar problem but less frequent.

Regards,

Santi