Solved: Re: Problems with 'Reliable Static Routing' using rtr

tangerine0072000 · ‎03-02-2006

I have a 1721 router with 3 nics.

f0 - LAN

e0 - primary

e1 - secondary

eo & e1 plug into two different firewalls and then off to the internet using two different ISP'S. The idea was to provide some degree of failover between to the two ISP's.

I decided to use 'reliable static routing' which should replace the default-gateway with a floating default-gateway to the secondary link.

I configured rtr to poll a public internet address which if failed to respond would replace the default-gateway. The problem I have is that every time I enable this rtr and tracking feature, it fails to see the public internet address, so I'm always in a failed over state.

If I disable rtr and tracking, I can ping the public address through both primary & secondary links no problem.

As I mentioned e0 & e1 plug into two differnet firewalls, firewalls are performing NAT and ports are completey open on each firewall.

I'm scracthing my head and don't understand why traking can't see the public address. Here is a copy of my config.....

LAB1#sh run

Building configuration...

Current configuration : 1250 bytes

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

hostname LAB1

boot-start-marker

boot-end-marker

enable secret 5 $1$5FeV$T4LY/smzKpMWtgee4OmvK.

enable password cisco

no aaa new-model

resource policy

memory-size iomem 25

mmi polling-interval 60

no mmi auto-configure

no mmi pvc

mmi snmp-timeout 180

ip cef

ip sla monitor 1

type echo protocol ipIcmpEcho 10.100.106.10

timeout 1000

threshold 2

frequency 3

ip sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

interface Ethernet0

ip address 192.168.225.2 255.255.255.0

half-duplex

interface Ethernet1

ip address 192.168.99.66 255.255.255.0

half-duplex

interface FastEthernet0

ip address 192.168.229.2 255.255.255.0

speed auto

full-duplex

ip local policy route-map MY_LOCAL_POLICY

ip route 0.0.0.0 0.0.0.0 192.168.225.1 track 123

ip route 0.0.0.0 0.0.0.0 192.168.99.1 254

no ip http server

access-list 101 permit icmp any host 10.100.106.10 echo

route-map MY_LOCAL_POLICY permit 10

match ip address 101

set interface Null0

set ip next-hop 192.168.99.1

control-plane

line con 0

line aux 0

line vty 0 4

password cisco

login

end

LAB1#

pkhatri · ‎03-02-2006

No probs... I did not even think of checking it at first !

The point of pushing it out through the primary interface is so that you will know for certain when that link is down since the ping cannot go out any other way.

Pls do rate the posts if you thought they were useful.

Regards,

Paresh

View solution in original post

pkhatri · ‎03-02-2006

Hi,

I believe the problem is in your route-map. Change it so that it looks like the following:

route-map MY_LOCAL_POLICY permit 10

match ip address 101

set ip next-hop 192.168.99.1

set interface Null0

i.e. add the 'set ip next-hop' command first followed by 'set interface null0'

Hope that helps - pls rate the post if it does.

Paresh

tangerine0072000 · ‎03-02-2006

Hi,

it doesn't seam to matter what order I enter the commands, the null 0 statement always appears before the next hop command.

I just deleted the route map and re-created it and still it appears before next-hop !

pkhatri · ‎03-02-2006

Actually, I must take back what I posted earlier.. that was a bit of a red herring...the 'set ip next-hop' will always take priority.

I suggest you enable 'debug ip policy' with the local policy applied and then attempt to ping 10.100.106.10. That will tell you whether the local policy is doing its job.

Paresh

tangerine0072000 · ‎03-02-2006

Just deleted everything and started again, lost count of how many time I've done that.

I added a bit to the end of the rtr statement so it forces traffic out of the appropriate interface and chose a public ip just a couple of hops away.

type echo protocol IpIcmpEcho 65.193.201.129 source-ipaddr 192.168.225.2 (e0)

still got the same problem and debug shows map is working I think

*Mar 1 17:00:14.311: IP: s=192.168.225.2 (local), d=65.193.201.129, len 64, pol

icy match

*Mar 1 17:00:14.311: IP: route map MY_LOCAL_POLICY, item 10, permit

*Mar 1 17:00:14.311: IP: s=192.168.225.2 (local), d=65.193.201.129 (Ethernet1),

len 64, policy routed

*Mar 1 17:00:14.311: IP: local to Ethernet1 192.168.99.1

*Mar 1 17:00:17.311: IP: s=192.168.225.2 (local), d=65.193.201.129, len 64, pol

icy match

*Mar 1 17:00:17.311: IP: route map MY_LOCAL_POLICY, item 10, permit

*Mar 1 17:00:17.311: IP: s=192.168.225.2 (local), d=65.193.201.129 (Ethernet1),

I confident it's something to do with route-map or policy because if I remove these, I can ping public internet addresses through either link.

here's my current config

Current configuration : 1275 bytes

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

hostname LAB1

boot-start-marker

boot-end-marker

enable secret xxxx.

enable password xxxx

no aaa new-model

resource policy

memory-size iomem 25

mmi polling-interval 60

no mmi auto-configure

no mmi pvc

mmi snmp-timeout 180

ip cef

ip sla monitor 1

type echo protocol ipIcmpEcho 65.193.201.129 source-ipaddr 192.168.225.2

timeout 1000

threshold 2

frequency 3

ip sla monitor schedule 1 life forever start-time now

track 123 rtr 1 reachability

interface Ethernet0

ip address 192.168.225.2 255.255.255.0

half-duplex

interface Ethernet1

ip address 192.168.99.66 255.255.255.0

half-duplex

interface FastEthernet0

ip address 192.168.229.2 255.255.255.0

speed auto

full-duplex

ip local policy route-map MY_LOCAL_POLICY

ip route 0.0.0.0 0.0.0.0 192.168.225.1 track 123

ip route 0.0.0.0 0.0.0.0 192.168.99.1 254

no ip http server

access-list 101 permit icmp any host 65.193.201.129

route-map MY_LOCAL_POLICY permit 10

match ip address 101

set interface Null0

set ip next-hop 192.168.99.1

control-plane

line con 0

line aux 0

line vty 0 4

password xxxx

login

end

LAB1#

pkhatri · ‎03-02-2006

Hey,

I think I know what the issue is... the next-hop address you specify in the route-map should be the next-hop address of the primary interface. You have configured it to be the next-hop on the backup interface. You have to set it to be 192.168.225.1.

Hope that helps,

Paresh.

tangerine0072000 · ‎03-02-2006

Your the man ! You've made my day !

It must be a typo in the Cisco document as this specifies the secondary interface as next-hop. My understanding of this was for next hop if primary failed.

Anyway I've amended it and it works a treat...thanks again !

pkhatri · ‎03-02-2006

No probs... I did not even think of checking it at first !

The point of pushing it out through the primary interface is so that you will know for certain when that link is down since the ping cannot go out any other way.

Pls do rate the posts if you thought they were useful.

Regards,

Paresh

IM-Design · ‎09-29-2006

Tangerine,

Im starting to configure an 1841 router with similar hardware capabilities: 2 WAN interfaces and 1 LAN interface.

Would you be able to post your operational configuration for the 1721?