Two-Switch Redundancy using LACP 802.3ad for devices and LAG between switches
I want to connect two TL-SG3210XHP-M2 together such that a NAS with two 1GbE interfaces can be configured for 802.3ad (mode-4 LACP channel bonding) with one eth port plugged into each switch to provide bandwidth aggregation and fail-over.
I presume the 2 SG switches would use 1 LAG between them (eg: Port 9 using a 10GbE SFP+ TwinAx "copper" cable) and a 2nd LAG on each switch that "up-links" to a non-TPL (Allied Telesys) switch (eg: Port 10 using an SFP 1GbE optical SFP and 65.2 micron fiber).
The goals are:
- Under normal conditions, the NAS device and all NAS clients would use both of the links for LACP bandwidth aggregation (approx 2Gb) with redundancy and also able to reach the core (the Allied Telesys switch) through the LAG up-link.
- If one of the SG3210 fails (or goes offline for maintenance), all NAS traffic would seamlessly use the surviving SG3210 switch (path) and all of its traffic would reach the core at 1Gb.
- Propagate any VLAN details between the core and the 2 SG switches.
Is this as simple as:
- Using the GUI on each SG switch to define a Static LAG on SG-1 and SG-2 for port 9 (using the same Group ID) and then connecting the 10GbE TwinAx cable between the two SG switches on port 9,
- Using the GUI on each SG switch to define a Static LAG on SG-1 and SG-2 for port 10 (using the same Group ID) and then connecting the 1GbE optical cable up to matching ports on the Allied Telesys switch (preconfigured).
- Using the GUI on each SG switch to define an LACP (SG-1, 1/0/1 and SG-2 1/0/1, both active, both using the same Group ID and both using the same Port Priority) for the NAS device (and duplicate as needed).
Thanks
I have 4 switches. I want to connect them together for reliability between switches and not (so much) for increased bandwidth (see the picture attached)
The main question is: Does there need to be unique LAG labels for each leg or can there be one LAG label used on all 4 switches? I set this up using unique labels, but I'm running out of labels in the switch's OS.
In the past, I always had (at least) 4 ports set aside on each switch for LAGs. And, I would use a "bow-tie" physical connection between any 4 switches. I don't have that luxury here.
See the attached image.
This is powered up and running right now.
I don't think STP has shut any of the "LAG" ports down (all switches show their LAG ports "up"). Unless I'm mistaken, without a LAG definition, STP would start shutting down links to block loops.
Layout:
There are 4 NAS boxes that each has dual 1G ports set to LACP 802.3ad with one connection on each "red" switch. This is for bandwidth aggregation and reliability between the two "red" switches in the event of a "red" switch failure. Some of the shares are for the network users and iSCSI for the hypervisors. I've tested this (power off 1 "red" switch) and it seems to be working as expected.
There is 3 VMWare servers with one 2.5G port each connected to the "red" switches. They use the NAS and provide virtual machines to the rest of the network. If one "red" switch fails, then those hosts will drop off, but the surviving host(s) and their guests will continue.
The "red" switches will also have another switch connected for a PoE switch for WiFi AP and security cameras.
The FW has two 1Gb ports that are defined as LAG / LACP with 1 leg per "green" switch. This would be for BW aggregation and reliability.
The FW says it supports multiple WAN connections from multiple ISPs. The ISP we have right now is flaky and we are getting a 2nd next week.