Hello wkong,
no, they do not.
Regards
Hi!
Interesting question...
Looking at what is reported on QuickSpecs for Aruba 5400R zl2 (supposing you want to implement VRRP using that Switch series), recent ArubaOS-Switch versions adhere to RFC 3768 (which obsoleted the RFC 2338 and consequently was obsoleted by RFC 5798)...so no VRRPe here...BUT, as reported here (many years ago), the main reported difference between VRRP versus VRRPe was that "...with VRRPe all routers are Backup routers and use a Virtual IP address: the Master is decided by a Priority value which you assign. This allows you to easily change which router will be the Master for a particular VRID. With VRRP instead you would either need to change the clients default gateway, or reconfigure the routers so that that you'd swapped their IP addresses around." or, in other terms, that VRRP, if compared to VRRPe implementation, doesn't permit to use a "Virtual IP address" and instead it forces you to use the real IP address of one Switch as VRRP VRID IP Address...BUT...and that is the interesting part...as reported here it looks like that there is a workaround for that restriction...a workaround that push VRRP implementation on HP ProVision NOS based switches (and, as extension, on current ArubaOS-Switch NOS based ones) near to what was VRRPe.
So, in the end, it looks like VRRPe features are somewhat permitted on actual VRRP implementation...hope not to be wrong here.
Note (from a very old - now only cached - HP chapted about VRRP on HP Routing Switches):
- There is no тАЬOwnerтАЭ router. You do not need to use an IP address configured on one of the routing switches as the virtual router ID (VRID), which is the address you are backing up for redundancy. The VRID is independent of the IP interfaces configured in the routing switches. As a result, the protocol does not have an тАЬOwnerтАЭ as VRRP does.
- There is no restriction on which router can be the default master router. In VRRP, the тАЬOwnerтАЭ (the routing switch on which the IP interface that is used for the VRID is configured) must be the default Master. HP routing switches configured for VRRPE can interoperate only with other HP routing switches.
I'm not an HPE Employee
Hello parnassus,
VRRP-extended is a Brocade-proprietary protocol and is not compatible with VRRP: it uses for example another MAC and destination multicast IP address. The information in the blog post is taken from the Brocade page, but the "HP proprietary" part was modified. Recent HPE firmware supports only VRRP. I doubt it, that ProCurve have supported VRRP-extended and have dropped it, but I did not check older guides (older than 5 years).
Regards
Where do you see that VRRP Extended references only to Brocade? I believe VRRPE implementation was offered on old glorious HP Routing Switches ProCurve 9300m too (at least old docs still available on Internet report that)...probably the same did Brocade on its Routing Switch of that era.
AFAIK, at a deeper look, the actual VRRPv3 (RFC 5798) implementation - and VRRPv3 is actually supported on ArubaOS-Switch NOS on selected series - doesn't include (and what is not included is excluded, right?) the "no owner design" mode of operation (the one reported on the Blog I linked above as a workaround to overcome strict VRRP mode of operation)...so I'm still not sure about what actually is VRRPv3 versus old proprietary HP VRRPE.
I'm not an HPE Employee
Hello parnassus,
yes, you are right, the 9300 series do support VRRPE, so that possibly other models support the protocol as well. Here is what I have found:
https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US&docId=emr_na-c02565639&withFrame
Chapter 15, page 15-1
External link to Ruckuswireless (Brocade)
Regards
Yes, reading Ruckus description of their VRRPE implementation made me think that is somewhat very similar to what was on old HP ProCurve 9300m Routing Switches...everybody claim to have its VRRPE implementation...and so back to the question about actual VRRP implementation on ArubaOS-Switch based Switch Series versus what was VRRPE years ago: when we actually read "VRRP" is it really "strict VRRP" as per updated RFC or is it "a sort of VRRPE well hidden behind an updated VRRP" (so the workaround I cited in my first post - the no owner design approach - described by a blogger is actually possible/justified and it works without breaking the VRRP we all know)?
I'm not an HPE Employee