In this scenario what we did was to put a router behind each bridge then configure GLBP on the routers. By using GLBP and setting the load balancing mode to ‘round-robin’ we allowed for a kind of ‘L3 ether-channel’ across the wireless. The dual-band radio’s allowed us to run both the a and g channels at 54Mbps and get a ‘by the book’ 108Mbps per bridge which means the customer gets 216Mbps. We met the requirements, they ratified the design and the investment was made. As it turned out we got about 150Mbps because of loss but you know what, they only ever used about 10Mbps at the most anyway which was a good conversation I assure you.

So what about GLBP, what is it that makes it a better FHRP than say HSRP or VRRP? Well unlike these other two, GLBP (or Gateway Load Balancing Protocol) is capable of distributing load between the other members of the GLBP group. Take for example three routers connected to one network segment. Each router is sitting in the same network of 192.168.1.0/24 with R1 being .11, R2 being .12 and R3 being .13. Now if this were HSRP or indeed VRRP those routers can operate as one HSRP or VRRP group too but only one of that group is active. Only one can forward traffic, the others are just sat there doing nothing except waiting for something bad to happen to the active node.

With GLBP there is still a master of sorts and that is called the AVG or Active Virtual Gateway. The AVG is elected in much the same way as the active node in HSRP and VRRP. Each node has a priority of 100 by default and the highest priority node in the group is elected as the AVG. Again, just like HSRP and VRRP the AVG when elected will not be de-selected for any other member of the group unless it is lost (e.g. the box running the AVG fails). You can however, just as with HSRP and VRRP chose to allow any member to take over control as the AVG if we set a higher priority and configure preemption.

So, how does GLBP work. Well GLBP is a great way of load balancing traffic between multiple gateways while at the same time allowing for automatic failover in case one of the members fails. We can set the load balancing to round robin where the source traffic is balanced equally to each node based on an ‘R1, now R2, now back to R1, then R1’ basis. We can also set a preference known as weight to send say 75% of traffic to R1 and the remaining 25% to R2.

How does it manage the load balancing? Well it uses a cool technique of virtual MAC allocation. Basically the AVG manages the GLBP group members. It knows the MAC addresses of the neighbors and it knows the virtual IP address (VIP) associated with the cluster. When a client sat behind the GLBP group wishes to send network traffic outside of the local network it ARP’s out for the MAC address of its gateway. This request comes into the GLBP AVG the AVG passes back a virtual MAC address (associated with one of the members of the group) to the client. The client then has that MAC address in it’s ARP table associated with the gateway VIP. Now when the client sends its data it sends it to the VIP. The AVG manages this whole process to make sure a distribution of traffic across the nodes in the group based on the load balancing configuration (.e.g. round-robin, none, weighted etc).

Lets take an example, here we are going to have three nodes in the GLBP group. Each node is going to be sharing the virtual IP address 192.168.1.1 and the clients will be using that IP address as their default gateway. Our clients will be R1 and R2. Nodes R3, R4 and R5 are members of the GLBP group which we will configure as group 1.


Screen shot 2011-06-18 at 11.42.50


Each of the nodes have been configured with the following IP addressing:

R1 Fa0/0 = 192.168.1.101
R2 Fa0/0 = 192.168.1.102
R3 Fa0/0 = 192.168.1.3
R3 Fa1/0 = 10.1.1.3
R4 Fa0/0 = 192.168.1.4
R4 Fa1/0 = 10.1.1.4
R5 Fa0/0 = 192.168.1.5
R5 Fa1/0 = 10.1.1.5
R6 Fa0/0 = 10.1.1.106
R7 Fa0/0 = 10.1.1.107

Lets start out by setting up a basic GLBP configuration on R3. Lets make R3 the AVG of the group by default, it will become the AVG because there are no other members. We’re going to turn on GLBP debug with the commands:

R3#debug glbp events
GLBP Events debugging is on

R3#debug glbp packets
GLBP Packets debugging is on


Lets turn on GLBP for the FastEthernet0/0 port. We’ll define the virtual IP address to bind to that interface (remember that there is already an IP address assigned to this interface of 192.16.1.3)

R3(config)#int f0/0
R3(config-if)#glbp 1 ip 192.168.1.1


Lets walk through the process:

*Mar 1 13:25:22.768: GLBP: Fa0/0 API 192.168.1.1 is not a GLBP address in table 0
*Mar 1 13:25:22.772: GLBP: Fa0/0 1 Disabled: a/GLBP IP address configured
*Mar 1 13:25:22.772: GLBP: Fa0/0 1 Disabled -> Init
*Mar 1 13:25:32.780: GLBP: Fa0/0 Interface up
*Mar 1 13:25:32.780: GLBP: Fa0/0 1 Init: d/GLBP enabled
*Mar 1 13:25:32.780: GLBP: Fa0/0 1 Init -> Listen


See that first line - this is GLBP doing a ‘double take’. Before I star this, do I already know anything about GLBP on this interface. Clearly it’s a no and the GLBP process goes form being disabled n the interface to active by moving to the Initial or Init phase. Right, GLBP is now ‘up’ on the interface (NOTE: this is not saying the interface moved from down to up). Right, into Listen phase. Now this is all good stuff, it looks exactly like almost every other protocol we ever saw ever...whats the best part of a conversation? The answer is listening before you speak, that way you won’t put your foot in it.

This is a ‘listen’ packet. See I’m asking specifically for ‘Grp 1’ this was our group. Our priority is 100 - thats the default. We’re going to send one of these every 3 seconds (3000 milliseconds).

*Mar 1 13:25:41.780: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Listen pri 100 vIP 192.168.1.1 hello 3000, hold 10000

Right I’ve done enough listening now, I heard nothing, so I’m going to shout out my intention to be the GBLP ‘man’ for group 1

*Mar 1 13:25:42.780: GLBP: Fa0/0 1 Listen: g/Active timer expired (unknown)
*Mar 1 13:25:42.780: GLBP: Fa0/0 1 Listen -> Speak


We’re going to send these Hellos now again every 3 seconds for a maximum of 10 seconds. See how we’re now in ’Speak’ mode not ‘Listen’

*Mar 1 13:25:42.780: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Speak pri 100 vIP 192.168.1.1 hello 3000, hold 10000

OK I’m not hearing anything coming back at all so I don’t need to assert my awesomeness anymore. I’m going to move into a the ’Standby phase’

*Mar 1 13:25:52.780: GLBP: Fa0/0 1 Standby router is local
*Mar 1 13:25:52.780: GLBP: Fa0/0 1 Speak -> Standby


One more Hello before I hit my 10second timer

*Mar 1 13:25:52.780: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Standby pri 100 vIP 192.168.1.1 hello 3000, hold 10000

Right lets transition into an ‘Active’ state now. I’m the AVG!

*Mar 1 13:25:52.784: GLBP: Fa0/0 1 Standby: g/Active timer expired (unknown)
*Mar 1 13:25:52.784: GLBP: Fa0/0 1 Active router IP is local
*Mar 1 13:25:52.784: GLBP: Fa0/0 1 Standby router is unknown, was local
*Mar 1 13:25:52.784: GLBP: Fa0/0 1 Standby -> Active
*Mar 1 13:25:52.784: %GLBP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active


OK so now thats sorted I’m in control of assigning the virtual MAC addresses. That means I need to think of one. So I’m going to call out, again, to see if anyone else is using the MAC address I want to use.

*Mar 1 13:25:52.788: GLBP: Fa0/0 1.1 Disabled: a/Forwarder MAC address acquired
*Mar 1 13:25:52.788: GLBP: Fa0/0 1.1 Disabled -> Listen


Right - lets whiz out a few ‘Hellos’ to see if anyone responds to my MAC address.

