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
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
ip unnumbered Loopback0
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
network XXX.XXX.XXX.0 0.0.0.255
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.
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?
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.
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:
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.
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.
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.
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.