Document MLAG relation between LAG ports #10837

@jeremystretch commented on GitHub (Mar 6, 2025):

Provide a field on the LAG interface that documents the relation to a LAG interface on another device. (other devices)

Could you expand on the specific proposal here? I'm not clear on how this would work. It sounds like there would be an inherent limitation of two LAG interfaces per "side" of the multi-chassis LAG.

Would applying a tag to the relevant MLAG interfaces suffice? Or a custom field?

@jeremystretch commented on GitHub (Mar 6, 2025): > Provide a field on the LAG interface that documents the relation to a LAG interface on another device. (other devices) Could you expand on the specific proposal here? I'm not clear on how this would work. It sounds like there would be an inherent limitation of two LAG interfaces per "side" of the multi-chassis LAG. Would applying a tag to the relevant MLAG interfaces suffice? Or a custom field?

adam commented

@PieterL75 commented on GitHub (Mar 6, 2025):

We would need two extra field. One that links one LAG interface to another LAG interface
And an extra field that documents the mlag id of that link.

Come to think of it, some kind of virtual cable could work also, if it could contain the mlag id.

@PieterL75 commented on GitHub (Mar 6, 2025): We would need two extra field. One that links one LAG interface to another LAG interface And an extra field that documents the mlag id of that link. Come to think of it, some kind of virtual cable could work also, if it could contain the mlag id.

adam commented

@jeremystretch commented on GitHub (Mar 13, 2025):

@PieterL75 I think this needs a bit more detail still as it's not clear IMO exactly what you're proposing. Could you extend the original description above to specify exactly what field(s) you're proposing be added and how they are to be defined?

(The idea of a virtual cable would not be tenable as it violates one of our core design tenets.)

@jeremystretch commented on GitHub (Mar 13, 2025): @PieterL75 I think this needs a bit more detail still as it's not clear IMO exactly what you're proposing. Could you extend the original description above to specify exactly what field(s) you're proposing be added and how they are to be defined? (The idea of a virtual cable would not be tenable as it violates one of our core design tenets.)

adam commented

