Help with dynamic failover/failback with TRACK and SLA on a 4507R

[erik.doss]

I am working on a new failover strategy for my remote sites that will utlize diverse carriers on both my HQ side and remote sites. I currently have two Firewall/UTM devices that service different internet connctions directly to my core layer 3 switch (4507R). The 4507R needs to be the routing decision maker at HQ for any failover scenarios at any of my remote sites.

What I am attempting to do is to use track and sla to detect when the primary connection to my remote site goes down and kicks over to the failover route using a higher metric (200)  I have been succseful with the failover part, but failing back to the primary when it comes back online at the remote side is where I am having trouble. I need to have the routes failover and back gracefully with no human intervention. So I ask, is this possible on the 4507R, and what type of track and sla confogurations should I be using for both the primary and secondary routes?

This is my current track/sla config that seems to work for the failover protion:

track1 ip sla 801 reachability

  delay down 5 up 10

ip sla 801

  icmp-echo 10.1.0.235 (node on the remote site network)

ip sla schedule 801 life forever start-time now

Any help would be greatly appreciated!

[erik.doss]

I KNOW someone out there knows the answer to this

[Vaibhava Varma]

Hi Erik

From my viewpoint if we have two GW(next-hops) for the Static Route and we are using floating-static routes for the remote destinations ( AD 200) then automatically the primary/secondary feature is activated.

Now coming to the point of detecting the reachability of the next-hop to declare the route as valid/unvalid would be applicable to both the Primary Static Route and Secondary Floating Static Route.

If the Primary Route's Next-Hop is back up and reachable it would be installed back in the RIB rather than the floating static route. if there's issue of the delay in reinstalling the Primary route why not go for BFD for the Static Routes to achieve ms convergence. Or is that the FW do not support BFD.

Is the actual issue in the delay of the Primary Static Route getting back installed in RIB or not at all getting back installed ?

Below is some similar older discussion on the IP SLA for Static Routing..Might be helpful to you

https://supportforums.cisco.com/thread/2011038

Hope this helps you something in your traffic requirements.

Regards

Varma

[erik.doss]

The issue is not delay, the route is not getting installed in the RIB when the primary comes back up.

Also, My 4507 does not support bfd, and my firewall doesn't support ospf, only static routing.

I will take a look at your link to see if that can clue me in to a solution. Thanks!

[Vaibhava Varma]

Hi Erik

So the Primary Once removed stays out of RIB forever when the secondary backup route is also up. Strange.How long have you observed for the Primary Route to not get back to RIB as in the above link they talked for a couple of seconds in the delay of switchover from secondary back to primary.

Does this happens when we do not use IP SLA,,means the same behaviour is experienced without IP SLA also ?

The above link is more focussed on the delay part not exactly to this interesting issue.

Regards

Varma

[erik.doss]

I will be testing the floating point in a few hours during a maintenace window. If that works, i will stop with the track and sla configuration.

[Vaibhava Varma]

Hi Erik

All the best with your configuration testing

Regards

Varma

[erik.doss]

My floating point routes did not work either. If anyone has any ideas on how to make this work, it would be much appreciated.

[cadet alain]

Hi,

so you have 2 static default routes and you are tracking the first one with ip sla and the second one is just a floating route with an AD greater than the primary. Once the track object goes down the backup route is installed in the RIB but once the track object goes up the primary is not installed back into RIB replacing the floating backup?

Configuration wise what you are doing is correct so either it is not configured correctly which I doubt whether it is a Bug .

To really throw out misconfiguration can you show us sh run | be ip sla|track|ip route output as well as sh ip route with the sh track when primary is up and when it is down as well as debug ip routing.

Regards.

Alain.

[erik.doss]

I should have been more clear, my apologies. The tracked object never comes back up on the primary route, thus it never takes over from the failover.

[erik.doss]

I made a few changes to my track and sla statements. Do these look right or do I need to change anything?

track 1 ip sla 801 reachability

ip sla 801

icmp-echo 10.1.0.4

timeout 300

frequency 3

ip sla schedule 801 life forever start-time now

sh track 1

Track 1

    IP SLA 801 Reachability

    Reachability is UP

        3 changes, last change 00:03:40

    Latest operation return code: OK

    Latest RTT: (milliseconds): 96

    Tracked by:

        STATIC-IP-ROUTINGTrack-list 0

[erik.doss]

I finally got this to work. I simply needed to add a static route for my target IP to always use the primary route next hop IP address. My final config is as follows...

track 1 ip sla 801

ip route 10.1.0.0 255.255.255.0 10.62.0.2 track 1

ip route 10.1.0.4 255.255.255.255 10.62.0.2

ip route 10.1.0.0 255.255.255.0 10.62.0.5 200

ip sla 801

   icmp-eche 10.1.0.4 source-ip 10.62.0.4

ip sla schedule 801 life forever start-time now

the nice thing about this is that it gives lots of flexability in using a traget IP anywhere along the path, as long as it can be pinged.