Wired

last person joined: yesterday 

Bring performance and reliability to your network with the Aruba Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of the ArubaOS-Switch and ArubaOS-CX devices, and find ways to improve security across your network to bring together a mobile first solution.
Expand all | Collapse all

Backplane Stacking and VSF Best Practices for ArubaOS-Switch

  • 1.  Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 14, 2019 03:18 PM
      |   view attached

    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.

    Attachment(s)



  • 2.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 16, 2019 01:08 PM

    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!



  • 3.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 17, 2019 05:12 AM

    Hi Matthew,

     

    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.

     



  • 4.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 17, 2019 12:13 PM

    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). 



  • 5.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 31, 2019 01:08 PM

    The guide has been updated with a minor revision to add VSF OoBM-MAD configuration for the 5400R.



  • 6.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Apr 04, 2019 08:05 AM

    Is it officially supported to stack devices in VSF even if they are in different racks or wiring closets?

     

    Thanks a lot



  • 7.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Apr 04, 2019 09:30 AM

    @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).



  • 8.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 17, 2019 03:33 PM

    Thanks very much for the guide. Deploying a 3810m stack at the moment and the info on OOBM is just in time.



  • 9.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 18, 2019 10:36 AM

    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)?



  • 10.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 18, 2019 12:18 PM

    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). 



  • 11.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jun 07, 2019 01:50 PM

    The guide has been updated once again. Summary of changes:

     

    • Software platform name has been updated to AOS-Switch
    • CLI command formatting updates
    • Added clarification on software version mismatch behavior on new backplane stack and VSF members


  • 12.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jul 30, 2019 10:29 AM

    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!



  • 13.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Sep 14, 2020 10:00 AM

    Hi Matthew,

     

    this is a great guide. But maybe I miss the requirements for cable length between the switches? 

    Do you have any further informations? 

    Thanks 

    Udo 



  • 14.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Sep 14, 2020 11:37 AM

    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.



  • 15.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Sep 14, 2020 02:16 PM

    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.



  • 16.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 05, 2020 03:27 PM
    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
    ------------------------------



  • 17.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 05, 2020 03:42 PM
    Yes, it is possible

    you need to use trunk command

    ------------------------------
    PowerArubaSW : Powershell Module to use Aruba Switch API for Vlan, VlanPorts, LACP, LLDP...

    PowerArubaCP: Powershell Module to use ClearPass API (create NAD, Guest...)

    PowerArubaCX: Powershell Module to use ArubaCX API (get interface/vlan/ports info)..

    ACEP / ACMX #107 / ACDX #1281
    ------------------------------



  • 18.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 05, 2020 05:14 PM
    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
    ------------------------------



  • 19.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 07, 2020 02:02 AM
    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
    ------------------------------



  • 20.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 07, 2020 04:02 AM
    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
    ------------------------------



  • 21.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 07, 2020 05:18 AM
    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
    ------------------------------



  • 22.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 07, 2020 02:00 PM
    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
    ------------------------------



  • 23.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 08, 2020 06:08 AM
    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
    ------------------------------



  • 24.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 08, 2020 03:32 PM
    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
    ------------------------------



  • 25.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 08, 2020 04:06 PM
    Hi David (and others)

    Sorry but my short response but limited time ;-)
    and yes stacking and MC LAG and other aggregate technologies are new and old on the sometime following what product do you are using and what do you need ;-)

    ------------------------------
    PowerArubaSW : Powershell Module to use Aruba Switch API for Vlan, VlanPorts, LACP, LLDP...

    PowerArubaCP: Powershell Module to use ClearPass API (create NAD, Guest...)

    PowerArubaCX: Powershell Module to use ArubaCX API (get interface/vlan/ports info)..

    ACEP / ACMX #107 / ACDX #1281
    ------------------------------



  • 26.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 08, 2020 05:15 PM
    Hi Alexis, I agree with you on that...as usual, it's an always evolving landscape...and we're struggling to find the perfect "technology match" for our scenarios.

    ------------------------------
    Davide Poletto
    ------------------------------



  • 27.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 09, 2020 06:00 AM
    You're right about my question, I've wrongly expressed my intent of creating a simple trunk/LAG/port-channel shared between 2 backplane stacked chassis - which were now fusing into a single logical one - this is the point where the discussion went haywire, because you started focusing on correcting my usage of terms (by taking the long looped road). Unfortuantely, there was no need for that here, as I could quickly grasp the only idea worth mentioning: "no multi-chassis with backplane stack, just a single logical chassis, so use regular trunk (btw, we call it "trunk" here and "lag" on OS-CX, ain't that a thing?).
    Concluding, I enjoyed your parade, also appreciate the extra knowledge, just didn't cope with your condescending tone and multiple repetitions! 
    It actually made me laugh thinking of you taking all of this way more serious than it actually is! Hope there's no hard feelings...


    ------------------------------
    Alex Vrabie
    ------------------------------



  • 28.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 09, 2020 11:07 AM
    Hi Alex, absolutely no hard feelings. I'm not a T-Rex ;-).

    "(btw, we call it "trunk" here and "lag" on OS-CX, ain't that a thing?)"

    They should be a only one thing...and, de-facto, they are...but the reason is related to different CLI grammars and it is historical:

    • ArubaOS-Switch = AOS-Switch (and historically the HP ProVision OS = HP PVOS from which it derives) -> an aggregation of more physical links is called a "Port Trunk" (command is indeed: trunk ...)
    • ArubaOS-CX = AOS-CX -> an aggregation of more physical links is called - like usually is also on other platforms (such as HPE Comware OS based switch series, some of them are historically called "A-Series switches" in the HP world pre-HPE era...to differentiate from "E-Series switches" represented by those ones with the ProVision CLI style) -  a "LAG" where LAG stands for Link Aggregation Group or BAGG too where BAGG stands for Bridge AGgregation Group or Bridge AGGregation (command is something like: HPE Comware OS uses interface bridge aggregation ... [*] but AOS-CX uses instead: interface lag ...)
    Since you started your post by saying you were playing with Aruba 3810M (AOS-Switch)...I used the term "trunk" for Port Trunking and LAG for AOS-CX...in both case we're speaking about "aggregation of links" made with or without a Control Protocol.

    Anyway, the above two terminology classes caused (and still are causing) a lot of headaches when transitioning between CISCO IOS and HP PVOS or Aruba AOS-Switch because Cisco IOS uses the term "trunk" for VLAN tagging (to tag a port with more than one VLAN, simply saying)...so go figure the potential confusion!

    [*] example here.
    ------------------------------
    Davide Poletto
    ------------------------------



  • 29.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 16, 2020 04:14 AM
    sir,

    will VSF and VRRP will work together as reductancy.

    any configuration available for VRRP.

    ------------------------------
    rajesh kumar
    ------------------------------



  • 30.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Dec 16, 2020 06:27 AM
    Hi Rajesh, since you double posted here and on the HPE Community, I answered you there.

    Eventually, as a best practice, open here a new dedicated thread (don't post your issues on this one).

    Nevertheless you should first familiarize with VSF and Routing through documentation: links are available on this thread (for VSF Best Practices) and on my reply on HPE Community (for VRRP setup in case no VSF is wanted).

    ------------------------------
    Davide Poletto
    ------------------------------



  • 31.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 11, 2021 11:30 AM
    Hi Mathew,

    Just wanted to know if VSF can be configured if my Aruba 5406R switch only have 1G ports?
    And is there a work around or are there any Aruba OS versions that I can use to activate VSF if switchports available are 1G ports only?

    Thanks,
    GSM

    ------------------------------
    manera
    ------------------------------



  • 32.  RE: Backplane Stacking and VSF Best Practices for ArubaOS-Switch

    Posted Jan 11, 2021 01:59 PM
    Hi Manera! Unfortunately (well, think about it, it's pretty reasonable given the switch class we're speaking about...so I should have said "luckily") VSF deployment on Aruba 5400R zl2 requires either 10G or 40G ports to setup VSF Links. 1G VSF Links AFAIK are not admitted for that purpose on that platform.