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.
Great guide Giles!
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.
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
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):
Thank you for putting my mind at ease
no problem with 2x25G. Just make sure ther eis enough BW in case of some failure scenarios (liek one uplink fails).
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.
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 ?
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.