Hi Alex, starting from the end:
"
Regarding conciseness (rarely found nowadays), please also keep in mind that my questions was actually answered by Alexis's one-liner response: "use the trunk command" :) - he understood what I asked and I understood what he replied (even if it lacked all the spicy details)"
It's up tp you...you can believe what you want...but the reality is that the answer provided by Alexis - pardon me Alexis - is IMHO wrong...the more I re-read that post...the more is clear that a new joiner will think that on a backplane/frontplane MC-LAGs or DT are possible. Wrong.
Why?
Because you asked: "
Will I still be able to create "multi-chasis" or "distributed" LAG's from this stack towards several other LACP enabled Switches or Static Lag devices (VMWare)?"
You didn't ask: "
Will is still be able to create a Port Trunk from this stack towards several other LACP enabled Switches or Static Lag devices (VMWare)?"
Can you see the difference?
An Aruba backplane stack (or a frontplane stack = VSF) - I really hate to repeat myself - has no concept of MCLAG or Distributed LAGs (you named those ones)...so the right answer to your above question - still this is my personal opinion - should have been a sound "No" (with an explanation) and so I wrote you the explanation above.
The fact that a Port Trunk (Static or LACP) can be created on a backplane/frontplane stack is totally normal and expected (can't you create it on a "single physical"? yes you can...thus you can do the same on a "single logical" too). Note that on a real HP DT scenario a Port Trunk can be created too BUT it needs to be declared neither as
trunk nor as
lacp but exactly as a
dt-lacp (which represents the Multi-Chassis LAG). For 3rd party peers there is basically no difference, they will continue to see a "LACP based Port Trunk" in any case.
Ending with the start:
"
I said it first and you've corrected me: both backplane stacking and some virtual switching technologies (IRF) are old techs that were re-used and sometimes improved by other vendors on the market (VSF). In both cases, the stack uses a single control and data plane and is regarded as a single logical entity from the outside. Hence the old-school-ness (in my opinion)! Only differrence is the ports that are used for interconnecting members.Now, what I would call a new tech is VSX, which splits the 2 planes while maintaining the outside appearance of a single logical entity, hence allowing the admin to upgrade the stack firmware with 0 downtime."
AFAIK concepts behind the VSX technique are really nothing new. The focus should be against the ArubaOS-CX operating system which is based on a database centric/driven architecture; thus the news is really the architecture the VSX is built on, not the VSX approach itself.
VSX initially was called MCLAG (Multi-Chassis LAG) on AOS-CX 10.0...then with AOS-CX 10.1 release (2018) the terminology changed to highlight the fact that with ArubaOS-CX you aren't doing simply a MC-LAGs (as other vendors do) but you're also surrounded with new specific features and developed commands because ArubaOS-CX architecture technically permitted them.
All in all VSX (as it happens on MCLAG of Juniper, MLAG or Arista and Extreme, MTC of Brocade and also DT of HP PVOS/AOS-Switch) requires (a) an ISL and (b) a Keepalive...configuration clearly differs, terminology differs and features differs but, as you can see, other vendors use the same "recipe", differentiations happen because each vendor uses a specific OS with specific features and restrictions...IMHO, with that regards, Aruba VSX looks like (or resembles) HP DT on steroids (clearly DT run on HP ProVision/ArubaOS-Switch...VSX run over ArubaOS-CX).
Don't consider - better: you're free to think whatever you like - IRF ancient or near dead...in DC world it's still a pillar and the IRF with ISSU (In Service Software Update) is robust enough and provide 0 downtime (plus it has years of development) and having a single management backplane often keeps things simple.
A funny thing I remember is that I saw a "VSF/IRF versus MLAG" Technical Whitepaper (early 2017) where Aruba stated that VSF (HPE Aruba) / IRF (HPE) chassis virtualization technologies were better (in simple terms) in comparison of MLAG (note ArubaOS-CX was not released at time)...the loop - years after - closed and now MCLAG technology (in its actual VSX incarnation) is considered better than VSF/IRF.
The lesson the dinosaur personally learned was: it really depends.
------------------------------
Davide Poletto
------------------------------
Original Message:
Sent: Dec 08, 2020 06:07 AM
From: Alex Vrabie
Subject: Backplane Stacking and VSF Best Practices for ArubaOS-Switch
I can see your struggle..it may be complicated for a dinosaur to explain virtual switching to plain mortals. :) (Don't worry, I meant it in a good way!)
I said it first and you've corrected me: both backplane stacking and some virtual switching technologies (IRF) are old techs that were re-used and sometimes improved by other vendors on the market (VSF). In both cases, the stack uses a single control and data plane and is regarded as a single logical entity from the outside. Hence the old-school-ness (in my opinion)! Only differrence is the ports that are used for interconnecting members.
Now, what I would call a new tech is VSX, which splits the 2 planes while maintaining the outside appearance of a single logical entity, hence allowing the admin to upgrade the stack firmware with 0 downtime.
P.S: Regarding conciseness (rarely found nowadays), please also keep in mind that my questions was actually answered by Alexis's one-liner response: "use the trunk command" :) - he understood what I asked and I understood what he replied (even if it lacked all the spicy details)
------------------------------
Alex Vrabie
Original Message:
Sent: Dec 07, 2020 01:59 PM
From: Davide Poletto
Subject: Backplane Stacking and VSF Best Practices for ArubaOS-Switch
Alex, glad you got it...just a note:
"After all, I hope no one here believes they're dealing with nuclear physics or such...it's just old-school technologies, like you said ;)"
You wrote it. It's not my vocabulary.
P.S.
Thank you for this statement: "I haven't stated that you are trying to impress with all that ancient knowledge you have"...I'm still rolling on the floor...this is REAL irony, not mine...and...thank you also for the "ancient knowledge" I'm supposed to have...gosh, not only I thought I'm too shy to try to impress anyone here...now I discover too I'm an old dinosaur ;-).
What a day today.
------------------------------
Davide Poletto
Original Message:
Sent: Dec 07, 2020 05:17 AM
From: Alex Vrabie
Subject: Backplane Stacking and VSF Best Practices for ArubaOS-Switch
Sorry but you just tend to complicate things more than needed! I am indeed new with stacking, aggregation and virtual switching and have been trying to catch-up quickly (after all, it's no rocket science). However, while other vendors offer more consistent, unitary and well documented solutions, Aruba seems to have differrent approaches for differrent chassis and OS's, without providing exhaustive documentation for each.
Regarding your irony-sprinlked & redundant explanations, certainly, I haven't stated that you are trying to impress with all that ancient knowledge you have. All I am saying is that you could just be a little more on-point & straight forward. After all, I hope no one here believes they're dealing with nuclear physics or such...it's just old-school technologies, like you said ;)
------------------------------
Alex Vrabie
Original Message:
Sent: Dec 07, 2020 04:02 AM
From: Davide Poletto
Subject: Backplane Stacking and VSF Best Practices for ArubaOS-Switch
Hi Alex, don't understand if you were referring to my above post...if so...my above explanation was neither unintended (indeed it was intended -> you then got it) nor necessarily over-explained...why? because, as I wrote, your question was aimed at asking if the assumption of being able to still create "multi-chassis" or "distributed" LAG's for such of a stack (backplane in your specific case) was still valid or not...such of a question meant you didn't understood what backplane/frontplane stacking technologies are capable of (and what other technology approaches they overcome)...thus my repetition. Pardon if I misunderstood.
Personally I don't consider the Aruba 3810M backplane stacking approach (Hardware Stacking Module + Stacking Cables) as an "old school" technology (then what's about IRF? it is a frontplane stacking approach and it is very old - its roots date back to 3Com XRN technology - but this doesn't mean it is really old school at all...it could be eventually old from the pure age standpoint - but clearly it evolved a lot over time - it's not old for sure from the technology standpoint). Also consider that, in both cases - backplane or frontplane - your Aruba 3810M pair acts as a virtual switch...and backplane stacking, in comparison, is able to provide you higher inter-switch bandwidth and higher resiliency without wasting precious 10G Ethernet front ports.
------------------------------
Davide Poletto
Original Message:
Sent: Dec 07, 2020 02:02 AM
From: Alex Vrabie
Subject: Backplane Stacking and VSF Best Practices for ArubaOS-Switch
Hi! Again, I appreciate the over-explaining, although couldn't yet figure if it's intended or just uncontrolled :)...anyway, I think I got it: I was stuck (not by choice) with this oldschool backplane stacking for the 3810 series, which means they form a single-chassis, which means I can aggregate any 2 ports on the stack like they were on a single switch!
And, since I am not using VSF and have already managed to do the backplane stack, I guess the document you're pointing me at will serve me no purpose...have you got anything on creating lags (trunks) on aruba 3810? Documentation is so scarce with Aruba.
Thank you
------------------------------
Alex Vrabie
Original Message:
Sent: Dec 05, 2020 05:14 PM
From: Davide Poletto
Subject: Backplane Stacking and VSF Best Practices for ArubaOS-Switch
Hi @darthy_sanchez, since you're deploying a backplane stack made of two Aruba 3810M (JL075), no Multi-Chassis LAG implementation is required at all (and, in any case, you can't deploy MC-LAGs since both Aruba 3810M aren't two separated chassis once you form the backplane stack, they form a single logical chassis...so you can't apply Multi-Chassis LAG because there isn't a multi-chassis).
Back to your question:
"Will I still be able to create "multi-chasis" or "distributed" LAG's from this stack towards several other LACP enabled Switches or Static Lag devices (VMWare)?"
No, there is no concept of Multi-Chassis LAGs on ArubaOS-Switch, the nearest technology could be Distributed Trunking...but DT-Trunking is the key part of a DT deployment (and a DT Deployment means you have two standalone chassis - supporting DT feature - working like they are fused together...but they aren't really, they are interconnected with a ISL Inter Switch Link).
When you already have a backplane stack of two Aruba 3810M then no DT is possible.
When you already have a backplane stack of two Aruba 3810M then no MC-LAGs is possible.
So...at this point you will ask: "What are - if any - the benefits of adopting backplane stacking?"
Backplane stacking totally overcomes the requirement of having to deal with DT or MC-LAGS...simply because peer switches/systems (your ESXi node or a another switch) will see the entire backplane stack as a single logical entity and Static (Non Protocol) LAGs or LACP (IEEE 802.3ad) LAGs will work against that stack exactly as it works against a single standalone chassis...it's simpler than setting up a DT pair scenario or a Multi-Chassis pair scenario (in any case not supported on ArubaOS-Switch OS based switch series)...and...it also has the advantage of letting you to setup a backplane stack with more than two members...and the Static/LACP LAGs will continue to work (LAG's member links will be distributed among backplane stack members to enhance resiliency and load balancing).
For backplane stacking read the guide linked on the first post of this thread (look for it at beginning).
------------------------------
Davide Poletto
Original Message:
Sent: Dec 05, 2020 03:26 PM
From: Alex Vrabie
Subject: Backplane Stacking and VSF Best Practices for ArubaOS-Switch
Hi,
I am working on setting up a backplane (JL078A module) ring stack between 2 Aruba 3810M's (JL075A) running AOS 16.07. I was previously aiming for VSF but have recently found out that this model is incompatible. Will I still be able to create "multi-chasis" or "distributed" LAG's from this stack towards several other LACP enabled Switches or Static Lag devices (VMWare)? If yes, can you please point me to the right documentation?
Thank you in advance
------------------------------
Alex Vrabie
Original Message:
Sent: Jan 14, 2019 03:18 PM
From: Matthew Fern
Subject: Backplane Stacking and VSF Best Practices for ArubaOS-Switch
Greetings!
We have developed a guide detailing best practices for deploying and maintaining backplane stacking and VSF on ArubaOS-Switch. The guide contains recommendations for deployment methods, maintenance, troubleshooting, and plenty of configuration examples.
The attached guide covers the 2930F, 2930M, 3810M, and 5400R switch series.