03-29-2017 02:59 PM - edited 03-05-2019 08:16 AM
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)
Solved! Go to Solution.
03-30-2017 01:00 AM
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
03-30-2017 01:00 AM
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
04-03-2017 09:18 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide