Thank you. And that is correct - we have old servers (we hope to retire sooner, rather than later) that are using teaming. I'll try it without the lacp mode commands as soon as we have a maintenance window to test, this week, before the full migration.
Much appreciated.
Original Message:
Sent: Jan 07, 2025 09:33 AM
From: thomasbnc
Subject: ArubaOS to ArubaOS Link Aggregation, non-LACP "trunk" command
...perhaps because there are servers connected, not switches. Servers typically do "teaming", which is an active-passive way of aggregating NICs, and not 802.3ad/LACP.
However, I share the opinion that using LACP is always a good idea as it adds some degree of control to the LAG.
Original Message:
Sent: Jan 07, 2025 08:35 AM
From: R0h0LM
Subject: ArubaOS to ArubaOS Link Aggregation, non-LACP "trunk" command
Why not use LACP ?
Better control of the lag and you will not send data into a blackhole.
The LAG guide is here:
https://www.arubanetworks.com/techdocs/AOS-CX/10.14/PDF/link_aggregation.pdf
lag without LACP is a static lag.
think you can use this (i always use LACP though):
#
interface lag 1
no lacp mode {active
#
a lag without lacp would be static.
This is from the guide:
LACP operating modes
LACP can operate in active or passive mode.
n Active mode: When the LACP is operating in active mode on either end of a link, both ports can send
PDUs. The "active" LACP initiates an LACP connection by sending LACPDUs. The "passive" LACP will
wait for the remote end to initiate the link.
n Passive mode: When the LACP is operating in passive mode on a local member port and as its peer
port, both ports cannot send PDUs.
Two peer ports operating in "passive" mode will never establish an LACP link.
For an LACP LAG, one side must have LACP in active mode and the peer must have an LACP
configuration of active or passive mode. If you do not
Hope it helps