Cisconinja’s Blog

HSRP/VRRP/GLBP Timers and Preemption

Posted by Andy on February 9, 2009

This post will take a look at some of the less common issues related to timers, preemption, and preemption delays in the first hop redundancy protocols.  The topology is shown below:

hsrp-vrrp-glbp1-topology

 

First we will configure HSRP, VRRP, and GLBP on R1 and R2 without changing any of the default settings:

R1:
interface FastEthernet1/0
 standby 1 ip 10.1.1.101
 vrrp 1 ip 10.1.1.102
 glbp 1 ip 10.1.1.103

R2:
interface FastEthernet1/0
 standby 1 ip 10.1.1.101
 vrrp 1 ip 10.1.1.102
 glbp 1 ip 10.1.1.103

As expected, R2 becomes the master router for VRRP group 1 and active router for HSRP and GLBP group 1 (as long as it is configured before R1 can transition to active) since R1 and R2 have equal priority and R2 has the higher IP address:

hsrp-vrrp-glbp-13

Next let’s enable preemption for all 3 protocols on R3 and then bring each of them up.  Preemption is enabled by default for VRRP so we only need to enable it for HSRP and GLBP:

R3:
interface FastEthernet1/0
 standby 1 preempt
 standby 1 ip 10.1.1.101
 vrrp 1 ip 10.1.1.102
 glbp 1 preempt
 glbp 1 ip 10.1.1.103

R3 now has an equal priority to the other routers in all 3 groups, the highest IP address in all 3 groups, and is allowed to preempt the master/active router of all 3 groups.  Take a look at the results after applying this configuration:

hsrp-vrrp-glbp-2

R3 has become the master for the VRRP group.  R3 has also overthrown R1 to become the standby router for both HSRP and GLBP, however it does not transition to active.  Of these 3 protocols, only VRRP allows a higher IP address to preempt a master/active router; HSRP and GLBP require a higher priority value in order for preemption to occur.

 

Next we will look at the hello and hold timers for each of the protocols.  First we will increase the HSRP and GLBP priorities on R3 so that it is the master/active router for each protocol:

R3:
interface FastEthernet1/0
 standby 1 priority 101
 glbp 1 priority 101

hsrp-vrrp-glbp-3

We will change the hello and hold timers for HSRP and GLBP to different values on each of the three routers:

R1:
interface FastEthernet1/0
 standby 1 timers 6 18
 glbp 1 timers 6 18

R2:
interface FastEthernet1/0
 standby 1 timers 5 15
 glbp 1 timers 5 15

R3:
interface FastEthernet1/0
 standby 1 timers 4 12
 glbp 1 timers 4 12

This does not cause a problem for HSRP or GLBP since the hello and hold timers are communicated by the active router in hello messages, and timers learned from the active router override manually configured timers.  Since R3 is active for both protocols, it is using a hello timer of 4 seconds and hold timer of 12 seconds:

hsrp-vrrp-glbp-4

hsrp-vrrp-glbp-5

R1 and R2 show that they have learned and are using these timer values, and make a note in parenthesis of what their actual configured values are:

hsrp-vrrp-glbp-6

hsrp-vrrp-glbp-7

If R3 fails or is preempted by a different router, the new active router will use it’s manually configured timers and the other routers will relearn the timers from that router.  In this case, if R3 fails R2 will become active for both HSRP and GLBP since it was already standby because it had a higher IP address than R1.  R1 will then learn the new timers from R2:

R3:
interface FastEthernet1/0
 shutdown

hsrp-vrrp-glbp-8

hsrp-vrrp-glbp-9

Next we will change the hello and hold timers for HSRP and GLBP to use sub-second values.  We will re-enable R3’s interface so that it becomes active for all groups and make the changes on R3:

R3:
interface FastEthernet1/0
 no shutdown
 glbp 1 timers msec 200 msec 800
 standby 1 timers msec 200 msec 800


R1 and R2 learn the new GLBP timers without any problems:

hsrp-vrrp-glbp-10

