Hello everyone, and welcome back to our series on the IP services topics on the CCNA exam. This is the third article in this series. In the first article, we discussed DHCP and in the second article, we started exploring the concept of first hop redundancy protocols (FHRPs). In this article, we would continue from where we left off in the previous article – load balancing in FHRPs.
So far, we have discussed HSRP and VRRP and we explored intriguing concepts such as preemption and tracking that can be used to create scenarios for high availability networks. But we left off with a question in the last post: How do we ensure that we use the resources of all our physical gateways instead of having one doing all the work and the rest acting as mere backups?
One way to solve this problem is to use multiple default gateways and redundancy groups. With multiple groups, each router can serve as the active router for one group while the other acts as the backup.
Refer to our network diagram from the last post which is shown below:
To implement load balancing in HSRP, we will create two groups so that R1 will have the higher priority in one and R2 will have the higher priority in the other. The configuration for HSRP load balancing on R1 would be:
Notice that the priority of group 1 has been set to 110, while the priority of group 2 is left at the default (100). Similarly, the configuration of R2 (shown below) has group 1 set to the default while the priority of group 2 is set at 110. Also note that the interfaces are being tracked to ensure that the connectivity to the ISP is maintained by the primary routers.
Based on the configuration above, R1 would be the active router for Group 1, while R2 would be the active router for group 2. We can confirm this from the output of the “show standby” command on any of the routers:
From the client’s perspective, you need to set the default gateway of some of the users to 192.168.2.1 and set the others to 192.168.2.11. One way to do this is to manually ensure that the users have the right gateway. If you are using the Cisco IOS as your DHCP Server, you can create different pools on both routers with different gateways. However, you would have no control over which client gets a particular gateway. You can also implement this on Microsoft or Linux DNS servers.
The load balancing concept in HSRP and VRRP using multiple gateways and redundancy groups is quite complex and difficult to scale with many default routers. Imagine you have four gateways and you need to achieve load balancing and redundancy; you would need four redundancy groups and four default gateways. This can easily become a nightmare for a network administrator to manage. Thankfully, we have a cleaner way to achieve load balancing with first hop redundancy protocols: the gateway load balancing protocol.
Gateway Load Balancing Protocol (GLBP)
The gateway load balancing protocol is a Cisco Proprietary FHRP that was designed to use multiple physical gateways at the same time. Unlike VRRP and HSRP, all the physical routers in a GLVP group can be active. This is quite useful in optimizing resources in the network while still ensuring that first hop redundancy is being maintained.
How would GLPB achieve this? A GLBP group is configured with one virtual IP address that is assigned as the default gateway. The members of the group would then select an active virtual gateway (AVG) which would listen for that virtual IP address. Unlike HSRP and VRRP, GLBP does not use a single virtual MAC address for the entire group. Instead, the AVG assigns different virtual MAC addresses to each of the physical routers in the group.
So what happens when a client needs to send packet to the default gateway? Since it knows the IP address, it requests the MAC address by sending an ARP (address resolution protocol) request on the subnet. The AVG responds to these ARP requests with the virtual MAC address of each of the active virtual forwarders (physical gateways that are still active), based on a load sharing algorithm.
There are three load sharing algorithms used by GLBP:
- Round robin—The AVG responds with the next virtual MAC address in a cycle.
- Host-dependent round robin—This load sharing ensures that the same virtual forwarder is assigned to the same host, while the next host gets the next AVF in a round robin fashion.
- Weighted—GLBP can also be designed to achieve weighted load sharing among physical routers. This means that, based on their configured weights, different amount of traffic can be sent to different physical gateways. This might be important if you have routers with different capacities in the same group and you want to configure the higher-capacity router to handle more traffic than the lower-capacity one.
Redundancy is maintained by using priorities. The router with the highest priority is the AVG; if that router goes down, the next router becomes the new AVG. In terms of AVF, if a physical router goes down (or its priority goes below a defined threshold), the router with the highest priority among the remaining routers will be selected as the backup for the AVF. Also, a redirect timer is started on the AVG. If the AVF does not come back online before the redirect timer expires, the AVG would stop assigning the virtual MAC address of that AVF to clients.
Finally, what happens when a device which failed comes back online? It will take over its role as the AVG or AVF if preemption is configured.
I know all the technical details described above might seem a little confusing, so I will explain using an example. And as you probably guessed, we will stick with the same network diagram that we have maintained since HSRP.
We will configure the routers to use GLBP, R1 being the higher priority. We will leave the load-sharing algorithm as the default (round robin) for now. The configuration for R1 is shown below:
The virtual IP address assigned to the client is 192.168.2.1. The configuration on R2 is shown below:
Based on this configuration, R1 would be elected as the AVG for the group while R1 and R2 would both be AVFs. We can see this from the output of the “show glbp” command on R1:
Notice that while R1 is the active AVG, it is in the listen state for Forwarder 2. This is because R2 is the active forwarder 2. Also, notice the assigned MAC addresses for the AVFS (0007.b400.0101 and 0007.b400.0101). The load balancing method is also left as the default (Round robin).
Now, let us hop over to the client side and test this out.
As we can see in the output, the default gateway is set to the virtual Ip address, 192.168.2.1. Let’s do a ping and see the MAC address that the client learns from the AVG:
Notice the MAC address is the MAC address for the second forwarder. So while R1 is the AVG, R2 has been selected as the gateway for this particular instance based on round robin.
Now, what happens when we clear the ARP and try again?
We can see that the MAC address has changed to the MAC address for AVF1 and, in this case, R1 has become the first hop for the client.
We can change the load balancing algorithm using the command “glbp <group-number> load-balancing <option>.” We can change the algorithm to host dependent load balancing as shown below:
Now we will add some additional features to our GLBP configuration. We would track interface Fa0/1 so that any of the routers that loses its connection to its ISP will lose its capacity as a forwarder too.
The configuration on R1 would be:
The exact configuration is also repeated on R2.
Note that, since we have changed the load-balancing algorithm to host-dependent, the AVF for our test client has been unchanged. A quick lookup of the ARP table shows that R2 is the AVF:
What happens when R2 loses its connection to the ISP? When we shutdown R2’s interface, we notice R1 takes over as the active forwarder for forwarder 2
The “show glbp” command shows that R1 is active for both forwarders and is responding to both MAC addresses:
What happens when the connection to the ISP (F0/1) is restored on R2? Because preemption is enabled between AVFs, R2 becomes the AVF again and the R1 goes back to the listen state.
You can test other scenarios on your own by tracking different elements and verifying the behavior of the AVGs and AVFs in response to your test scenarios.
There you go! This is all you need to learn about FHRPs for the new CCNA exam (and hopefully, for some fun implementations in the real world too). I hope you found this article as interesting as I did. We have almost come to the end of the series on IP Services. In the final post, we will discuss syslog and SNMP features on a router.