cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7494
Views
35
Helpful
3
Comments
Szombatfalvi Hunor
Spotlight
Spotlight

Hello everyone, I have written the following guide for myself for my CCNP switch studies. I would like to publish it here for the benefit of others as I was not able to find all the information for it in one place and a lot of different documentation out there was actually misleading.

Everything written here is tested on equipment and based on experimenting and packet captures to make sure it is true.

I would like feedback on anything that I might have gotten wrong and also if anyone has some extra information on a few minor points i was not able to clarify completely:

  • What is the point of the Speak state in the AVG selection process?
  • Is the client-cache required for host-dependent load balancing? does it serve any other purpose?
  • What is the default time-out of entries in the client-cache tables?

As for a legend:

<item> indicates mandatory parameters

{item} indicates optional parameters

<item_1 | item_2> indicates a choice between two mandatory parameters

 

GLBP

 

GLBP stand for Gateway Load-Balancing Protocol

GLBP is a Cisco proprietary first-hop redundancy protocol

 

GLBP in many ways is the "big brother" of HSRP, it follows a lot of the same design philosophies while adding load balancing and in some places correcting some of the design issues of HSRP

  • GLBP uses the similar states as HSRP for the AVG
  • GLBP uses the same multicast IP (but on different ports)

 

GLBP provides default gateway redundancy and per host load-balancing

GLBP uses a single virtual IP address but multiple GLBP routers can be responsible for it at the same time, the differentiation being done by AVG at layer 2 using multiple virtual MAC address

 

GLBP virtual IP and MAC

  • GLBP uses a virtual IP and several virtual MAC addresses to achieve its purpose of a first hop redundancy protocol with load balancing. Usually this virtual IP is configured to be the default gateway in a subnet and the interfaces configured for GLBP in this subnet/broadcast domain hand over the responsibility for the virtual IP and MAC addresses amongst themselves making sure that the IP always remains reachable and if possible leveraging the virtual MACs to also allow for load balancing
  • The virtual IP can't be the same as the IP of the physical interface
  • The virtual IP address needs to be manually defined and is the only mandatory configuration element for VRRP
    • For IPv4, It is defined with (config-if)#glbp <0 - 1024> ip {a.b.c.d} {secondary}
      • It is possible to not enter an IP address, in this case the virtual IP will be learned from other GLBP interfaces with the same group number and subnet
      • It is possible to enter secondary virtual IP addresses as well from the same network  //I did not manage to make this work
    • For IPv6, It is defined with (config-if)#glbp <0 - 1024> ipv6 {x:x:x:x::x | autoconfig}
      • GLBP for IPv6 uses link-local IPs to communicate within the GLBP group

 

  • Interfaces participating in GLBP source packets from the IP of the interface, from port UDP/3222, sometimes using the interface's physical MAC and sometimes using the virtual MAC to the multicast address 224.0.0.102 UDP/3222

 

  • The virtual MAC address can't be defined manually
    • The automatically generated MAC assigned to each AVF is of the format of 0007.b4xx.xxyy, where
      • 0007.b4
        • Defines a MAC address as a GLBP virtual MAC
      • xx.xx
        • GLBP group number, converted from decimal to hexadecimal
      • yy
        • AVF number, , converted from decimal to hexadecimal
  • AVFs request their AVF number and virtual MAC from AVG

 

GLBP group

  • Each GLBP process uses a GLBP group number to differentiate between GLBP processes as one single interface can participate in multiple GLBP processes at the same time
  • When configuring GLBP on an interface, the syntax is (config-if)#glbp <group-id> <command> where group-id can be a value between 0 and 1023
  • Using the group-id, it is possible to configure the same interface in completely different ways for every GLBP process it participates in
  • The group-id is only significant inside the broadcast domain and the same group-id can be re-used on different interfaces of the same router as long as these interfaces are in different broadcast domains

 

  • It is possible to give a descriptive name to the GLBP group using (config-if)#glbp <0 - 1024> name <name>

 