*Mar 1 13:25:52.788: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Active pri 100 vIP 192.168.1.1 hello 3000, hold 10000 VF 1 Listen pri 167 vMAC 0007.b400.0101

I’m asking about virtual MAC 0007.b400.0101. Lets have a look at this MAC. Well we build this up using a common MAC in the first instance of 0007.b400. Now the next 16 bits are up for grabs. The 01 closest to the left is derived from the group number i.e. group 1 is 01, group 2 would be 02 etc. You can have a maximum of 1024 groups so I guess we can use up to 10 bits for group (we can have 4 forwards per group). The right most two numbers of ’01’ relate to the member ID. First member to come up gets 01, next is 02 etc...

OK so, we’ve run out of time and not heard anyone complaining about the vMAC so we’ll assert that on our interface now and go active.

*Mar 1 13:26:02.788: GLBP: Fa0/0 1.1 Listen: g/Active timer expired
*Mar 1 13:26:02.788: GLBP: Fa0/0 1.1 Listen -> Active


Check out the VF keyword here in this debug - VF = Virtual Forwarder.

*Mar 1 13:26:04.788: GLBP: Fa0/0 Grp 1 Hello out 192.168.1.3 VG Active pri 100 vIP 192.168.1.1 hello 3000, hold 10000 VF 1 Active pri 167 vMAC 0007.b400.0101

OK so we’re up and running. I’m going to ping out between R1 and R6 now then lets have a look at the ARP table on R1.

R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/29/40 ms


Here is the ARP table. We’ve got the MAC address for R3’s Fa0/0 interface and the vMAC address for the GLBP group.

R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.100 - cc00.05a1.0000 ARPA FastEthernet0/0
Internet 192.168.1.1 1 0007.b400.0101 ARPA FastEthernet0/0
<-- this is the Virtual MAC
Internet 192.168.1.3 67 cc02.05a1.0000 ARPA FastEthernet0/0
<-- this is the MAC for R3
Internet 192.168.1.2 75 cc02.05a1.0000 ARPA FastEthernet0/0


All good stuff. At the moment then you are looking at a virtual mac and a virtual IP address running on the physical Fa0/0 interface on R3. But this is a First Hop Redundancy Protocol right so we need to add in some redundancy. Lets load up GLBP on R4 and add it to the cluster group running on R3. First we go into the interface then add the GLBP statement. Notice it’s using the same GLBP group number as R3 and the same virtual IP address of 192.168.1.1.

R4(config)#int f0/0
R4(config-if)#glbp 1 ip 192.168.1.1


On R4 with no ‘debug’ running this is the output on the console. We see the GLBP process going through a forwarding state change from Listen to Active for GLBP group 1.

*Mar 1 13:53:13.140: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 2 state Listen -> Active

This is the debug running on R3. Notice it has seen the Hello’s from R4 (192.168.1.4) and the AVG running on R3 has agreed with R4 that R4 is to become the standby router for that group.

*Mar 1 13:53:06.412: GLBP: Fa0/0 1.2 Disabled: a/Forwarder MAC address acquired
*Mar 1 13:53:06.412: GLBP: Fa0/0 1.2 Disabled -> Listen
*Mar 1 13:53:20.412: GLBP: Fa0/0 1 Standby router is 192.168.1.4


Looking back on R3 we can examine the status of the nodes in the current GLBP cluster.

R3#sh glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Fa0/0 1 - 100 Active 192.168.1.1 local 192.168.1.4
Fa0/0 1 1 - Active 0007.b400.0101 local -
Fa0/0 1 2 - Listen 0007.b400.0102 192.168.1.4 -


Now then, we have a resilience to failure. If we lose R3 then R4 should take over as the AVG and therefore ownership of the AVG. The client (R1) should see no difference to it’s MAC table during the failure process. So lets do that now, we’ll knock out R3 by shutting down the Fa0/0 interface.

This is the console debug on R4 after we shutdown R3.

