Wired Intelligent Edge

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.

:

https://support.hpe.com/hpsc/doc/public/display?docId=a00094242en_us

Have a great Christmas time.

Vincent

Attachment(s)

AOS-CX VSX - Technical Whitepaper - v1.0.pdf   3.04 MB 1 version

AOS-CX VSX - Technical Whitepaper - v1.3.pdf   3.87 MB 1 version

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.

https://support.hpe.com/hpesc/public/docDisplay?docId=a00094242en_us

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

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

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.

Thanks.

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

https://support.hpe.com/hpsc/doc/public/display?docId=a00094242en_us

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 ?

@vincent.giles

Awesome guide, thank you very much! Especial, the different Examples for Aruba CX (Core/Agg/Access) and Aruba AOS (Access) are very helpful.

Any chance we can get an Update for newer Firmware Version? This guide references Aruba CX 10.4.

Maybe there are new and helpful features in more recent Firmware Versions?

Everything written for 10.04 is still valid. Here it is attached.

Attachment(s)

AOS-CX VSX - Technical Whitepaper - v1.4.pdf   4.41 MB 1 version