The crux is that LACP and the underlaying LACPDU was never intended to go beyond a single LAG connection, e.g. between a host and a switch, or for the matter between switch and switch. Said this, the LACPDU will never leave the connection making up a LAG or for sake an aggregation - it remains between the the two participants. Citing some parts from a public document Link Aggregation Control Protocol bv Mick Seaman

===

...

This note is not a ballot comment, but provides background for ballot comments in the usual form.

...

This revision summarizes my (Mick Seaman) understanding of the P802.3ad Link Aggregation Control Protocol described in D1.0 and proposes some minor changes.

When it is clear that protocol exchanges between participants in separate systems are being discussed (rather than the aggregate behaviour of participants in a single system) the term “participants” refers to the local participant, sometimes called the “actor” for clarity, and his remote “partner”. Protocol Data Units A single message type, the LACPDU, is transmitted by protocol participants. It comprises the following information both for the transmitting actor, and its remote partner : the partner information being the actor’s current view of its partners parameters.

Port Number
System ID
Key
Status

The Status information comprises the following flags:

LACP_Activity
LACP_Timeout
Aggregate
Synchronization
Collecting
Distributing

....

===

The rewriting of the MAC addresses is intentional on an LACP LAG:

A LACP Link Aggregation Group (LAG) uses a single virtual MAC address (System ID), formed by combining a unique System Priority and the switch's base MAC address, to act as one logical link, allowing seamless failover and load-balancing; this virtual MAC identifies the entire bundle, not individual ports, ensuring consistent LACP negotiation and traffic flow across the aggregated link, crucial for systems like MC-LAG (Multi-Chassis LAG) to maintain a single identity.

Can't find at any point in the 802.3 documentation, including P802.3ad Link Aggregation Control Protocol, that the LACPDU could be distributed further than the two end points of the aggregation bundle.

This is why the switch on the next hop will not specially take care about the virtual MAC address, not's not coming especially together with the LACPDU. So the next hop switch does not especially take care about the fact that is could know about it's previous hop aggregation - so the switch won't specially process and distribute these frames the way one might expect.

Several community members came to the community before, querying about the possibility of cascading multiple switches using LACP LAGs.

Even re-distributing the aggregated traffic to a static LAG won't change anything in my understanding.

Does this clarify about the ghosts you try to fight?

Forum Discussion

RS500 unusably bad upload speeds