LACP Partner Information is Persistent

[FAQ_User]

Article ID: 11319

Products
Securestack A2, A4, B2, B3, B5, C2, C3, C5
D-Series
G-Series
I-Series

Changes
Formed a Dynamic LAG, then detached the LAG peers to remove the LAG.

Symptoms
The ports are removed from the LAG, but the partner's LACP information is retained.

Cause
The LAG partner information is retained in case the LAG should reform - in which case the same LAG aggregator, along with its VLAN-specific assignments, will be reselected for use.

This might become an issue is if all six possible aggregators (

code:

lag.0.1

->

code:

lag.0.6

) have been learned as associated with partner devices, and you attempt to form a LAG with a new partner. Regardless of whether any of the aggregators are presently unused, none are able to learn a new partner so no new LAG will form.

Another way this could cause a problem is because the LAG aggregator is what is actually VLAN-assigned. If a switch is replaced (for instance, as a result of RMA) with a different unit and its peer thus uses the next available aggregator to make the connection, the VLAN assignments on that peer switch will be applied to an aggregator no longer in use instead of the aggregator actually in use - with the result that traffic over that connection will be incorrectly VLAN-assigned.

Solution/Workaround
Functions as Designed (FAD).

To remove learned partner information from a LAG instance (aggregator), use the following CLI commands:

code:

set lacp static

<

LAG_aggregator

>

code:

clear lacp static

<

LAG_aggregator

>

For example:B2(su)->show lacp lag.0.1
Global Link Aggregation state: enabled
Single Port LAGs: disabled

Aggregator: lag.0.1
Actor Partner
System Identifier: 00:11:88:3F:1A:D0 00:00:00:00:00:00
System Priority: 32768 0
Admin Key: 32768
Oper Key: 32768 0
Attached Ports: None.
B2(su)->A Dynamic LAG peer ("partner") is then attached, and is dynamically learned on the local ("actor") system.B2(su)->show lacp lag.0.1
Global Link Aggregation state: enabled
Single Port LAGs: disabled

Aggregator: lag.0.1
Actor Partner
System Identifier: 00:11:88:3F:1A:D0 00:01:F4:C6:69:45
System Priority: 32768 32768
Admin Key: 32768
Oper Key: 32768 0
Attached Ports: ge.1.23
ge.1.24
B2(su)->The peer is then physically detached from the local system - but its information is retained.B2(su)->show lacp lag.0.1
Global Link Aggregation state: enabled
Single Port LAGs: disabled

Aggregator: lag.0.1
Actor Partner
System Identifier: 00:11:88:3F:1A:D0 00:01:F4:C6:69:45
System Priority: 32768 32768
Admin Key: 32768
Oper Key: 32768 0
Attached Ports: None.
B2(su)->Note that there are no ports in the LAG but the peer's System Identifier and System Priority are still set.B2(su)->set lacp static lag.0.1

Issuing :
set lacp static lag.0.1
set lacp aadminkey lag.0.1 1

B2(su)->show lacp lag.0.1
Global Link Aggregation state: enabled
Single Port LAGs: disabled

Aggregator: lag.0.1
Actor Partner
System Identifier: 00:11:88:3F:1A:D0 00:00:00:00:00:00
System Priority: 32768 0
Admin Key: 1
Oper Key: 1 0
Attached Ports: None.
B2(su)->clear lacp static lag.0.1

Issuing :
clear lacp aadminkey lag.0.1

B2(su)->show lacp lag.0.1
Global Link Aggregation state: enabled
Single Port LAGs: disabled

Aggregator: lag.0.1
Actor Partner
System Identifier: 00:11:88:3F:1A:D0 00:00:00:00:00:00
System Priority: 32768 0
Admin Key: 32768
Oper Key: 32768 0
Attached Ports: None.
B2(su)->After forming and clearing a Static LAG, the referenced aggregator instance is back to its original values.

See also: 5531.