backup route question

[eric_garnel]

OK, here is my scenario:

I have a primary connection to isp "A" via a static route 0.0.0.0

0.0.0.0 gateway.

I also have a secondary connection to isp "B"

Neither ISP is willing to participate (or extend) in dynamic routing

with my network therefore a floating static route as a backup will not

work.

not only is my default route defined in the configuration, it is

applied to a vlan interface, which is logical and is not prone to a

lot of the issues that affect physical interfaces. I am running IOS

12.1.19(EW) on sup III blades in Cat 4006 switches, both connected to

a 3550 which is just acting as a switch at the moment (no layer 3

processing).

Interum solution:

I have setup a script on a server that pings the gateway for ISP "A"

and will telnet into the primary hsrp router and change the default

route to point to ISP "B" and write it. The script runs every few

minutes via cron. Another script checks to see if it is back up (ping)

and restores the original route. This is a complete rig and not the

best solution, but it does the job until I can find a better way.

Desired solution:

Have the routers decide routing in event of a failure. I understand

that the switches do not support ping based PBR yet even though the

command syntax seems to be there.

Has anyone else dealt with a similar scenario?

[keith.campbell]

How about;

! Configure the objects to be tracked.

! Object 123 will be up if the router can ping 10.1.1.1.

! Object 124 will be up if the router can ping 10.2.2.2.

rtr 1

type echo protocol ipicmpecho 10.1.1.1

rtr schedule 1 start-time now life forever

!

rtr 2

type echo protocol ipicmpecho 10.2.2.2

rtr schedule 2 start-time now life forever

!

track 123 rtr 1 reachability

track 124 rtr 2 reachability

!

! Enable policy routing using route-map alpha on Ethernet 0.

interface ethernet 0

ip address 10.4.4.254 255.255.255.0

ip policy route-map alpha

!

! 10.1.1.1 is via this interface

interface ethernet 1

ip address 10.1.1.254 255.255.255.0

! 10.2.2.2 is via this interface

interface ethernet 2

ip address 10.2.2.254 255.255.255.0

!

! Configure a route-map to set the next-hop to 10.1.1.1 if object 123 is up. If object 123

! is down, the next hop will be set to 10.2.2.2 if object 124 is up. If object 124 is also

! down, then policy routing fails and unicast routing will route the packet.

route-map alpha

set ip next-hop verify-availability 10.1.1.1 10 track 123

set ip next-hop verify-availability 10.2.2.2 20 track 124

[eric_garnel]

So, it does support reachability via the verifiy-availability then?

[eric_garnel]

Another question: this should work with 0.0.0.0?

set ip next-hop verify-availability 0.0.0.0 10 track 123

set ip next-hop verify-availability 0.0.0.0 20 track 124

[eric_garnel]

The track command is not functional on the switch. It requests an interface type.

track 123 rtr ?

% Unrecognized command

ACCD-SHOWNET2(config)#track 123 ?

interface Select an interface to track

ACCD-SHOWNET2(config)#track 123 in

ACCD-SHOWNET2(config)#track 123 interface ?

CTunnel CTunnel interface

FastEthernet FastEthernet IEEE 802.3

GigabitEthernet GigabitEthernet IEEE 802.3z

Loopback Loopback interface

Port-channel Ethernet Channel of interfaces

Tunnel Tunnel interface

Vif PGM Multicast Host interface

Vlan Catalyst Vlans

fcpa Fiber Channel

ACCD-SHOWNET2(config)#track 123 interface vlan 20 ?

ip Track interface IP capability

line-protocol Track interface line-protocol

track 123 interface vlan 20 ip ?

routing Track interface IP routing capability

ACCD-SHOWNET2(config)#track 123 interface vlan 20 ip ro

ACCD-SHOWNET2(config)#track 123 interface vlan 20 ip routing ?

[eric_garnel]

Keith, this looks like it will only work with 12.3 IOS. Unfortunately, I do not have the option available on the 4000 series switches yet.

[eric_garnel]

Is this a Possible option?

Enhanced Object tracking from:

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

example:

Tracking IP-Route Reachability

This task describes how to track the reachability of an IP route. A tracked object is considered up when a routing table entry exists for the route and the route is accessible.

Does this mean that even though there is a static route entry in the routing table, the track will still be able to determine that the route is not reachable via the rtr command? Given the above example, I do not see how the rtr statements would ever be called by the policy due to the fact that I am only able to implement the track command upon an interface and not on a rtr object

[mvalentine]

this option is available in 12.3(4)T and later code

[eric_garnel]

So that leaves me stuck with my interum solution of having a script check for upstream connectivity and running an expect script to "auto-manually" change the default route to point to the 2nd ISP and back