Firmware 5.11.21 and higher
Single port LAG
'set lacp singleportlag'
Firmware 5.11.21 release notes state, in the Software Changes and Enhancements section:
Single port LAG behavior has changed in this release. In previous firmware
(introduced in 5.01) a LAG would re-form with just one port if the system had
formed a multiport lag to the same partner in the past. Versions prior to
5.01 would maintain a lag if it failed back to a single port but would not
reform it the next time the system booted, or that single port left the LAG
due to partner activity.
A system wide command that allows the user to optionally choose to have the
system form lags when only one port is receiving protocol from a lag partner
is now available. A CLI command 'set lacp singleportlag enable/disable' will
have set, show, clear and show config options. This feature is disabled by
[/code]In summary (and expanding upon what is stated in release notes), as of firmware 5.11.21:
- Knowledge of previous Dynamic LAG peers is persistent (survives a reboot), causing the learned partner to be "preferred" in two ways by the local actor: (1) It will re-form a LAG using one or more links and (2) it will reserve and try to use the same aggregator instance (ex: lag.0.1) if possible. A learned entry consists of a paired partner MAC address and actor Aggregator instance. Learning may be cleared by dropping back to a system Factory Default configuration (5296), or may be more simply cleared by establishing ('set lacp static lag.0.x fe.x.x') then clearing ('clear lacp static lag.0.x fe.x.x') a Static LAG for the affected aggregator and port (5203).
- The requirement of needing to form a multi-port Dynamic LAG to a particular peer before a single-port Dynamic LAG can form to that peer may be overridden by means of the 'set lacp singleportlag enable' command.
- A single-port Dynamic LAG may also form while the 'set lacp singleportlag' command is disabled on the local actor and no LAG has previously formed with the peer in question, if the peer device is willing to form a single-port LAG, and advertises that fact. Once such a LAG has formed, while physical link remains the singleportlag behavior will tend to be persistent through a combination of peer learning and cross-advertisement - even if the above "learning clear" workaround is applied.
To avoid these side-effects, consider first configuring the unused LAG virtual ports to require a specific key. Often the lower-numbered LAG aggregators will already be in use and active. This command form, issued on each of the peer chassis, would set the key for the rest of the aggregators: DFE(rw)->set lacp aadminkey lag.0.x-48 1234
[/code]Then, assign to the same aadminkey each of the ports you want to form singleport LAGs after singleportlag behavior is enabled: DFE(rw)->set port lacp port ge.x.y aadminkey 1234
[/code]You will also need to configure onto the resulting lag.x.y logical port any port-specific settings you had already applied to the physical port, once the LAGs form. To make this more deterministic (allowing port reconfiguration before the LAGs form) you may opt to use unique aadminkey values for each physical/logical port pair rather than one value for all.
As the final step, allow the single-port LAGs to form, as possible: DFE(rw)->set lacp singleportlag enable
[/code]Contact Enterasys Networks Technical Services for further assistance, as necessary.