If you have two VSX Clusters, back-to-back (VSX to VSX), then the most reasonable approach to follow is to create a Multi-Chassis LAG (VSX LAG) on each VSX Cluster to deal with connections coming from the other VSX Cluster. The same applies on the other VSX Cluster.
So you will have:
VSX "A" Primary node - MC-LAG x interfaces n1,m1
VSX "A" Secondary node - MC-LAG x interfaces n2,m2
The x will be the MC-LAG stretched to both VSX "A" Cluster members. Then:
VSX "B" Primary node - MC-LAG y interfaces o1,p1
VSX "B" Secondary node - MC-LAG y interfaces o2,p2
The y will be the MC-LAG stretched to both VSX "B" Cluster members.
Generally (n1,m1,n2,m2 and o1,p1,o2,p2) physical links should be interconnected together in a "square way" (like a |X| between VSX Clusters).
More or less like:
"
how would that affect the performance with the LAG between two VSX Clusters not being a multi chassis LAG?"
If you have configured a single LAG - say (because you are forced to do so) - with its member interfaces necessarily originating on a particular VSX Member (the Primary or the Secondary) of the VSX "A" Cluster and those interfaces necessarily are terminating into one particular peer VSX Member of the peering VSX "B" Cluster...it's quite simple to understand what is going to happen if one involved asset goes down...MC-LAGs are completely different story. Try to draw what you have done and it will be crystal clear what is going to happen and what is not going to happen if you - example - simulate a fault on a particular component of your design.
Original Message:
Sent: Dec 09, 2022 01:29 PM
From: Ashour Shamoon
Subject: Configuring LAG between 5406 and 8320 switches
Thank you all, I did miss the LACP mode active.
I have two VSX Clusters and realized after reading the multi chassis, I did not set up the LAG between them as a multi-chassis LAG. I'll fix it, but how would that affect the performance with the LAG between two VSX Clusters not being a multi chassis LAG?
Original Message:
Sent: Dec 09, 2022 10:56 AM
From: Davide Poletto
Subject: Configuring LAG between 5406 and 8320 switches
Hi, just pay attention that the "multi-chassis" LAG option applied on a single standalone Aruba 8320 (so not in relationship with a VSX of two Aruba 8320 switches) doesn't make any sense. A LAG on a single standalone Aruba 8320 could be just lacp or non-protocol, exactly like you will be able to configure it on Aruba 5400R zl2 series. Pay attention to VLANs memberships matching.
Original Message:
Sent: 12/9/2022 3:15:00 AM
From: snaydenov
Subject: RE: Configuring LAG between 5406 and 8320 switches
Hi,
lan is correct. After setting the lacp mode to active, the lag will be formed for sure.
Original Message:
Sent: Dec 09, 2022 03:09 AM
From: Ian Nightingale
Subject: Configuring LAG between 5406 and 8320 switches
Hi, could this be missing LACP parameters. See working examples below:
CX
interface lag 3 multi-chassis
no shutdown
description abc123
no routing
vlan trunk allowed 5,6,7
lacp mode active
procurve:
interface F3
trunk trk10 lacp
exit
Original Message:
Sent: Dec 08, 2022 07:57 PM
From: Ashour Shamoon
Subject: Configuring LAG between 5406 and 8320 switches
I am going to be setting up a LAG between a 5406 and an 8320. For some reason I have trouble with configuring the LAGs. My understanding is that this would be set up like a LAG on the 8320, but a trunk on the 5406 like this:
On the 8320:
config
int lag 1
no routing
no shut
desc 8320 <--> 5406
int lag 1
vlan trunk allowed 1,2,3,4,5
int 1/1/46
no routing
no shut
desc 8320 <--> 5406
lag 1
On the 5406:
config
trunk 1 trk1 lacp
int 1
name 8320 <--> 5406
vlan 1
untagged trk1
vlan 2
tagged trk1
vlan 3
tagged trk1
vlan 4
tagged trk1
vlan 5
tagged trk1
I am just using 1, that's not the actual VLANs. I am just not sure that this is the proper way...