Router roles in GLBP

  • GLBP devices have two roles at the same time, one role relating to the selection of the AVG and one role relating to the selection of the AVFs
    • The two roles are completely independent and a GLBP device can have any role in the AVG selection process combined with any role form the AVF selection process

 

  • The AVG (Active Virtual Gateway) is the manager of the GLBP group, it replies to ARP requests sent to the virtual IP and determines host-to-gateway allocations, meaning which host gets informed of which MAC address for the default gateway IP, spreading the load between multiple routers in this way
    • One GLBP group can only have a single AVG
    • The load-balancing algorithm is configured on the AVG
    • The AVG is determined by the router with the highest configured priority or if priority is a tie, the router with the highest configured IP from the same subnet as the virtual IP wins. However preemption is disabled by default so most of the time it's the first interface that was configured that becomes the AVG

 

  • The AVF (Active Virtual Forwarders) are the GLBP interfaces that are responsible for routing traffic for the virtual IP
    • One GLBP group can have a maximum of 4 AVFs
    • Each AVF has a different virtual MAC address but the same virtual IP, this is how the load-balancing is achieved
    • Normally the AVFs are determined based on highest configured weighting and if equal the highest IP address from the same subnet as the virtual IP, however since preemption for AVFs works differently than for the AVG and can only really happen if object tracking is also configured or the interface fails, most of the time the first 4 routers to join the GLBP process become the AVFs

 

  • States for the GLBP Group Management role (for AVG)
    • Disabled
      • There is no virtual IP address configured
    • Initial
      • There is a virtual IP address configured but the interface is down
    • Listen
      • Any GLBP enabled interface that does not qualify as the AVG or the Standby interface will remain in Listening state
      • Interfaces in the Listening state track the status of the Standby interface and all interfaces in Listening state will try to become the new Standby interface if the current one goes down
      • Between interfaces in Standby and Listening state preemption is always enabled and if an interface in Listening state receives a Hello with lower priority then itself either from the Active or Standby router it will try to over-take the role (going to Speak state and then to Standby or Active)
    • Speak
      • A transitory state between that GLBP interfaces go through when being promoted from interfaces in Listen state to Standby or Active or when being demoted from Active or Standby

//I can't understand the purpose of this role as all GLBP interfaces send Hello packets all the time anyways and the reasons why HSRP uses this role do not apply

  • Standby
    • There is only one interface in Standby role per GLBP group
    • The Standby interface is the one that did not qualify as the AVG but has the next highest priority
    • A standby interface  tracks the status of the AVG. If the AVG's Hold timer expires it will automatically be upgraded to the AVG
    • Between interfaces in Standby and Listening state preemption is always enabled and an interface in Standby can be demoted dynamically if a new device has a higher priority or equal priority but a higher IP. There is no coup message in GLBP, however every device, even in listening state sends Hello messages, if the current Standby interface receives a Hello message with a higher priority it will demote itself (going into Speak and then Listen state)
    • If preemption is enabled the above happens with the AVG as well
  • Active (AVG - Active Virtual Gateway)
    • There is only one AVG in a GLBP group
    • The AVG is responsible for assigning virtual MAC addresses to the AVFs
    • The task of the AVG is to respond to ARP requests sent to the virtual IP, by doing this it is responsible for the load balancing scheme configured and hands out the MAC address of the appropriate AVF for each separate ARP request
    • The role of AVG is not tied in any way to packet forwarding and it's possible that any of the packet forwarding specific roles be the AVG
    • The role of the AVG can be subject to preemption but this is disabled by default

 

  • States for the GLBP Forwarding roles (for AVFs)
    • Disabled
      • There is no virtual MAC assigned
    • Initial
      • The virtual MAC is assigned but the interface is down
    • Listen
      • All the interfaces that are up but are not in Active state go into Listening state
      • Interfaces in Listening state monitor the status of the Active interfaces (AVFs), by listening for their Request/Response messages, and if the Hold timer for these interfaces expires they will try to become the new AVFs
    • Active (AVF -Active Virtual Forwarder)
      • There are up to 4 AVFs in a GLBP group
      • The task of the AVF is to route traffic destined to the virtual IP address and the virtual MAC allocated to him
      • The AVFs send periodic Request/Response messages as keepalives

 

GLBP role selection

  • AVG role selection
  • GLBP uses a configurable value called priority to designate roles for the AVG
    • Priority is set to 100 by default
    • It can be manually configured between the values of 1 - 255

(config-if)#glbp <0 - 1024> priority <1 - 255>

  • The interface in a subnet/broadcast domain with the highest priority will be designated as Active, the second highest as Standby and all others as Listening
  • If the priority of two interfaces participating in GLBP is the same, the interface with the higher IP from the same subnet as the virtual IP takes priority
  • The priority value can only be set statically and tracking can't be used to decrease it dynamically
  • Preemption can be configured to dynamically update which device is the current AVG based on changes in the GLBP process

 

  • AVF role selection
  • The GLBP uses a configurable value called weighting to designate roles for the AVFs
    • Weighting is set to 100 by default
    • It can be manually configured between the values of 1 - 254 and within the same command lower and upper thresholds can be configured which are used for preemption

(config-if)#glbp <0 - 1024> weighting <1 - 254> {lower 1 - 253} {upper 1 - 254}

  • If the weighting of two interfaces participating in GLBP is the same, the interface with the higher IP from the same subnet as the virtual IP takes priority
  • Using object tracking it is possible to configure weighting to dynamically decrease if an object is down, this is used for preemption

 

Preemption

  • GLBP has the possibility to use preemption
  • Preemption is the capability of GLBP to dynamically change which interfaces serve as the AVG and AVFs based on changes in the GLBP process
  • In GLBP preemption is configured separately for the role of Active Virtual Gateway and Active Virtual Forwarders and follow completely different logics for when preemption happens

 

AVG Preemption

  • The GLBP AVG uses priority for preemption
  • AVG preemption is disabled by default
  • With the AVG, preemption only applies to the selection of the Active interface, the rest of the roles (Standby and Listening) always change dynamically based on configuration/priority changes in the HSRP process, even if preemption is off
  • Preemption for the role of AVG Active interface only takes into account the priority value, meaning that if an interface with an equal priority but higher IP comes online, the current Active interface does not chance
  • GLBP dynamically changes the AVG Passive interface based both on priority and interface configured IP
  • Preemption can be enabled with (config-if)#glbp <0 - 1023> preempt {delay minimum 0 - 3600}
    • Using the delay minimum keywords it's possible to delay preemption, this can be useful to prevent GLBP reconfigurations based on a flapping interface or to allow a freshly booted router that might still be converging it's routing table to become the GLBP AVG
  • Every interface participating in an GLBP process has its preemption settings configured separately meaning that it might be possible to fail over to some interfaces but not possible to fail back if only some have preemption configured
  • It is advised to configured all GLBP interfaces in the same way for a consistent behavior as whichever one gets elected as the AVG decides on the current load-balancing schema

 

AVF Preemption

  • The GLBP AVFs uses weighting for preemption
  • Preemption for AVFs is enabled by default, however it functions completely differently to the AVG preemption logic and is dependent on the weighting lower and upper limit
    • To configure weighting (config-if)#glbp <0 - 1024> weighting <1 - 254> {lower 1 - 253} {upper 1 - 254}
      • The default weighting of an AVF is 100, default lower limit is 1 and default upper limit is 100
      • The lower limit, by default 1, specifies a threshold below which a GLBP interface gives up being an AVF is preemption is enabled
        • The lower threshold can be set between 1 and the currently configured weighting minus 1
      • The upper limit, by default equal to the weighting set on the interface, specifies the threshold at and above which a GLBP interface is allowed to be an AVF if preemption is enabled
        • The upper threshold can be set to a value starting from the value of the lower limit and up to the weighting configured on the GLBP interface
    • Object tracking is used to dynamically lower the weighting of an interface based on the health of a tracked object by a configurable decrement
      • The default decrement is 10
      • This can be configured using (config-if)#glbp <0 - 1023> weighting track <1 - 1000> {decrement 1 - 255}
        • GLBP does not have the possibility to track an interface directly as HSRP, however the state of this interface can be tracked as a track object

 

  • Preemption in the case of AVFs only happens if the weighting for an interface falls below the lower threshold and then this interface gives up the AVF role allowing other interfaces to take over the role
    • If forwarder preemption is disabled, an interface remains an AVF even if the weighting falls below the lower threshold and a new AVF is selected only if the interface completely fails
  • Preemption takes into account weighting and if this is equal, the interface with the higher IP from the same subnet as the virtual IP becomes an AVF, however preemption only happens if one of the current AVFs falls below its lower threshold and just configuring a higher weighting does not trigger preemption

 

  • Because of the above preemption can't happen with default settings as the lower threshold needs to be higher than the default value of 1 and object tracking needs to be enabled to dynamically lower the weighting

 

  • AVF or active forwarder preemption can be configured to happen after a delay using (config-if)#glbp <0 - 1024> forwarder preempt {delay minimum <0 - 3600>}
    • The default delay is 30s

 

GLBP load-balancing

  • The load-balancing algorithm is controlled by and configured on the AVG
  • If the AVG role changes the new AVG might have different-load balancing settings configured
  • Load balancing can be configured with (config-if)#glbp <0 - 1024> load-balancing <host-dependent | round-robin | weighted>

 

Load-balancing algorithm:

  • Round-robin (default)
    • For every ARP request coming in for the virtual IP, the AVG hands out the virtual MAC of the next AVF in a round-robin fashion
  • Host-dependent
    • Remembers which AVF was assigned to which host and keeps allocating the same AVF to the same host
    • The Host dependent load-balancing algorithm is dependent on the existence of a client-cache
  • Weighted
    • Configure preference ratios between AVFs
      • An AVF with weighting set to 200 will have its virtual MAC handed out twice as much as an AVF with its weighting set to 100

 

 

GLBP client-cache

  • The client-cache is a store of the MAC and IP addresses of all the devices that ARPed for the virtual IP address
  • This cache is maintained by the AVG
  • There is no client-cache enabled by default
  • A client-cache is required if using Hose-dependent load balancing
  • The client-cache is configured using (config-if)#glbp <0 - 1024> client-cache maximum <8 - 2000> {timeout <1 - 1440>}
    • Where 8 - 2000 is the number of clients entries to cache and the timeout is in minutes
    • The default timeout is 1440 minutes (one day)

 

GLBP message types

  • GLBP uses two message types
  • One GLBP packet can contain both message types, they are defined and delimited by TLV (type/length/value) fields
    • Hello messages
      • These are sent by all GLBP interfaces and are keep-alive packets for the AVG related roles

 

  • Request/Response messages
    • These are sent only by the GLBP interfaces that are currently the AVFs as keep-alive packets

 

GLBP Timers

Hello and Hold timers

  • GLBP uses a Hello and Hold timer to track the status of GLBP devices
    • Hello timers, which specifies the interval at which Hello packets are sent, by default this is 3s
    • Hold timer (also sometimes called the Dead timer) which specifies how long to wait without hearing a Hello message before considering the monitored interface dead and triggering a role change
    • The Hello and Hold timers apply to both the AVG and AVFs Hello and Hold timers

 

  • Interfaces in the GLBP process learn and adjust their timers automatically based on the timers advertised by the AVG
    • If the timers on the AVG are changed, all other interfaces participating in the GLBP process adjust their timers
    • If timers on a non-AVG devices are changes, these are ignored even by the device on which they were changed until they become the AVG

 

  • To configure timers in seconds use (config-if)#glbp <0 - 1024> timers <1 - 60> <x - 180>
    • Where 1 - 60 is the Hello timer and x - 180 is the hold timer, x being the value the hello timers is set to plus 1
  • To configure timers in milliseconds use (config-if)#glbp <0 - 1024> timers msec <50 - 60000> msec <x - 180000>
    • Where 50 - 60000 is the Hello timer and x - 180000 is the hold timer, x being the value the hello timers is set to plus 20ms

 

Redirect and Forwarder timers

  • In the event of an AVF failing and not being any more available GLBP devices to take over this role, one of the current AVFs will take over ownership of the virtual MAC address of the failed AVF in addition to its already assigned one
  • GLBP will try to remove this extra virtual MAC address in time, but since there might be devices who are using it to get to their default gateways,  GLBP implements two timers to allow a graceful removal of the extra virtual MAC
  • The first timer is the Redirect timer, this specified the time the AVG will continue responding to new ARP requests with the virtual MAC of the dead AVF
  • The second timer is the Failed Forwarder timer, this specifies the time the AVF that took over ownership of the extra virtual MAC will keep answering to it. After this timer expires the extra virtual MAC is dropped
  • These timers are configured using (config-if)#glbp <0 - 1024> timers redirect <0 - 3600>  <x - 64800>
    • Where 0 - 3600 is the Redirect timer and  x - 64800 is the Failed Forwarder timer, x being the value of the Redirect timer plus 600 seconds
    • Both timers are in seconds

 

