cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
686
Views
0
Helpful
2
Replies

weird SLA tracking issue

anon3776
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

e.ciollaro
Level 4
Level 4

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)

View solution in original post

2 Replies 2

e.ciollaro
Level 4
Level 4

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)

Elliott Willink
Level 1
Level 1

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

Review Cisco Networking for a $25 gift card