Route Redundancy Puzzle

Answered Question
Feb 18th, 2009

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?

Regards,

David

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Loading.
baldy Wed, 02/18/2009 - 04:28

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 -

http://www.cisco.com/en/US/products/ps6815/products_ios_protocol_group_home.html

dsnixon Wed, 02/18/2009 - 07:54

Hi,

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

Your quick responses are appreciated!

Regards,

David

Actions

This Discussion