FTD IP SLA using Dynamic Default Routes

[ChrisNye]

I am using FTDv version 7.3 FDM to configure policy-based VPN using a Hub and Spoke topology in a lab environment. The spoke's VPN profile uses two different outside interfaces as it's source (outside1 & outside2). Each spoke dynamically pulls it's outside IP address and default route from a primary and secondary ISP to support redundant path failover (Static is not an option).  My issue is that IP SLA monitors can only be assigned to manually configured static routes. Is there an alternative solution for failover? I have also configured a Remote Backup peer using the secondary outside interface as the source, but this does not failover when the primary interface is manually shutdown. I am wondering if that issue is a bug with the virtual FTD and not necessarily something that will be an issue with the hardware version of the software. 

[Marius Gunnerud]

You could look into ECMP, though I am a little unsure how that would work when you receive the routes from the ISP...I think it would work the same as if you had dynamic routing configured. 

https://www.cisco.com/c/en/us/td/docs/security/firepower/730/fdm/fptd-fdm-config-guide-730/fptd-fdm-routing.html#ID-2101-0000004d

Another option would be PBR, though this would not be an automatic failover to the backup ISP should the primary ISP fail...though perhaps could look into some EEM configuration to automate this.  But that would start to become unnecessarily complex.

As for the failover issue.  This is is not a bug.  You are running FTDv, the interfaces on the FTDv are never actually down since the virtual interfaces connecting the FTDv to the host machine are always active, and therefore will never failover. Second, shuting down an interface will not initiate a failover as this is a graceful shutdown.  You would need to simulate an actual link failure, i.e. unplug a network cable for this to work, and even then there are other functions that come into play that the FTD uses to make sure that this is an actual failure scenario.

The only reason to have HA on and FTDv is for hardware redundancy, if you have both FTDv on the same host machine it is just a waste and taking up space and resources.

[ChrisNye]

Thank you for your response. The document you linked to states that ECMP Traffic Zones cannot contain “Interfaces used for site-to-site VPN or remote access VPN connections.”
Your explanation of the FTDv interfaces makes sense. I was using it FTDv to test out the FTD software until I receive the ISA3000 to use in production. In the lab I configured the primary outside interface to pull a dynamic IP and default route from ISP1 with a statically assigned administrative distance of 1 and for the secondary outside interface to dynamically pull an IP and default gateway from ISP 2 with a statically assigned administrative distance of 2. My assumption is that if the primary outside interface goes down for any reason the primary default route will be removed from the routing table and the secondary default route will take its place. Is that safe to assume using a FTD hardware appliance?

Ultimately, I would like to monitor the link using SLA’s so that automatic failover can occur if the distant end is unreachable but doesn’t seem like an option in my scenario. Is EEM an option for FTD? If that’s the only way to monitor the routes it may be worth the complexity based of my scenario it.

Thanks again!

[tvotna · Accepted solution]

Yes, if interface goes down, all routes through this interface are removed. And yes, next-hop cannot be omitted when a static route is configured on ASA/FTD, so you definitely need to know ISP1/2 gateway address to configure static routes with tracking and IP SLA.

On ASA EEM can react to syslog messages and execute CLI commands in conf t mode, e.g. add or remove static routes, but I don't see how this can work on FTD where conf t is disabled by default. Yes, you can unlock conf t, but I believe that such configuration are unsupported.

Personally I'd try to solve this puzzle with route-based VPNs, but you'd still need to know ISP1/2 gateway IP in order to configure static /32 routes to HUB1/2. This way you'd have two independent VPNs clouds, one over ISP1 and another one over ISP2 with dynamic routing running over them. Dynamic routing will help with path monitoring and switchover. Newest ASA/FTD versions should support traffic zones on tunnel interfaces, so connections shouldn't fail after switchover (in theory).

[ChrisNye]

Thank you for your clarification and suggestion. The FTD doesn't allow configuration of traffic zones on interfaces used for VTI's when managed through the Firepower Device Manager (FDM). That configuration option is only available through FMC management based on configuration guides. However, using VTIs with the traffic zone is a great solution. Additionally, I am considering sourcing the tunnels from loopback interfaces. I will consider using the ASA software instead of FTD to utilize these features.

[ChrisNye]

I ended up re-imaging the FTD to ASA 9.19(1). I am using DVTI at the Hubs and VTIs at the spokes w/ EIGRP for Load balancing/failover. Thank you for your suggestion.