@github-actions[bot] commented on GitHub (Mar 21, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (Mar 21, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

adam commented

@PieterL75 commented on GitHub (Mar 24, 2025):

@jeremystretch I've update the FR. I hope its detailed enough.
As I don't have (deep) insights in how NetBox works under the hood, I can't provide a detailed 'database' or solution. Only what I expect what this FR should implement

@PieterL75 commented on GitHub (Mar 24, 2025): @jeremystretch I've update the FR. I hope its detailed enough. As I don't have (deep) insights in how NetBox works under the hood, I can't provide a detailed 'database' or solution. Only what I expect what this FR should implement

adam commented

@enkidu commented on GitHub (Mar 28, 2025):

@PieterL75 use of MLAG typically involves some kind of virtual chassis (either hardware or software stacking). When you create Virtual Chassis you can add LAG interface from master device and you will be able to assign LAG membership to any port on any Virtual Chassis member

@enkidu commented on GitHub (Mar 28, 2025): @PieterL75 use of MLAG typically involves some kind of virtual chassis (either hardware or software stacking). When you create Virtual Chassis you can add LAG interface from master device and you will be able to assign LAG membership to any port on any Virtual Chassis member

adam commented

@PieterL75 commented on GitHub (Apr 10, 2025):

An MLAG is NOT a Virtual Chassis.
The virtualchassis implies a central 'master' that controls the all members, a central mgmt ip etc.

MLAG is just 2 separated devices that talk to eachother using MLAG links and provide a LAG over multiple devices.

@PieterL75 commented on GitHub (Apr 10, 2025): An MLAG is NOT a Virtual Chassis. The virtualchassis implies a central 'master' that controls the all members, a central mgmt ip etc. MLAG is just 2 separated devices that talk to eachother using MLAG links and provide a LAG over multiple devices.

adam commented

@enkidu commented on GitHub (Apr 10, 2025):

@PieterL75 not really. M(C)LAG forms some reduced kind of virtuall chassis "as seen by connected device" (especially for DT-LACP). In case of HP this is actually limited subset of IRF.VSX, which would fall under "true virtual chassis" is even more complicated: it forms common backplane for L2 but it does not for L3.

Netbox Virtual Chassis allows you to use multiple management IPs - this is exactly how I did the case you are struggling with:

There is no shared IP (both member switches have distinct IP):

There is no need to designate any device as master. Only drawback: LAG interface will be listed only on one device, but member ports will have it assigned - relation to another device is clearly seen:

Vendor-specific settings can be implemented via Custom Fields, however you cannot filter for interface type when diplaying them. HP for example has its DT-LACP implementation very close to regular static LACP in terms of configuration: you just have to assign trunk group (which is also used as LAG name) and specify protocol - but will limit you to exactly two devices; meanwhile, other vendors (like MikroTik) require ID, mode, name and peer port - while permitting more complex topologies.

If your use case cover the latter, then virtual chassis approach will fail (one device cannot be member of two virtual chassis).

@enkidu commented on GitHub (Apr 10, 2025): @PieterL75 not really. M(C)LAG forms some reduced kind of virtuall chassis "as seen by connected device" (especially for DT-LACP). In case of HP this is actually limited subset of IRF.VSX, which would fall under "true virtual chassis" is even more complicated: it forms common backplane for L2 but it does not for L3. Netbox Virtual Chassis allows you to use multiple management IPs - this is exactly how I did the case you are struggling with: ![Image](https://github.com/user-attachments/assets/77568f1d-b053-4f6e-aebb-c7d84c240a41) There is no shared IP (both member switches have distinct IP): ![Image](https://github.com/user-attachments/assets/edd55d49-d3d3-4dad-b096-708fad59ebe2) There is no need to designate any device as master. Only drawback: LAG interface will be listed only on one device, but member ports will have it assigned - relation to another device is clearly seen: ![Image](https://github.com/user-attachments/assets/628fda5f-a6e9-4ffb-bb0e-32302e17ea51) Vendor-specific settings can be implemented via Custom Fields, however you cannot filter for interface type when diplaying them. HP for example has its DT-LACP implementation very close to regular static LACP in terms of configuration: you just have to assign trunk group (which is also used as LAG name) and specify protocol - but will limit you to exactly two devices; meanwhile, other vendors (like MikroTik) require ID, mode, name and peer port - while permitting more complex topologies. If your use case cover the latter, then virtual chassis approach will fail (one device cannot be member of two virtual chassis).

adam commented

@jeremystretch commented on GitHub (Apr 10, 2025):

An MLAG is NOT a Virtual Chassis.

Agreed. A virtual chassis is formed by multiple devices sharing common control & management planes. Multi-chassis LAG is formed between two (or more?) independently managed nodes which coordinate to appear as a single entity to the far end of the LAG.

@jeremystretch commented on GitHub (Apr 10, 2025): > An MLAG is NOT a Virtual Chassis. Agreed. A virtual chassis is formed by multiple devices sharing common control & management planes. Multi-chassis LAG is formed between two (or more?) independently managed nodes which coordinate to appear as a single entity to the far end of the LAG.

adam commented

@MarlonSieker commented on GitHub (May 9, 2025):

I see two possible ways to model a Multi-Homing ESI-LAG (MLAG).

One way is to add a type and make it possible to select more than one device and display the interface (and subinterfaces) on all devices like interfaces in a virtual chassis.

The other way is that the MLAG has its own menu under device components.

Both options ensure that you can create MLAGs without virtual chassis and spread them across as many devices as you like.

@MarlonSieker commented on GitHub (May 9, 2025): I see two possible ways to model a Multi-Homing ESI-LAG (MLAG). One way is to add a type and make it possible to select more than one device and display the interface (and subinterfaces) on all devices like interfaces in a virtual chassis. ![Image](https://github.com/user-attachments/assets/9afe31cc-d257-4230-a404-30d2ed39643a) The other way is that the MLAG has its own menu under device components. ![Image](https://github.com/user-attachments/assets/b0e3b228-ca92-43cf-936d-5cc5e41dca0f) Both options ensure that you can create MLAGs without virtual chassis and spread them across as many devices as you like.

adam commented

@jhammond-git commented on GitHub (May 9, 2025):

Would it be reasonable to just have a field for "MLAG Peer" or something at the device level so you wouldn't have to continually choose the second device? Set MLAG Peer on a device (assigns peer's ID on both devices), then when creating a LAG, having an option for MLAG ID (if peer ID is set), which could be a select from existing ID's on local/peer or create new. I think that would allow the bare minimum of functionality without adding a new model.

@jhammond-git commented on GitHub (May 9, 2025): Would it be reasonable to just have a field for "MLAG Peer" or something at the device level so you wouldn't have to continually choose the second device? Set MLAG Peer on a device (assigns peer's ID on both devices), then when creating a LAG, having an option for MLAG ID (if peer ID is set), which could be a select from existing ID's on local/peer or create new. I think that would allow the bare minimum of functionality without adding a new model.

adam commented