GLBP Authentication

 

  • Supports plain text and MD5 with key-string or key-chain authentication
  • To enable plain text authentication use (config-if)#glbp <0 - 1023> authentication {text} <authentication-string>
  • To enable MD5 authentication with a key-string use (config-if)#glbp <0 - 1023> authentication md5 key-string {0|7} <authentication-string>
  • If using MD5 authentication with a key-chain that also uses key lifetime settings NTP needs to be enabled on all interfaces participating in HSRP
    • After configuring the key-chain with the key(s) to configure HSRP to use them (config-if)#glbp <0 - 1023> authentication md5 key-chain <key-chain>

 

Verification Commands

 

show glbp {brief} {detail}

  • The detail keywords allows the display of the client-cache as well

show glbp client-cache

 

debug glbp errors

debug glbp events <all | api | cache | detail | protocol | redundancy | terse | track>

debug glbp packets <all | detail | hello | reply | request | terse>

debug glbp terse

  • Using terse displays a limited range of GLBP errors, events and packets
Comments
lmorace
Level 1
Level 1

Good morning,

I have some questions.

Let's suppose we have 5 routers with the following weights and physical ip on the GLBP interface: R1's weight=25 and ip=192.168.1.1, R2's weight=50 and ip=192.168.1.2, R3's weight=75 and ip=102.168.1.3, R4's weight=100 and ip=192.168.1.4 and R5's weight=25 and ip=192.168.1.5 and priority=200, while the other 4 has priority=100, and preemption enabled. So R5 is the AVG, but it is not an AVF. Now if we have a tracking object on R3 on a link which goes down and takes the weighting value to 50, does the selection process of the new AVF work like this:

- Are first considered the remaining routers with the forwarder preemption enabled, valid weighting value (not lower than the lower threshold or equal or higher tha the upper threshold if it has gone under the lower threshold), and  weighting value strictly higher than the decremented weighting value of the failed AVF. If none of the remaining routers satisfies these three conditions together, the failed AVF stills keeps its role. 

- If two or more routers satisfy the three conditions I have written above, it is considered the router among them with the lowest forwarder preemption minimum delay to take the role of the failed AVF.

- If there are two or more routers that satisfy the three conditions I have written above and with the same lowest forwarder preemption minimum delay, it is considered among them the router with the highest weighting value to take the role of the failed AVF.

-If there is a weighting value tie among the remaining routers which satisfy all the conditions above, it is considered the router with the highest ip address of the GLBP interface in the GLBP group.

IS IT CORRECT SO FAR?

So, in this example it will be R4 to take the role of the failed R3, won't it?

If in R5, which is the AVG, we have load-balancing weighted configured and R4 has taken the role of the failed AVF of R3 and 11 new arp requests arrive before redirect timer expires, will they be assigned in this way:

8 to R4 (because AVF3 has now the weighting value of R4), 2 to R2 and 1 to R1?

Now, if instead of a tracking object failure we have a GLBP interface failure of R3, is the failed AVF of R3  assigned to one of the remaining routers by following this criterium:

-the router with valid weighting value (not lower than the lower threshold or equal or higher tha the upper threshold if it has gone under the lower threshold) and the highest ip address of the GLBP interface in the GLBP group, regardless weighting value and forwarder preemption? So in this case it will be R5 to take the AVF role of R3, won't it?

Now, if I disable load-balancing on R5, which is the AVG, by writing "no glbp 1 load-balancing" (let's suppose we are in group 1) and new requests arrive, which router will take them? R1 because it has the lowest AVF number and R5 is not an AVF which is primary owner? And if R1 falls down, after the redirect timer expires R2 will recieve the new arp requests because it has the next lowest AVF number? And if R1 comes back to work, when the secondary hold expires, all the new arp request will be addressed to R1 again, while the old ones will still sent to R2? Right?

I am aware these are very strange questions, not related to real life problems, but I would like to know that.

Rich R
VIP
VIP

@lmorace the best way to test your theory is to build yourself a lab setup and confirm that it works as you expect it to.

lmorace
Level 1
Level 1

The problem is I have no chance to build that. I do not work in a company with CISCO simulation environment or CISCO devices, even if that is my wish. Moreover, I have not found any videos dealing with this topic so deeply, and ChatGPT does not help. But I am too curious.

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: