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.
The guide has been updated with corrections to the backplane stack and VSF member replacement procedures, clarification to guidelines for mixing switch models within a stack or VSF fabric, and various formatting fixes.
Please feel free to respond to this thread with any issues, suggestions, or other feedback!
Just two suggestion: first, on Timings appendix there is a wording that is not totally clear to me...take "Member addition" time on "2930F VSF (4 members)" paragraph: is it referring to VSF non sequenced update or to a VSF Member addition to an existing VSF fabric?
If the former is true maybe the "Member addition" wording should be changed into a more suitable "Member SW update".
Then a second thing: always on the same appendix...the statement "with brief traffic interruption on aggregated links when second member reboots" used on "5400R VSF (2 members)" paragraph is suggesting an global LAG traffic interruption (indeed using "...aggregated links..." doesn't help the reader to understand which physical links of the aggreagate will go down and which not) and not, more correctly, the fact that each LAG with links distributed to both VSF Member will just lose its physical links terminated into the VSF Member that is rebooting for update.
On the first point: the timing entry for "Member addition" is for adding a new member to the fabric, from the point where the member is powered on (with cables connected to a VSF port on an existing member) to switch ports coming up after the switch has joined the fabric.
As for the second point: the physical links to the rebooting chassis will go down; this can cause a brief interruption on a LAG as traffic flows utilizing the (now down) link to the remaining active link, with the duration of interruption varying by protocol (see the timings on page 2 of the document linked in this post for more details; the table will be integrated into a future revision of the best practices guide).
The guide has been updated with a minor revision to add VSF OoBM-MAD configuration for the 5400R.
Is it officially supported to stack devices in VSF even if they are in different racks or wiring closets?
Thanks a lot
@rronsse wrote: Is it officially supported to stack devices in VSF even if they are in different racks or wiring closets?
Yes, it's not important where you install your VSF Members...it's important how you interconnect them: if VSF ports are deployed using SFP/SFP+/QSFP+ Transceivers or DAC Cables then VSF Members connectivity restrictions became really SFP/SFP+/QSFP+ or DAC Cable restrictions (length)...imagine you have VSF Member 1 on Site A and VSF Member 2 on Site B, between Site A and B there are 30 km of (various) fiber optic cables "point to point" then you can easily deploy a VSF solution that is spread across distant sites (clearly with DAC Cables the maximum distance is measured in few meters...so when you are going to use DACs then it means you have VSF Members very near each others...generally on the very same room on the very same rack or on very near racks).
Thanks very much for the guide. Deploying a 3810m stack at the moment and the info on OOBM is just in time.
Hey Matthew, thank you for the document! I have a qusetion that you can help me. If I have more than 1 switch in stack mode (2930M), is it possibile to sync the OSPF informations (protocol sync)?
The stack behaves as a single logical switch, so protocol state (including OSPF) is automatically synced across the entire stack (no manual steps are required).
The guide has been updated once again. Summary of changes:
So we set up a site with four 2930F's a using VSF in a ring formation with only one closet. What would be the best design with multiple closets? I am thinking we get 5400R and put selected ports in the same domain in the VSF stack to each corresponding closet with 2930F's. Would this be the best design to support a site with multiple closets? Very happy with the VSF design for our smaller office.Thanks!
this is a great guide. But maybe I miss the requirements for cable length between the switches?
Do you have any further informations?
Hi! cable lengths between switches part of a VSF obey to same rules valid for similar physical interfaces. This mean that VSF Links type (speed and technology) determines the maximum length of the cable run between VSF Member switches.
Example 1: if VSF Links are deployed by using SFP+ LR (Long Range) optical transceivers then you can expect to reach up to 10 kms between VSF Members (you then have also to consider that VSF reaches its potential if peer devices are multi-homed against all member switches...so you have to take into account that each peer you have connected to VSF should also be able to reach different distant locations...that's to say it's not a matter of VSF Links maximum length). Clearly here come in a lot of notes about the type of connectivity setup between distant site...it should be basically a Layer 2 with no devices in between...so in the example I assumed you're dealing with a sort of (single mode) fiber optic "dedicated line" between distant sites, point-to-point.
Example 2: if VSF Links are deployed by using SFP+ DAC cables you should expect no more than few meters (generally I would say less than 5 meters) between VSF Members.
There is no specific cable length limitation for VSF links — you can use up to the maximum supported length for the cable type you're using for the link.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.