Hi!
"
I must admit that I do not understand the point you are trying to make in this sentence with the last, "isn't it?" The grammar doesn't quite work out."
Sorry, I'm not English mother tongue so, maybe, my text couldn't be as clear as I wanted...but with the last
rhetorical question (yes, it was) was meant to ask a inter-negative question as "Don't you agree with that?", of course you agreed indeed you then wrote "But yes, that is point #3 above." and point 3 above means that LAG and Mesh didn't cope well if compared to how LAG instead performs when deployed against a Virtual Switch (so against virtualization technologies like, as example, the VSF = Frontend Stacking approach, IRF, VSX or even Backend Stacking approach just to name a few provided by HPE/Aruba portfolios).
Point by point:
"To #1 ("That a peer switch, can have a LAG with links to each VSF member"), this is only an advantage to VSF only if the primary consideration is that the VSF switches are geographically far apart."
Why? because a peer switch connected with a LAG to VSF Members has an advantage in any case, even if VSF and peer switch sit just few centimeters away each others (so also when VSF Members aren't "geographically" separated in remote sites), like when they are deployed just few racks away from each others or also in the very same rack. Why that? because the usage of LAG and VSF hasn't an essential relationship with the fact VSF Members must be "separated" (it would be a bonus in particular cases but not a mandatory requirement), the real "gain" it brings is the redundancy and resiliency (even with a well formed and stable STP topology). A LAG link fails? no STP topology recalculation (generally).
"Otherwise we can do a LAG into a stack (single virtual switch) of either VSF or backplane stacked switches with no difference."
I don't understand the above sentence if related to the previous one...but it's true, really there is no difference: a LAG against a VSF or against a Backplane Stack acts the same way because both stacking technology/approaches represent a single logical entity and so LAG member links can be terminated against the VSF/Backplane Stack members."
The difference is a VSF only switch has much worse topology in the stack itself because it supports only ring or chain. In the case of a 3-switch stack of either a 3810M or 6300M in specific, the former has 80G links between each of the two nodes while the 6300M only has 50G (using one 50G port to connect to each of its neighbors in the ring)."
VSF supporting Mesh (up to 5 Switches), Ring topology or Chain topology is, IMHO, not a Cons but a Pro (it's just my point of view) and
Ring is the recommended one when you have more than 5 Switches (it requires that each VSF Member is configured with two VSF Links, interconnecting each member with two other members in the stack) and Mesh below that number. In any case, VRRP, OSPF, MSTP and LACP are supported by any adopted stacking topology.
About your Aruba 3810M Backplane Stack versus Aruba CX 6300 VSF stacking bandwidth comparison: Aruba 3810M Backplane Stack provides 80 Gbps if exactly two neighbor stack switches are used (8x10Gbps stacking ports) but Aruba 6300M VSF could aggregate more 50Gbps ports together (note the plural in ports) to form the VSF Link(s) - both in case of two or three VSF Members - so you can easily overcome the Aruba 3810M stacking bandwidth (OK, at the expense of precious Frontplane 50Gbps ports but Aruba 3810M Stacking Module and Cables aren't cheap too) even if the comparison is against the two Backplane stacked switches case (a Chain).
"
With more than 3 in the stack, forget it, mesh is better for multiple interconnect, and even up to 5 nodes, a backplane stack can be fully interconnected. A VSF stack can never be fully interconnected beyond 3 units."I'm not sure the "Mesh Domain" versus "VSF Stacking" is a fair comparison, also isn't fair the comparison between Aruba 3810M "Backplane Stacking" deployed with a Mesh Topology (up to 5 members) and the Aruba CX 6300 deployed as VSF because VSF doesn't support a "Mesh Topology" approach as the Aruba 3810M does (only Chain or Ring) and here I'm not speaking of just "Mesh Domain" (which, again, is not a Virtualization Technology).
"
Also on point #1 ("That a peer switch, can have a LAG with links to each VSF member"), if that peer switch were just part of the mesh, then it can have mesh links to (almost) as many switches in the mesh as it wants and any LAG restrictions/limitations are erased."
But a peer switch here is considered an external entity with regard to the VSF or the Backplane Stack so I don't understand the purpose of that sentence.
"
To #2, that is true, but again, if the peer switch were using mesh instead of LAG this limitation wouldn't exist anyway."
Again, why a peer switch (with Mesh Domain related restriction) should be part of a Mesh Domain? and if you don't have a peer switch but just a peer host (server) which is able "to speak" LAG with LACP, as example? The whole network assets can't be part of a Mesh Domain, generally.
"
To #3, yes, that is true, but as you said, bandwidth will not be shared, and in many cases, hops will increase, due to the requirement of disabling ports via STP."
That's Cons of the Mesh Domain approach, necessarily.
"
I appreciate the elaboration of different scenarios of VSF only vs. mesh, but I don't see any compelling argument for VSF only stacking AND getting rid of mesh."
Maybe on Aruba CX switch series (running ArubaOS-CX operating system != ArubaOS-Switch = HP ProVision OS) the Mesh Domain wasn't considered as an essential feature given technologies like VSF (of ArubaOS-CX) and VSX. Simply Aruba decided to not implement that feature into ArubaOS-CX operating system based switch series given they provided VSX (two members) and VSF (various members) virtualization technologies.
"
The only point in its favor is the from point #1 above, the ability to terminate a peer switch's LAG group to multiple physically distant switches in the same VSF."
Remove the word "
physically distant" because it's not a requirement necessary to validate and justify the usage of peer switch/host LAG against a VSF stack. The sentence should instead sound, in my opinion, this way:
"
One of the point in its favor is the from point #1 above, the ability to terminate a peer switch's LAG member links to multiple switches belonging to the same VSF."
Again
"I wonder how useful that actually is, but regardless, the point becomes moot if the peer switch were connected via mesh, which would work seamlessly."
See above, a peer (Switch/Host) could not be necessarily part of a Mesh Domain...you have to admit that VSF or Backplane Stacking are agnostic enough to leave freedom to connected peers, you can do LAG...do it and enjoy the Pro, you can't? don't do it and accept the Cons, VSF will continue to provide its services and peers continue to be perfectly/imperfectly connected to it.
Edit: I love Aruba 3810M, it is a really powerful platform (with or without Mesh), I consider it at the same level of the Aruba 5400R zl2.
Original Message:
Sent: Nov 07, 2022 11:21 AM
From: Zak Smith
Subject: Mesh discontinued with AOS-CX & 3810M replacements - Why?
parnassus,
Thank you for your reply. I take away from your post several points (facts):
1. That a peer switch, can have a LAG with links to each VSF member.
2. A peer switch cannot have a LAG with links to multiple switches in a single mesh domain.
3. A peer switch can have multiple regular (non-LAG) links to multiple switches in a mesh domain (will require a spanning tree algorithm) which will provide redundancy to link-failure but not increase bandwidth. (The use of multiple external links to a mesh with STP is specifically diagrammed out in the documentation link in the first post.)
"The fact you can have a peer Switch with multiple single links terminating into different Switches forming the same Mesh domain means that those links are necessarily not concurrently active, isn't it?"
I must admit that I do not understand the point you are trying to make in this sentence with the last, "isn't it?" The grammar doesn't quite work out. But yes, that is point #3 above.
But anyway, point by point. To #1, this is only an advantage to VSF only if the primary consideration is that the VSF switches are geographically far apart. Otherwise we can do a LAG into a stack (single virtual switch) of either VSF or backplane stacked switches with no difference. The difference is a VSF only switch has much worse topology in the stack itself because it supports only ring or chain. In the case of a 3-switch stack of either a 3810M or 6300M in specific, the former has 80G links between each of the two nodes while the 6300M only has 50G (using one 50G port to connect to each of its neighbors in the ring). With more than 3 in the stack, forget it, mesh is better for multiple interconnect, and even up to 5 nodes, a backplane stack can be fully interconnected. A VSF stack can never be fully interconnected beyond 3 units.
Also on point #1, if that peer switch were just part of the mesh, then it can have mesh links to (almost) as many switches in the mesh as it wants and any LAG restrictions/limitations are erased.
To #2, that is true, but again, if the peer switch were using mesh instead of LAG this limitation wouldn't exist anyway.
To #3, yes, that is true, but as you said, bandwidth will not be shared, and in many cases, hops will increase, due to the requirement of disabling ports via STP.
I appreciate the elaboration of different scenarios of VSF only vs. mesh, but I don't see any compelling argument for VSF only stacking AND getting rid of mesh. The only point in its favor is the from point #1 above, the ability to terminate a peer switch's LAG group to multiple physically distant switches in the same VSF. I wonder how useful that actually is, but regardless, the point becomes moot if the peer switch were connected via mesh, which would work seamlessly.
Original Message:
Sent: Nov 07, 2022 06:52 AM
From: Davide Poletto
Subject: Mesh discontinued with AOS-CX & 3810M replacements - Why?
Hi, given that Mesh is not a Virtualization Technology then I have a question related to this particular sentence (the highlighted text):
"It's not quite VSF as the switches are not made into one virtual switch, but it goes beyond the sophistication of LAGs ("Trunks" in Aruba nomenclature). The advantages over regular inter-switch links (including LAGs) is that optimal routes are automatically recalculated often and that traffic is automatically allocated based on performance."
Here we are forgetting the fact that - from the specific peers' standpoint - a LAG (Port Trunk) with its member links terminating against all available VSF members (or just against the VSF Conductor and VSF Standby members only) translates to enhanced up/down-links redundancy and resiliency (call it "sophistication" if you want even if I don't think it is the kind of sophistication you are referring to)...so here the question about the Mesh deployment:
Provided that a peer Switch (the equivalent of a Switch connected to the Mesh domain) with a LAG with member links terminating into two different Switches of the same Mesh domain is not a supported scenario (indeed a LAG requires to terminate its member links into a single logical entity and a Mesh domain isn't a single logical entity while a VSF is exactly that)...the fact you can have a peer Switch with multiple single links terminating into different Switches forming the same Mesh domain means that those links are necessarily not concurrently active (differently to what happens to LAG's links), isn't it?
Just this point.
Original Message:
Sent: Nov 06, 2022 03:27 PM
From: Zak Smith
Subject: Mesh discontinued with AOS-CX & 3810M replacements - Why?
By mesh I mean mesh as defined in this manual, and as implemented on the 3810M
https://techhub.hpe.com/eginfolib/networking/docs/switches/K-KA-KB/15-18/atmg/content/ch06s07.html
From the document,
"Any switch in the mesh can have up to 24 meshed ports.
A mesh domain can contain up to 12 switches.
Up to 5 inter-switch meshed hops are allowed in the path connecting two nodes.
A fully interconnected mesh domain can contain up to 5 switches."
There don't seem to be any other topology restrictions than those above, and links of different speeds can be used. In other words, connect up all the ports you want to provide bandwidth, redundancy, and additional links to reduce latency (hop count), and it'll figure it out.
It's not quite VSF as the switches are not made into one virtual switch, but it goes beyond the sophistication of LAGs ("Trunks" in Aruba nomenclature). The advantages over regular inter-switch links (including LAGs) is that optimal routes are automatically recalculated often and that traffic is automatically allocated based on performance.
From the document, "Provides significantly better bandwidth utilization than either Spanning Tree Protocol (MSTP) or standard port trunking. Uses redundant links that remain open to carry traffic, removing any single point of failure for disabling the network, and allowing quick responses to individual link failures. This also helps to maximize investments in ports and cabling. Unlike trunked ports, the ports in a switch mesh can be of different types and speeds (10 and 100 Mbps, gigabit, and 10 gigabit). For example, a 10Base-FL port and a 1GB port can be included in the same switch mesh."
The 3810M series has reached EOS, with EOsL in 2027. The recommended replacement is the 6300M. I don't see references to meshing in any 6300M documentation (or any CX documentation period). As far as I can tell, the 6300M *only* has VSF stacking, not backplane stacking. This limits the stacked bandwidth to what is available on the front of the switch via normal ports, which is normally two 50G ports (one in, one out in supported VSF topology). This sacrifices other non-VSF bandwidth to what will be required to connect it to the stack.
VSF only supports chain or ring topologies, not mesh or other arbitrary interconnect (see mesh comments above), thus limiting speed between to arbitrary switches in the stack. A full connected 3810M stack of 3 switches will have 80G bandwidth between each pair in the stack and with only one hop, whereas a VSF chain with 50G links will have only 50G bandwidth between any two switches and 33% of all possible routes will have two hops instead of one. That's sort-of comparing backplane stacking to VSF. A 5-switch VSF ring has more hops for the average random port-to-port route than a 5-switch fully interconnected backplane stack.
Now if we look at mesh vs. VSF, VSF only supports chain or ring, not arbitrary interconnect, so it seems like for a way to flexibly, scalably, and redundantly interconnect switches, mesh is superior to VSF (and multiple LAGs via the manual's own comments quoted above).
Can someone tell me what I'm missing here?
How is dropping meshing not a big drop in functionality? Especially when VSF is limited in interconnect and topology?
VSF stacking does not allow fully-connected or arbitrary interconnect (in what would have been called the "mesh domain" in a mesh setup), so it limits performance scaling compared to both backplane stacking and mesh domains.