SAA is only part of the solution. SAA monitors some target (for example, ping some IP address not necessarily next-hop). The other part of the solution is to read status of that monitor object (this process is called tracking) and install a route if status is OK. In reverse that also means that if after route has been installed the check fails (e.g. SAA didn't receive reply) then the route will be removed. Cisco refers to this method as 'reliable static routing'. The solution is very simple and yet it's powerful. As a monitoring target it's better to specify not just next-hop router, but something more meaningful for determining whether link is usable.
There is one catch using reliable static routes, or routes with tracking - if the route is down, how does SAA reach target? Looks like it's gonna be down all the time unless route is installed. And if route is installed what's the point of tracking? Similar to chicken and egg issue. To resolve this loop, SAA tracking is often implemented together with policy-routing that will ensure that probe packets are always sent via particular interface.
We use 'reliable static routing' all the time when more than one link provisioned to a site, unless specific situation demands dynamically learn routing information. Only then we'll put a dynamic routing protocol. We use ordinary static routes only in situations where there is only one line to a site (what's point to monitor it - if it doesn't work we haven't got anything else anyway, so no complexety).
in the diagram you have provided, if the link between rtr4 & rtr6 goes down, then the only path available to 10.20.20.0/24 is via 192.168.2.2
the problem is that rtr1 still knows of 10.20.20.0/24 via 192.168.1.2 is a better cost then 192.168.2.2. (this is due to your staticRoute via 192.168.1.2)
this happens because rtr1 has no idea that 10.20.20.0/24 is not reachable via 192.168.1.2. even if the link between 4 & 6 goes down, rtr1 knows to get to 10.20.20.0/24 it must send the packet to 192.168.1.2.
if you used a routing protocol through 1, 2, 4 & 6 at least with a floatingStaticRoute pointing to 192.168.2.2, then you could acheive a link outage between 4 & 6 and the routers would adjust their tables via routingProtocol and the floatingStaticRoute (that has the higher cost) would be used.
it may be best to implement a basic eigrp or even rip to get basic link status/routing updates.
(of course, if you use a routing protocol such as eigrp or even rip throughout all routers, there should be no need for a floatingStaticRoute with your design)
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...