Yes, that's enough to setup a VSX LAG (Multi-Chassis LAG) between the two VSX clusters.
Let's say you want to setup a VSX LAG lag21 on the VSX Stack "A" and a VSX LAG lag34 on the VSX Stack "B": in your specific scenario you're forced to assign only one interface (per VSX Member of that VSX Stack) which means that a VSX LAG (on each VSX Stack) will be made of just two interfaces (exactly your two 40Gbps links) and those two interfaces will be "stretched" along both VSX Members appearing to the other peer device (the other VSX Stack in your case) as a classical LACP LAG (the same applies when you setup a VSX LAG to the IDF Stack represented on the left of your Network Diagram).
On VSX Stack "A" Primary you need:
interface lag 21 multi-chassis
no shutdown
description "This is VSX LAG 21 on VSX A Primary"
no routing
vlan trunk native <vlan-id>
vlan trunk allowed <vlan-id>
lacp mode active
loop-protect
loop-protect vlan <vlan-id>
interface <40Gbps-interface-id-on-VSX-A-Primary>
no shutdown
mtu 9198
low-control rx
description <description-of-40Gbps-interface-which-is-part-of-a-VSX-LAG-lag21-on-VSX-A-Primary>
lag 21
On VSX Stack "A" Secondary you need:
interface lag 21 multi-chassis
no shutdown
description "This is VSX LAG 21 on VSX A Secondary"
no routing
vlan trunk native <vlan-id>
vlan trunk allowed <vlan-id>
lacp mode active
loop-protect
loop-protect vlan <vlan-id>
interface <40Gbps-interface-id-on-VSX-A-Secondary>
no shutdown
mtu 9198
low-control rx
description <description-of-40Gbps-interface-which-is-part-of-a-VSX-LAG-lag21-on-VSX-A-Secondary>
lag 21
now it should be clear that on VSX Stack "B" you need to define the corresponding VSX LAG (lag34) on both members and to bind the correct type of 40Gbps interfaces to that VSX LAG.
On VSX Stack "B" Primary you need:
interface lag 34 multi-chassis
no shutdown
description "This is VSX LAG 34 on VSX B Primary"
no routing
vlan trunk native <vlan-id>
vlan trunk allowed <vlan-id>
lacp mode active
loop-protect
loop-protect vlan <vlan-id>
interface <40Gbps-interface-id-on-VSX-B-Primary>
no shutdown
mtu 9198
low-control rx
description <description-of-40Gbps-interface-which-is-part-of-a-VSX-LAG-lag34-on-VSX-B-Primary>
lag 34
On VSX Stack "B" Secondary you need:
interface lag 34 multi-chassis
no shutdown
description "This is VSX LAG 34 on VSX B Secondary"
no routing
vlan trunk native <vlan-id>
vlan trunk allowed <vlan-id>
lacp mode active
loop-protect
loop-protect vlan <vlan-id>
interface <40Gbps-interface-id-on-VSX-B-Secondary>
no shutdown
mtu 9198
low-control rx
description <description-of-40Gbps-interface-which-is-part-of-a-VSX-LAG-lag34-on-VSX-B-Secondary>
lag 34
Change lag21 and lag34, involved interface(s)-id and VLAN id(s) with desired values...also consider the above as VSX LAGs between peer switches...so you would need also to allow other VLAN id(s) over the VSX LAG, that's to say it is just a basic example and other adjustments are necessary.
There are other considerations...vsx-sync, spanning tree...etc...but the above is just to start and understand the mechanism.
------------------------------
Davide Poletto
------------------------------
Original Message:
Sent: Dec 19, 2021 05:29 PM
From: John Bockarie
Subject: VSX to VSX LAG
Hi Davide
"I don't understand the question...but Yes, a two links LAG is like a four links LAG even if it has less member links (less resiliency/redundancy). In the end you're just assessing if a VSX-to-VSX (back to back) could work...it works! but the point is really the resiliency level of this back-to-back interconnection...and this level is directly proportional to the number of physical links you use to build this interconnection (and the way you do it)."
Is that design supported for an MC-LAG ? My understanding is if the switch is dual homed the MC-LAG/VSX LAG applies however here we have single links between each VSX-PAIR. Can the single links still be configured as a MC-LAG ?
------------------------------
John Bockarie
Original Message:
Sent: Dec 18, 2021 05:17 AM
From: Davide Poletto
Subject: VSX to VSX LAG
Hi Matthew,
"If an IDF switch stack has a LAG to Switch1 & Switch2 and the link between Switch1 & Switch3 goes down, will the traffic entering switch1 from the Switch Stack LAG be sent to Switch2 to get across to the remote location?"
Yes, a Stack LACP connected Switch Stack (say a VSF or a IRF or another VSX or a Backplane) or a standalone LACP connected Switch (or any other LACP connected peer) on the left of your network diagram...if properly connected to (via a Link Aggregation, LACP is preferred) the VSX (Switch 1+2) will be able to continue to reach its destination party on the far right of the same diagram even if - with that VSX "A" to VSX "B" two links interconnection - the link between VSX "A" Switch 1 and VSX "B" Switch 3 goes down...and that will happen because VSX "A" will flow that messages via VSX ISL logical interface to VSX "A" Switch 2 to VSX "B" Switch 4.
What I said before was...what will happen if CONCURRENTLY you will lose the physical link between VSX "A" Switch 1 and VSX "B" Switch 3 and - let me say you will be very unlucky - the VSX "A" Switch 2 OR/AND the VSX "B" Switch 4 goes/go down? that I mean about "resiliency" of VSX "A" to VSX "B" interconnection...clearly if you have only two physical links you must accept what you can achieve with those two links...and just to be prepared to the "black swan" event (if it happens).
"Would the MC-LAG operate as an LACP LAG even though it is only 2 links instead of the recommended 4 links?"
I don't understand the question...but Yes, a two links LAG is like a four links LAG even if it has less member links (less resiliency/redundancy). In the end you're just assessing if a VSX-to-VSX (back to back) could work...it works! but the point is really the resiliency level of this back-to-back interconnection...and this level is directly proportional to the number of physical links you use to build this interconnection (and the way you do it).
------------------------------
Davide Poletto
Original Message:
Sent: Dec 17, 2021 06:53 PM
From: Matthew Ausmus
Subject: VSX to VSX LAG
Vincent, thanks for the response. That setup is the optimal it just isn't an option in this environment.
Davide, my question is really about the resiliency of this configuration. I included an updated diagram that I hope helps.
If an IDF switch stack has a LAG to Switch1 & Switch2 and the link between Switch1 & Switch3 goes down, will the traffic entering switch1 from the Switch Stack LAG be sent to Switch2 to get across to the remote location? Would the MC-LAG operate as an LACP LAG even though it is only 2 links instead of the recommended 4 links?
------------------------------
Matthew Ausmus
Original Message:
Sent: Dec 17, 2021 05:45 AM
From: Vincent Giles
Subject: VSX to VSX LAG
Hello,
You'll find an example (more complex that your use-case as dealing with L3 also) here:
https://support.hpe.com/hpesc/public/docDisplay?docId=a00094242en_us
Page 106- Appendix F
------------------------------
Vincent Giles
Original Message:
Sent: Dec 15, 2021 08:48 PM
From: Matthew Ausmus
Subject: VSX to VSX LAG
I have a client with 2 40Gb dark fiber connections between their corporate office and their data center. This connection is purely layer 2. Layer 3 just isn't an option here.
They currently have Arista switches and we were going to just do an MLAG between the locations but I learned that MLAGs (Arista, Nexus and possibly others) work as a triangle meaning a normal switch or switch stack on one side with an MLAG on the other. You can't do an a connection that is an MLAG to MLAG. I'm including an image of what we're trying to accomplish.
The reason we don't want to just do a 2 member switch stack on each side is mainly for firmware update reasons. The client would prefer not to have the network go completely down during an upgrade. That leaves either MLAG or a stack that supports ISSU or in 1 vendor's case, NSSU.
My question: Can this be done with VSX? Would it operate like an LACP trunk?
------------------------------
Matthew Ausmus
------------------------------