[c-nsp] GLBP vs. HSRP vs. VRRP
Mark Lasarko
mlasarko at co.ba.md.us
Thu Feb 9 19:32:06 EST 2006
Thank You for the feedback.
I was looking at this from a few angles;
1st, Use of bandwidth.
With a campus/LAN/(high-speed)MAN environment with multiple VLAN's per building I thought it easy enough to go with the even-odd approach to balance out the traffic; But then I started to think about the resources the users are trying to reach and it seems those resources are often in the same broadcast domain, i.e. server farm, blades, etc... located in the core of the network; So if I use HSRP or VRRP I essentially cut my bandwidth down to some extent, realistically in half in many cases. That said, GLBP not only makes use of the bandwidth, but can do so by means of weighted, host dependent, or round robin configuration. Interesting start - GLBP wins this round by a landslide!
2nd, Complexity of configuration.
Looking over the options it seems like GLBP has everything and the kitchen sink - lots of goodies, maybe too many for some of the others on my team. If you don't want to dig deep into the various load-balancing options then perhaps some may not get the full benefit from GLBP. Whereas HSRP is very straight-forward and VRRP is "virtually" the same as HSRP (no pun intended). HSRP probably wins a photo-finish with VRRP, GLBP is a distant third.
3rd, Ability to troubleshoot.
HSRP @ 224.0.0.2 via UDP port 1985 is fairly easy to find when you need to.
VRRP, @ 224.0.0.18 via protocol 112 is also easily isolated when troubleshooting.
GLBP with it's hierarchy and virtual MAC's seem to be the most challenging here if you're looking at raw data. It may be more tedious to see what is going on underneath, as with flexibility often (usually in my experience) comes complexity. This is nothing a little CLI savvy can't fixup, don't get salty, etc... but that's another issue altogether.
This is where I insert my disclaimer - where I work some of us do what we can, while others only do what they must. Sometimes I want to configure things just so those who "know enough to be dangerous, but don't really [want to | understand]" stay away - complexity can be a good thing - like bug repellent, if used responsibly.
The way I see it there are 10 types of people in this world. Those who can read a packet capture and those that cannot. Considering that, I have to throw in the experience part and with that I give them all a tie in troubleshooting. If you understand what you are implementing then you won't have a problem troubleshooting it if and when you have to.
After considering all of the above I had concluded that GLBP was the best bet for optimizing traffic to the server farm, based on the optimal use of bandwidth when configured properly. HSRP was proven as the "standard" for the "Cisco shop", and this serves well for the edge of the network, attaching to the Internet and such. With VRRP right there in the event that multiple vendors are involved.
All this assumes no ICMP redirects, no proxy-ARP, STP-clear, etc...
Those good housekeeping things in place - where am I left?
Trying to balance bandwidth vs. "If I get hit by a bus tomorrow..."
My next step was the post, to which y'all kindly responded.
After reading my perspective do your picks still stand?
Thank You for your time,
~M
>>> "Asbjorn Hojmark - Lists" <Lists at Hojmark.ORG> 02/09/06 6:58 PM >>>
> IIRC, GLBP used different MAC addresses for the virtual MAC on
> a group-by-group basis; It seemed like it would cause a
> headache during troubleshooting. Please correct me if I am
> misunderstanding something.
It's true that the AVG and the AVFs have virtual MAC addresses,
which depend on the GLBP group number, but the group number can
be the same on multiple interface.
UD11#sh glbp brie
Interface Grp Fwd Pri State Address Active router Standby
route
Vl2001 1 - 200 Active 10.65.1.1 local 10.65.1.3
Vl2001 1 1 7 Active 0007.b400.0101 local -
Vl2001 1 2 7 Listen 0007.b400.0102 10.65.1.3 -
Vl2002 1 - 100 Standby 10.65.2.1 10.65.2.3 local
Vl2002 1 1 7 Active 0007.b400.0101 local -
Vl2002 1 2 7 Listen 0007.b400.0102 10.65.2.3 -
Vl2003 1 - 200 Active 10.65.3.1 local 10.65.3.3
Vl2003 1 1 7 Active 0007.b400.0101 local -
Vl2003 1 2 7 Listen 0007.b400.0102 10.65.3.3 -
Vl2004 1 - 100 Standby 10.65.4.1 10.65.4.3 local
Vl2004 1 1 7 Active 0007.b400.0101 local -
<snip>
HSRP also uses a virtual MAC dependant on the standby group, but
has no concept of an AVF, of cause.
-A
More information about the cisco-nsp
mailing list