*Mar 1 14:00:32.504: %GLBP-6-STATECHANGE: FastEthernet0/0 Grp 1 state Standby -> Active
*Mar 1 14:00:32.504: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 1 state Listen -> Active


R4 is now the active (AVG) for GLBP group 1. Notice that the Active router is now ‘local’ and this comand is being run in R4 not R3. There is now also no standby router.

R4#show glbp
Interface Grp Fwd Pri State Address Active router Standby router
Fa0/0 1 - 100 Active 192.168.1.1 local unknown
Fa0/0 1 1 - Active 0007.b400.0101 local -
Fa0/0 1 2 - Active 0007.b400.0102 local -


Lets run a ping again from R1 to the remote host and look at the MAC addresses.

R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 19 0007.b400.0101 ARPA FastEthernet0/0


Looks the sae right? Thats because the AVG manages the AVF. the AVG knows what it’s doing here. BUT one of the great things whch happens next is aging. When the client’s arp cache is lost it has to re-learn the MAC address for the gateway (192.168.1.1) so it ARP’s out again and guess what? Well this time the AVG fires off the new vMAC associated with R4.

R1#clear arp
R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:!!!!!
R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0


So now 192.168.1.1 is associated with R4’s vMAC - remember the last two digits are 02 indicating the second member in the group?

OK lets bring R3 back into service and then we’ll bring R5 into the GLBP group so we have three member in the group ad then we will be ready start tweaking, tuning and generally messing about with the cluster members to show how it all fits together.

Ok so here are some of the things we can mess with:

Priority - this determines who is going to be in charge of the cluster group. The one who manages the AVF’s and dishes out the vMACs. The highest priority is preferred.
Preempt - if we have this set then then the node will become the active AVG if the priority is higher than all o the other nodes in the group.
Weight - changing the weight of a node affects how much ‘load/traffic’ it is given by the AVG.
Load balancing - we can change the way the group operates to include things like source MAC, round-robin and weight.

Of the following the most useful in terms of GLBP and it’s benefit above other FHRP’s with HSRP and VRRP are the weight and load balancing. Changing the way traffic is passed through the cluster can be of great benefit if you are trying to better utilise over/under utilised links. Source MAC load balancing is a pretty neat way of ensuring traffic *always* goes the way you need it to (a bit like affinity or ‘stickiness’ for session based traffic). The source will be sent a MAC address for the AVF at that time and it will always be given that MAC. The others will change the MAC advertised to the source.

Here is the output from R3 for ‘show glbp’. Notice we have the shared virtual IP of 192.168.1.1. The main points here are in bold - you can see we have 3 group members and we list their REAL physical MAC addresses. You can see there are three AVF’s or active virtual forwarders. The active AVF is R3 and all of the other AVF’s listen to R3...he rules. We’ve setup R3 to have a priority of 120, R4 to be 100 and R3 to be 80. The AVG goes to the one with the highest priority (remember the preempt rules).

We’ve also set R3 to have a AVF weight of 75, R4 to have 50 and R5 to have 25. The AVF weight is used when we are distributing load using the ‘weighted’ load balancing algorithm. We can set limits or ‘thresholds’ for weighting and if we set a lower threshold and decrement below that lower threshold we can in effect STOP the AVF forwarding traffic.

R3#sh glbp
FastEthernet0/0 - Group 1
State is Active
6 state changes, last state change 00:19:41
Virtual IP address is 192.168.1.1
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.324 secs
Redirect time 600 sec, forwarder time-out 14400 sec
Preemption enabled, min delay 0 sec
Active is local
Standby is 192.168.1.4, priority 100 (expires in 7.940 sec)
Priority 120 (configured)
Weighting 75 (configured 75), thresholds: lower 1, upper 75
Track object 1 state Up decrement 51
Load balancing: round-robin
Group members:
cc02.05a1.0000 (192.168.1.3) local
cc03.05a1.0000 (192.168.1.4)
cc04.05a3.0000 (192.168.1.5)

