IP SLA Route Tracking on host routes (/32)

[jerecassidy]

Greetings! Thanks for the help in advance.

I have a situation where the SLA target I want to test against to control a route insertion (redistribution via eigrp) will start to succeed when traffic is redirected via an alternate path.

Consider the following topology where HOST_A is reachable via two different patchs

HOST_A <-WAN-> CUST_A  <----->  NXOS Switch <--->   EIGRP IP network  <--->  IOS ROUTER <-----> CUST_B <-WAN-> HOST_A

Currently, On NXOS Switch, I am somply tracking against the directly connected interface of CUST_A device.   On the IOS Router, I am doing the same against the directly connected interface of CUST_B device.  THen based on these results, I am injecting the host route HOST_A/32.   Unfortunately, these tests don't really test anything beyond the status of the directly connected device.  I do not have control of the CUST_A and CUST_B devices.

The configuration is pretty simple:

track 40 ip sla 41 reachability
delay up 10 down 10

ip sla 41
icmp-echo CUST_A source-ip NXOS_Switch
threshold 2000
frequency 5
ip sla schedule 41 life forever start-time now

ip route HOST_A/32 CUST_A track 40

But I want to actually test a TCP connection to HOST_A.  I cannot use ICMP to test as the WAN is locked down.  So here's an attempt:

track 50 ip sla 51 reachability
delay up 10 down 10

ip sla 51
tcp-connect HOST_A 80 source-ip NXOS_Switch control disable
timeout 15000
frequency 20
ip sla schedule 51 life forever start-time now

ip route HOST_A/32 CUST_A track 50

Here's the problem.  When HOST_A becomes unreachable via NXOS_Switch, the route is removed, but then the backup route via IOS_Router becomes preferred and then the tracking begins to succeed again (via IOS_Router).  Then the routes are inserted again, they fail, and are replaced in a cycle.   

I thought maybe I could solve this with a ip local policy route-map that would match the SLA probe and push it out toward the CUST_A device no matter what the state of the routing table, but the NXOS does not appear to have support for that (PBR demands an input interface).

I could also prevent the probes from NXOS_Switch by placing an access list on the interface between IOS_Router and CUST_B (and prevent probes from IOS_ROUTER from transiting the NXOS_Switch to CUST_A boundary).   ALthough in this scenario - the routes would never recover. Tests would continue to follow the alternative route and never succeed.

So - what's the best way to accomplish something like this?

Thanks again!

[Collin Clark]

Have you looked into using multiple sla monitors and the boolean operation? You can insert the route only if 1) the WAN IP is not pingable and 2) the backup route is up

[jerecassidy]

Thanks for the reply Collin!  

I believe that's not what I need - I need the test to the host to not be influenced by the route itself.  i.e.  I'd like my test data (from the sla configuration) to be routed on the same path (across CUST_A) regardless of the status of the inserted route (which would shift from CUST_A toward CUST_B).  

Thanks.

-Jere

[Collin Clark]

Ah. Yes that's an issue when you track remote hosts. One option would be to use an ACL to block the IP SLA traffic. It can be very specific so failover will still work.

ip access-list extended IPSLA-BLOCK
 deny tcp host [source IP of SLA] host [HOST_A] eq [TCP port]
 permit ip any any

Think this will work? BTW how does the IOS_ROUTER know about CUST_A HOST_A? Is there a backup link off of him? Is it learned via an IGP? Instead of IPSLA and tracking could you do a floating static?