Trying to implement a static route with the 'while host responds to ping' option being used as a fail over mechanism but it isn't working as expected.
We have 9 sites inter-connected by site-site vpn in mesh mode, there are 3rd party routers for a hosted app at 2 sites and we advertise routes into the sd-wan so that the other sites can communicate to the subnet of the hosted app. There are 2 routes to the same subnet, one to be the primary and the other to be the backup route should the primary go down. The primary is a /27 route while a host in that subnet responds to ping and the backup is a /24 route via the other site. Tried disabling the interface connected to the primary router to simulate a failure but it doesn't drop the route and start using the backup, in theory this should work right or have I misunderstood?
The 2 routes work independently because if I manually disable the primary traffic routes fine over the backup.
Static routes can be configured with three different availability settings:
Active while the next hop responds to ping
Active while host responds to ping
If the static route is always active, the configured static route will always be maintained in the routing table.
When a route is configured as "Active while the next hop responds to ping", or "Active while a host responds to ping", the MX tracks the route. If the MX stops receiving ping responses for a period of time, the route will be removed from the routing table. The route is re-added when responses are received again.
Note: If a route is configured as "Active while host responds to ping", the configured host IP must lie within the subnet configured for the static route
Note: If a static route is configured with the "Active while host responds to ping" option, both the next-hop and the specified host need to be able to respond to pings. If either IP address stops responding to pings, the route will be marked as down and will be removed from the MX's route table.
The route tracking mechanism only has local significance, which means, that the status of the route doesn't influence whether the route is advertised or not and it won't affect the routing on the remote end of the VPN.
I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.
Please, if this post was useful, leave your kudos and mark it as solved.