route-map to override default gateway

Guest

Hello,

I am in the process of switching backbone providers and for a time will
have two ISPs connected to my cisco 3600.

1st on a t1
2nd on a atm pvc

I have been operating on the 1st using static routes 0.0.0.0 pionting
to the serial interface, now I want to config my servers on the lan
with IPs provided by the 2nd ISP so each server will have two IPs, one
from the 1st and one from the 2nd.

So how do I get traffic on the 2nd ISP's IPs to only traverse the atm
pipe?

I though of doing a route-map as copied below, which looks to work for
traceroute and ping, but any tcp/udp traffic stalls. It seems to send
one packet and then get hung.

Thank you for your advice!
Christopher

--

access-list 1300 remark Provides matching of CIT addresses for atm pipe
access-list 1300 permit 63.247.209.0 0.0.0.255
access-list 1300 permit 63.247.210.0 0.0.1.255
access-list 1300 permit 63.247.212.0 0.0.0.255

route-map gotosprings permit 10
match ip address 1300
set ip next-hop 63.247.196.33 <- 2nd isp end of the atm pvc

int f0/0 <- this int has a primary ip from the 1st isp and a secondary
from the 2nd
ip policy route-map gotosprings
ip route-cache policy

Merv · Guest

if you have cef enabled then remove the " ip route-cache policy"
command as that is for fast-switching PBR which is slower than CEF PBR

Guest

Merv,

Thanks for the info...

I turned of cef "no ip cef", but it did not make any difference.

I also tried making default routing a policy only decision and removed
all the default 0.0.0.0 routes like this:
route-map findgateway permit 10
match ip address 1300 <- matches source ip's from 2nd isp
set ip default next-hop b.b.b.b
route-map findgateway permit 20
match ip address 1301 <- matches source ip's from 1st isp
set ip default next-hop a.a.a.a

1st ISP worked, but 2nd did not. I even shutdown the 1st ISP
interfaces just to make sure it wasn't through a kink into the works,
but no go.

Any other ideas?

Could there be a ACL or policy upstream on the 2nd ISP causing
problems?

Thank you,
Christopher

Guest

I fixed the problem.

Turned out to be an ATM cloud issue with the telco that was dropping
packets over 500 bytes. Once that was fixed by the telco rebuilding the
path, everything worked!

A few notes on cpu utilization and route-map.

When running CEF and route-map, make sure to issue no ip route-cache
cef on the interface that is doing route-map and also add ip
route-cache policy.

Christopher