08-31-2013 08:00 AM - edited 03-07-2019 03:14 PM
Hello everyone,
I've made some tests recently regarding the preemption delay feature: quick reminders
Preempting an AVG Router::
(config-if)#glbp group-id preempt [delay minimum avg-seconds]
// delay minimum avg-seconds: Specifies a minimum number of seconds that the router will delay before taking over
// the role of AVG. The range is from 0 to 3600 seconds with a default delay of 30 seconds(!);
Preempting an AVF Router:
(config-if)#glbp group-id forwarder preempt [delay minimum avf-seconds]
// Configures a router to take over as AVF if the current AVF falls strictly below its low weighting threshold.
// By default, already the case with delay = 30s;
My tests show that in both cases, if you set the minimum delay to 0 second, the AVG or AVF election process is disturbed:
On HSRP or VRRP, a 0 second preemption delay does not disturb the election processes.
Any similar or contradictory experiences?
09-01-2013 08:19 AM
I'm surprised no one tried to achieve sub-second failover time with GLBP.
It looks like a bug now.
09-01-2013 10:56 AM
Hi Jean-Christophe,
I was not able to reproduce your observation.
Running two 2691 routers on a common segment, this was their configuration:
R1:
interface FastEthernet0/0
ip address 10.0.0.11 255.255.255.0
duplex auto
speed auto
glbp 1 ip 10.0.0.1
glbp 1 forwarder preempt delay minimum 0
R2:
track 1 interface Loopback0 line-protocol
!
interface FastEthernet0/0
ip address 10.0.0.12 255.255.255.0
duplex auto
speed auto
glbp 1 ip 10.0.0.1
glbp 1 weighting 100 lower 95 upper 99
glbp 1 weighting track 1 decrement 10
glbp 1 forwarder preempt delay minimum 0
On R2, I am running debug glbp terse. At the beginning, the state of the GLBP group is as follows:
R1:
R1(config-if)#do show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Fa0/0 1 - 100 Active 10.0.0.1 local 10.0.0.12
Fa0/0 1 1 - Listen 0007.b400.0101 10.0.0.12 -
Fa0/0 1 2 - Active 0007.b400.0102 local -
R2:
R2(config-if)#do show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Fa0/0 1 - 100 Standby 10.0.0.1 10.0.0.11 local
Fa0/0 1 1 - Active 0007.b400.0101 local -
Fa0/0 1 2 - Listen 0007.b400.0102 10.0.0.11 -
After shutting down the Lo0 on R2 which is being tracked, the debug produces the following output:
R2(config-if)#int lo0
R2(config-if)#shut
R2(config-if)#
*Mar 1 00:48:32.523: %TRACKING-5-STATE: 1 interface Lo0 line-protocol Up->Down
*Mar 1 00:48:32.527: GLBP: Fa0/0 1 Track 1 object changed, state Up -> Down
*Mar 1 00:48:32.527: GLBP: Fa0/0 1 Weighting 100 -> 90
*Mar 1 00:48:34.523: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Mar 1 00:48:34.587: GLBP: Fa0/0 1.1 Active: i/Hello rcvd from higher pri Active router (135/10.0.0.11)
*Mar 1 00:48:34.587: GLBP: Fa0/0 1.1 Active -> Listen
*Mar 1 00:48:34.587: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 1 state Active -> Listen
*Mar 1 00:48:35.523: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
Notice that the GLBP took note of the track object going down at 00:48:32 and at 00:48:34, R2 moved from Active to Listen state. This takeover took roughly 2 seconds. After activating the Lo0 again, the debugs show:
R2(config-if)#int lo0
R2(config-if)#no shut
R2(config-if)#
*Mar 1 00:50:04.103: %TRACKING-5-STATE: 1 interface Lo0 line-protocol Down->Up
*Mar 1 00:50:04.107: GLBP: Fa0/0 1 Track 1 object changed, state Down -> Up
*Mar 1 00:50:04.111: GLBP: Fa0/0 1 Weighting 90 -> 100
*Mar 1 00:50:04.411: GLBP: Fa0/0 1.1 Listen: k/Hello rcvd from lower pri Active router (135/10.0.0.11)
*Mar 1 00:50:04.415: GLBP: Fa0/0 1.1 Listen -> Active
*Mar 1 00:50:04.419: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 1 state Listen -> Active
*Mar 1 00:50:06.099: %LINK-3-UPDOWN: Interface Loopback0, changed state to up
*Mar 1 00:50:07.099: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to up
Here, the switchover back to Active state is practically instantaneous.
The switchover time can be further reduced by lowering the Hello timer, as the Hello timer is responsible for another AVF to take over by presenting a higher weight than the current AVF. After configuring glbp 1 timers msec 100 1 (Hello is 100 msec, Hold is 1 sec) on both R1 and R2, let's see the effect of shutting down of Lo0 on R2:
R2(config-if)#int lo0
R2(config-if)#shut
R2(config-if)#
*Mar 1 00:53:10.467: %TRACKING-5-STATE: 1 interface Lo0 line-protocol Up->Down
*Mar 1 00:53:10.467: GLBP: Fa0/0 1 Track 1 object changed, state Up -> Down
*Mar 1 00:53:10.467: GLBP: Fa0/0 1 Weighting 100 -> 90
*Mar 1 00:53:10.507: GLBP: Fa0/0 1.1 Active: i/Hello rcvd from higher pri Active router (135/10.0.0.11)
*Mar 1 00:53:10.507: GLBP: Fa0/0 1.1 Active -> Listen
*Mar 1 00:53:10.507: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 1 state Active -> Listen
*Mar 1 00:53:12.467: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Mar 1 00:53:13.467: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
Here, deeply under a single second, GLBP relinquished the AVF Active role and proceeded to Listen.
Would you mind trying out a similar configuration on your devices and double checking the results?
Best regards,
Peter
09-03-2013 09:54 AM
Thanks Peter for your answer.
I reproduced my setup to show you the surprising results.
The configuration is a little bit more complex and oriented towards a production network, with 3 L3 switchs connected on the same subnet: 3725 IOS 12.4(15)T5. Each L3 switch is connected to Internet (2 links) et tests these connections.
The following setup tests AVF preemption, but we could do the same with AVG preemption. If you're interested, I can perform the same tests with 3 x 7206 loaded with IOS 15.2.
SW1 configuration:
SW2 configuration:
SW5 Configuration:
Now, I cut the remaining Internet connection on SW1:
But SW1 remains AVF despite the fact that its weighting is below its lower threshold:
09-03-2013 03:04 PM
Jean-Christophe,
I have slightly updated my configuration to resemble yours, though I still have only two routers (I do not think their count makes a difference here):
R1:
interface FastEthernet0/0
ip address 10.0.0.11 255.255.255.0
glbp 1 ip 10.0.0.1
glbp 1 timers msec 100 1
glbp 1 forwarder preempt delay minimum 0
end
R2:
track 1 interface Loopback0 line-protocol
track 2 interface Loopback1 line-protocol
!
interface FastEthernet0/0
ip address 10.0.0.12 255.255.255.0
glbp 1 ip 10.0.0.1
glbp 1 timers msec 100 1
glbp 1 weighting track 1 decrement 50
glbp 1 weighting track 2 decrement 50
glbp 1 forwarder preempt delay minimum 0
I am running debug glbp terse on R2. Now:
R2(config)#do show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Fa0/0 1 - 100 Standby 10.0.0.1 10.0.0.11 local
Fa0/0 1 1 - Listen 0007.b400.0101 10.0.0.11 -
Fa0/0 1 2 - Active 0007.b400.0102 local -
R2(config)#int lo0
R2(config-if)#shut
R2(config-if)#
*Mar 1 00:07:57.751: %TRACKING-5-STATE: 1 interface Lo0 line-protocol Up->Down
*Mar 1 00:07:57.755: GLBP: Fa0/0 1 Track 1 object changed, state Up -> Down
*Mar 1 00:07:57.755: GLBP: Fa0/0 1 Weighting 100 -> 50
*Mar 1 00:07:59.751: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Mar 1 00:08:00.751: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
R2(config-if)#int lo1
R2(config-if)#shut
R2(config-if)#
*Mar 1 00:08:09.547: %TRACKING-5-STATE: 2 interface Lo1 line-protocol Up->Down
*Mar 1 00:08:09.547: GLBP: Fa0/0 1 Track 2 object changed, state Up -> Down
*Mar 1 00:08:09.551: GLBP: Fa0/0 1 Weighting 50 -> 0
*Mar 1 00:08:09.579: GLBP: Fa0/0 1.2 Active: i/Hello rcvd from higher pri Active router (135/10.0.0.11)
*Mar 1 00:08:09.579: GLBP: Fa0/0 1.2 Active -> Listen
*Mar 1 00:08:09.579: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 2 state Active -> Listen
*Mar 1 00:08:11.543: %LINK-5-CHANGED: Interface Loopback1, changed state to administratively down
*Mar 1 00:08:12.543: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback1, changed state to down
R2 promptly left the Active role after the weighting got decreased to 0 (using the default thresholds of 1 and 100). Clearly, your and mine results using a similar configuration differ considerably.
One thing to point out is that the R2 did not leave the Active role by itself - rather, it depended on receiving a Hello from R1 that caused it to relinquish the Active role. I wonder if the same happens with your device. Can you run debug glbp terse on your SW1 and post the debug outputs?
Another suggestion is to actually use the glbp weighting command to define non-standard thresholds, that will be crossed easily, say, glbp 1 weighting 100 lower 40 upper 45. Can you test this out?
Best regards,
Peter
09-04-2013 09:09 AM
With "debug glbp terse" + "debug glbp packets hello" (necessary on this old IOS version otherwise no hello debug message appear on the console):
As you can see, nothing happens after SW1 weighting goes below 1 and it receives SW2 hello.
Changing its weight as suggested does not change anything.
Now, if I add a 7206 in the same subnet (IOS 15.2), other strange things happen:
First, it takes over all AVF roles!:
Next, when its weight goes below its lower threshold, it immediately drops 2 AVF roles and keeps the last one!:
Could it be stranger?
09-04-2013 09:41 AM
Now, same setup but with only 3 7206 IOS 15.2 in the same subnet with identical configuration:
This time, everything works like a charm; one router drops its AVF role:
... while another 7206 takes over:
Conclusion: there seems to be a bug in IOS 12.4(15)T5 on 3725 related to AVF (and AVG) preemption minimum delay set to 0s.
Do you agree Peter?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: