Wired Intelligent Edge

Hi,

 

how many MC-LAGs are supported at the Aruba 8320 switches configured as VSX?

I have installed version 10.04.030.

 

Regards

Christopher

Hi! IIRC actually on ArubaOS-CX 10.4 the maximum number of VSX LAGs should be 51.

 

Edit: the rule of thumb (practical and also operationally validated, if I'm not mistaken) is that the maximum number of configurable VSX LAGs is the result of the maximum number of interfaces minus two (used for ISL, taken as very bare minimum) minus one (used for the VSX Keepalive link or ROP port)...thus basically it's equal to maximum number of available interfaces minus three.

 

On Aruba 8320 with 48 SFP+ plus 6 QSFP+ the above rule means exactly 54 - 3 = 51.

How about on Aruba 6410 where you can have 10x48 ports but LAGs are numbered only from 1 to 256  

I don't work for Aruba so I don't know the exact engineering reasons/rules/theories explaining some declared features' limits (no matter those reasons are obeing to software/hardware architectural limits or to product positioning decisions): let me made a not too far from real example, let me to suppose that a pair of Aruba CX 6410 switches is deployed as a VSX, if each switch is fully loaded with 480 SFP+ ports then yet 239 VSX LAGs value should be really enough considering a reasonable deployment scenario would require 4 ports per VSX LAGs (LAG made by 2 ports on each VSX Member, n=1-239)...considering that a LAG should be reserved for ISL LAG (non VSX) and other non VSX LAGs would be probably required for other uses...I don't think actual maximum values (especially for chassis based Aruba CX Switch series such as 8400 and 6400) are really too limiting.

We have more than 300 access switches in our newest building connected to a pair of 6405's. If we wanted to get maximum bandwidth we could've done M-LAG to each switch (there are enough fibers to do that) and even management wouldn't be a problem with NetEdit. But then we would already be over the max LAG limit. So instead we're doing stacks at the access layer which cuts the amount of LAGs under the limit.

 

(Of course we would've needed to get 6410 and not 6405 too :))

 

One option would be of course to route everything. But there's no possibility to do VXLAN tunnels with ClearPass so having L2 between two different devices in different access switches would be problematic. In our case we're however trying to implement dynamic segmentation everywhere. Helps also towards the core as ArubaOS-CX doesn't have MPLS support and with dynsec we'd need less VRFs

Yeah, I understand what you mean...that's for sure a reasonable feature request (increasing the maximum number of configurable LAGs, VSX LAGs included, especially on modular switch series).

 

If I remember correctly [*] we made a similar request - was just discussed here in the Community - for the Aruba 8320 during the ArubaOS-CX 10.1 phase (so at very beginning of the VSX experience) because, at that time and still today, we felt that the limit due by ArubaOS-CX software - now it is a reasonable 51, at time it was just 32 - would eventually become too low for our future additions and/or changes (the idea was and still is: from having a few servers resiliently connected with more VSX LAG ports per server to have more servers always resiliently connected but with less VSX LAG ports per server...resulting in a higher number of VSX LAGs on the VSX with respect to our initial deployment). Our is maybe a corner case (and, to be honest, we didn't reach the actual limit yet even if we are slowly closer and closer to the former one) but today, as you wrote, it could be quite easy to reach such thresholds.

 

[*] Yes, I do...read here.

Just to complement previous answer, 6410 has a software limit of 255 VSX LAGs.

A fully loaded 6410 could actually provide with 10x R0X39B 520 ports, so 519 VSX LAGs in theory

but in practice, as Davide explained, -3 ports (2 for ISL and 1 for keepalive - when VSX KA over upstream routed-port is not possible).  So that would provide 517 VSX LAGs. The current software limit is set to 255. 

If you think this is not enough please reach out to your local Aruba contact to raise the need for increase.

AS this is software limit and validation test, increase should be possible (in theory).