cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
838
Views
0
Helpful
10
Replies

IP SLA Query

thstagman
Level 1
Level 1

I have 4 routers in 2 pairs, each pair is in a different location. Two (7513’s) one in each location  are just be used as big media converters (ATM to IP) and as such have no dynamic routing configured on them. But they do have a static route each pointing each to the far end to aid in BGP Peering.

The other two routers (ASR’s) are running BGP and use the 7513’s to peer with one another again with the use of static routes.

My problem is that if a connection fails that is not directly connected to the ASR’s. The ASR’s continue to send packets down the line where the fault connection lies because the local ASR static route is still active.

If I was to fail a directly connected link then the BGP swings into action and re routes via some other routers because BGP has the best admin cost.

I am thinking of trying to use IP SLA, get it to ping the far end and if there should be a failure somewhere along the static route,  remove the static route from the routing table allowing BGP to take over

I have been told that this can be done but I’m dammed if I can get it working. The IP SLA stuff is set all ok and I can see the pings going out using a debug command. But the stale route always remains in the routing table.

Any ideas anyone ?

10 Replies 10

Jon Marshall
Hall of Fame
Hall of Fame

Mike

Might help if you could post the IP SLA config on one of the ASR's. When you fail the indirect link are you seeing the IP SLA status change ? Are you tracking the route to the IP SLA ?

Jon

Hello Jon

Here is the IP SLA config from one of the routers and I have to say the only router that has the IP SLA  config on?

  track 123 rtr 1 reachability

ip route 155.131.5.14 255.255.255.255 155.131.5.17 track 123

ip sla 1

      icmp-echo 155.131.5.14 source-interface FastEthernet0/0

      timeout 1000

      threshold 2

      frequency 3

I am tracking the route I think ? 

Thanks

Mike

Mike

Apologies for the delay in getting back.

You are tracking the route but if this is the full IP SLA config then you haven't actually started the SLA monitoring. Have you got something like this in your config -

router(config)# ip sla monitor schedule 1 life forever start-time now

Jon

Hi Jon

Sorry , yes I have

Mike

Mike

Before you drop the indirect link can you run -

sh ip sla monitor statistics

then drop the indirect link and repeat -

sh ip sla monitor statistics

and post results.

Jon

Hello Jon

Ok, I do it tomorrow morning as its now 22:30hrs overhere ..

Cheers

Mike

thstagman wrote:

Hello Jon

Here is the IP SLA config from one of the routers and I have to say the only router that has the IP SLA  config on?

  track 123 rtr 1 reachability

ip route 155.131.5.14 255.255.255.255 155.131.5.17 track 123

ip sla 1

      icmp-echo 155.131.5.14 source-interface FastEthernet0/0

Mike

Mike

It would help if you could knock up a very quick schematic of how the 4 routers connect and the relevant IPs.

By the way are you in the UK as it's the same time for me.

Jon

Type escape sequence to abort.

Tracing the route to 155.131.5.14

  1 155.131.5.17 216 msec 16 msec 160 msec

  2 155.131.5.2 180 msec 280 msec 336 msec

  3 155.131.5.14 [AS 13114] 528 msec 328 msec *

STC1#

I have not been able to provide stats before a connection has been stopped because as soon as I change the static route to "Track 123" IP SLA fails and

my pings do not get through. When I remove the Track 123 from the static route the pings work.

This is all being run on virtual router simulation software. Obviously I cannot be test in this in a live environment.

So I have included a working traceroute to give an idea of the round trip delays.

sh ip sla stat

Round Trip Time (RTT) for       Index 1

        Latest RTT: NoConnection/Busy/Timeout

Latest operation start time: *00:30:29.435 UTC Fri Mar 1 2002

Latest operation return code: Timeout

Number of successes: 0

Number of failures: 20

Operation time to live: Forever

*Mar  1 00:30:04.411: %TRACKING-5-STATE: 123 rtr 1 reachability Up->Down

traceroute 155.131.5.14

Type escape sequence to abort.

Tracing the route to 155.131.5.14

  1 155.131.5.17 216 msec 16 msec 160 msec

  2 155.131.5.2 180 msec 280 msec 336 msec

  3 155.131.5.14 [AS 13114] 528 msec 328 msec *

Hi Mike

Well that took a bit of testing !!

I think the issue you have is that you are montoring with IP SLA the same destination IP as you have in your route ie. 151.131.5.14 so it's getting into a bit of a loop. Ironically using the same setup i couldn't get the route installed as opposed to not having it removed.

So can you try using another IP to ping within the IP SLA. Now looking at your diagram you need to know if any link in the chain fails. The problem is that the 7513 -> WTC-1 connection is ethernet so unless this is direct crossover connection ie. no switch in between then there is no alternative IP because if you ping 151.131.5.13 that could still be up but 151.131.5.14 be down. Note if this was a direct connection or a serial connection then you could assume if .14 went down then so does .13.

So what i did was to create a loopback interface on WTC-1 and use that in the IP SLA configuration. The loopback for arguments sake is 192.168.10.1 and obviously STC-1 needs to know how to route to it. So my config looked like -

track 123 rtr 1 reachability

ip sla monitor 1

type echo protocol ipIcmpEcho 192.168.10.1

frequency 10

ip route 151.131.5.14 255.255.255.255 151.131.5.17 track 123

this all tested fine. I could shutdown any interface along the path and the route was removed, bring up any interface and the route is restored.

See if this works for you.

Jon

Thanks Jon

I'll give it ago .and let you know ..

Cheers

Mike

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: