Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Route Redundancy Puzzle

Hi Guys,

I thought I'd pick your collective brains on an interesting little puzzle.

I have a VRF running on a 6500 series switch. This currently has a static route pointing to a firewall (that will not participate in a dynamic routing protocol) to get to a desired destination.

We now need to implement a dynamic resilient alternative route to the same destination.

This alternative route is learnt via OSPF from another router. This route is only to be used in the event of a primary route failure.

Under normal circumstances the primary route, being static, has a lower admin distance and therefore takes priority.

I can detect a failure using IP SLA, however is it possible to be able to react to this and disable/remove the static route?

The interface the static route points out of will not drop, as I am looking to accomodate for an upstream failure.

dialer-watch will not appear to help me in this instance, as my redundant route is not a dial-interface (is it possible to make a VPN tunnel a dial interface?)

I am also seeking to avoid manual interventation (rather than the current delays of realise fault -> logon to switch -> remove static route.)

Any thoughts?




Accepted Solutions
Super Bronze
New Member

Re: Route Redundancy Puzzle

You need to investigate Embedded Event Manager. Depending on the version you are using you can monitor track events and rtr instances. It allows you, among other things, to run arbitrary cli commands which will allow you remove a route. If I remember rightly there was an example doing exactly what you are asking for.

Its a steep but (short) learning curve to pick up EEM but its very handy to know.

Start here -

Super Bronze
New Member

Re: Route Redundancy Puzzle


Many thanks, linking the static route to the IP SLA was the final link.

Your quick responses are appreciated!