Image Image Image Image Image Image Image Image Image Image

This 8-Bit Life | October 23, 2014

Scroll to top

Top

No Comments

GLBP vs HSRP - This 8-Bit Life

GLBP vs HSRP
Jacob
  • On March 21, 2014

Welcome. My name is Jacob and I have spent about eight years in the Network industry. I have worked for the DoD in many positions and currently pay the bills as a Network Engineer working out of Colorado. I hold a few certs: CCNA, CCNA-Sec, CCNP-R&S, and CCIE-R&S written. More importantly, I love networking and I do this stuff for the fun and challenge of it.

I am excited about this opportunity to post on T8BL as it embodies how I feel when it comes to technology; a “prove it” mentality. Too many times in the networking world I hear people talk about protocols or technology in general, stating “facts” without having put them to the test themselves, or even witnessing them in action. So what I would like to do is take those “facts” and put them to the test and get measurable data that we can then use for a “more smarter” discussion.

Now as a disclaimer, I will say that with this material I assume that you have a good knowledge of networking material and a fair amount of experience with Cisco equipment. This is for an individual studying for the CCNP SWITCH exam with a little ROUTE sprinkled in.

For my first installment I will put two well know High Availability protocols up against each other. But why? We already know who will win….or so you thought.

 

GLBP vs HSRP

 

Putting a Cisco proprietary protocol, Gateway Load Balancing Protocol (GLBP), up against an industry standard protocol, Hot Standby Router Protocol (HSRP), and state the facts.

Now both of these protocols, as you may know, take multiple physical devices that are layer three capable; meaning they can have an IP address on an interface and create a single virtualized gateway device with a unique IP that clients can use as a default-gateway. This means that if a single physical device or link goes down the virtual default-gateway, IP will remain up and servicing clients requests as long as at least one device stays up. Voila, High availability achieved.

Here is the 10,000 foot view of key differences between the two protocols:

GLBP:

*Can load balance across up to four routers in each group.

HSRP:

*One router is forwarding per group, the others are in standby.

 

That is really the high level view of the differences. There are others but usually these differences mentioned above are the elephants in the room when comparing the two protocols.

 

We will be using GNS3 for this experiment. Here is the set up:

Topo

You can see I built a typical small redundant network. This is very basic and it provides the multi homed ISP connection we need to test these two out. I am running OSPF as my routing protocol (I will elaborate on later) and I am running 802.1d STP on the switches. I wish GNS3 supported better switching functions but it just doesn’t yet (New GNS3 1.0 release will, coming soon, google it). I am running SNMPc by CastleRock for my Network Monitoring software. This will be the measurement instrument for this experiment.

One thing I will mention before we begin: load balancing, which is different than load sharing, is by nature asymmetric, meaning that traffic will flow down different paths and require reassembly at the end device. This is ok for most traffic, but the big no no is voice and video! Do not route voice and video asymmetrically.  It will cause massive jitter and you will be troubleshooting voice issues until mid-night. We will not be diving into that soup sandwich this time but just beware.

 

The baseline test for each will be:

File transfer performance (a 1,700 KB file) all four host or branch offices will pull at once

Failover speed- all four host pinging at once and removing the cable from DSW1 to RTR1

Available link utilization- over the two available WAN links

*The percentages are small due to the nature of the test, but the differences are the important thing.

 

HSRP is up first.

Here are the benchmarks for this open standard. Here are the results:

File transfer performance- downloaded 1,751,867 bytes copied in 325.220 secs (5,387 bytes/sec)

Failover speed- !..! = 4 seconds

Available link utilization-

RTR1- Client Gateway measured = .14%

RTR2- Client Gateway measured = .10%

When you look at these results in figure 1.1, you may notice that both client gateways have utilization, almost like they are being load balanced… well they ARE! But not by HSRP. The links are being load balanced because if we look at the topology, each of the branch routers has two equal cost paths back to our clients servers. Because we were “downloading” the file TO our local clients and not “uploading” to or downloaded FROM the branch office, we are seeing OSPF load balance our return traffic. This is a surprising result at first until you remember that both our routers WAN links have the same OSPF cost from the branch routers perspective. When our two local routers receive the return traffic they will simply check the ARP table for the destination’s IP address and associated mac-address, then forward the traffic back to the clients regardless of who is the Active HSRP router. I did this intentionally to show that a dual homed site will still utilize both links but only for returned traffic. In other words, if you are doing the downloading (assuming you had a WAN connection that allowed you to run your own routing protocol). So now let’s see what happens when the branch offices start downloading from our clients.

Figure1.1

The next set of results is from an upload session, see figure 1.2

File transfer performance- 1,751,867 bytes copied in 168.008 secs (10,427 bytes/sec)

*This time our Branch Office was downloading a file from us

