I’m amazed at how the approach of the CCNA certification has changed since the time I took my test and entered the Cisco world officially. Even though I personally believe Cisco has done a great job at gathering the topics and assembling tough evaluations, somehow there comes a point where technology changes and the topics that used to be worthy of attention and effort become outdated and the market starts demanding some new skills.
I came to realise this soon after I achieved my CCNA and started preparing for CCNP; one of the things I always wondered as a CCNA student was: why if default gateways are such a critical piece in a LAN environment, they seem to be a single point of failure? I found my answer in the CCNP SWITCH curricula on a topic called “First Hop Redundancy Protocols” and people who are preparing for the newest version of CCNA are lucky enough that this is now a topic taught and evaluated as part of this certification’s blueprint.
Well, first off, let’s briefly recall the concept of a default gateway: a default gateway is nothing else than the first hop for packets from a particular LAN (or VLAN to be more accurate) that need to reach a remote network; the router is able to forward such packets as long as its routing table keeps a route to the intended remote network or a default route is present. This means that if that first hop ever goes down, that particular network will become incapable to communicate to the outside world and only local communication across the switched domain will be possible, which in most cases, is of little use.
Having stated the problem, there’s a solution to it, fortunately. First Hop Redundancy protocols will allow default gateway redundancy, meaning, having more than one default gateway enabled, in the event of a router failure there’s a backup device that will kick in and almost transparently to users, continue to forward traffic to remote networks, thus avoiding the situation of isolation depicted in the above paragraph.
There are three first hop redundancy protocols that could be used for this purpose:
1. HSRP: It’s the first FHRP ever created and it’s Cisco proprietary, which means, it will not work with other manufacturers’ gear. HSRP is enabled in a particular interface and this interface is part of a “standby” group; besides the physical IP address of the defined interface, there’s a virtual IP address in the same subnet. The idea behind this is to perform, parallel to this, a similar configuration in an interface belonging to another router; this will effectively generate redundancy, since to different interface from different devices will share the same virtual IP address, then you can freely assign that virtual IP address as a default gateway to hosts in a network and regardless of which host is active you will always have a consistent gateway you could reach.
Now, I know you might be wondering about ARP and how the change is managed in the physical part of the communication; well, by default, HSRP also provides a virtual MAC address which is advertised by either router depending on which one is active at a given time; so the only thing to be updated when it comes to MAC addresses is the CAM table of the switch(es) in place; truly this is transparent to end users as they keep having the same entry in their ARP tables. What you see in the diagram as “Standby 1” is the group name the interface belong to, notice that both redundant interfaces in each router belong to the same “standby”. Also notice that a particular priority value is configured; in HSRP the higher the priority the more preferred the router, meaning R1 in this case will be the “active” router for standby 1, whereas R2 will be idle and ready to jump in if something happens to R1. As you can see, both interface have their own IP address, however the both share the virtual IP 10.2.2.1 since this is the one that hosts will know as their default gateway.
2. VRRP: Since Cisco had this great idea with HSRP, soon the industry wanted to have such a functionality ported out to products from different vendors, therefore the IETF started working on a standards-based FHRP and the result was VRRP. As much as it might disappoint you, VRRP is not significantly different from HSRP, it’s really just the “open” version of it; the differences that exist between the two protocols are minimal, and this is why the CCNA curricula doesn’t ask you to have a deep understanding of VRRP. It’s still important that you understand what are this few differences, but the topic has already been covered by Joe in this article in RouterFreak and I do recommend for your certification and general knowledge.
3. GLBP: Finally, the more advanced of the three possible FHRP protocols is GLBP. GLBP was designed with one main goal: improve the resource utilisation by achieving built-in load balancing between participating routers, and if you think about it, it makes perfect sense. Whenever you’re using HSRP or VRRP of gateway redundancy, if you wanted to achieve load-balancing between say, different VLANs, you would have configure different standby groups with different priorities in each router to achieve this “active-active” type of design that will not waste the capabilities of a full router while waiting for the other to fail. Even when this is still a common practice (the only possible one in many instances), it’s administratively burdensome and it might not scale as well as one would wish. The answer to this, was to create protocol that would natively provide both redundancy and load balancing, thus GLBP was created.
What you see in the figure above is the mechanism GLBP utilises to achieve its load balancing functionality. There’s a designated AVG (Active Virtual Gateway) which responds to ARPs from hosts; the trick here is, it doesn’t, of course, respond to those ARPs with a physical MAC address but a virtual one, which it assigns to one of the AVF (Active Virtual Forwarder) routers and thus the host sends it’s traffic to the router using the designated virtual MAC address. In this way, hosts have the same IP as their default gateway, but different MAC addresses int their ARP table, thus, they send the traffic to different devices and the goal of load distribution is achieved. By default, the AVG will respond and assign AVFs in a round-robin fashion, although the source-mac-based and weighted options are also available.
One final warning about GLBP is that (as disappointing it might be) it’s not available in all Cisco platforms but on Cisco 4500 and 6500 switches; I know I’m not the only one hoping that Cisco will eventually make this wonderful protocol available on the branch planforms as well, but only time will tell.
While I didn’t expect to make you “master of FHRPs” by reading this single article, I do hope you get the idea and understand the functionality and particularities of the protocols described here. You will find a lot of this in your job as a network engineer and is advisable that you practice it a lot, tweaking different parameters.
Would you like to know more about FHRP protocols? Please leave a comment so we know what you’d like to see in future posts!