04-27-2004 06:53 AM - edited 03-02-2019 03:17 PM
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?
04-27-2004 07:22 AM
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
04-27-2004 07:59 AM
So, it does support reachability via the verifiy-availability then?
04-27-2004 08:08 AM
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
04-27-2004 08:31 AM
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 ?
04-27-2004 09:23 AM
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.
04-27-2004 08:56 AM
Is this a Possible option?
Enhanced Object tracking from:
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
04-27-2004 09:31 AM
this option is available in 12.3(4)T and later code
04-27-2004 10:09 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide