Saku Ytti wrote on 03/08/2019 15:49:

I don't think any work for GLBP exists in IETF.

A shot in the dark. Correct. https://www.google.com/#q=%28"GLBP"%7C"Gateway+Load+Balancing"+Protocol%7C"Global+Load+Balancing"+Protocol%29+AND+inurl%3Adatatracker+AND+inurl%3Aietf (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...(?) -- Best regards, Chriztoffer

cyrus, cyrus ramirez wrote on 04/08/2019 21:40:

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. -- [ have you enabled IPv6 on something today...? ] [ Chriztoffer Hansen +1 914 3133553 ] [ 0x18dd23c550293098de07052a9dcf2ca008ebd2e8 ]

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. On 04/08/2019 21:40, cyrus ramirez via NANOG wrote:

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

Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>

On Sat, Aug 3, 2019 at 10:19 AM, Chriztoffer Hansen <chriztoffer@netravnen.de> wrote:

Saku Ytti wrote on 03/08/2019 15:49: > I don't think any work for GLBP exists in IETF.

A shot in the dark. Correct.

https://www.google.com/#q=%28"GLBP"%7C"Gateway+Load+Balancing"+Protocol%7C"Global+Load+Balancing"+Protocol%29+AND+inurl%3Adatatracker+AND+inurl%3Aietf

(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...(?)

-- Best regards, Chriztoffer

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. On 05/08/2019 19:55, Grant Taylor via NANOG wrote:

On 8/5/19 9:19 AM, Nicolas Chabbey wrote:

...

Are there any good reasons of using proprietary FHRPs like HSRP and GLBP over VRRP ?

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.

On 8/5/19 1:17 PM, Vincentz Petzholtz wrote:

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) -- Grant. . . . unix || die

On Mon, Aug 5, 2019 at 11:38 AM Nicolas Chabbey <nchabbey@n3network.ch> wrote:

Are there any good reasons of using proprietary FHRPs like HSRP and GLBP over VRRP ?

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