hsrp-vrrp-glbp-111

HSRP, however, behaves differently:

hsrp-vrrp-glbp-121

hsrp-vrrp-glbp-131

hsrp-vrrp-glbp-14

R1 and R2 still see R3 as the active router, but neither has learned R3’s hello or hold timers – instead R1 and R2 are using their manually configured timers.  Looking at the HSRP packets in Wireshark reveals what the problem is:

hsrp-vrrp-glbp-wireshark-1 

hsrp-vrrp-glbp-wireshark-2

The first picture shows an HSRP hello sent by R2 and the second an HSRP hello sent by R3.  The hellotime and holdtime fields are each 1 byte long and contain the manually configured timers on that router in seconds.  We can see that R3 has set both of them to 0 since there is no way of entering a sub-second value, so R1 and R2 continue to use their manually configured timers.  The hold time for the active router never falls below 17.8 seconds on R1 and 14.8 seconds on R2 since R3 is sending hellos every 200 ms.  If R3 fails, failover will not occur for 15 seconds because R2 is not able to take advantage of the sub-second hold time.  Since R3 is using a holddown timer of 800 ms and R2 (the standby router) is using its manually configured timer to send hellos every 5 seconds, R3 will continually cycle through seeing R2 as the standby router for 800 ms and thinking that there is no standby router for the next 4200 ms:

hsrp-vrrp-glbp-15

HSRP version 2 can be used to overcome this problem.  We will configure HSRP version 2 on each router:

R1:
interface FastEthernet1/0
 standby version 2

R2:
interface FastEthernet1/0
 standby version 2

R3:
interface FastEthernet1/0
 standby version 2

HSRP version 2 sends the hello and hold timers in milliseconds and uses a 4 byte field for each of them:

hsrp-vrrp-glbp-wireshark-3

We can see that R1 and R2 now correctly learn R3’s timers and prefer them over their manually configured ones:

hsrp-vrrp-glbp-16

hsrp-vrrp-glbp-17

Unlike HSRP and GLBP, VRRP does not automatically learn timers from the master router.  Also unlike HSRP and GLBP, VRRP requires that the hello timer of all routers in the group match.  Let’s try configuring a different hello timer on each router:

R1:
interface FastEthernet1/0
 vrrp 1 timers advertise 2

R2:
interface FastEthernet1/0
 vrrp 1 timers advertise 3

R3:
interface FastEthernet1/0
 vrrp 1 timers advertise 4

hsrp-vrrp-glbp-18

hsrp-vrrp-glbp-19

hsrp-vrrp-glbp-20

After applying the configuration, all 3 routers think that they are the master router for the group.  VRRP can be configured to learn timers from the master router so that it behaves similarly to HSRP and GLBP:

R1:
interface FastEthernet1/0
 vrrp 1 timers learn

R2:
interface FastEthernet1/0
 vrrp 1 timers learn

R3:
interface FastEthernet1/0
 vrrp 1 timers learn

If configured with both vrrp timers advertise and vrrp timers learn, timers learned from the master router will override manually configured timers just like with HSRP and GLBP.  R1 and R2 once again see R3 as the master and transition into the backup state.  R1 and R2 also continue to display their manually configured hello timer as well as the hello timer that they have learned from the master:

hsrp-vrrp-glbp-21

hsrp-vrrp-glbp-22

hsrp-vrrp-glbp-23

Like we saw with HSRP and GLBP, if R3 fails, R2 will become the master router and begin advertising its manually configured hello timer of 3 seconds.  R1 will learn the new timer from R2 and accept R2 as the master router.  VRRP has a similar problem to HSRP version 1 when attempting to get other routers in the group to learn sub-second timers.  VRRP even gives a warning if timer learning is enabled on the router that we try to configure sub-second timers on:

R3:
interface FastEthernet1/0
 vrrp 1 timers advertise msec 200

% cannot configure millisecond timers when timer learning enabled