There are 3 forwarders (1 active)
Forwarder 1
State is Active
3 state changes, last state change 00:28:41
MAC address is 0007.b400.0101 (default)
Owner ID is cc02.05a1.0000
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local,
weighting 75
Arp replies sent: 3
Forwarder 2
State is Listen
MAC address is 0007.b400.0102 (learnt)
Owner ID is cc03.05a1.0000
Redirection enabled, 599.596 sec remaining (maximum 600 sec)
Time to live: 14399.596 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.4 (primary),
weighting 50 (expires in 9.596 sec)
Forwarder 3
State is Listen
MAC address is 0007.b400.0103 (learnt)
Owner ID is cc04.05a3.0000
Redirection enabled, 598.580 sec remaining (maximum 600 sec)
Time to live: 14398.580 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.5 (primary),
weighting 25 (expires in 8.580 sec)

We’ll demonstrate the ‘load balancing’ part of GLBP now - this is what we are after isn’t it. So lets have a look at the interface - the default load balancing is to use ‘round robin’. For round robin in our example we’re going to talk to R3 then R4, then R5, then R3 then R4 then R5 in that order based on weight.

Remember the default for GLBP is round robin so there is no configuration change at this time.

Load balancing: round-robin

OK lets ping R6 first from R1

R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 24/35/40 ms
R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.100 - cc00.05a1.0000 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.4 0 cc03.05a1.0000 ARPA FastEthernet0/0


Notice the MAC address given to R1 for the VIP of 192.168.1.1 ends in ’0101’ - GLBP group 1, first node.

OK lets clear the ARP table so we have to re-learn the MAC address for R6. The AVG should now allocate the vMAC for R5 which ended in 0102

R1#clear arp
R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/30/40 ms
R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.100 - cc00.05a1.0000 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.4 0 cc03.05a1.0000 ARPA FastEthernet0/0


OK lets clear the ARP table so we have to re-learn the MAC address for R6. The AVG should now allocate the vMAC for R6 which ended in 0103

R1#clear arp
R1#ping 10.1.1.106
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.106, timeout is 2 seconds:.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/32/40 ms
R1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.1.100 - cc00.05a1.0000 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0
Internet 192.168.1.4 0 cc03.05a1.0000 ARPA FastEthernet0/0


Right, thats the default of round robin. We’ve also got weighted and MAC based. Lets setup MAC based load balancing and ping from R1 and R2 to R6. We should see R1 get a vMAC and R2 get a different vMAC (hopefully) and after that no matter how many times we clear the ARP table on either R1 or R2 they should get the same vMAC.

First we configure the load balancing based on source MAC (you would do this on all members but this is the AVG right now)

R3(config-if)#glbp 1 load-balancing host-dependent

Right lets ping from R1 and look at the learned vMAC

Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0

Lets clear the ARP table and ping again

Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0

It never changes...sticky.

Right weighted load balancing. Lets setup out topology so that R3 is the best weighting with 100, R4 with get 50 and R5 will get 10 .So, when we ping R6 form R1 we would expect that 5 out of 10 times R5 would be the source vMAC for 192.168.1.1 and R6 would be it 1 in 10 times.

Lets setup the weighting method and weights (change the 100 for 50 and 10 respectively for each router)

R3(config-if)#glbp 1 load-balancing weighted
R3(config-if)#glbp 1 weighting 100


Here is the output from show glbp showing the weights are applied

Forwarder 1
State is Active
7 state changes, last state change 00:13:42
MAC address is 0007.b400.0101 (default)
Owner ID is cc02.05a1.0000
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local,
weighting 100
Arp replies sent: 6
Forwarder 2
State is Listen
MAC address is 0007.b400.0102 (learnt)
Owner ID is cc03.05a1.0000
Redirection enabled, 599.564 sec remaining (maximum 600 sec)
Time to live: 14399.560 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.4 (primary),
weighting 50 (expires in 9.560 sec)
Arp replies sent: 2
Forwarder 3
State is Listen
MAC address is 0007.b400.0103 (learnt)
Owner ID is cc04.05a3.0000
Redirection enabled, 598.536 sec remaining (maximum 600 sec)
Time to live: 14398.532 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.1.5 (primary),
weighting 10 (expires in 8.528 sec)
Arp replies sent: 21


