A bit about ip sla / rtr in Cisco ...

I read two articles " Dual ISP on cisco routers without BGP " and " Simultaneous use of two providers on cisco routers ." The idea came to mind to try to draw and describe the solution to another, slightly non-standard problem.
So, consider a simple example. There is a client and there are two providers (uplink). We do not have an autonomous system for building BGP-peers, but we need to work when one channel drops. At the same time, we have an internal client of our network that does not work like everyone else, but exactly the opposite. In normal (both channels are working) this client still goes through the backup channel (Dialer1), while everyone works on the main (Dialer0) and switches to the main channel only if the backup (!) Drops (sometimes such).

One of the possible solutions (so to speak, "in the forehead") may look like this:

  interface vlan1
  ip address 192.168.0.1 255.255.255.0
  ip policy route-map tracking
 !
 route-map tracking permit 10
  match ip address 1
  set default interface Dialer1 Dialer0
 !
 route-map tracking permit 20
  match ip address 2
  set default interface Dialer0 Dialer1
 !
 access-list 1 permit 192.168.0.101
 access-list 2 deny 192.168.0.101
 access-list 2 permit 192.168.0.0 0.0.0.255 

Yes, this design works, but there is one drawback, and not enough obvious.
There may be such a situation that both the status and the protocol may be in the Up state, and the channel may not work. Then this design will not help.
What to do? It's very simple: use the features of sla.
What do we need for this? You just need to rewrite the route-map tracking and write the rules for sla.

  interface vlan1
  ip address 192.168.0.1 255.255.255.0
  ip policy route-map tracking
 !
 track 123 rtr 1 reachability
 !
 track 124 rtr 2 reachability
 !
 ip sla 1
  icmp-echo 195.5.5.208 source-interface Dialer1
  timeout 2000
  threshold 2
  frequency 3
 ip sla schedule 1 life forever start-time now
 ip sla 2
  icmp-echo 193.34.140.1 source-interface Dialer0
  timeout 2000
  threshold 2
  frequency 3
 ip sla schedule 2 life forever start-time now
 !
 route-map tracking permit 100
  match ip address 1
  set ip next-hop verify-availability 195.5.5.208 10 track 123
  set ip next-hop verify-availability 193.34.140.1 20 track 124
 !
 route-map tracking permit 120
  match ip address 2
  set ip next-hop verify-availability 193.34.140.1 10 track 124
  set ip next-hop verify-availability 195.5.5.208 20 track 123
 !
 route-map tracking permit 200
  set ip next-hop verify-availability 195.5.5.208 10 track 123
  set ip next-hop verify-availability 193.34.140.1 20 track 124
 !
 access-list 1 permit 192.168.0.101
 access-list 2 deny 192.168.0.101
 access-list 2 permit 192.168.0.0 0.0.0.255 

Actually everything is trivially simple. ;)
The route-map stops processing its rules for the packet after it finds the first match. Therefore, in fact, the procedure for determining sequences is important!
Now, if we look at the state of the interfaces, we will see:

  #sh ip int br |  i ^ Dialer
 Dialer0 193.34.141.151 YES IPCP up up
 Dialer1 unassigned YES IPCP up up 

At the same time, we see that both the status and the Dialer1 protocol are in the up state, i.e. the first route-map tracking option would not work and the client 192.168.0.101 simply would not work. But if we look at the statistics on route-map tracking from the second option, we will see:

  #sh route-map tracking
 route-map tracking, permit, sequence 100
   Match clauses:
     ip address (access-lists): 1 
   Set clauses:
     ip next-hop verify-availability 195.5.5.208 10 track 123 [down]
     ip next-hop verify-availability 193.34.140.1 20 track 124 [up]
   Policy routing matches: 711 packets, 95929 bytes
 route-map tracking, permit, sequence 120
   Match clauses:
     ip address (access-lists): 2 
   Set clauses:
     ip next-hop verify-availability 193.34.140.1 10 track 124 [up]
     ip next-hop verify-availability 195.5.5.208 20 track 123 [down]
   Policy routing matches: 216 packets, 14100 bytes
 route-map tracking, permit, sequence 200
   Match clauses:
   Set clauses:
     ip next-hop verify-availability 195.5.5.208 10 track 123 [down]
     ip next-hop verify-availability 193.34.140.1 20 track 124 [up]
   Policy routing matches: 0 packets, 0 bytes 

The state in ip next-hop verify-availability 195.5.5.208 10 is designated as down, and accordingly these routes will not be installed.

ps: Many comments that could be inserted are omitted, since it is implied that the two articles mentioned above have been read, and therefore the reader knows what is being said.