GRE / VTI Tunnel Will Never Go Admin Down

[kkirk1979]

I have a tunnel to a remote site that refuses to go down when the destination becomes unreachable. The SAs remain active and the tunnel remains up. This is an issue because EIGRP will recognize when the far side becomes unreachable and drop the route, however once the far side comes back up EIGRP does not re-create the route.

This side of the tunnel is going through a NAT while the other is direct. The tunnel sets up and works perfectly fine as long as there is no physical disconnect.

Manually bringing the tunnel down and then back up will wake EIGRP up.  This was working previously, however I cannot find a sufficiently old configuration to compare against. All of my backup configs appear to be the same when it comes to ISAKMP, EIGRP, and the tunnel.

I also tried adding a keepalive to the tunnel, however this appears to have no affect. I also notice that my SA for this tunnel never shifts from QM_IDLE, even if I set an idle timeout of 30 seconds or a lifetime of 120 seconds.

Relevant Config Snippets:

!

crypto isakmp policy 1

encr aes 256

authentication pre-share

group 2

lifetime 28800

crypto isakmp key KEY#1 address XXX.XXX.XXX.XXX

!

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association idle-time 300

!

crypto ipsec transform-set VPN-1 esp-aes 256 esp-sha-hmac

crypto ipsec df-bit clear

!

crypto ipsec profile KU-VPN

set transform-set VPN-1

!

!

!

interface Tunnel17

bandwidth 380

ip unnumbered Loopback0

delay 4000

tunnel source VlanX

tunnel destination XXX.XXX.XXX.XXX

tunnel mode ipsec ipv4

tunnel protection ipsec profile KU-VPN

!

All interfaces are passive except for the tunnel.

!

router eigrp 2222

passive-interface Vlan1

passive-interface Vlan3

passive-interface Vlan4

network XXX.XXX.XXX.0 0.0.0.255

no auto-summary

eigrp stub connected

!

If you have any ideas why the tunnel destination going down would not cause the tunnel to go down, or the SAs to die, please let me know.

-Ken

[Talha Ansari]

How is the tunnel destination reachable.. is it reachable by static route or some other protocol...can you share the configuration related to this? Also when you configured keepalives, did you configure keepalives at both ends of the tunnel?

Regards,

Talha

[kkirk1979]

Thank you for the response. I can't provide the exact configuration as I do not have access at the moment, but it is not complicated.

The far end of the tunnel is reachable by a weighted static route, 0.0.0.0 0.0.0.0 192.168.0.1 200, where 192.168.0.1 is actually a satcom modem. This works because after the tunnel is built the EIGRP routes passed over the tunnel are a lower weight and are preferred over the static route (but the physical connection is not one of the routes advertised by EIGRP).

The keepalive was just thrown in for troubleshooting from my side and does not exist on the other. Keepalive 3 5 I think I used. It doesn't seem to matter in the slightest as even when the link is physically disconnected the keepalives do not bring down the tunnel.  I simulate "outages" by physically disconnecting the link to my modem.

-Ken

[Peter Paluch]

Hello Ken and Talha,

Please allow me to join this thread and share a couple of observations.

First of all, GRE keepalives are not supported with crypto profiles. This fact is somewhat obscure but can be found here:

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008048cffc.shtml#prob

Second, the GRE tunnel seems to be using IP Unnumbered configuration, borrowing its IP address from the Loopback0. Is this IP address perhaps being also used as the endpoint of the tunnel (i.e. configured on the opposite tunnel endpoint as the tunnel destination)? That would cause a recursive routing with the tunnel reaching its own endpoint via itself.

Best regards,

Peter

[Talha Ansari]

Hello Peter... u r welcome!

Thanks for sharing the doc... I wasn't aware about this.

About the same IP address been used at the other end in that case I m not sure if EIGRP will form neighborship over the tunnel. The loopback IP addresses at both ends may be of the same range as the widcart bits for network advertised in EIGRP is /24. May be Kenneth could elaborate on this detail.

Regards,

Talha

[kkirk1979]

The Loopback that the tunnel is tied to shares only the /8 with the destination address (I.E. xxx.yyy.yyy.yyy is loopback, xxx.xxx.xxx.xxx is destination).

I don't believe there are any loopback issues, and EIGRP does correctly set up across the link initially. The issue only arises when the tunnel is supposed to fail but does not.

Thank you,

-Ken

[Talha Ansari]

Hi Kenneth,

Then I believe the option available to you is to configure the router with the traditional GRE over IPSEC instead of using tunnel with a crypto profile if thats feasible... apply a crypto map on the physical interface. It would be good option to have a seperate /30 subnet for the tunnel ip addresses and set keepalives on tunnel in a GRE over IPSEC.

Regards,

Talha