IP SLA Tracking issue

[Mokhalil82]

Hi 

I have the following setup. The 3750x switches are acting as the gateway to the internet. This is a lab but in reality I will be installing asa firewalls there. I am trying to get ip sla to ping 8.8.8.8 on core 1 and send traffic via core 2 if core 1 fails.

3750x (Primary GW)                                  3750x (Secondary Gateway)

    |                                                                   |

Core1------------------------------------------------Core2

IP SLA config is as follows

IP sla 100
icmp-echo 8.8.8.8
frequency 3

ip sla schedule 100 start-time now life forever

track 1 ip sla 100 reachability

At this point I have a default route on core1 pointing to my primary gateway. IP SLA comes up fine as it can ping 8.8.8.8 but when I remove the route and reinsert it with the track 1 statement (ip route 0.0.0.0 0.0.0.0 172.20.250.149 track 1) then this route just drops out the routing table and ip sla goes down.

I have inserted a secondary route with lower admin to point to core 2 and that comes active, but the route to my primary gateway goes down as soon as I add the treack 1 statement

Any help will be greatly appreciated
 

[paul driver]

Hello

First of all can you ping 8.8.8.8 from core 1  and is it reachable via its default source address/interface

If so try and specify a source address in the sla.statement, test again.

res

Paul

 

[Richard Burts]

I agree with Paul that specifying a source address might be helpful. If the route is withdrawn when you configure it with the track statement then something is going on with track or IP SLA. Are there any log messages generated? What does IP SLA say about the sate of the tracked object?

HTH

Rick

[Mokhalil82]

Hi Guys

I think I have misinterpreted the issue slightly, After some investigation I realised that when the ip sla is initially up, then I pull the primary link, it fails over to secondary. But when the primary link is active again, it does not fail back.

Now the only way I get the failback working is if I add a static route on core1 for the 8.8.8.8 network and set the default gateway as the primary gateway, then it all works. But what this means is when the primary link does fail, we will lose connectivity to 8.8.8.8.

Secondly I used 8.8.8.8 for testing purposes, in reality what happens is if you use an address that is accessible at both gateways, the ip sla starts to flap as it loses connection to gateway 1 then can ping that ip via gateway 2 so the ip sla comes back up to ping via gateway 1 but then realises its down and flips back and so on

Is there any way around these, how can I get a successful failover to work

Thanks

[paul driver]

Hello

can you post your config for this please?

FYI - Also do the two statics have any admin distances applied to them and if so make sure the primary tracked route has a value lower than the secondary route.

res

Paul

 

[Mokhalil82]

Hi Paul 

Here is the config

ip route 0.0.0.0 0.0.0.0 172.20.250.140 track 1
ip route 0.0.0.0 0.0.0.0 172.20.152.18 5
ip route 6.6.6.6 255.255.255.255 172.20.250.140
!
!
ip sla 100
 icmp-echo 6.6.6.6
 frequency 5
ip sla schedule 100 life forever start-time now     

track 1 ip sla 100 reachability

So 172.20.250.140 is the primary gateway. 172.20.152.18 is the eigrp next hop to core 2.

On the 3750x switches I have configured loopback interfaces 8.8.8.8 on both ends for testing connectivity and 6.6.6.6 just on the primary 3750x side which ip sla is pinging. I founf when pinging 8.8.8.8 which is reachable at both ends, ip sla starts to flap

Currently this works as I have the route to 6.6.6.6 in core 1. when I remove that route then ip sla goes down and starts using my secondary gateway. or if i insert a route without the track command to the primary gateway, ip sla comes up again. 

Im thinking can I get round it by using my isp next hop as the icmp-echo destination, then i can have a static route to this aswel as no traffic on core 1 is directly destined for the isp gateway. 

[paul driver]

Hello

Is 6.6.6.6 being advertised anywhere else and is 172.20.250.140 the next-hop?

As this would could cause the primary route not to come back up as it should?

res

Paul


 

[Mokhalil82]

Hi

No its not being advertised anywhere else. I think I might go with adding a static route to the icmpecho address and this may be the isp default gateway. That works currently when using a separate default route to 6.6.6.6

[paul driver · Accepted solution]

Hello

Hum.. I have just labbed this up and it worked accordingly
can you try the following and test again?

sh track
Track 1
  Response Time Reporter 100 reachability
  Reachability is Up
    6 changes, last change 00:00:02
  Latest operation return code: OK
  Latest RTT (millisecs) 39
  Tracked by:
    STATIC-IP-ROUTING 0

R1#traceroute 8.8.8.8

Type escape sequence to abort.
Tracing the route to 8.8.8.8

  1 172.30.250.140 64 msec 44 msec 28 msec

int lo0
shut

*Mar  1 00:26:54.819: %TRACKING-5-STATE: 1 rtr 100 reachability Up->Down
R1#sh track
Track 1
  Response Time Reporter 100 reachability
  Reachability is Down
    7 changes, last change 00:00:06
  Latest operation return code: No connection
  Tracked by:
    STATIC-IP-ROUTING 0
 

R1#traceroute 8.8.8.8

Type escape sequence to abort.
Tracing the route to 8.8.8.8

  1 172.20.152.18.5 56 msec 52 msec 8 msec

ip sla 100
 icmp-echo 6.6.6.6
 frequency 5
ip sla schedule 100 life forever start-time now

track 1 rtr 100 reachability

ip route 0.0.0.0 0.0.0.0 (interface) 172.30.250.140  track 1
ip route 0.0.0.0 0.0.0.0 (interface) 172.20.152.18.5
ip route 6.6.6.6 255.255.255.255 (interface) 172.30.250.140 

res

Paul

[Mokhalil82]

Thanks Paul

That worked on my lab before aswel but only when i had the route inserted

ip route 6.6.6.6 255.255.255.255 (interface) 172.30.250.140 

I thought it should work without having the route to 6.6.6.6 becuase packets to 6.6.6.6 should be using the original default route, that's what I was trying to get working so I take it the route to 6.6.6.6 has to stay to have this working

[paul driver · Accepted solution]

Hello

Core 1 needs to know where to go for 6.6.6.6 so either by a static/dynamic routing, In this case if it you take the static route to 6.6.6.6 out or disable 6.6.6.6 interface/or its directly connected interface the track route will drop as it tied in with the static route.

That's why it works if you put the primary default route back in WITHOUT the tracking applied as it now has a valid path again and it ant working with ip sla or tracking.

res

Paul

[Mokhalil82]

Ok now I understand that, i thought it didn't have to be tied into that route. 

Really appreciate your help Paul, something new ive learnt today and will have more to learn tomorrow got vss and mecs to setup for the 1st time :-)

Thanks