Parent/child relationship for subinterfaces

[candlerb]

Issue type

[X] Feature request
[ ] Bug report
[ ] Documentation

Environment

• Python version: 3.5.2
• NetBox version: v2.2-beta1

Description

Currently there is limited functionality for associating an interface with a parent interface:

• The parent must be of type LAG
• The child must be a physical interface

However there is another type of parent-child relationship which would be helpful to model:

• The parent is a physical or virtual interface, e.g. Gi0/1 or eth0
• The child is a virtual VLAN subinterface, e.g. Gi0/1.100 or eth0.100

Workaround: create standalone virtual interfaces, and use name prefix matching to associate them implicitly with the parent.

[jeremystretch]

Explicitly modeling the relationship is probably unnecessary. As you mention, subinterfaces usually (always?) take the form of <parent>.<id>: Simple regex validation would probably suffice. But what would we do with this information? How would it be presented?

[candlerb]

I was thinking nesting: children always displayed underneath parent, perhaps indented.

However if the interface names are sorted ASCII-wise then it should already be the case that children are displayed under parents.

[Bill-Irvine]

I'd be interested in this feature.
It would be great to be able to expand / collapse the sub-interfaces of each interface, it would considerably tidy up he interfaces view.

[InsaneSplash]

And it would also help to order them correctly.

[gandasi]

I'd be interested in allowing virtual interfaces to have parent lags as well for the following type of scenario (although I am also open to being told to structure things differently)

In my use case I have a storage array (device) providing NFS storage. The array has multiple physical 10GbE connections - for arguments sake, say eth 0-7.
I can create a LAG1 with eth0-3 and LAG2 with eth 4-7. On the device I can then create multiple virtual interfaces, each of which has an IP address associated with it, and these are associated with one of the 2 LAGs. Each virtual IP could be on a different vlan.

While I can model the physical characteristics of this currently, in order to track the associated IPs (for the NFS traffic), it feels unsatisfying to be unable to associate them with the physical parent LAG

[c0dyhi11]

Hello,

I believe I would also like this feature (Unless I'm missing something).
My use case is quite simple:
1x Server
2x Nics (eth0 & eth1)
Nics go into 1x LACP bond0
4x vLan interfaces are created off of that bond0

I'd like to be able to choose the virtual interface option and then optionally choose the vLan associated with that virtual interface.

But if there is a better way to do this bookkeeping I'm all ears.

Thanks!
Cody Hill

[candlerb]

I was the OP for this feature request, and I've come around to the idea that actually Netbox does it quite well :-)

To start with: Netbox's primary job is to model the physical infrastructure, so you tell it:

• eth0 connects to switch foo port bar
• eth1 connects to switch baz port quz

Next, you can create a virtual LAG interface, let's say "bond0", with children eth0 and eth1. So far so good.

You can then create pure virtual interfaces "bond0.100", "bond0.101", "bond0.102", "bond0.103", and assign to them the IP addresses you are using on each VLAN. That works fine too.

What you don't have is:

1. An explicit link between the bond0 LAG interface, and the bond0.xxx VLAN subinterfaces. But it's kind-of obvious from the naming convention. It would be cool if interface foo.N was displayed nested under interface foo

2. An explicit link from the bond0.100 interface to VLAN 100, which in fact could be one of several different VLAN 100's you may have in your infrastructure (Netbox lets you create multiple VLANs using the same tag). But there is an implicit binding, because bond0.100 has an IP address, and the IP address belongs to a prefix, and the prefix is associated with a VLAN.

This is actually the same as for a regular interface. If you give interface eth0 an address, say 192.168.5.5/24, and let's say eth0 is plugged into switch1 port ge2, you are not saying which VLAN that interface is using; you can't currently tell Netbox that switch1 port ge2 is an access port on vlan 5.

But you can associate VLAN 5 with the prefix 192.168.5.0/24, and therefore you get an interface - prefix - VLAN association. Hence you know that eth0 must be on VLAN 5 somehow. Whether it's tagged or untagged is not recorded, at either the switch end or the server end.

In some ways, this is quite elegant. Entering data into Netbox is manual enough as it is, without having to say for every switch port which VLAN(s) are carried over that cable. But by knowing which prefix(es) are present on an interface, it implies which VLAN(s) must be present there. You can work out how your switch ports should be configured.

If you had to label each port and/or cable as carrying VLANs W, X, Y tagged and Z untagged, it sounds like a huge amount of data entry work - and may not actually add much value.

There is one case I can think of which is hard to model at the moment, and that's associating virtual machine interfaces to physical ports (or LAGs). Suppose you knew that VMs A, B and C were bridged to port eth0, and VMs D, E and F bridged to port eth1. Using the information about the IP allocations on each VM, you could work out which VLANs needed to be present on each port. But this internal bridging is not modelled. I think there might have been a separate feature request for that somewhere.

[gandasi]

Hi Brian

Thanks for the reply and input, it's very helpful to hear how others are approaching things. You're probably right that I am overthinking things a little. I imagine in the large environment that Netbox has been created for, infrastructure teams are only concerned with the physical connectivity, so it makes sense that it works this way.

[devpets]

Hello,
Would be great to include parent device LAG interface selection in child "device bay" module.
For instance LAG members are ports from on-board and from module.

Wouldn't it make sense for the sub-interface to get created automatically as soon as an interface is put into "802.1Q Encapsulation" "Tagged" or "Access" mode (from netbox 2.3.0, currently in beta2 state), for every Untagged and Tagged VLAN that is added to it? Since one device can have multiple interfaces assigned to the same VLAN, the newly created virtual VLAN interface should only get created once, despite of many interfaces being in that VLAN. Also the VLAN interface should be by default disabled, since on switches you might not want to put an IP onto it.

Regarding ordering: I'm not sure putting it underneath the parent interface makes much sense, out of that same reason, the device could have multiple interfaces in the same VLAN, and this VLAN interface will contain logically on this device the same set of IP addresses. Might make more sense to have a new column on the interface overview in the device, which contains a drop down list, which contains hyperlinks for every VLAN assigned to it. That hyperlink jumps to the VLAN interface description.

This approach would be consistent with the way parent LAGs have their own column. Also, the child VLAN interface should inherit that LAG tag in the LAG column. Similarly, it wouldn't hurt to add the drop down list with all the VLAN hyperlinks to all the interfaces that make up the LAG.

This seems to be a missing feature of 2.3.0-beta2 anyway, I can't see a place where the information I enter into interfaces about "802.1Q Encapsulation" is actually utilized or presented elsewhere (but might miss something here).