NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Issues with LACP with VLANs
Hi all, Network newbie here. I am having some trouble with VLAN's combined with LACP. The setup I have at the moment are purely for educating my self. It consists of: One Netgear GS724Tv4 On...
I will start answering your last questions. There is no real reason. At the moment, I am using the setup purely for educational purposes. I want to try different setups to test my understanding, and when I do run into troubles like this, take the chance to learn something! My ISP is nothing special, 300/300...
"The decision on which port to use is based on a hash of the source and destination mac addresses in the ethernet packet. So it will be deterministic for a specific LAG. In your particular case, the router is likely rewriting the source mac address."
I think this is it! When the router is transmitting the flows, the MACs and IPs are changed. Instead of having unique MACs and IPs, both flows now have the same MAC and IP. This is making the switch to decide to transmit them on the same port...
All right. What should I do instead? Let's say that I want a segmented network for increased security. Let's say that I have different VLANs for different clients. Let's say that I have a NAS serving multiple purposes (of course with multiple pools for the corresponding client group). Of course I want to make use of that the NAS has 4 gigabit connection for maximum bandwidth with multiple clients
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?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
