Need to explain HSRP preempt delay

[sjrcoel]

Hello. The reason for delaying Preempt while looking at cisco HSRP-related documents is because"When a router first comes up, it does not have a complete routing table. If HSRP is configured to preempt, the local HSRP group may become the active router, yet it is unable to provide adequate routing services. This problem can be solved by configuring a delay before the preempting router actually preempts the currently active router."

I came across a phrase.
I knew that FHRP like HSRP or VRRP was a gateway redundancy protocol, but I didn't really understand why the routing table was included in that description. So I'm going to ask you a few questions.
Q1. Even if there is no direct impact on FHRP, is it in terms of preventing the problem of dropping packets due to the routing table that are not intact after the router boots by putting pre-emptive delay in HSRP in overall operation of the network.
Q2.You said the routing table is not complete after boot, but all routing protocols are not complete after boot.

[M02@rt37 · Accepted solution]

Hello @sjrcoel 

The reasoning behind delaying preempt in HSRP is indeed related to the completeness of the routing table after a router boots up. When a router boots, it goes through various processes to establish its routing table. If HSRP is configured to preempt immediately upon coming online, it might become the active router before its routing table is fully populated and stable. This could lead to suboptimal routing or even packet loss.

By introducing a preemption delay, you allow the router some time to ensure that its routing table is stable and complete before it takes over as the active router in the HSRP group. This helps avoid potential issues associated with routing instability during the initial router startup phase.

You're correct that not all routing protocols have a complete routing table immediately after boot. The delay is particularly relevant for routers participating in interior routing protocols (like OSPF, EIGRP) where it might take some time to establish adjacencies, exchange routing information, and build a stable routing table. The concern is more pronounced for routers running interior gateway protocols because they actively exchange routing information with neighboring routers. HSRP itself is not a routing protocol; it's a FHRP responsible for providing gateway redundancy.

[MHM Cisco World]

Why preempt in hsrp?

When we power on both router the hsrp active election starts and end by elect one router as active' when it fails the standby be new active' now old active up again 

A- without preempt' the standby (new active) and old active not start election again even if old active have higher priority.

B- with preempt' the old active send special hsrp message' making standby (new active) start election again and in end since old active have higher priority it will elect as active again

From above you can clear get that with preempt is make network not stable if the active router (old) flapping or it track to interface is flapping' here come the role of delay. We make some delay to be sure that old active stable before start new election.

MHM

[Joseph W. Doherty]

Q1:  If there was no possible impact to packets bring sent to a FHRP gatewy, there would be no need for a prempt the routing delay, possibly such as is only connected and/or static routes were needed to populate the routing table.  But as M02@rt37 already described, dynamic routing protocols can take some time to populate the routing table.  During such time packets would be dropped but would not have been if directed to the prior active FHRP gateway.  (BTW, this issue is NOT limited to just FHRPs.  iBGP depending on an IGP is a similar issue.)

Q2:  Yes, correct, so we're trying to allow enough time for individual router "convergence" before we start routing traffic, in this case, FHRP traffic.

[MHM Cisco World]

Now imagining that both HSRP not run any IGP but have static route' do I need preempt delay?

Yes you need it preempt delay as I mention before make sure the old active be stable before standby starts new election.

So one factor indeed RIB stability if all router reload but the most important is fact that make old active failed to be active for hsrp group' one of these fact track or interface flapping.

MHM

[Joseph W. Doherty]

"Now imagining that both HSRP not run any IGP but have static route' do I need preempt delay?

Yes you need it preempt delay as I mention before make sure the old active be stable before standby starts new election."

Unsure you "need" HSRP delay with static routes.  I would expect a router, booting, to insert local information into a route table before external issues are dealt with.  Would also expect this to take less time than a HSRP switch over.

Of course, that's my expectation.  Don't recall seeing a Cisco guarantee on boot order feature start up precedence like Cisco does for some other order of operations.  I.e. adding a delay would help guarantee static routes are in the route table before a HSRP switch over.  Unfortunately, don't also recall Cisco providing explicit delay time values that should be used for different boot up feature times.

In the real-world, if HSRP preempt can happen before static route insertion into the route table, I would expect the latter would not be much behind.  I.e., for static routes, probably it's a non-issue for most networks.

[MHM Cisco World]

Sorry for late reply 

But I so busy finally I will finish studying SDWAN.

Anyway 

When router not failed 

Or 

Router dont use IGP (use defualt route and it stable)

We need preempt delay?

Sure we need it' as I mentioned before the goal of preempt delay is wait until link OR router stable.

I want to clear this point to anyone read this post later'

We wait router or it interfaces (links) stable then we run new election.

I done want to close it to statement 

If router use igp then use delay if not no need

Hope this clear my point 

MHM

[Joseph W. Doherty]

Unfortunately, your reply, to me, not totally clear.

In any case, how long should the delay be?  Would delay be the same in all cases?

BTW actual need, I believe, is relative too.  I.e. assume HSRP switch over happens too quickly, what's the impact per individual case.  (Also consider, in a failure situation, likely some traffic may be loss until HSRP standby becomes active.  [Also, don't misunderstand, I'm not arguing against the value of this feature, just you might want to consider actual value in various cases.  For example how I configure networks to well support VoIP is often more involved then non-VoIP networks.])