802.3ad Configuration Guidelines for the N-Series

[FAQ_User]

Article ID: 5203

Products
Matrix N-Series
DFE

Protocols/Features
LACP
LAG

Standards
802.3ad

Goals
Sample configuration

Solution
To form a Link Aggregation Group (LAG), ports are grouped within an available Aggregator instance, with a common Actor Admin Key (aadminkey) being one of the more important factors when combining the Aggregator and Ports.

Since by default all Aggregator and Port instances have the same aadminkey value (32768), by default forming a LAG can be as simple as making multiple ethernet connections between 802.3ad peer devices. The Link Aggregation Control Protocol (LACP) is used to intercommunicate control information between the attached peers.

Here is an example of an established LAG:
Matrix N3(rw)->show lacp lag.0.1
Global Link Aggregation state: enabled
Single Port LAGs: enabled

Aggregator: lag.0.1
Actor Partner
System Identifier: 00:01:f4:7f:17:cb 00:e0:63:54:ad:f5
System Priority: 32768 1
Admin Key: 32768
Oper Key: 32768 133
Attached Ports: fe.1.1-2

Matrix N3(rw)->
VLAN assignments to an Aggregator are the same as for a physical port:
Matrix N3(rw)->set port vlan lag.0.2 2
Matrix N3(rw)->
It is also possible to set an Aggregator and a set of physical Ports to associate with one another, if you don't want it to be automatic. This is useful if you lose a LAG (ports are down), and you want to re-use that same lag ID for a new set of ports. This is an unlikely but possible situation.
Matrix N3(rw)->set lacp aadminkey lag.0.2 2000
Matrix N3(rw)->set port lacp port fe.1.11-12 aadminkey 2000 enable
Similarly, you can also assign unique aadminkey values so certain combinations won't form, if for instance you want two different LAGs to form between one set of 802.3ad peer devices.

Note that the DFE will persistently store the LAG_ID (built from the actor/partner MAC+Key) bindings and use them to restore dynamic LAGs after a system reboot. However, if the system reaches a point where it needs to build a new aggregation and there is no matching "historical" binding and no available "clear" Aggregator, it will reuse one of the available "historical" Aggregators.

Generally speaking; if you don't have two or more Ports, the protocol won't form a LAG (5649). With a failure of one Port in a two-port LAG, the LAG will stay up because it has already formed. With the failure of both Ports, if only one comes back the LAG will not re-form. For this reason it is good practice to VLAN-configure the underlying ports in the same manner as the LAG. Typically, they are 802.1Q-trunks (5038).
Matrix N3(rw)->set vlan egress 2 fe.1.11-12 tagged [explicit tagging]
Matrix N3(rw)->set vlan egress 2 lag.0.2 [tagging by default]
A Static LAG is a manually configured LAG that will connect to 'no-protocol' type port aggregation. This is useful for connecting in a load-sharing manner to legacy devices that don't support 802.3ad protocol and must be manually configured.

Entering in the following command will issue the below script.
Matrix N7(rw)->set lacp static lag.0.1 key 2000 ge.1.11-12

Issuing :
clear port lacp port ge.1.11-12 aadminstate all
clear port lacp port ge.1.11-12 padminstate all
clear port lacp port ge.1.11-12 aadminstate lacpactive
set lacp aadminkey lag.0.1 2000
set port lacp port ge.1.11-12 aadminkey 2000
set port lacp port ge.1.11-12 padminkey 2000
clear port lacp port ge.1.11-12 padminsysid
set port lacp port ge.1.11-12 disable
Note: With firmware 5.11.21 and higher, script command... set port lacp port padminstate lacpagg ...is also issued. See firmware 5.22.03 release notes for more about this.

For both Dynamic and Static LAGs, any VLAN configurations should minimally be applied to the logical LAG port instance, rather than the underlying Ports; because for a Port that is also part of a LAG, the LAG's VLAN configuration will prevail for that Port. However, it is common practice to VLAN-configure both the LAG and underlying Ports, so the VLAN behavior will be consistent regardless of whether or not the LAG is in effect.

The N-Series supports up to 48 LAG instances (lag.0.1 to lag.0.48). This can be verified by launching the 'Interface Summary' FlexView in NetSight Atlas Console. The number of underlying physical ports is not limited, and they may be located anywhere within the (possibly multi-slot) system.

See also: 5158, 5340, and 12248.
For 7.x firmware cautions, see 12516 and 13678.