> 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 <nanog@nanog.org>: > > 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
