Introduction to the Cisco Gateway Load Balance Protocol (GLBP)
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Often one of the least redundant parts of a network is the first hop between a host and the rest of the network. This is because they are typically configured with a default gateway IP address that links to a single device. Should this device fail, then all of the users on a specific segment who are using it as their default gateway will be unable to reach any other subnet including the Internet.
There are a number of different solutions to this problem, and most of these are all grouped together and referred to as First Hop Redundancy Protocols (FHRP). This article takes a look at the Gateway Load Balancing Protocol (GLBP), which is a Cisco proprietary FHRP that provides not only first-hop redundancy like HSRP and VRRP but also more integrated load-balancing capabilities.
This article specifically looks at GLBP, how it operates, along with the main concepts that should be known before attempting to configure it; another GLBP configuration article follows with the details of how to configure GLBP.
How Does GLBP Work?
The purpose of GLBP development was to bridge a gap that existed with the Hot Standby Router Protocol (HSRP)—that is, easy implementation of load balancing. With HSRP (and VRRP, the standard version of HSRP), the problem that exists is that only a single device within a group is ever forwarding traffic at any given time. When only a single device is actually forwarding data, a large amount of idle bandwidth is left sitting off the interfaces of the standby devices. There is a way to get around this by configuring multiple HSRP groups on the devices, but this also requires that half the hosts be configured with one gateway and the other half with another that increases the amount of administration and is still a crude solution to the problem.
GLBP works a bit differently from these other protocols. To understand this, there are two terms for GLBP device roles that need to be defined: Active Virtual Gateway (AVG) and Active Virtual Forwarder (AVF). The AVG is responsible for managing the traffic to all of the configured GLBP Active Virtual Forwarder (AVF) devices. That is done by controlling the ARP process. When GLBP comes up, the AVG is elected, and one of its first duties is to take responsibility for the virtual IP address and assign each of the configured GLBP devices with a virtual MAC address (including itself). When an ARP message is seen by the AVG, it responds and gives out these virtual MAC addresses in a round-robin format; this way, each of the AVFs is assigned an even amount of traffic from the devices requesting access. Up to four different virtual MAC addresses and thus AVFs can actively exist.
GLBP Redundancy
How redundancy works with GLBP can be a little confusing, especially if the engineer has had experience with HSRP and/or VRRP. With GLBP, there are actually two different types of redundancy: AVG redundancy and AVF redundancy. AVG redundancy works almost exactly the same as HSRP or VRRP redundancy; a single AVG is elected when GLBP comes up and keeps that role until it goes down or until another router takes the role from it. Like HSRP and VRRP, GLBP uses a priority to elect the AVG; in the case of a tie (the default is 100), the highest IP address is used. GLBP (AVG) preemption is disabled by default; what this means is that the current AVG must fail for another device to take over the role even if it has a higher priority.
AVF redundancy is a little different; if the device that is responsible for a specific virtual MAC address fails, one of the other current AVFs takes over the forwarding duties by taking over the specific virtual MAC address. This change is communicated to the current AVG, and over a series of timeouts, the traffic is transferred from that specific virtual MAC address to other, currently up, AVFs. Preemption for AVFs is enabled by default. This enables the other devices within GLBP to keep track of when an AVF fails and take over the duties proactively.
GLBP Weighting and Interface Tracking
GLBP uses a concept of weighting to determine the load capacity of each of the AVFs. By default, each of the AVFs is configured with a weighting of 100 (values range from 1 to 254). By default, the load balancing behavior of GLBP is to use round robin, which will always result in a distribution of hosts to AVFs. If this load balancing behavior was altered to use weighting, then depending on the current weighting assigned to an AVF, each specific forwarder would get a specific load of the traffic.
The weighing can also be configured with lower and upper levels. These are then used to determine if an AVF should be forwarding. For example, if configured with a lower limit of 40 and an upper limit of 80, when the weighting on a device changed to be lower than 40, the AVF would stop forwarding. It would remain in this state until its weighting increased to above 80.
The weighting of specific AVFs can be controlled both statically and dynamically. When configured statically, the network administrator/engineer will configure a specific weighting to each AVF. When configured dynamically, GLBP uses the status of a track object to determine the current AVF weighting. Track objects can use a number of different criteria to determine their state (up or down). The most basic of these is interface line protocol state and interface IP routing capability (is an IP address configured?).
Summary
When considering whether to use an FHRP and which one to use, the initial decision comes down to the vendor of equipment that is being used on the devices. Because both HSRP and GLBP are Cisco proprietary, the obvious limitation is that the equipment being configured must be Cisco. VRRP, on the other hand, is standards-based and is supported on a number of different vendor’s platforms. Of the three, GLBP is certainly the one that provides the best solution in attempting to not waste any bandwidth and provide the lowest administrative burden overall; it all comes down to the vendor’s equipment deployed.
None of these three protocols is particularly complex to configure, and can be implemented in a very short amount of time. I hope that this article has provided enough of an introduction to GLBP to make a reasonably informed decision about whether GLBP is a solution that should be researched further. Introductory articles on HSRP and VRRP are also covered on this site, and can be referenced when attempting to make an informed decision about which of the three to select.