• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1643
  • Last Modified:

Cisco IP SLA Tracking not recovering (not coming back up)

Hi there, I'll try to keep this short and sweet.  I am trying to set up redundant default (static) routes out of my network.  I have x2 routers each with an internet connection to the ISP (O2 broadband) and static WAN addresses.  Simple diagram attached.

The main issue I have however is that I don't know the next hop IP address of my ISP, and if I do a traceroute both routers return the same next hop (which is probably correct as both lines go back to the same telephone exchange).

I'm focusing on R1 at the moment.  I have added the following config:

track 1 ip sla 1 reachability
ip sla auto discovery
ip sla 1
 icmp-echo 4.2.2.2 source-interface Dialer0
 frequency 5
ip sla schedule 1 life forever start-time now
!
ip route 0.0.0.0 0.0.0.0 Dialer0 5 track 1
ip route 0.0.0.0 0.0.0.0 11.0.0.2 10


At the mo, a "show ip route" returns the following:

S*    0.0.0.0/0 is directly connected, Dialer0

If I shut down ATM 0 on R1 track 1 goes DOWN as it should do and the second static route becomes active:

S*    0.0.0.0/0 [10/0] via 11.0.0.2

So far so good.  The issue is that when I "no shut" ATM 0 track 1 doesn't come back up.  The second route stays in the routing table and I have to manually enter the following command to restore R1's primary route (ip route 0.0.0.0 0.0.0.0 di0).  Before I re-enter the static route to bring track 1 back UP I've done some checks:
interface dialer0 is UP/UP.  It has an IP address and is happy (we even have some GRE tunnels out of R1 Di0 to other sites that come up).  It seems to be that interface Di0 doesn't know what route to take to check connectivity to 4.2.2.2

OSPF is running across these routers so once I had got the static routes working I was going to look at redistributing them into OSPF.

Any help would be much appreciated.

Cheers, Andy
Picture1.jpg
0
andrewprouse
Asked:
andrewprouse
  • 3
  • 3
  • 2
  • +2
1 Solution
 
MiftaulCommented:
Can you change the second static route with its exit interface.
0
 
Hassan BesherCommented:
icmp-echo 4.2.2.2 source-interface Dialer0

Try to replace Dialer0 with your LAN Interface, and how it goes!
0
 
Pete LongTechnical ConsultantCommented:
did you Nail 4.2.2.2 to the dialero interface?

e.g.

ip route 4.2.2.2 255.255.255.255 Dialer0 permanent
0
Big Data Means Big Business

In data-dependent industries like IT, finance, and healthcare, there’s a growing demand for qualified analysts to fill leadership roles. WGU’s MS in Data Analytics has IT certifications from Oracle and SAS built into its curriculum at a flat fee that could save you money.

 
InfamusCommented:
Try this.

track 1 ip sla 1 reachability
 delay down 20

ip sla 1
 icmp-echo 4.2.2.2
ip sla schedule 1 life forever start-time now
ip sla enable reaction-alerts

ip route 0.0.0.0 0.0.0.0 Dialer0 5 track 1
ip route 0.0.0.0 0.0.0.0 11.0.0.2 10
ip route 4.2.2.2 255.255.255.255 Dialer0
0
 
andrewprouseAuthor Commented:
Hi guys,

Thank you for your replies.  I tried all suggestions and the resolution seems to be a mixture (mainly PeteNetLive's suggestion).

My only gripe now however is that the only route to 4.2.2.2 is through Di0, if Di0 is down and all internet traffic is heading though R2, nor the router or LAN users will be able to ping / access 4.2.2.2

Is there a way around this, or is there another reliable public IP that I could use for this tracking SLA? (not Google).

Cheers, Andy
0
 
Hassan BesherCommented:
what if you do  the same here for 4.2.2.2:

ip route 4.2.2.2 255.255.255.255 11.0.0.2 20
0
 
Pete LongTechnical ConsultantCommented:
Use

8.8.8.8


P
0
 
InfamusCommented:
Why would the users need to be able to ping 4.2.2.2?

It's one of the level 3 communication's DNS server.
0
 
andrewprouseAuthor Commented:
Hassan - If I use your suggested command then I believe this will do one of two things:
  1) give an alternative route to 4.2.2.2 which will bring the SLA back up without Di0 being active.
   2) not be used.  If the Di0 WAN link is broken at the exchange, but the Di0 interface is still UP/UP, the secondary route (your command) will never be used.  I don't think.

PeteLong - We use 8.8.8.8 & 8.8.4.4 as DNS forwarders from our internal DNS servers

Infamus - I have got into the habit of using 4.2.2.2 as an 'internet connectivity test'. In a year or so's time I will have forgotten about this SLA rule and 4.2.2.2 route therefore if the Di0 WAN connection has failed over I will not be able to ping 4.2.2.2
0
 
InfamusCommented:
4.2.2.1 is also available
0
 
andrewprouseAuthor Commented:
thank you very much.  This was the solution (mainly the final command forcing all traffic to 4.2.2.2 through Di0).

I also changed the icmp-echo to 4.2.2.1 as per the final comment.
0

Featured Post

Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

  • 3
  • 3
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now