last person joined: 4 hours ago 

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

VSX Configuration - Best Practices - AOS-CX 10.4

  • 1.  VSX Configuration - Best Practices - AOS-CX 10.4

    Posted Dec 20, 2019 03:23 AM
      |   view attached

    Dear community,

    Here is a technical white paper on VSX Best Practices.

    There are three main use-cases being detailed with step-by-step configuration. You can also jump to the appendixes to find configuration files and copy/paste. I hope you'll find this document useful for your projects.




    Have a great Christmas time.



  • 2.  RE: VSX Configuration - Best Practices - AOS-CX 10.4

    Posted Dec 20, 2019 04:20 AM

    Great guide Giles!

  • 3.  RE: VSX Configuration - Best Practices - AOS-CX 10.4

    Posted Apr 03, 2020 04:48 PM

    Small update: the guide has been updated with a new appendix (F)

    dealing with site-to-site L2 extension with interconnection between two VSX pairs.



  • 4.  RE: VSX Configuration - Best Practices - AOS-CX 10.4

    Posted May 15, 2020 11:00 PM

    Is it possible to create a VSX cluster between 2 6405 switches, interconnected by 4 x 25Gbps ISL that is 4500m long, and running AOS-CX 10.4 release?

    All Guides reference 10,40 and 100 Gas appropriate speeds. I could not find 25G as a valid interconnection speed. Is it due to its newness or are there underlying technical issue I ignore


    Thank you

  • 5.  RE: VSX Configuration - Best Practices - AOS-CX 10.4

    Posted May 16, 2020 04:05 AM

    Hi Miguel, personally I really don't see any restriction in deploying the VSX ISL LAG between your two Aruba 6400 Switches by using two or more SFP28 (25 Gbps) physical interfaces at least as long as you're fulfilling well known VSX ISL related requirements (as example: use same speed interfaces, prefer 9128 MTU, prefer higher speed interfaces - among other available - for ISL LAG members) and restrictions (as example: do not use more than 8 aggregated interface).


    Theoretically you could aggregate up to eight 25G physical interfaces to form the VSX ISL LAG, this on each VSX peer (and supposing you have just 2 modules with SFP28 interfaces available, if I were you I would distribute those 8 - or less - links across both modules to implement physical resiliency against a module failure...but that's a normal approach, pretty much independent by the interfaces chosen...just a best practice to follow when possible).


    Directly from the Aruba VSX Configuration Best Practices for Aruba CX 6400, 8320, 8325, 8400 Technical Whitepaper for AOS-CX Version 10.4 (Edition 1.1 January 2020):




  • 6.  RE: VSX Configuration - Best Practices - AOS-CX 10.4

    Posted May 18, 2020 08:45 AM

    Thank you for putting my mind at ease

  • 7.  RE: VSX Configuration - Best Practices - AOS-CX 10.4

    Posted May 18, 2020 09:40 AM

    no problem with 2x25G. Just make sure ther eis enough BW in case of some failure scenarios (liek one uplink fails).

  • 8.  RE: VSX Configuration - Best Practices - AOS-CX 10.4

    Posted Jun 06, 2020 11:46 PM
      |   view attached

    Hi Vincent,


    I have read this document and my own scenario is a little bit different. I have two 8320 VSX nodes (single VRF model) connecting one firewall as the Core. My concern is the OSPF routing between the VSX nodes and the firewall. 


    In my case, servers have their SVIs on the VSX peers so using the Active-Gateway concept makes sense. Basically, the reason for the firewall is Internet access for the servers.


    However, while reading through the document, I noticed that the OSPF p2p routing between the AGG and the Core switches (page 12) was done using Routed Ports (ROP). I am not sure if this should apply in my case. 

    I was thinking of using an SVI interface on the VSX-peer side since on the firewall side, I assigned an IP address (/30) to a Dot1Q aggregate interface (binding the two physical connections to the VSX peers) for OSPF p2p routing. I guess I am expecting the firewall to see only one OSPF neighbor. I am not sure if what I am thinking is appropriate. I am honestly open to corrections. I just need advice on how best to do the OSPF routing in my own case. 


    Generally, what I expect is: traffic from the servers (destined to the Internet) to pass through the primary VSX peer to the firewall and vice-versa; except in an event when the primary VSX peer fails. Traffic can also pass through the secondary VSX peer via the ISL anyway. I am just trying to avoid asymmetric and/or sub-optimal routing in the end.


    I have a diagram attached.



  • 9.  RE: VSX Configuration - Best Practices - AOS-CX 10.4

    Posted Jun 08, 2020 04:56 AM

    In your case, please follow the VSX Best Practices p36-50



    Due to the nature of the uplink connectivity: active/standby (I assume), you have to use VSX LAG to interconnect the FW, which I think you did. As you use OSPF, configure active-forwarding on the L3 transit VLAN interface facing the FW. (on both primary and secondary), see bottom of p45.


    Does it help ?