Wired Intelligent Edge

Hi,

 

I have 2 x 8320's and im going through setting up VSX. Im configuring my ISL over 2 x 40G DACs and setting up another 10GbE link across the switches as the keep alive. I'll check theyre in sync and then I'll then be configuring VLANs a with a VLAN interface for each and settting up active-active gateway. Is there anything else critical i need to do to ensure the switches are ready for production? In a config video i watched, the guy doing the demo setup a multi-chassic lag after he setup the VSX ISL that connected to a 3rd access switch. It confused me when he said "because both switches can have different port members, we have to configure the lag interface on both switches. once configured we can them move to the primary switch for further configuration". Can someone clear that up for me, what is the purpose of a multi-chassi lag vs a normal lag?

 

Thanks!

 

 

A VSX LAG (also initially referred to Multi-Chassis LAG or MCLAG before Multi-Chassis was renamed into VSX) is a LAG that is "spead across" VSX members having member interfaces belonging to both of them...even if it is singularly configured (simmetrically, I add) on each of them.

A traditional LAG instead references to member interfaces of a singular switch (or of many of them if in presence of VSF/IRF cluster).

Say you have Aruba 8320 node 1 (VSX Primary role) and Aruba 8320 node 2 (VSX Secondary role)...then an example of VSX LAG - we are going to call it "lag1" necessarily on both nodes - would include (and would be defined by): lag1 with member interfaces 1/1/1 - 1/1/4 on node 1 and lag1 with member interfaces 1/1/1 - 1/1/4 on node 2 ...for a (maximum) grand total of 8 member interfaces...those 8 interfaces are seen as member of an unique ports trunk by any upstream/downstream LACP LAG capable devices...this even if the LACP LAG on them will be not co-termininus on the same VSX node (that's the purpose of VSX LAGs...overcoming this essential requirement).

I don't recall it is a restriction but, for simmetry (and to keep things simple to troubleshoot IMHO), I think it's better to use simmetrical member interfaces on both VSX nodes for VSX LAGs...at least this is what I've done: for sure you should at least involve the same number of interfaces on both VSX members...avoiding a VSX LAG with an odd number of total member interfaces (use always 2 and multiple of 2, up to 4 per node...8 at most in total per VSX LAG...so 1+1, 2+2, 3+3 or 4+4).

Traditional LAG, as said above, are "simple" ports aggregation (Non Protocol or LACP) residing on a single switch.