veryify static route next hop

[kjbarrass]

Hi

Iam looking into a problem where we have no option other than to use static routes for political reasons ;0)

Unfortunatly our core network between layer 3 devices is a switched ethernet backbone.

The problem we have is that if a next hop of a static route goes down the static route stays valid as the outgoing interface to the next hop is up.

I was told that using the command "ip route static adjust-time" there is some internal feature in IOS that checks the availability of the next hop IP address but in testing this does not work. Can anyone advise if I have miss read the below document.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a00802801fe.html

Kind Regards in advance

Kev Barrass

[kerek · Accepted solution]

Hello Kev,

In my interpretation this command does not make any kind of checking of the next hop availability just how fast the affected static routes are changed in case of routing table change.

If you want the achieve the requested approach try out the enhanced object tracking.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00801541be.html

Hope it helps, rate if does,

Krisztian

[kjbarrass]

Hi

Cheers for the below, Iam currently testing the IP SLA, track option. I dont understand the adjust-time option in that as far as I was aware removing and installing static routes into the routing table was instant with no delay.

Regards

Kev

[paul.matthews]

Don't you just love layer 8 of the 7-layer model (Political)?

You can improve the handling of next hop with a little bit of craftiness. Using statics, it is impossible to totally guarantee that a route will disapear, but you can make it more likely to go.

You need the next hop in a port on the layer 3 switch, or directly on an ethernet of a router. You set the port as a layer 3 port, and you use a small subnet, treating it like a PTP link. It is important that there is nothing between the device and the switchport that will keep the link up.

Then, should the cable fail, or the device fail in such a way that its NIC goes offline the interface on the switch/router will go down, and the staic pointing to it will be removed from the routing table. Obviously, if the fail mode of the next hop keeps the NIC up, the route will stay.

I am also getting a little idea about using a pair of CSSs to handle it. It is NOT what a CSS is designed for, but just maybe...

A CSS can track devices by ping, and can control the failover between devices based on availability of a service, monitored by a ping. A CSS will also do routing.

So, take a pair of CSSs and configure VRRP between them, one has static routes to primary next hop, the other has static routes to the backup. The one with routes to the primary next hop is configured to be VRRP active. The primary next hop is configures as a critical service, so that should the device stop responding to pings, the CSS VRRP will fail over to the backup, that has routes pointing elsewhere.

Now, I am not going to say that is a good thing to do, but could be an interesting use for a CSS!

Paul.