IP SLA issue

[mansi-mhatre]

Hello Team,

I am facing issue with IP SLA configuration working.

i have 2 networks investment and users and In investment network i have 2 ILL links. Investment and users networks are interconnected through core switches of both the networks.

my requirement is when my both IIL links are down in investment network then my ILL traffic should flow through the users core switch.

the below is my IP SLA configuration on investment core switch:

ip sla 2
icmp-echo 59.144.216.1 source-ip 10.1.123.5
threshold 5000
timeout 5000
frequency 60
exit

ip sla schedule 2 life forever start-time now

ip sla 3
icmp-echo 121.241.211.9 source-ip 10.1.123.5
threshold 5000
timeout 5000
frequency 60
exit

ip sla schedule 3 life forever start-time now

track 4 list boolean and
object 2
object 3
exit

ip route 0.0.0.0 0.0.0.0 10.1.123.5 track 4
ip route 0.0.0.0 0.0.0.0 10.1.122.130

ip route 59.144.216.0 255.255.255.0 10.1.123.5
ip route 121.241.211.0 255.255.255.0 10.1.123.5

track 2 ip sla 2 reachability

track 3 ip sla 3 reachability

Also, I have attached my network architecture diagram below for better understanding.

[Enes Simnica]

Hello. From the configuration, ur IP SLA probes and tracking objects are set up to monitor both ILL links and use track 4 to detect when both are down. However, the failover route to the users’ core may not activate because the backup static route does not have a higher administrative distance, and the specific routes for 59.144.216.0/24 and 121.241.211.0/24 are still forced via the ILL gateway.

So to meet ur requirement, adjust the backup route’s administrative distance so it is only used when track 4 fails, and update the specific subnet routes so they can also switch over to the users’ core when both ILL links are down. You should also test by shutting both ILL links to confirm the routing table updates as expected. 

hope it helps, and ping me if u have more questions…

-Enes

[mansi-mhatre]

hi Enes Simnica,

i have already adjusted the AD value of backup route to 200, but still getting same output.

also, there are no "59.144.216.0/24 and 121.241.211.0/24" such  subnet available in USER network, this are the ILL subnets.

we have added static routes for "59.144.216.0/24 and 121.241.211.0/24" this subnets because when ip sla triggered the default gateways changes to backup and when our ILL links are up then there are no routes are present in the routing table to track this ILL links.

[Enes Simnica]

hello @mansi-mhatre and now we are talking my friend. Ur reply actually confirms the root cause. So u added static routes for the ILL subnets so the SLA probes can reach their targets even when the default route flips. But those static routes are unconditional, so the router always believes the ILL subnets are reachable; that keeps the IP SLAs (and track 2/track 3) reporting Up. And since track 4 is an AND of those objects, track 4 never goes Down and the backup/default route never becomes preferred, AD changes won’t help while the ILL routes remain installed. 

what i recommend is to make the ILL-specific static routes conditional on the corresponding track objects so those routes disappear when their SLA fails. Also ensure the backup default is tied to the inverse condition or simply leave the primary tied to track 4 and the backup unconditional (or AD higher),  either approach works if the ILL-specific routes are tracked. Also i can give u a config example my Cisco friend:

MAKE USRE TO keep ip sla and tracks as u have
track 2 ip sla 2 reachability
track 3 ip sla 3 reachability

ALSOO make the ILL subnet routes depend on the SLA state
ip route 59.144.216.0 255.255.255.0 10.1.123.5 track 2
ip route 121.241.211.0 255.255.255.0 10.1.123.5 track 3

primary default only present when both SLAs are OK
ip route 0.0.0.0 0.0.0.0 10.1.123.5 track 4

backup default, either unconditional or tied to an inverse track
 Option A + unconditional (lower priority while primary exists)
ip route 0.0.0.0 0.0.0.0 10.1.122.130 200

 Option B - explicit: enable backup only when track 4 is down (requires an inverse track)
 create track 5 that is true when track4 is down:
track 5 boolean invert
object 4
ex
ip route 0.0.0.0 0.0.0.0 10.1.122.130 track 5

AND IN THE END, If an ILL target fails, its tracked route is removed; if both fail, track 4 goes down, the primary default is removed, and the backup takes over.  HOPE IT WASNT A LONG ANSWER, HOPE IT HELPS AND PEACE!

-Enes

[mansi-mhatre]

Hi Enes,

I want to remind you that, we dont have direct links termination for both ILL on our core switch where we applied IP SLA. so when ip sla triggered, our defaut route is disabled and we dont have any route to track gateway of ILL links, that why we added the static route. 

[MHM Cisco World]

ip route 59.144.216.0 255.255.255.0 10.1.123.5 <<- use egress interface not next hop
ip route 121.241.211.0 255.255.255.0 10.1.123.5 <<- use egress interface not next hop

MHM

[paul driver]

Hello

---

@mansi-mhatre wrote:
we hane added static routes for "59.144.216.0/24 and 121.241.211.0/24" this subnets because when ip sla triggered the default gateways changes to backup and when our ILL links are up then there are no routes are present in the routing table to track this ILL links.

If i understand correctly you need to negate those address from being learned via the alternate path for echo,

Remove these static routes and apply the following: 

access-list 100 permit icmp host 10.1.123.5 host 59.144.216.1 echo
access-list 101 permit icmp host 10.1.123.5 host 121.241.211.9 echo

route-map ipsla permit 10
match ip address 100
set ip next-hop xxxx
set interface Null0

route-map ipsla permit 20
match ip address 101
set ip next-hop xxxxxx
set interface Null0

ip local policy route-map ipsla

[MHM Cisco World]

I deep thinking what is wrong here 

Then I get issue 

You use source IP is 

10.1.123.5 

Which is same as next-hop of route !!!!!!!!!!!!!!

This meaning either static route is wrong or ip sla is wrong 

This IP is IP of your interface?

If Yes then static route is wrong' in which we use egress or next-hop not IP of interface of router

If NO then ip sla is wrong' ip sla use IP of interface in router not IP of neighbor 

Note:- again use egress in static route not next-hop or use both 

MHM