cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2598
Views
0
Helpful
6
Replies

GLBP AVG and AVF Preemption Issue

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:

  • with avg-seconds= 0 on contender(s), the current AVG does not relinquish its role when it should be preempted by another gateway with a higher priority or IP address.
  • with avf-seconds= 0 on contender(s), the current AVF does not relinquish its AVF role when its weight falls strictly below its lower threshold (with a falling tracked object) and it should be preempted by another AVF.

On HSRP or VRRP, a 0 second preemption delay does not disturb the election processes.

Any similar or contradictory experiences?

6 Replies 6

I'm surprised no one tried to achieve sub-second failover time with GLBP.

It looks like a bug now.

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

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:

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

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?

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?

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco