09-25-2007 11:45 AM - edited 03-05-2019 06:42 PM
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
09-25-2007 12:38 PM
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
09-25-2007 01:51 PM
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.
09-25-2007 02:11 PM
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.
09-26-2007 07:24 AM
If we could negotiate SLAs, their service would be free :-)
Any other idea?
09-26-2007 11:54 AM
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.
09-26-2007 05:35 PM
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
09-26-2007 11:06 PM
Question: What kind of switches do you have in the 200.x.x.x network (where fa0/1 connects to)?
09-27-2007 12:53 AM
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
09-27-2007 02:57 AM
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
09-27-2007 03:04 AM
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
09-27-2007 09:09 AM
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
10-12-2007 07:56 AM
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.
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