Parent/child relationship for subinterfaces #1253

@jeremystretch commented on GitHub (Sep 20, 2017):

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?

@jeremystretch commented on GitHub (Sep 20, 2017): 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?

adam commented

@candlerb commented on GitHub (Sep 20, 2017):

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.

@candlerb commented on GitHub (Sep 20, 2017): 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.

adam commented

@Bill-Irvine commented on GitHub (Sep 22, 2017):

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.

@Bill-Irvine commented on GitHub (Sep 22, 2017): 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.

adam commented

@InsaneSplash commented on GitHub (Oct 4, 2017):

And it would also help to order them correctly.

@InsaneSplash commented on GitHub (Oct 4, 2017): And it would also help to order them correctly.

adam commented

@gandasi commented on GitHub (Dec 18, 2017):

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

@gandasi commented on GitHub (Dec 18, 2017): 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

adam commented

@c0dyhi11 commented on GitHub (Dec 19, 2017):

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

@c0dyhi11 commented on GitHub (Dec 19, 2017): 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

adam commented

2025-12-29 16:30:44 +01:00

@candlerb commented on GitHub (Dec 19, 2017):

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:

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
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.

@candlerb commented on GitHub (Dec 19, 2017): 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.

adam commented

@gandasi commented on GitHub (Dec 20, 2017):

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.

@gandasi commented on GitHub (Dec 20, 2017): 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.

adam commented

@devpets commented on GitHub (Feb 14, 2018):

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.

@devpets commented on GitHub (Feb 14, 2018): 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.

adam commented

@ghost commented on GitHub (Feb 26, 2018):

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).

@ghost commented on GitHub (Feb 26, 2018): 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).

adam commented

@onemorepash commented on GitHub (Jun 18, 2018):

@candlerb Could you please elaborate the following a bit?

(Netbox lets you create multiple VLANs using the same tag)

But how? ;) Basically whether I miss something, or it's not the case.

For me it's a kind of showstopper of the current NetBox model that it does not distinguish VLAN as a broadcast domain and VLAN as an interfaces dot1Q tag, so you can't have a VLAN foo which is tagged 500 on one side, 600 on another and Q-in-Q 555/666 on the third. Kind of C6500 ;)

I would be happy if I miss something. So please correct me if I am wrong.

@onemorepash commented on GitHub (Jun 18, 2018): @candlerb Could you please elaborate the following a bit? >(Netbox lets you create multiple VLANs using the same tag) But how? ;) Basically whether I miss something, or it's not the case. For me it's a kind of showstopper of the current NetBox model that it does not distinguish VLAN as a broadcast domain and VLAN as an interfaces dot1Q tag, so you can't have a VLAN foo which is tagged 500 on one side, 600 on another and Q-in-Q 555/666 on the third. Kind of C6500 ;) I would be happy if I miss something. So please correct me if I am wrong.

adam commented

@candlerb commented on GitHub (Jun 18, 2018):

But how? ;)

Simple: create a VLAN with tag 123 (the GUI confusingly calls this "ID"). Then create another VLAN with tag 123. They are two separate VLAN objects with their own database ids.

it does not distinguish VLAN as a broadcast domain and VLAN as an interfaces dot1Q tag, so you can't have a VLAN foo which is tagged 500 on one side, 600 on another

That is true: a VLAN in the Netbox model has only one tag. And there's no Q-in-Q either.

@candlerb commented on GitHub (Jun 18, 2018): > But how? ;) Simple: create a VLAN with tag 123 (the GUI confusingly calls this "ID"). Then create another VLAN with tag 123. They are two separate VLAN objects with their own database ids. > it does not distinguish VLAN as a broadcast domain and VLAN as an interfaces dot1Q tag, so you can't have a VLAN foo which is tagged 500 on one side, 600 on another That is true: a VLAN in the Netbox model has only one tag. And there's no Q-in-Q either.

adam commented

@onemorepash commented on GitHub (Jun 22, 2018):

@candlerb Yep, my bad for the VLANs with the same ID. I've tested, it's possible but not when VLANs are in a group. This is why I got "VLAN with this Group and ID already exists" when I tested before. And it's a bit strange, I would say, to have a different behavior in a group. Thanks anyway ;)

That is true: a VLAN in the Netbox model has only one tag. And there's no Q-in-Q either.

I would say that it's not a problem per se. The problem is rather the model where VLAN as a broadcast domain and VLAN as a tag is the same thing.

