-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New module for link aggregation support (mvp) #1143
base: dev
Are you sure you want to change the base?
Conversation
I like it the generic idea, and having lag.id on an interface is probably the way to go. However, the whole thing is way more complex than what can be done with your approach... unless we limit ourselves to LAG-with-VLAN-trunks, but then I know we'll pay a heavy price sometime in the future (see also: VLAN module). For example, here's a simplest possible topology modeling a L3 LAG link between two adjacent nodes:
You approach (fixing the interface names afterwards) would fail miserably, as we have to assign a single subnet to the LAG link. I think we have to do something similar to how we handle VLAN trunks and create extra virtual links for LAGs, turning the physical link into a L2-only link. |
Some changes - highlights:
TODO:
|
…ink to that * Add topology test cases
Fix one more test case
- make mc_lag support optional, check - some interop defaults (enable LACP by default, don't do standby signaling by default)
Is this ready or are you still working on it? |
Example:
For discussion - syntax could also work like vlans, declaring the links