Virtual interfaces part of a LAG

662 views
Skip to first unread message

xav....@gmail.com

unread,
Jul 2, 2021, 7:58:40 AM7/2/21
to NetBox
Currently, NetBox does not allow virtual interfaces to be part of a LAG.

This is however a reality with things like Blade servers where the blade servers' individual physical interfaces are infact virtual in that there are no physical cables connected.

So I'm wondering how people manage this. Up till now, I've created interfaces as 10GbE ones (as that's the closest to reality) and then created a LAG to which I can then attached these interfaces.

In a way, it's just cosmetic as the buttons appear to create a cable and do a cable trace, both of which do not exist for interfaces on blade servers.

The best solution I can think of is to allow Virtual interfaces to be part of a LAG. But maybe this would break the data model or is not possible (which is why it hasn't been implemented), I don't know...

xav....@gmail.com

unread,
Jul 2, 2021, 8:14:46 AM7/2/21
to NetBox
I guess the workaround to this is to use Parent instead of LAG as that allows everything to remain virtual ?

Brian Candler

unread,
Jul 2, 2021, 9:05:27 AM7/2/21
to NetBox
I presume that in reality, the blade has two physical interfaces (say "eth0" and "eth1") which go into an internal switch in the chassis. On the blade you're combining eth0 and eth1 into a LAG (say "bond0").  The chassis internal switch is also connected to some physical external port (or ports) presented on the outside of the chassis.

You can, if you want, model this exactly.  That is: you can put interfaces on the chassis, some facing the blades, and some facing the outside world.  Then you can put interfaces on the blades, and you can connect those to the chassis with internal "cables". That sounds like excessive work, although if the internal switch is manageable it might be worth it.

It is simpler to ignore the internal switch.  In that case, you will have external ports on the chassis which connect upstream, but there will be no association between any interfaces on the blades and interfaces on the chassis (because the blades are different "devices" in Netbox anyway).  It would be implied by IP subnet / VLAN.

As a compromise, what I suggest is that you model eth0 and eth1 as real physical interfaces on the blade (because they *are* real interfaces), and simply not connect them to anything: Netbox 2.11 has an interface flag to "mark connected" without having to insert a cable.  Then you can make a LAG which combines eth0 and eth1, which is what you wanted in the first place, and is accurate from the blade's point of view.

If you go entirely with "virtual" interfaces, then you can do what you like. You can just have a virtual "bond0" and nothing more.  You can have a virtual "bond0", "eth0" and "eth1".  However you can't have an interface with multiple parents, and bond0's parents should be both eth0 and eth1 - the parent being the interface that gets you "closer to the outside world".  If you want to do it backwards (eth0's parent is bond0, eth1's parent is bond0), then Netbox won't complain, although I would argue it's not really accurate.  But equally it's not really accurate that eth0 and eth1 are virtual, as they are real physical interfaces with electronics.

xav....@gmail.com

unread,
Jul 4, 2021, 6:11:58 AM7/4/21
to NetBox
Hi Brian,

Thank you for the comprehensive reply.

The HP c-class blade server is a strange beast in that the servers do have twin 10Gb NICs, but, depending on how the "Virtual Connect" switch inside the chassis is configured, the server's NICs can be split into multiple NICs (up to 4, sharing the 10Gb bandwidth which can even be user-selectable). Of course, the signal path is a real thing from the blade's NICs to the VC's internal ports, but they are fixed copper tracks. So modelling this (although possible of course) is rather complex and ultimately, unnecessary in my opinion. The only cable tracing / routing that's of interest is the physical one outside of the chassis to the upstream network switches / patch panels / interfaces. And as the Virtual Connect module is a kind of switch, it's not a simple pass-through device meaning modelling a path from the server's NICs to something physical outside isn't really feasible.

I might just keep the server's interfaces in NetBox as physical NICs so I can have them linked to a LAG but mark them as connected even if the "cable" hasn't been created inside NetBox.

Thanks!
Reply all
Reply to author
Forward
0 new messages