In fact 802.1Q tag is not an attribute of a VLAN, it's an attribute of a VLAN to physical port association. So it can be assigned whether globally on the VLAN (default tag used on all ports) or, like most modern switches/routers allow to do, per VLAN-subinterface (doesn't exist in NetBox). I would also appreciate a possibility to not have any default VLAN ID at all.

So my actual workflow is to create interfaces like xe-0/0/0.100, make them tagged and configure a VLAN tag on top of it for L3 p2p interconnections or assign a VLAN. This resembles more or less the Juniper MX model. You don't need to maintain all possible combinations at the VLAN (aka bridge domain) level, instead the sub-interface aka unit is king: it can derive the default VLAN tag from the VLAN configuration or have it's own one or be Q-in-Q tagged or something fancier.

The only problem is that there is no way to automatically associate such interface with it's parent physical interface like xe-0/0/0.100 -> xe-0/0/0. They are independent from the NetBox point of view. Just like @jeremystretch proposed above.

Interfaces names parsing works but it's a kind of workaround. You can't simply say that in front of Device A ge-0/0/0.100 you have Device B Gi0/10/2.200.

@onemorepash commented on GitHub (Jun 22, 2018): @candlerb Yep, my bad for the VLANs with the same ID. I've tested, it's possible but not when VLANs are in a group. This is why I got "VLAN with this Group and ID already exists" when I tested before. And it's a bit strange, I would say, to have a different behavior in a group. Thanks anyway ;) >That is true: a VLAN in the Netbox model has only one tag. And there's no Q-in-Q either. I would say that it's not a problem per se. The problem is rather the model where VLAN as a broadcast domain and VLAN as a tag is the same thing. In fact 802.1Q tag is not an attribute of a VLAN, it's an attribute of a VLAN to physical port association. So it can be assigned whether globally on the VLAN (default tag used on all ports) or, like most modern switches/routers allow to do, per VLAN-subinterface (doesn't exist in NetBox). I would also appreciate a possibility to not have any default VLAN ID at all. So my actual workflow is to create interfaces like xe-0/0/0.100, make them tagged and configure a VLAN tag on top of it for L3 p2p interconnections or assign a VLAN. This resembles more or less the Juniper MX model. You don't need to maintain all possible combinations at the VLAN (aka bridge domain) level, instead the sub-interface aka unit is king: it can derive the default VLAN tag from the VLAN configuration or have it's own one or be Q-in-Q tagged or something fancier. The only problem is that there is no way to automatically associate such interface with it's parent physical interface like xe-0/0/0.100 -> xe-0/0/0. They are independent from the NetBox point of view. Just like @jeremystretch proposed above. Interfaces names parsing works but it's a kind of workaround. You can't simply say that in front of Device A ge-0/0/0.100 you have Device B Gi0/10/2.200.

adam commented

@robje commented on GitHub (Apr 23, 2019):

subinterfaces usually (always?) take the form of <parent>.<id>

This is mostly true except there is no 1:1 relation between ID en vlan ID.

Valid cisco config:

int g0/0.123
 encapsulation dot1Q 321

Valid netiron conf

vlan 321 name "test"
 router-interface ve 123

@robje commented on GitHub (Apr 23, 2019): > subinterfaces usually (always?) take the form of `<parent>.<id>` This is mostly true except there is no 1:1 relation between ID en vlan ID. Valid cisco config: ``` int g0/0.123 encapsulation dot1Q 321 ``` Valid netiron conf ``` vlan 321 name "test" router-interface ve 123 ```

adam commented

@onemorepash commented on GitHub (Apr 25, 2019):

@robje

I think you wanted to say the following for the Netiron case (L3 attachment point doesn't really matter for the previous discussion):

vlan 321 name "foobar"
  tagged Ethernet1/2

I. e. adding an interface to a VLAN, not a VLAN to an interface. Yes, the fine NetIron software can only do like this, agree. You can also have this type of configurations on other platforms which support both styles (e. g. JUNOS).

But it doesn't matter. Logical unit (subinterface) might exist in the router config or not, what matters is that the following:

— Service attachement circuit (unit in Juniper speak, subinterface in Cisco speak, SAP in Alcatel Speak etc etc — yes, you might not have it in the configuration)
— VLAN dot1q TAG
— Broadcast domain

These 3 things are not the same thing. They should be represented by three different objects. If the router has no special name for the attachment circuit, I don't really care, as fare as I can do the following:

— Create an object of type "subinterface/unit" and give it an arbitrary name. Like "Ethernet1/2, vlan123" if we follow the aforementioned NetIron config example
— Associate it with a dot1q tag 123 (in fact it can be other kind of L2 circuit ID, e. g. pair of q-in-q tags, L2VNI, whatever)
— Associated the object "Ethernet1/2, vlan123" with a broadcast domain object called "VLAN foobar".

Than, if you want to add IP, you can either attach an address to the interface-unit object "Ethernet1/2, vlan123" (directly on the subinterface) or create another interface-unit object called "ve123", attach it to the broadcast domain, and set an IP address on top of it (aka Cisco SVI / Juniper RVI).

@onemorepash commented on GitHub (Apr 25, 2019): @robje I think you wanted to say the following for the Netiron case (L3 attachment point doesn't really matter for the previous discussion): ``` vlan 321 name "foobar" tagged Ethernet1/2 ``` I. e. adding an interface to a VLAN, not a VLAN to an interface. Yes, the fine NetIron software can only do like this, agree. You can also have this type of configurations on other platforms which support both styles (e. g. JUNOS). But it doesn't matter. Logical unit (subinterface) might exist in the router config or not, what matters is that the following: — Service attachement circuit (unit in Juniper speak, subinterface in Cisco speak, SAP in Alcatel Speak etc etc — yes, you might not have it in the configuration) — VLAN dot1q TAG — Broadcast domain These 3 things are not the same thing. They should be represented by three different objects. If the router has no special name for the attachment circuit, I don't really care, as fare as I can do the following: — Create an object of type "subinterface/unit" and give it an arbitrary name. Like "Ethernet1/2, vlan123" if we follow the aforementioned NetIron config example — Associate it with a dot1q tag 123 (in fact it can be other kind of L2 circuit ID, e. g. pair of q-in-q tags, L2VNI, whatever) — Associated the object "Ethernet1/2, vlan123" with a broadcast domain object called "VLAN foobar". Than, if you want to add IP, you can either attach an address to the interface-unit object "Ethernet1/2, vlan123" (directly on the subinterface) or create another interface-unit object called "ve123", attach it to the broadcast domain, and set an IP address on top of it (aka Cisco SVI / Juniper RVI).

adam commented

@steffann commented on GitHub (Jun 18, 2019):

Would it be useful to combine subinterfaces with breakout cables? Something roughly equivalent to seeing the parent port as the "rear" port and the subinterfaces as the "front" ports.

That would then also be a solution for the MPO cables and breakout boxes mentioned in https://github.com/digitalocean/netbox/issues/3193, and the use of breakout cables mentioned in https://github.com/digitalocean/netbox/issues/3018.

Edit: I first posted this as a comment under https://github.com/digitalocean/netbox/issues/3018, but that issue was about a validation bug, not a feature request…

@steffann commented on GitHub (Jun 18, 2019): Would it be useful to combine subinterfaces with breakout cables? Something roughly equivalent to seeing the parent port as the "rear" port and the subinterfaces as the "front" ports. That would then also be a solution for the MPO cables and breakout boxes mentioned in https://github.com/digitalocean/netbox/issues/3193, and the use of breakout cables mentioned in https://github.com/digitalocean/netbox/issues/3018. Edit: I first posted this as a comment under https://github.com/digitalocean/netbox/issues/3018, but that issue was about a validation bug, not a feature request…

adam commented

@clinta commented on GitHub (Jun 19, 2019):

subinterfaces usually (always?) take the form of <parent>.<id>

This is mostly true except there is no 1:1 relation between ID en vlan ID.

On linux the names of subinterfaces can be entirely arbitrary.

ip link add link eth1 name foobar type vlan id 100

@clinta commented on GitHub (Jun 19, 2019): > > subinterfaces usually (always?) take the form of `<parent>.<id>` > > This is mostly true except there is no 1:1 relation between ID en vlan ID. On linux the names of subinterfaces can be entirely arbitrary. `ip link add link eth1 name foobar type vlan id 100`

adam commented

@robje commented on GitHub (Jul 16, 2019):

I think you wanted to say the following for the Netiron case (L3 attachment point doesn't really matter for the previous discussion):

IMHO this issue is about relationship for VLAN subinterfaces or attachment point of L3 interfaces, hence the attachment point does matter. Though using examples 123 and 321 might have been confusing.

subinterfaces usually (always?) take the form of <parent>.<id>

This is mostly true except there is no 1:1 relation between ID en vlan ID.

Point and case is that a way to administer the relationship between the interface or VLAN and the subinterface is needed. Assuming there is a 1-to-1 relationship between subinterface ID and VLAN tag is incorrect.
It is perfectly valid to have subinterface ID 123 related with vlan tag 321

@robje commented on GitHub (Jul 16, 2019): > I think you wanted to say the following for the Netiron case (L3 attachment point doesn't really matter for the previous discussion): IMHO this issue is about relationship for VLAN subinterfaces or attachment point of L3 interfaces, hence the attachment point does matter. Though using examples 123 and 321 might have been confusing. > > subinterfaces usually (always?) take the form of `<parent>.<id>` > > This is mostly true except there is no 1:1 relation between ID en vlan ID. Point and case is that a way to administer the relationship between the interface or VLAN and the subinterface is needed. Assuming there is a 1-to-1 relationship between subinterface ID and VLAN tag is incorrect. It is perfectly valid to have subinterface ID 123 related with vlan tag 321

adam commented

@onemorepash commented on GitHub (Jul 23, 2019):

@robje

IMHO this issue is about relationship for VLAN subinterfaces or attachment point of L3 interfaces,

No, it's not. It's about the relationship between interfaces and subinterfaces (interface units), which is not really modelled in Netbox.

And the discussion is all about "what is a subinterface (interface unit)?" in its broad sence, so that it wouldn't be vendor dependent but compatible with the common usage and cover SP/DC-oriented use-cases.

My answer to this question is that an interface unit is a circuit attachment point, which associates a circuit, delivered to the physical port, with a set of services inside the device.

In the Ethernet worlds a circuit is a dot1q tag or a pair of Q-in-Q tags.

The services, which are attached to the interface unit (subinterface) can be:

broadcast domain (mac learning/loopkup table)
an L3 interface with IPv4/IPv6 addresses
a rate-limiter (aka policer)
ingress and egress ACL
many more.

So the relationship is:

physical-interface or LAG <--(1:N)--> interface unit <--(1:N)--> services

@onemorepash commented on GitHub (Jul 23, 2019): @robje >IMHO this issue is about relationship for VLAN subinterfaces or attachment point of L3 interfaces, No, it's not. It's about the relationship between interfaces and subinterfaces (interface units), which is not really modelled in Netbox. And the discussion is all about "what is a subinterface (interface unit)?" in its broad sence, so that it wouldn't be vendor dependent but compatible with the common usage and cover SP/DC-oriented use-cases. My answer to this question is that an interface unit is a circuit attachment point, which associates a circuit, delivered to the physical port, with a set of services inside the device. In the Ethernet worlds a circuit is a dot1q tag or a pair of Q-in-Q tags. The services, which are attached to the interface unit (subinterface) can be: - broadcast domain (mac learning/loopkup table) - an L3 interface with IPv4/IPv6 addresses - a rate-limiter (aka policer) - ingress and egress ACL - many more. So the relationship is: physical-interface or LAG <--(1:N)--> interface unit <--(1:N)--> services

adam commented

@jameno123 commented on GitHub (May 9, 2020):

If you have ever seen a fortigate's network interface configuration screen this would be nice to have modeled in the netbox ui the same way.

The subinterfaces (and vlans) are attached under the main interface and can be displayed the clicking on a [+] icon to the left of the interface and then it drops down, indented. Something like this would be nice. By default the subinterfaces are not displayed and you must click the [+] to expand them.

@jameno123 commented on GitHub (May 9, 2020): If you have ever seen a fortigate's network interface configuration screen this would be nice to have modeled in the netbox ui the same way. The subinterfaces (and vlans) are attached under the main interface and can be displayed the clicking on a [+] icon to the left of the interface and then it drops down, indented. Something like this would be nice. By default the subinterfaces are not displayed and you must click the [+] to expand them.

adam commented

@Xenia-Io commented on GitHub (Sep 25, 2020):

Sorry but I have a question just a step before we reach the point of creating parent-child relationship.. How do we understand who is the parent and who is the child ? Like is there a way to get all parents of the network in a list and then check their children ?

@Xenia-Io commented on GitHub (Sep 25, 2020): Sorry but I have a question just a step before we reach the point of creating parent-child relationship.. How do we understand who is the parent and who is the child ? Like is there a way to get all parents of the network in a list and then check their children ?

adam commented