FlexVPN Hub and Spoke backup routes

When deploying a hub and spoke FlexVPN topology, it is possible to create backup routes in the routing table that will be used in the event that the FlexVPN topology fails. However, there are some behaviors of the FlexVPN topology that must be taken into account when applying such backup routes.

In a FlexVPN Hub and Spoke setup, backup routes do not load automatically when the hub fails because the spoke routers are still maintaining an active IPSec Security Association (SA) with the hub. The virtual-access interfaces that are associated with the IPsec SAs remain up, even though the hub is no longer reachable. This is because the routing used in the setup is not aware of the underlying IPsec tunnel’s actual state. Otherwise, any backup routes would kick in.

Issuing the clear crypto session command forces the IPsec SAs to be torn down and the associated virtual-access interfaces to be removed. This triggers the routing to re-evaluate the routes and load the backup routes into the routing table.

If left to itself, the SA will remain up for the configured lifetime duration, which by default is 86400 seconds or one full 24-hour day.

One solution to this behavior is to reduce the lifetime to something on the order of several seconds, but this will cause the router to reestablish the SA continually, which may not cause disruption to the network, but will increase the burden of resources on the router.

Another solution is to automate the process of issuing the clear crypto session command in the event the hub fails. This can be done using Cisco's Embedded Event Manager (EEM) with an IP SLA where the clear command can be run whenever communication with the hub has failed.

Similarly, when any hub failure has been restored, FlexVPN connections take some time to reestablish and reach the original stable topology. This is because of a related issue. If the SAs on the spokes haven’t expired yet when the hub comes back up, they will still be active, so the spokes won’t attempt to reestablish the new SAs with the hub. The spokes will wait until the SAs time out before attempting to reestablish. If Dead Peer Detection (DPD) is activated, which is a mechanism used by IPSec VPN devices to detect if the remote peer is still alive. The default timeout is 30 seconds with a retry interval of 10 seconds. The delay in detecting the peer’s state can affect the reestablishment of the connections.

https://networklessons.com/cisco/ccie-enterprise-infrastructure/flexvpn-hub-and-spoke https://networklessons.com/cisco/ccie-routing-switching-written/cisco-ios-embedded-event-manager https://networklessons.com/cisco/ccie-routing-switching-written/ip-sla-eem-script