HSRP-Overriding preemption Delay

[e-alvarez]

Hi All,

I have a question (a problem, really) regarding HSRP configured for using the preempt delay minimum feature.

Rtr A is our main router, while Rtr B is our backup router. We need to switch over to the backup, should a track change state. So far, so good, as it does that just fine. To avoid flapping and to give the main circuit a chance to stabilize, we configured the preempt delay minimun, so that even when the main circuit comes back up, rtr A still waits for the preempt timer to expire before becoming the active router. Still, so far so good. This part also works fine. The problem is when router B is Active, main circuit is up, preempt timer has not expired and router?s B link goes down. HSRP still waits for the preempt timer on router A to expire before becoming active, even though router B is now useless, and router A is functional, except for HSRP.

Any ideas on how to solve this problem will be greatly appreciated.

These are the configs:

Main, active router:

rtr A (IOS=c2801-spservicesk9-mz.123-11.T10.bin):

!

track 100 rtr 1

!

!

!

interface FastEthernet0/0

ip address 10.48.205.66 255.255.255.224

ip nat inside

duplex auto

speed auto

standby 1 ip 10.48.205.65

standby 1 timers 15 20

standby 1 priority 110

standby 1 preempt delay minimum 3600

standby 1 track 100 decrement 20

rtr 1

type echo protocol ipIcmpEcho 148.xx.xx.x source-ipaddr 149.xxx.xxx.x

frequency 30

rtr schedule 1 life forever start-time now

.

.

.

Backup router.

rtr B (IOS=c2800nm-ipbase-mz.124-3d.bin):

interface FastEthernet0/0

ip address 10.48.205.67 255.255.255.224

ip nat inside

duplex auto

speed auto

standby preempt

standby 1 ip 10.48.205.65

standby 1 preempt delay minimum 5

[l.mourits]

Noticing the small subnet you use, I figure you have a small vlan for wan connectivity. If this is the case and your switch is layer 3 capable I would consider making the switch part of your routing protocol AS in that vlan for wan connectivity and then remove HSRP as the routing protocol will do the trick for you. In that case there is no need to track either.

HTH,

Leo

[e-alvarez]

Thanks for your answer.

The WAN is realy a MAN, with each router connecting to a different ISP through fastethernet interfases. The problem with our ISPs is that they often have routing problems in their cloud, or their Internet carrier sometimes also goes down. The fastethernets never go down either phisically or logically (i.e. inetfase down/down nor up/down). There is no Sw, either L2 nor L3, in front of the routers. The ISP are in Central America and the tracked object is "a little bit to the north". Behind the routers are a couple of firewalls making a VPN through the Internet. We run our apps using this tunnel. So...we need the object tracking to make sure we are getting through. Thats how we ended up with that config.

[cyphur353]

I would lower router A's preempt timer. 3600 seconds is a long time to wait, if the circuit is back up. Dial it back to 5 - 10 minutes at most, and see if that helps.

If you lose both pipes within 5-10 minutes of eachother often enough that you need to configure around that eventuality, I'd re-negotiate your SLA's.

[e-alvarez]

If we could negotiate SLAs, their service would be free :-)

Any other idea?

[l.mourits]

Question; If you have no switch at all, where do the router fastethernet interfaces connect to?

Just a cross connect, or what?

I?m sorry, but you have to provide some more detail on what you have on your internal network. The tracking option is far from ideal in your case, that I?m sure of.

[e-alvarez]

In the .doc attachement is a network diagram, along with the complete config for both routers and some other info. If you feel you additional data, just let me know. We have a lab set up with this config, so we can run debugs or try other changes you feel appropiate.

Again, thanks for your interest.

Regards,

Eduardo

[l.mourits]

Question: What kind of switches do you have in the 200.x.x.x network (where fa0/1 connects to)?

[l.mourits]

Okay, here is what you need to do.

Router A

ip sla monitor 1

type echo protocol ipIcmpEcho 151.xx.xx.54

timeout 1000

frequency 3

threshold 2

request-data-size 1400

ip sla monitor schedule 1 start-time now life forever

!

track 2 rtr 1 state

track 3 rtr 1 reachability

!

interface FastEthernet0/0

ip address 10.48.205.66 255.255.255.224

ip nat inside

duplex auto

speed auto

standby 1 ip 10.48.205.65

standby 1 timers 15 20

standby 1 priority 110

standby 1 preempt

standby 1 track 2 decrement 20

standby 1 track 3 decrement 20

!

end

Router B

ip sla monitor 1

type echo protocol ipIcmpEcho 151.xx.xx.54

timeout 1000

frequency 3

threshold 2

request-data-size 1400

ip sla monitor schedule 1 start-time now life forever

!

track 2 rtr 1 state

track 3 rtr 1 reachability

!

interface FastEthernet0/0

ip address 10.48.205.67 255.255.255.224

ip nat inside

duplex auto

speed auto

standby 1 ip 10.48.205.65

standby 1 timers 15 20

standby 1 priority 100

standby 1 preempt

standby 1 track 2 decrement 20

standby 1 track 3 decrement 20

!

end

That should do the trick. You can play with the sla monitor settings and tracking decrements to better fit your needs.

For more info on this enhanced object tracking, please see this document:

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a008042fbeb.html

HTH,

Leo

[Richard Burts]

Leo

I see that you are suggesting that both routers should track. In looking at the original post and the following discussion I felt that one weakness of the original implementation was that it was only tracking on one router. And I agree that there is an advantage in having both routers track. But I am not convinced that tracking on the second router really addresses the issue in the original post.

Am I correct in my understanding that the essence of your suggested improvement is that you have removed the preempt delay which was the focus of the original question?

HTH

Rick

[l.mourits]

Rick,

Correct, my approach is to not use preempt delay and have both routers track and decrement their priority by the ip sla tracking.

I addressed the issue on how to prevent flapping by using the ip sla feature. I believe this could be the solution to teh original problem, and it is still a simple config ;-)

HTH,

Leo

[e-alvarez]

Great, we?ll try that solution in the lab and I?ll post the results, probably next week because of more pressing matters.

I really appreciate your interest and help.

Thanks

[markmotors]

Not sure if this issue has been solved yet, but how about using a routing protocol over your tunnels? I am using eigrp over 2 tunnels for failover and load balancing. EIGRP hellos should check your reachability for each route.