Mapping of a Multi Chassis link aggregation (MLAG)(Cisco vPC) across different devices

[jcralbino]

I believe that this is a common questions that occurs for Multi Chassis Link Aggregation technologies. In this cases we have two separate independent switches, that are not part of a virtual chassis, and that can have an interface aggregation. What in netbox is considered a LAG.

In ACI we create a vPC domain where two switches can create a link aggregation. This vPC link is then shared in two different switch devices.

When configuration a LAG interface in Netbox this is limited to the device where the LAG is created. How can we model this association in netbox where a LAG interface is associated with two separate devices?

Is there any who has experience with this, and can detail the best practice to model a vPC in netbox?

Thanks in advance.

[julianze]

We are using Multichassis-LACP with Cisco ASR920. So i am really interesting if there is a solution for or maybe an feature could be planned.

[jcralbino]

I was able to find this information related to this:

2830 Opened in Jan 30, 2019.
5916 Opened in Mar 3,2021 and set as duplicate of 2830
3033 Opened in Apr 1, 2019 with same requirements

From here the main conclusion i took is resumed bellow:
"
To model multichassis LAG, you'll need to create the LAG interface with the same name/ID on both switches. There isn't really anything else for NetBox to model: The multichassis functionality is accomplished by proprietary hacks performed on the forwarding plane, which vary in their implementation among platforms and are out of scope for NetBox.
"
Although i understand this as possible solution, use the name/ID on both switches, I would prefer to use the same LAG object that will identify the all interfaces associated with this aggregation.

In order to make that happen, and considering my basic understanding on netbox where a LAG object is associated with one device only, and that this LAG object is composed by the interfaces associated with that device.

If we want to support MC-LAG, we would need to create a separate LAG object that is not related with a physical device, and only with the interface id that is used to compose this LAG Object.

Could this be considered a valid feature, the creation of another object MC-LAG, device independent, that can be associated with interfaces of different devices?

[candlerb]

I think you're Doing It Wrong™. The following works for me (v2.11.2):

1. Create testsw1 and testsw2 (of any device type which has interfaces: I used Netgear GS724Tv4, which has 26 interfaces, g1..26)
2. Bulk rename g to g1/ on testsw1, and g to g2/ on testsw2
3. Create a virtual chassis name "testsw", members testsw1 and testsw2 (members selected in the virtual chassis creation page). This puts them in positions 1 and 2
4. Edit the virtual chassis and select testsw1 as "master"
5. Go to testsw1 and look at the interfaces tab. Notice that all 52 interfaces are shown: g1/1..26 and g2/1..26, as if this were one switch
6. Add interface, name lag1, type LAG
7. Edit interface g1/1, set LAG to lag1
8. Edit interface g2/1, set LAG to lag1

Note that in step 8, I was still working on the master device (testsw1). The interface g2/1 is physically on box testsw2, but logically it now belongs to testsw1, the chassis master.

Doing it this way, making a LAG between two ports on the two different boxes works fine.

[jcralbino]

I have 2.11.0 and this was not working.
I will upgrade and test it again.

In the scenario where i actual want to model a vPC across two independent switches (MLAG peers) i wanted to avoid renaming the interfaces. Is this renaming mandatory to make it work?

[candlerb]

Netbox does not permit LAGs between independent switches: they must be part of a virtual chassis. That means a single control plane, single primary ip etc.

If you have not renamed interfaces, a virtual chassis becomes extremely confusing to use: you'll see multiple interfaces with the same name, and it's not easy to distinguish which belongs to which physical switch.

[jcralbino]

What i have seen is that if you do not select a master, then the first device will not have the multiple interfaces. Meaning it will not take over the interfaces of the other nodes as their own.

Now this is what i tested in 2.11.2

1. Create a switch Leaf_101

2. Create a switch Leaf_102S

3. Create a virtual chassis (vPC_Domain_2)
   

4. create a LAG interface ( vPC_Port1) in Leaf_101

5. associate Ethernet1/1 with this interface (vPC_Port1) in Leaf 101
   

6. associate Ethernet1/1 with this interface (vPC_Port1) in Leaf 102
   

This is enough for me to model this setup.
The main point, is that if i do not select a master in a virtual chassis i am able to maintain the interfaces names, and still use the virtual interface for a LAG across two devices.

[jcralbino]

the problem i have this now is that when adding cables it seems we have a duplicate names, and i get this error. For example when using Leaf_101 and Ethernet1/1 on termination B.
"msg": "More than one result returned for termination_b"

But that seems related with this bug
#6312

[jcralbino]

I have upgraded and the behavior i have now in v2.11.3 , is the following:

• Create 1 a virtual chassis: stack-1-withoutmaster

• Create first switch: stack1-sw1

• Create second switch: stack1-sw2

• Associate them to the stack-1-withoutmaster

• As i do not associate a master both switches have only their own interfaces

• Create Link Aggregation type (lag-stack1-port1) in stack1-sw1

• Associate lag-stack-port1 to stack1-sw1 interface e1/1

  What i expected is that i would be able to associate this on stack1-sw2.
  But this is not possible now in 2.11.3 , It was possible in 2.11.2

I tested also this:

• Create 1 a virtual chassis: stack-2-withmaster
• Create first switch: stack2-sw1
• Create second switch: stack2-sw2
• Associate them to the stack-2-withmaster
• Associate a master on sw1. I see all interfaces moved there.
• Rename the interfaces in stack2-sw2 to e2/x
• Create Link Aggregation type (lag-stack2-port1) in stack2-sw1
• I can associate this on interface e1/1 in stack2-sw1.
• I cannot associate this on interface e2/1 in stack2-sw2.

What i expected is that i would be able to associate this on stack2-sw2.
But this is not possible now in 2.11.3 , It was possible in 2.11.2

@candlerb can you confirm that this is a bug?

[jcralbino]

is it related with #6426

[candlerb]

See discussion #6409

I think change #6312 broke this in v2.11.3

[jcralbino]

I have upgraded and the behavior i have now in v2.11.4 , is the following:

Created 1 a virtual chassis: stack-1-withoutmaster

Create first switch: stack1-sw1

Create second switch: stack1-sw2

Associate them to the stack-1-withoutmaster

As i do not associate a master both switches have only their own interfaces

Create Link Aggregation type (lag-stack1-port1) in stack1-sw1

Associate lag-stack-port1 to stack1-sw1 interface e1/1

What i expected is that i would be able to associate this (lag-stack1-port1) on stack1-sw2.
But this is not possible now in 2.11.4 , It was possible in 2.11.2

@candlerb , can you confirm that this should have work?

[candlerb]

I have never tested without master, and I really don't know if it's supposed to work without master. Why don't you want to set one of the switches as master?

[jcralbino]

This was working in 2.11.2. I do not want to associate a master as I do not want to change the name of interfaces of the second node.
In this case this is how the stack is built

[candlerb]

OK, then open a bug report on github, giving the exact sequence of steps to replicate.

[afics]

I have just hit this in v2.11.12. @jcralbino did you open a bug report?

[jcralbino]

Yes , it's here

#6531

[nickper]

I see this issues is running for a while. And I am with jcralbino.
In my case I have Arista switches which can use MLAG which we use extensively in our DC.
In my oppinion there is no real master, and we sometimes run both mlag port-channels and redundant BGP sessions which cause the config to not be the same on both devices.
There is no real master, and automation would be more difficult if I have to rename the ports on both switches.

The current implementation of virtual chassis is mostly focused on Stack switches, which do indeed have the master node, and unique interface names, but it would be nice to also be able to correctly represent a redundant switch pair as is the case in the increasingly popular leaf-spine networks.

It would therefore be nice to re-evaluate the earlier decision.
To my opinion only sharing the LAG interfaces between the devices within a virtual Chassis would be sufficient.

I'm currently running 3.1.9 and will soon test 3.3.10, but so far nothing has changed.

[ronnyaa]

we have the same issue as @nickper. but using dell OS10 switches with vlt (mc-lag) configuration. but only some ports are like this. others can be regular port. or router ports. so having a consistent way to define a mc-lag would be great.

[DanSheps]

I think a transition to a more robust model for vPC/MC-LAG might be needed beyond the Virtual Chassis model IMO.

[pv2b]

I ran into this use case myself, i.e. mapping a VPC (Virtual Port Channel), which is a Cisco implementation of the MLAG concept into Netbox.

What I ended up doing was creating the LAG interfaces on each switch. (To clarify, that could mean a LAG with a single member.)

To then mark those LAG interfaces as belonging to a VPC, I created the custom string fields vpc_domain_id and vpc_interface_id, belonging to the Interface object. Then, representing them as being a member of that VPC you just have to populate those fields. That should be enough to generate config in future, should we decide to go that route.

Finally, in order to easilly be able to find related LAGs in the UI, I added a custom link to Netbox like this:

Link text:

{% if object.cf.vpc_domain_id and object.cf.vpc_interface_id %}
Find VPC Members
{% endif %}

Link URL:

/dcim/interfaces/?cf_vpc_domain_id={{ object.cf.vpc_domain_id|e }}&cf_vpc_interface_id={{ object.cf.vpc_interface_id|e }}

That way, when I click on a LAG, I can see the button "Find VPC Members" if the LAG is part of a VPC (or MLAG) configuration, and clicking that button will bring up all interfaces with the same VPC Domain and Member ID (i.e. part of the same MLAG).

(The button only shows up when both fields are populated so the UI isn't cluttered for most other interfaces.)

It's not perfect by any stretch, I'd much rather be able to create a first-class Netbox object representing a VPC / MLAG, but it's fully functional if not pretty.

[pv2b]

I ended up writing an MC-LAG plugin to Netbox, as a learning exercise. The plugin adds models for Multi-Chassis Domains (similar to a "Virtual Chassis", but without all that implies) and a Multi-Chassis Group that allows the user to bundle together multiple LAG interfaces on different switches.

It's a little rough around the edges, and I've not yet tried it on any real data, but for anyone who's looking to model MC-LAG, this might be one way to do it.

I hope someone finds this useful: https://github.com/pv2b/netbox-plugin-mclag - My particular itch is just being able to document these kinds of links in a fairly understandable way in the GUI, and also validate that the model allows for configuration generation if we choose to go that route in the future.