Suspend SLA Tracking for migration

[CAR IT]

We are performing a cutover from our current provider's MPLS to a new provider. We have an MPLS between HQ and Office1 and a site-site tunnel from HQ and Office1 (using our ASAs). We push our backups over the VPN, and all internal user and phone traffic uses the MPLS.

After the migration, it seemed all the traffic was still routing through the VPN, not taking the MPLS path (the internal IPs are the same). I'm a little unclear about all the parameters of SLA. This is from our core router at HQ. I understand the logic, but not sure if it's implemented or the parameters. My take is each track waits 20 seconds before it considers the link down (and back up). The live routes are track 200 and the backup routes are going through x.x.234.1. These are based on state being up, responding to a ping.

I have a couple of questions:

1. What sets sla 200 as the default sla (using 233.1)?

2. When connection is re-established, is the config below going to properly switch back to sla 200? I think because the MPLS was down while migrating the IP block, everything was routed over our VPN, but the IP echo being tested would still respond, because it can be reached by the VPN..so, would it know to switch back to sla 200 when the connection was re-established?

3. I don't see sla 100 referenced in the ip route commands, and I'm unsure what the 10 is at the end of the ip route statement.

4. Can I just suspend SLA tracking while the migration is going and re-enable it? Would that be the quickest way to handle this?

Sorry, I know this is probably fundamental, but I'm crunched for time and wading through thousands of Cisco docs and posts has veered me off in several million tangents. Please let me know if I need to provide more config information, I've obviously cut out anything that didn't seem to relate to the SLA/Route config. It's a 3750X Version 12.2(58r)SE.

TIA!

Here is the SLA config (edited heavily):

track 100 ip sla 100
 delay down 20 up 20
!
track 200 ip sla 200
 delay down 20 up 20

[lots of config edited out]

ip route 192.168.8.0 255.255.255.0 192.168.233.1 track 200
ip route 192.168.102.0 255.255.255.0 192.168.233.1 track 200
ip route 192.168.60.0 255.255.255.0 192.168.233.1 track 200
ip route 0.0.0.0 0.0.0.0 192.168.234.1
ip route 192.168.8.0 255.255.255.0 192.168.234.1 10
ip route 192.168.60.0 255.255.255.0 192.168.234.1 10
ip route 192.168.102.0 255.255.255.0 192.168.234.1 10

ip sla 100
 icmp-echo [external address I didn't recognize] source-ip 10.10.10.10
 frequency 10
ip sla schedule 100 life forever start-time now
ip sla 200
 icmp-echo 192.168.253.2 source-ip 192.168.233.2
 frequency 10
ip sla schedule 200 life forever start-time now

access-list 101 permit ip any host 192.168.8.163
route-map MPLS-MAP permit 10
 match ip address 101
 set ip next-hop 192.168.233.1
!
route-map TestLAN-to-UserLAN permit 10
 match ip address TestLAN-to-UserLAN
 set ip next-hop 192.168.234.1 (route through main Internet)

[Georg Pauwen · Accepted solution]

Hello,

you really only need one SLA. In the below example, your primary default route is tracked. If the ping fails, the secondary default route is being installed. The secondary default route has a higher administrative distance (10) than the primary, in order to prevent it from being used while the primary is still in use.

The source interface for the ip sla (FastEthernet0/0 in this example) should be the interface used by MPLS, that is, the interface that actually is not reachable when MPLS fails.

track 1 ip sla 1 reachability
delay down 20 up 20

ip sla 1
icmp-echo x.x.x.x source-interface FastEthernet0/0
timeout 1000
threshold 3
frequency 10
ip sla schedule 1 life forever start-time now

ip route 0.0.0.0 0.0.0.0 192.168.233.1 track 1
ip route 0.0.0.0 0.0.0.0 192.168.234.1 10

[CAR IT]

Thank you Georg, that makes sense, and I could probably remove the extraneous logic. We're doing the migration tomorrow night, so I appreciate the information.

Regards,

Steve