Failover speed- !..! = 4 seconds

Available link utilization-

RTR1- Client Gateway measured = .21%

RTR2- Client Gateway measured =  .0%

Here is the more typical result you would expect to see from HSRP. One link is being utilized while the other sits untouched.  Here, we can see while the file was being downloaded from our branch office the packets were only utilizing the single link, giving us a 10.4 kbps download speed. If you were paying for that other link this may upset you.

Figure1.2

GLBP is up!

GLBP is proprietary, meaning Cisco owns it and if you have other vendor equipment (why would you though) it will not work well with others. But in a Cisco environment it is an option. Let’s see how the numbers stack up.  

Figure 1.3

File transfer performance- 1,751,867 bytes copied in 168.408 secs (10,403 bytes/sec)

*This time our Branch Office was downloading a file from us

Failover speed- !.! = 2 seconds

Available link utilization-

RTR1- Client Gateway measured =  .10%

RTR2- Client Gateway measured =  .11%

Well, almost exactly what you would expect from something named Gateway Load Balancing protocol. Clearly the traffic was split up between the two LAN interfaces while traveling back to each of the respective branch office routers. Even with that, we did not improve our branch offices download speeds. This is because once our traffic was forwarded into the ISP cloud where we hit our first bottle neck and it is as if we sent all that traffic over a single link. We basically took two 100 mbps links and funneled them into one, resulting in the same throughput; Final mark 10.4 kbps.

Now with all that being said I do believe we would see a performance gain from GLBP if we dual homed the branch office router as well. In this case, four remote sites with single internet connections downloading simultaneously from four different clients it did not make it significant difference implementing GLBP. Another major point is that we have avoided the link congestion by splitting the traffic across our links, we can then effectively handle double the volume of the HSRP configuration before we reach over subscription.

Figure1.3

Summary

To sum it all up, we took two protocols designed to do basically the same thing, only one does a little more sharing than the other, and put them to the test head to head servicing TFTP request, measuring link utilization and recovering from link failures. What we found is they both perform very well at what they were created to do.  “High Availability” clients were able to maintain services while an entire  link went down. Failover on each protocol was configured with 500 millisecond hellos and 2 second dead timers. HSRP clients continued service after missing only two pings and GLBP clients missed only one. Then servicing TFTP request from our clients downloading from the branch offices they both relied on OSPF to do the heavy lifting. OSPF split the traffic across the two equal cost links back to RTR1 and RTR2 and then from there each router forwarded to the respective client. When we had the branch offices download from the clients for the link utilization test, GLBP swept the game without question. It is great at load-balancing between active gateways. We did not, however, see a real performance gain from the branch offices perspective because in the end each branch router only had a single ISP connection funneling the traffic back down to one link. We would see a congestions management benefit in servicing more request, if we could generate maybe 10 simultaneous downloads from our clients we would see our GLBP routers start out performing HSRP. HSRP would have maxed out its single connection and queues would have started filling up and packet dropping while the interface serialized the data. In this small scale test we did not see a huge performance difference as many believe GLBP would magically provide. Like all networking technology you need to know where and when and how it will be a benefit before making the leap.

 

Conclusion

In a Cisco environment where asymmetric traffic is acceptable and you have the know how to implement, I would go with GLBP as it is today’s winner by TKO.

But if you have a mixed environment you can always stagger your HSRP priorities so one router services half of the VLAN’s while the other router does the other half; Load share.

And that is the down and dirty Street Fight between GLBP and HSRP. If you would like to see more detail or something specific let me know. Below I will post the configurations for you to try out or just review.

 

Thank you

-Jake

 

Configuration used:

HSRP*****************RTR01_Using HSRP*******************

!

interface FastEthernet0/0.100

encapsulation dot1Q 100

ip address 101.16.29.2 255.255.255.0

standby 1 ip 101.16.29.1

standby 1 timers msec 500 2

standby 1 priority 255

standby 1 preempt

!

HSRP*****************RTR01_Using HSRP*******************

!

interface FastEthernet0/0.100

encapsulation dot1Q 100

ip address 101.16.29.253 255.255.255.0

standby 1 ip 101.16.29.1

standby 1 timers msec 500 2

standby 1 priority 254

standby 1 preempt

!

#####################################################

!

GLBP*****************RTR01_Using GLBP*******************

!

interface FastEthernet0/0.100

encapsulation dot1Q 100

ip address 101.16.29.2 255.255.255.0

glbp 1 ip 101.16.29.1

glbp 1 timers msec 500 2

!

GLBP*****************RTR01_Using GLBP*******************

!

interface FastEthernet0/0.100

encapsulation dot1Q 100

ip address 101.16.29.253 255.255.255.0

glbp 1 ip 101.16.29.1

glbp 1 timers msec 500 2

!

Submit a Comment