Since R3 is the master router, it won’t be learning timers anyway so the warning is probably there because it assumes our other routers are using timer learning as well.  Let’s see what happens when we disable timer learning on R3 and configure it to advertise millisecond timers to the other routers:

R3:
interface FastEthernet1/0
 no vrrp 1 timers learn
 vrrp 1 timers advertise msec 200

hsrp-vrrp-glbp-24

hsrp-vrrp-glbp-25

hsrp-vrrp-glbp-26

R1 and R2 both see R3 as the master still, but they think that R3’s advertisement interval is 1 second.  Look at what R3’s VRRP packet looks like in Wireshark:

hsrp-vrrp-glbp-wireshark-4

VRRP also uses a 1 byte field for the hello timer in seconds.  In VRRP, a sub-second hello timer results in a hello timer of 1 second being sent.  If the other routers are configured for timer learning, they will learn the received value of 1 second.  If the other routers are not configured for timer learning and their hello timer has been left as the default of 1 second, they will think that the master is using the same hello timer value and accept it.  If the other routers are not configured for timer learning and their hello timer has been manually configured to a nondefault value, the routers will not accept the advertisement from the master configured with a sub-second hello timer and one or more of them will transition to the master state.  One other difference between VRRP and the other 2 protocols in regards to timers is that the master down interval (hold timer) is not configurable.  Instead, VRRP uses a value of 3 times the hello timer + the skew time as the master down interval.  The skew time is calculated as ((256 – VRRP priority) / 256), which will result in higher priority routers having a shorter skew time and master down interval.  First, we will change R3’s hello timer to 1 second so that all 3 routers are using the same hello timer again:

R1:
interface FastEthernet1/0
 vrrp 1 timers advertise 1

Using a hello time of 1 second and default priority of 100, each router calculates the master down interval as:

(3 * 1) + ((256 – 100)/256)  = 3.609 seconds

hsrp-vrrp-glbp-27

If R3 fails, R1 and R2’s master down intervals both expire at the same time and both of them try to seize the role of master router simultaneously:

R3:
interface FastEthernet1/0
 shutdown

hsrp-vrrp-glbp-wireshark-51

Once R1 sees R2’s superior advertisement, it accepts R2 as the master and goes back to the role of backup.  This causes R1 to transition to the master state, and then immediately back to backup a few milliseconds later once R2’s advertisement reaches it:

hsrp-vrrp-glbp-28

If R1 is configured to a lower priority (or R2 and R3 to a higher priority), it’s master down interval will be larger than R2:

R1:
interface FastEthernet1/0
 vrrp 1 priority 10

hsrp-vrrp-glbp-291

R2 now has about 350 ms after it’s master down interval expires for it’s advertisement to reach R1 before R1 tries to claim the role of master.

 

Next we will look at how initialization delay and preemption delay can be used.  HSRP is the only one of the 3 protocols that allows an initialization delay to be configured.  We will use the following HSRP configurations on each router. 

R1:
interface FastEthernet1/0
 standby 1 ip 10.1.1.101
 standby 1 timers 1 3

R2:
interface FastEthernet1/0
 standby 1 ip 10.1.1.101
 standby 1 timers 1 3

R3:
interface FastEthernet1/0
 shutdown
 standby 1 ip 10.1.1.101
 standby 1 timers 1 3
 standby 1 priority 101
 standby 1 preempt
 standby delay minimum 30

R3 has a higher priority and is configured to preempt, but is shutdown to begin with.  Now we will enable R3’s interface to simulate it coming back online:

R3:
interface FastEthernet1/0
 no shutdown

The configured initialization delay prevents HSRP from progressing beyond the Init state until it expires.  On R3, we can see that the state is Init and a timer counting down the number of seconds left until HSRP can initialize:

hsrp-vrrp-glbp-30

Approximately 30 seconds after the interface comes back up, HSRP transitions to the Listen and then Speak states, and then sends a coup to R2 and transitions to Active:

hsrp-vrrp-glbp-31

 

Preemption delay is supported by all three protocols.  Unlike HSRP intialization delay which kept HSRP in the Init state, preempt delay only prevents the router from transitioning to active/master.  We will take R3 offline and configure a preemption delay of 30 seconds for each protocol on R3.  We will also configure an HSRP intialization delay of 30 seconds to see how it operates with both delays configured.  The configuration of each router is:

R1:
interface FastEthernet1/0
 standby 1 ip 10.1.1.101
 standby 1 timers 1 3
 vrrp 1 ip 10.1.1.102
 glbp 1 ip 10.1.1.103
 glbp 1 timers 1 3

R2:
interface FastEthernet1/0
 standby 1 ip 10.1.1.101
 standby 1 timers 1 3
 vrrp 1 ip 10.1.1.102
 glbp 1 ip 10.1.1.103
 glbp 1 timers 1 3

R3:
interface FastEthernet1/0
 standby 1 ip 10.1.1.101
 standby 1 timers 1 3
 standby 1 priority 101
 standby 1 preempt delay minimum 30
 standby delay minimum 30
 vrrp 1 ip 10.1.1.102
 vrrp 1 preempt delay minimum 30
 glbp 1 ip 10.1.1.103
 glbp 1 timers 1 3
 glbp 1 priority 101
 glbp 1 preempt delay minimum 30
 shutdown

Approximately 7 seconds after enabling the interface, we can see that VRRP is in the backup state and has 23 seconds remaining until it can preempt the current master:

hsrp-vrrp-glbp-321

Approximately 9 seconds after enabling the interface, HSRP remains in the Init state.  The HSRP intialization delay takes effect before the preemption delay, so HSRP will remain in this state for 30 seconds.  We can see that the initialization delay timer has 21 seconds remaining:

hsrp-vrrp-glbp-34

Approximately 10 seconds after enabling the interface, we can see that GLBP has taken over the standby role.  There are 20 seconds remaining until it can preempt the current AVG:

hsrp-vrrp-glbp-331

After 30 seconds, R3 becomes the VRRP master router and GLBP AVG.  The HSRP initialization delay has expired and preempt delay begins.  Approximately 37 seconds after enabling the interface, we can see that HSRP is now in the standby state and has 23 seconds left on the preemption delay before it can become active:

hsrp-vrrp-glbp-35

After a total of 60 seconds, R3 becomes the active HSRP router.  The messages logged to the console also show a timeline of how the events take place:

 

*Mar 1 05:55:40.574: %VRRP-6-STATECHANGE: Fa1/0 Grp 1 state Init -> Backup
*Mar 1 05:55:42.562: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar 1 05:55:43.562: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up
*Mar 1 05:56:11.270: %VRRP-6-STATECHANGE: Fa1/0 Grp 1 state Backup -> Master
*Mar 1 05:56:11.614: %GLBP-6-STATECHANGE: FastEthernet1/0 Grp 1 state Standby -> Active
*Mar 1 05:56:11.618: %GLBP-6-FWDSTATECHANGE: FastEthernet1/0 Grp 1 Fwd 1 state Listen -> Active
*Mar 1 05:56:14.094: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Speak -> Standby
*Mar 1 05:56:42.078: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Standby -> Active


GLBP also allows preemption and preemption delay to be configured for the Active Virtual Forwarders (AVFs).  By default, preemption is enabled with a delay of 30 seconds.  Looking back at the logging messages, we can see that forwarder 1 changed state to active on R3 at almost the exact same time as the AVG changed state to active, since we configured the AVG with a preempt delay of 30 seconds also.  Let’s see what happens if we disable AVF preemption on R3 and then shutdown and re-enable the interface:

R3:
interface FastEthernet1/0
 no glbp 1 forwarder preempt
 shutdown

A few seconds later…

no shutdown

R3 becomes the AVG again after the 30 second AVG preemption timer expires, however it does not become active for any of the forwarders.  Instead R2, which took over forwarder #1 when R3 went offline, continues to remain active for both forwarder #1 and #2:

hsrp-vrrp-glbp-36

hsrp-vrrp-glbp-37

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: