Solved: Route Maps & IP SLA

Kevin Brennan · ‎04-01-2009

Hi All,

I'm having a problem with tracking and route maps.

My route maps are working, but not with the track keyword. I know the reason it is not working, but I'm not sure how to fix it.

I have two /30 links between two sites. These /30's are presented as ethernet (read: interfaces always up, therefore IP addresses are always reachable) I am tracking the far side ip address on the /30's, but when one link goes down, the tracked ip address is still available via the other route so the route map never changes.

I have my config below (and topology attached) - the routemaps and track objects are the same on 3560_1 and 3560_2. I'm running EIGRP all over. I was thinking it could be made to work if I could set the TTL on ipIcmpEcho to 1, but I couldn't find a way to do that. The only other thing I can think of is to use an ACL blocking ICMP in a specific way.

Any suggestions?

Thanks

Kevin

-=-=-=-

!

track 101 rtr 101 reachability

!

track 102 rtr 102 reachability

!

access-list 101 permit ip host 172.18.1.26 host 172.20.209.50

access-list 102 permit ip host 172.18.1.27 host 172.20.209.51

route-map EX_REP permit 10

match ip address 101

set ip next-hop verify-availability 192.168.20.5 1 track 101

!

route-map EX_REP permit 20

match ip address 102

set ip next-hop verify-availability 192.168.20.1 1 track 102

!

control-plane

!

rtr 101

type echo protocol ipIcmpEcho 192.168.20.5

timeout 1000

threshold 1000

frequency 2

rtr schedule 101 life forever start-time now

!

rtr 102

type echo protocol ipIcmpEcho 192.168.20.1

timeout 1000

threshold 1000

frequency 2

rtr schedule 102 life forever start-time now

Richard Burts · ‎04-01-2009

Kevin

I would suggest that one way to fix your issue is to configure a pair of host specific static routes in which you specify both the next hop you want to reach and the interface to use to get there. It might look something like:

ip route 192.168.20.1 255.255.255.255 fastether?/?

ip route 192.168.20.5 255.255.255.255 fastether?/?

Your issue is that when one of the interfaces stops working the remote address is still reachable through the other interface and so the track does not detect the failure. The host specific static will take precedence over any other way to get to the next hop and it will say to get to that address you must use only this interface. This will allow the track to detect failure of forwarding over that interface.

HTH

Rick

HTH

Rick

View solution in original post

Richard Burts · ‎04-01-2009

Kevin

I would suggest that one way to fix your issue is to configure a pair of host specific static routes in which you specify both the next hop you want to reach and the interface to use to get there. It might look something like:

ip route 192.168.20.1 255.255.255.255 fastether?/?

ip route 192.168.20.5 255.255.255.255 fastether?/?

Your issue is that when one of the interfaces stops working the remote address is still reachable through the other interface and so the track does not detect the failure. The host specific static will take precedence over any other way to get to the next hop and it will say to get to that address you must use only this interface. This will allow the track to detect failure of forwarding over that interface.

HTH

Rick

HTH

Rick

Kevin Brennan · ‎04-01-2009

Hi Rick,

Thank you very very much - I'd never have thought of that in a million years!

I've got it mostly working, but I think I need to do some tidying work on the 6500 switch in site A.

I've noticed that traceroute from the hosts involved is a little odd (as are the ping responses), but I do think that is due to the route maps on 6500.

Thanks again.

Kevin

Richard Burts · ‎04-01-2009

Kevin

I am glad that you got it working - mostly. I had a similar challenge in a project for a customer recently in tracking a FastEthernet interface and found the host specific static route with next hop and interface to be an effective solution.

Thank you for posting back to the thread indicating that it was working. Thank you for using the rating system to indicate that the problem was resolved (and thanks for the rating). It makes the forum more useful when people can read about a problem and can know that they will see a suggestion which lead to a solution.

If you have other issues getting this cleaned up and working better let us know.

HTH

Rick

HTH

Rick

DialerString_2 · ‎04-01-2009

Hey guys, I have a question as I've configured this on my network, w/o the timeoute option.

rtr 101

type echo protocol ipIcmpEcho 192.168.20.5

timeout 1000

threshold 1000

frequency 2

rtr schedule 101 life forever start-time now

If the track does not receive a response w/in 1000 miliseconds what happens?

Thanks

Kevin Brennan · ‎04-14-2009

Hi Rick, All,

Just a note on this fix, One tweak that I had to do was to put in an ACL that stopped ICMP from the SLA monitor traversing the other /30.

The reason for this was that if (as happened over the weekend) the ethernet port on the carriers NTU went down, the static route was taken out of the routing table and the ping request were across the other link as per the EIGRP routing table.

Cheers

Kevin