Right, lets ping R6 from R1...this is 100 pings and clears so I’m not going to show them all...believe me when I tell you it works out ;-) Here are the best bits from 10 pings.

Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0101 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0


So for 10 pings we got 6 using R1, 3 using R2 and 1 using R3... I’m not doing this for 100 pings guys ;-) It’s close enough for me to expect it’ll work out by the end. The point here is we would do this sort of weighted approach for different line capacities or if we have poor circuits we don’t want to use as much. As an example maybe we’d weight a 100Mbps and 1Gbps uplink in a 1:10 ratio respectively since the bandwidth ratio is the same.

OK, lets move on a little now. we’ve seen how we failover from R3 to R4 when we shutdown the local GLBP interface but what if we lose connectivity between R3 and R6? There is no point in traffic coming to R3 if there is no way for R3 to send that traffic on to the destination. We’ll setup a basic interface track to manage that. If the interface goes down we’ll decrement by 99 which will take the priority down to 0 which means that is should stop forwarding traffic

Lets setup the object tracking, then we’ll assign a weight decrement value for the AVF, then we’ll shutdown interface F1/0 and watch the results.

Object tracking - we’ve seen this before and it’s in other articles on here so no big depth. We’re going to watch for line protocol changes on interface F1/0.

R3(config)#track 1 interface fa1/0 line-protocol

Right now we’ll assign a weight value to the interface for the GLBP group 1. We’re dropping 51 if we lose the interface F1/0

R3(config-if)#glbp 1 weighting track 1 decrement 99

Right now we’ll setup the weighting in the interface so that if the value falls below 1 (remember this is just a test, you can use multiple trackings to manage the weight value e.g. drop by 20 if this route is out of the table etc) that the AVF stop forwarding traffic.

R3(config-if)#glbp 1 weighting 100 lower 1

This is the output from R3 after we shutdown Fa1/0. Notice the tracked object state change and weight from 100 to 0 (100-100=0)

*Mar 1 14:53:10.728: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Standby -> Init
*Mar 1 14:53:10.732: %TRACKING-5-STATE: 1 interface Fa1/0 line-protocol Up->Down
*Mar 1 14:53:10.732: GLBP: Fa0/0 1 Track 1 object changed, state Up -> Down
*Mar 1 14:53:10.732: GLBP: Fa0/0 1 Weighting 100 -> 0
*Mar 1 14:53:12.728: %LINK-5-CHANGED: Interface FastEthernet1/0, changed state to administratively down
*Mar 1 14:53:13.728: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to down


Then we get a GLBP response from the active router R5

*Mar 1 16:16:09.055: GLBP: Fa0/0 1.1 Active: i/Hello rcvd from higher pri Active router (135/192.168.1.5)
*Mar 1 16:16:09.055: GLBP: Fa0/0 1.1 Active -> Listen
*Mar 1 16:16:09.059: %GLBP-6-FWDSTATECHANGE: FastEthernet0/0 Grp 1 Fwd 1 state Active -> Listen
*Mar 1 16:16:09.059: GLBP: Fa0/0 API MAC address update
*Mar 1 16:16:09.063: GLBP: Fa0/0 1.1 Ignoring Hello (135/192.168.1.4 < 135/192.168.1.5)


OK lets try that weighted ping again. This time we should *never* use R3 since it’s weighting is now below the threshold and should not be forwarding traffic.

Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0102 ARPA FastEthernet0/0
Internet 192.168.1.1 0 0007.b400.0103 ARPA FastEthernet0/0

Right, well that took way longer than I expected to put down here but I really hope it helped anyone out

Good luck with your studies

View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.