Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Chris Marget]

On Mon, Aug 5, 2019 at 11:38 AM Nicolas Chabbey  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

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Chriztoffer Hansen]

On 06/08/2019 05:20, Grant Taylor via NANOG wrote:
> 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.  }:-)

Colour me surprised! Option is documented as early as the FreeBSD-5.4
carp(4) man pages.

https://www.freebsd.org/cgi/man.cgi?query=carp=0=4=FreeBSD+5.4-RELEASE=default=html

-- 

[ have you enabled IPv6 on something today...? ]
[ Chriztoffer Hansen+1 914 3133553 ]
[   0x18dd23c550293098de07052a9dcf2ca008ebd2e8 ]

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Grant Taylor via NANOG]

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



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Vincentz Petzholtz]

> 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

> Am 05.08.2019 um 19:55 schrieb Grant Taylor via NANOG :
> 
> 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.
> 
> 
> 
> --
> Grant. . . .
> unix || die
> 



signature.asc
Description: Message signed with OpenPGP

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Nicolas Chabbey]

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.
> 
> 
> 

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Grant Taylor via NANOG]

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.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Nicolas Chabbey]

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
> 
> 
> On Sat, Aug 3, 2019 at 10:19 AM, Chriztoffer Hansen
>  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
> 

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Fred Baker]

> On Aug 4, 2019, at 5:29 PM, Chriztoffer Hansen  
> wrote:
> 
> 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.

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Chriztoffer Hansen]

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 ]



signature.asc
Description: OpenPGP digital signature

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[cyrus ramirez via NANOG]

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 
 
  On Sat, Aug 3, 2019 at 10:19 AM, Chriztoffer Hansen 
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