Cisco has their FHR protocol specifications protected as proprietary IP.
* Gateway Load Balancing Protocol (GLBP)
* Hot Standby Router Protocol (HSRP)
* https://packetlife.net/media/library/3/First_Hop_Redundancy.pdf
Apart from the EIGRP specifications. Which has become publicly available in-part.
Q: Anyone know about if the same has ever been discussed with regards to their HSRP and GLBP protocol specifications?
A shot in the dark. Correct.
(My IETF history is short. =I won't know any older history.)
... I doubt any current or previous Cisco folks on the list would want to chirm in about history from inside Cisco on the GLBP topic...(?)
If you’re looking for vendor neutral FHRP, VRRP has RFC documentation. GLBP and HSRP are Cisco proprietary protocols and are protected information other than the study material and how too out there.
Cyrus
cyrus,
If you're looking for vendor neutral FHRP, VRRP has RFC
documentation. GLBP and HSRP are Cisco proprietary protocols
and are protected information other than the study material
and how too out there.
The thing about the study material I know already. (have been
through both ccna- and ccnp-level route/switch/design training material
in recent 1-4 years)
The question was simply about if GLBP/HSRP had ever been up in discussions in the IETF concerning publishing the protocol specifications as a standard. (As pointed out. I totally forgot about the RFC concerning HSRP.) Haven't gotten a response on the GLBP part. Which I am more than doubtful, myself, will ever come to fruition as a standard in an IETF WG.
AFAIK (and any specific knowledge I have of Cisco is dated), Cisco has not asked the IETF to standardize its proprietary protocol. An obvious start would be for Cisco customers to ask Cisco to do so.
With HSRP/VRRP, someone wrote a specification that they thought Would accomplish the Cisco-proprietary objectives, and championed that through IETF processes. At least part of that had to do with a Cisco competitor and someone who had a bee in their bonnet. I'm not telling you to do that (my observation of HSRP/VRRP is that the result has been two competing protocols, not a winner and a loser), but it's a question you might ask your vendor about.
Are there any good reasons of using proprietary FHRPs like HSRP and GLBP
over VRRP ?
I know that one reason may be interoperability with some vendors
equipment and old gears, but VRRPv3 is now widely used, in particular
for IPv6.
Also VRRP can be easily extended with proprietary extensions and looks
very similar to HSRP in its operation.
Regards.
I thought that GLBP had functionality that allowed both participants to be active/active. I.e. you could cause ⅔ of traffic to go to one GLBP peer and the remaining ⅓ go to the other GLBP peer.
It's my understanding that neither HSRP nor VRRP support this active/active operation and that they are purely active/passive.
Sure, you can have multiple HSRP / VRRP IPs and spread the load via client configuration. But that's outside of the scope of the protocols themselves.
Please correct me if I'm wrong.
Good point. I forgot about this one.
Apparently, you can have four active forwarders per group. The load is
balanced across them via the virtual MAC addresses.
I could implement something similar to my open VRRP implementation (I
wrote about it on the ML recently), but only if it's a wanted features.
I don't think it's overly complex to do, but of course it won't be
covered by any current RFCs.
Regards.
I thought that GLBP had functionality that allowed both participants to be active/active. I.e. you could cause ⅔ of traffic to go to one GLBP peer and the remaining ⅓ go to the other GLBP peer.
Yes it’s true. It achieves forwarding active/active situations. One of the GLBP group members get elected „master“ (just like in HSRP/VRRP).
This master also knowns the („virt“) interface MAC addresses of the other members within the same BC segment. If then a client arp’s for the GW/GLBP virtual IP
then the master is basically spoofing the arp response with a mac of the other members. You have some sort of control of how the mac addresses of the
other members are handed out by the master. This leads to a „static“ client assignment style of load balancing (because you can’t really know how much traffic this one client then generates/gets).
And as far as I remember: If a member fails then another one is taking over responsibility over the used mac address.
It surprised me a little bit that this never really taken off (not even within Cisco folks in the enterprise field as far as I know).
I was also keen if/when this ever get available on other vendors and/or open source software.
Just as everybody else we do run two VRRP instances with ECMP style routes on datacenter gear a lot.
But in some situations it would be nice to have something to spread the traffic across different routers (even when the client is too „dump“ for ecmp routes).
Best regards,
Vincentz
And as far as I remember: If a member fails then another one is taking over responsibility over the used mac address.
That's my understanding as well.
It surprised me a little bit that this never really taken off (not even within Cisco folks in the enterprise field as far as I know).
The few times that it's been discussed with colleagues has usually run into an issue of "how do we do GLBP between two L3 switches?".
I get the impression that GLBP would be more likely used with separate routers connected to common switches that didn't do L3 switching.
I was also keen if/when this ever get available on other vendors and/or open source software.
Agreed.
I did some sleuthing and just learned that OpenBSD's Common Address Redundancy Protocol (also ported to other *BSDs and Linux) does support an active/active configuration.
I found some details in FreeBSD's carp(4) man page. Search said page for "net.inet.carp.arpbalance".
So … I'm going to need to do some pontification about CARP. }
Just as everybody else we do run two VRRP instances with ECMP style routes on datacenter gear a lot.
I see VRRP used a lot as a way to move VIPs between servers for similar redundancy reasons.
But in some situations it would be nice to have something to spread the traffic across different routers (even when the client is too „dump“ for ecmp routes).
Yep. Cisco's GLBP can do that. I now know that OpenBSD's CARP can do that too. (#todayilearned)
Colour me surprised! Option is documented as early as the FreeBSD-5.4
carp(4) man pages.
HSRP has an potential advantage over VRRP in that HSRP speakers keep
track of groups (virtual gateway clusters) in which they do not
participate.
The distinction could matter in a configuration where the routers all
participate in dynamic routing and might be generating ICMP redirects
to steer host traffic toward routers in different groups.
A VRRP router will redirect the client traffic toward the physical
interface of a (failure-prone) physical router (the redirect matches
the sending router's routing table).
An HSRP router recognizes that the preferred next-hop is participating
in an HSRP group, so it redirects the client traffic toward the VIP
associated with that group, rather than the physical router's
interface.
Since these redirects result in something akin to a static route in
the host device, it's safer to have that route pointing at a virtual
gateway than a physical interface.
You could easily convince me that any access LAN including multiple
routers participating in different FHRP groups is due for a redesign,
so this distinction might be moot. But I think it's a neat subtlety.
/chris