01-25-2016 10:55 PM - edited 03-05-2019 03:12 AM
In our production network, we have a MPLS VPN for the remote office and recently we just deployed an ASA NGFW as an edge firewall and I want to create a backup S2S VPN if the MPLS link goes down.
So I tried labbing it up and my configuration seems to work, only when I tested shutting down a port on the MPLS switch, the SLA tracking checks the reachability and the track could go up even the port is shut down. The result is, the connectivity got time out for a several seconds. Why did it happen?
Here's the output:
R1#sh track
Track 1
IP SLA 123 reachability
Reachability is Down, delayed Up (3 secs remaining)
41 changes, last change 00:03:01
Delay up 180 secs, down 30 secs
Latest operation return code: Timeout
Tracked by:
Static IP Routing 0
R1#
R1#sh track
Track 1
IP SLA 123 reachability
Reachability is Down, delayed Up (1 sec remaining)
41 changes, last change 00:03:04
Delay up 180 secs, down 30 secs
Latest operation return code: Timeout
Tracked by:
Static IP Routing 0
R1#
*Jan 26 11:21:18.976: %TRACK-6-STATE: 1 ip sla 123 reachability Down -> Up
R1#
R1# ! The connection times out below !
R1#sh track
Track 1
IP SLA 123 reachability
Reachability is Up, delayed Down (11 secs remaining)
42 changes, last change 00:00:28
Delay up 180 secs, down 30 secs
Latest operation return code: OK
Latest RTT (millisecs) 1
Tracked by:
Static IP Routing 0
R1#
*Jan 26 11:21:59.076: %TRACK-6-STATE: 1 ip sla 123 reachability Up -> Down
R1# ! The connection goes up again !
R1#sh track
Track 1
IP SLA 123 reachability
Reachability is Down, delayed Up (179 secs remaining)
43 changes, last change 00:00:05
Delay up 180 secs, down 30 secs
Latest operation return code: Timeout
Tracked by:
Static IP Routing 0
R1#
The full configuration is here
Solved! Go to Solution.
01-30-2016 12:06 AM
I think tracking is configured with a delay, something like this:
track 1 ...
delay down 10 up 10
So, when ip sla fails, the tracking starts a delay timer and it switches from up to down (or down to up) just after the timer expires.
Try to check the configuration and let me know (if you like post the config)
01-30-2016 12:06 AM
I think tracking is configured with a delay, something like this:
track 1 ...
delay down 10 up 10
So, when ip sla fails, the tracking starts a delay timer and it switches from up to down (or down to up) just after the timer expires.
Try to check the configuration and let me know (if you like post the config)
02-01-2016 06:54 AM
So on R1, you have a static route for 10.178.138.0/24 tracking object 1
Object 1 is pinging 10.178.138.1 over E0/1
You also have a static backup route with administrative distance 20 for 10.178.138.0/24 over your backup link.
Your IP SLA doen't care how it hits 10.178.138.1, so this is what is happening:
Rouer: 10.178.138.1 is available
You: ** Shutdown E0/1 **
Router: 10.178.138.1 is unavailable, tear down static route tracking object 1
Router: 10.178.138.1 is now available via backup route, re-instate static route tracking object 1!!
If you manage all the routers at both ends, I would be running a routing protocol rather than trying to do this with IP SLAs, but an easy fix, is to create a /32 loopback on the remote router. On the local router, have a static route for the /32 loopback over your primary link, and have your static route tracking based on an IP SLA tracking the loopback IP. This will force the router to only check for the remote router over the primary link.
Let me know how you go.
Something like this:
CS2:
interface Loopback100
ip address 10.200.200.1 255.255.255.255
!
R2:
ip route 10.255.255.1 255.255.255.255 10.178.129.1 permanent
ip sla 123
icmp-echo 10.200.200.1
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