'Reliable Static Routing' problem on a Cisco 1721 (not very reliable)

[tangerine0072000]

Hi all,

Using the 'reliable static routing' feature on a Cisco 1721. It's basically configured to poll a public address which if fails to respond, will replace the default-gateway with a floating default-gateway pointing to another comms links and ISP.

The failover works fine and the default-gateway gets replaced, but while in a failover state, every few pings fail, so my ping responces to a public address look like the following....

C:\>ping 198.6.1.4 -t

Pinging 198.6.1.4 with 32 bytes of data:

Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=82ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Reply from 198.6.1.4: bytes=32 time=82ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246
Reply from 198.6.1.4: bytes=32 time=81ms TTL=246

further investigation reveals that during the 'request timed out ' period, the original default-gateway is put back and then removed again. Strange behaviour, not very reliable.

Has anybody used this feature and got it to work ?

My config for this is below, 198.6.1.4 is simply a DNS server on the Internet.

Lab1#sh run
Building configuration...

Current configuration : 1204 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$l6b2$bNl2i74E5CFlVeRUf.K/V/
enable password cisco
no aaa new-model
resource policy
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 198.6.1.4
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 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
no ip http secure-server

access-list 101 permit icmp any host 198.6.1.4 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 123456
login

end

LAB1#

 

[ROUTERKID1]

http://www.cisco.com/en/US/products..._feature_guide09186a00801d862d.html#wp1071380

 

[tangerine0072000]

I have actually followed this document step-by-step.

Because the tracking object (in this case the ip address of the DNS server) can be seen on both primary and secondary WAN Internet links, the router sees the tracking object as being 'up' and tries to replace the original gateway. This appears to cause a loop resulting in failed ping responses in a failover condition.

Is this it's normal behaviour ?

 

[tangerine0072000]

Is there someway the tracking object can be forced to check an ip address through a specific interface only, but not through all interfaces which I'm currently experiencing.

 

[KiscoKid]

Hello.

Try setting the source-interface or source-ipaddr to the primary interface in ip sla monitor configuration, i.e.

type echo protocol ipIcmpEcho 198.6.1.4 source-interface e0

HTH

 

[tangerine0072000]

KiscoKid thanks for your replies. I'm getting intermittent strange results at the moment.

My primary and secondary router interfaces sit behind two different firewalls which perform a NAT so public addresses can be pinged.

It seams that every time I setup a 'tracking object' to poll a public address, it fails to see it, so the primary default-gateway never gets installed.

Whats wiered is that when I disable all tracking, I can ping this public address perfectly through the primary WAN.

Its as though the it doesn't like the firewall, but nothing is being blocked. I'm scratching my head now....

 

[ROUTERKID1]

Sounds like a firewall issue to me, Kisco what do you think ?

 

[JOAMON]

Is it possible that the devices connected to e0 and e1 need an ip route that directs traffic destined for the 192.168.229.0/24 subnet? You could also try using rip and see if advertising your networks to those other devices helps.

 

[JOAMON]

???
Isn't the following item missing from your config:

ip local policy route-map MY_LOCAL_POLICY

 

[tangerine0072000]

Both my firwalls have routes back to the 192.168.229.0 networks via each interface.

The ip local policy route-map MY_LOCAL_POLICY is also present.

My problems occur when simply enabling tracking. The tracking simply doesn't see the ip addresses I'm trying to monitor.

If I disable tracking, I can ping the public address on either interface.

This is my current config....

LAB1#sh run
Building configuration...

Current configuration : 1267 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$A.Wu$YVv/RSa5nG/nJ/LuiP1kL1
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 198.6.1.4
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
no ip http secure-server

access-list 101 permit icmp any host 198.6.1.4 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#

 

[tangerine0072000]

More info....

when I do 'sh track 123' it is always down

sh track 123
Track 123
Response Time Reporter 1 reachability
Reachability is Down
118 changes, last change 00:00:03
Latest operation return code: Timeout
Tracked by:
STATIC-IP-ROUTING 0

 

[tangerine0072000]

This is now resolved. Thanks for all your help.

The problem turned out to be an incorrectly route-map which was pointing the next-hop address to the 192.168.99.1 where it should have been 192.168.225.1

now works a treat !!