Allow assigning of VLAN(s) to device ports #113

New Issue

adam · 2025-12-29T15:33:31+01:00

adam commented

2025-12-29 15:33:31 +01:00

Originally created by @justinhippen on GitHub (Jun 30, 2016).

It would be nice to be able to assign VLANs allocated to the device's site to it's ports

Originally created by @justinhippen on GitHub (Jun 30, 2016). It would be nice to be able to assign VLANs allocated to the device's site to it's ports

adam closed this issue

2025-12-29 15:33:31 +01:00

adam commented

2025-12-29 15:33:32 +01:00

@ryanmerolle commented on GitHub (Jun 30, 2016):

This would then have to be able to assign native/untagged vlans along with allowed/tagged vlans. This could get complicated, but is possible.

For those Cisco focused individuals, voice vlans would just be classified as a allowed/tagged vlans, and access ports would be assigned untagged/ native vlans.

@ryanmerolle commented on GitHub (Jun 30, 2016): This would then have to be able to assign native/untagged vlans along with allowed/tagged vlans. This could get complicated, but is possible. For those Cisco focused individuals, voice vlans would just be classified as a allowed/tagged vlans, and access ports would be assigned untagged/ native vlans.

adam commented

2025-12-29 15:33:32 +01:00

@cstueckrath commented on GitHub (Jul 20, 2016):

an interface would be either an access port (untagged vlan defaults to 1, but can be changed) or a trunk port. The trunk vlans might be configurable by either an "all" radio button or a text field, where you can enter ranges similar to this: [1-16], [20-26], 58, [65-70], 99, 901, 903, 919, 4095
the information on the interface could be displayed like this:
Tagging: enabled PVID: 1 VLANs:1-16 20-26 58 65-70 99 901 903 919 4095

@cstueckrath commented on GitHub (Jul 20, 2016): an interface would be either an access port (untagged vlan defaults to 1, but can be changed) or a trunk port. The trunk vlans might be configurable by either an "all" radio button or a text field, where you can enter ranges similar to this: [1-16], [20-26], 58, [65-70], 99, 901, 903, 919, 4095 the information on the interface could be displayed like this: Tagging: enabled PVID: 1 VLANs:1-16 20-26 58 65-70 99 901 903 919 4095

adam commented

2025-12-29 15:33:32 +01:00

@specialcircumstances commented on GitHub (Nov 6, 2016):

Just a thought, but it could be useful to maintain a record of VLANs associated (i.e. active) on a device. I guess a join table linking VLANs to Devices would be the way, or perhaps to interfaces, and the device count known through ORM.
That said, on consideration, it would be useful to have them seperate, and that could help with assigning VLANs to ports (as the list to select from could be the VLANs active on the device). I guess you'd need two join tables, one for VLANs-Devices and one for VLANS-Ports, but I think that would support many operations fairly neatly.
I could see this being useful when assigning IPs to devices that are dot1q connected, and also for the whole IP address assignment process, as once the VLAN is assigned to the port, the list of prefixes will be fairly short (drop-down box-able).
I will be happy to help out if you like (also being a net eng who has learnt python and django!) - but that will need to wait a couple of weeks!

@specialcircumstances commented on GitHub (Nov 6, 2016): Just a thought, but it could be useful to maintain a record of VLANs associated (i.e. active) on a device. I guess a join table linking VLANs to Devices would be the way, or perhaps to interfaces, and the device count known through ORM. That said, on consideration, it would be useful to have them seperate, and that could help with assigning VLANs to ports (as the list to select from could be the VLANs active on the device). I guess you'd need two join tables, one for VLANs-Devices and one for VLANS-Ports, but I think that would support many operations fairly neatly. I could see this being useful when assigning IPs to devices that are dot1q connected, and also for the whole IP address assignment process, as once the VLAN is assigned to the port, the list of prefixes will be fairly short (drop-down box-able). I will be happy to help out if you like (also being a net eng who has learnt python and django!) - but that will need to wait a couple of weeks!

adam commented

2025-12-29 15:33:32 +01:00

@Beiriz commented on GitHub (Dec 23, 2016):

This is very important for our PPPOE hubs. We use several VLANs linked to BRIDGES. They serve to aggregate customers by geographical areas and to facilitate the relocation of IP blocks between these equipments.Thank you :)

@Beiriz commented on GitHub (Dec 23, 2016): This is very important for our PPPOE hubs. We use several VLANs linked to BRIDGES. They serve to aggregate customers by geographical areas and to facilitate the relocation of IP blocks between these equipments.Thank you :)

adam commented

2025-12-29 15:33:33 +01:00

@InsaneSplash commented on GitHub (Jan 17, 2017):

I'd be interested in being able to assign a VLAN to a port, especially when one separates traffic on a port ie, voice and data or the customer requires multiple services over a single connection.

@InsaneSplash commented on GitHub (Jan 17, 2017): I'd be interested in being able to assign a VLAN to a port, especially when one separates traffic on a port ie, voice and data or the customer requires multiple services over a single connection.

adam commented

2025-12-29 15:33:33 +01:00

@lampwins commented on GitHub (Mar 13, 2017):

This is really blocking my use of netbox as a source of truth. I want to be able to provision devices based on what is in netbox and later to do compliance checks. VLAN port assignments are a crucial part of this.

@lampwins commented on GitHub (Mar 13, 2017): This is really blocking my use of netbox as a source of truth. I want to be able to provision devices based on what is in netbox and later to do compliance checks. VLAN port assignments are a crucial part of this.

adam commented

2025-12-29 15:33:34 +01:00

@InsaneSplash commented on GitHub (Mar 22, 2017):

What I have done to get around this is to create new vlan interfaces prefixed by the physical port and as a type Other. This allows me to see which port the vlan is attached to. Maybe oneday when we can link a vlan to a port, I will then modify the data in the Database using the current format to determine what goes where.

sfp1.vlan10

@InsaneSplash commented on GitHub (Mar 22, 2017): What I have done to get around this is to create new vlan interfaces prefixed by the physical port and as a type Other. This allows me to see which port the vlan is attached to. Maybe oneday when we can link a vlan to a port, I will then modify the data in the Database using the current format to determine what goes where. `sfp1.vlan10`

adam commented

2025-12-29 15:33:34 +01:00

@jeremystretch commented on GitHub (Mar 23, 2017):

We'll need to nail down the data model before any progress can be made on this. I'm open to suggestions. How would you define a relationship between an Interface and one or more VLANs?

@jeremystretch commented on GitHub (Mar 23, 2017): We'll need to nail down the data model before any progress can be made on this. I'm open to suggestions. How would you define a relationship between an `Interface` and one or more `VLANs`?

adam commented

2025-12-29 15:33:34 +01:00

@specialcircumstances commented on GitHub (Mar 23, 2017):

Here's one way to approach it without massive join tables...

Interface has foreign lookup to VLAN Group.
Interface has two additional attributes, native VLAN and VLAN Filter list.
Native VLAN is an integer (0-4095). It can be valid or not based on if the VLAN is active in the VLAN Group. A "null" could be not set.
VLAN filter list could be of the normal sort of format e.g. "2,3,4,5-17,32-100,54". Any VLAN in the VLAN Group and matching the filter would be active on the Interface.
Not great, OK. Bad idea.

Option 2, with join tables. Probably closer to realistic.

Interface has foreign lookup to VLAN Group, Interface rather than device because for example, a router could have trunk links to multiple VLAN domains, or a switch might have some form of internal partitioning (e.g. Cisco VDC). I guess there could be a default VLAN Group for the device, and if not otherwise set/overidden the VLAN Group on an interface would be the VLAN Group of the device.
Join table stores intersection between active VLANs and Interfaces. Guess it could get large though.

Interface would need a typing field I think, e.g. Routing (e.g. L3), Access (L2 Untagged), Tagged. VLAN association should probably be limited to 1 VLAN for Routing and Access, but many for Tagged. Some consideration here perhaps for the concept of native VLANS.

The model could be extended to MPLS or VXLAN VNI, or any other tagging technology, if the VLAN models were rewritten to a more generic Tagging type, with VLANs being just one sort of Tagged item (perhaps set by the Tagged Group they are a member of).

@specialcircumstances commented on GitHub (Mar 23, 2017): Here's one way to approach it without massive join tables... Interface has foreign lookup to VLAN Group. Interface has two additional attributes, native VLAN and VLAN Filter list. Native VLAN is an integer (0-4095). It can be valid or not based on if the VLAN is active in the VLAN Group. A "null" could be not set. VLAN filter list could be of the normal sort of format e.g. "2,3,4,5-17,32-100,54". Any VLAN in the VLAN Group and matching the filter would be active on the Interface. Not great, OK. Bad idea. Option 2, with join tables. Probably closer to realistic. Interface has foreign lookup to VLAN Group, Interface rather than device because for example, a router could have trunk links to multiple VLAN domains, or a switch might have some form of internal partitioning (e.g. Cisco VDC). I guess there could be a default VLAN Group for the device, and if not otherwise set/overidden the VLAN Group on an interface would be the VLAN Group of the device. Join table stores intersection between active VLANs and Interfaces. Guess it could get large though. Interface would need a typing field I think, e.g. Routing (e.g. L3), Access (L2 Untagged), Tagged. VLAN association should probably be limited to 1 VLAN for Routing and Access, but many for Tagged. Some consideration here perhaps for the concept of native VLANS. The model could be extended to MPLS or VXLAN VNI, or any other tagging technology, if the VLAN models were rewritten to a more generic Tagging type, with VLANs being just one sort of Tagged item (perhaps set by the Tagged Group they are a member of).

adam commented

2025-12-29 15:33:34 +01:00

@lampwins commented on GitHub (Jun 10, 2017):

My idea for this model is to allow a "VLAN Configuration" on a per interface level. Each dcim.Interface will have a 1-to-1 relationship to the new InterfaceVLANConfiguration model. This model contains an attribute for the native_vlan and a vlan_members attribute which is a many-to-many relationship to ipam.VLAN.

In the UI, the user adds this InterfaceVLANConfiguration model to an interface by clicking a new button next to the rest. They filter the vlans like today, by site/vlan group. They are allowed to add multiple vlans to the vlan members section though (I am not sure they is any sort of similar functionality in the UI today?).

At this point though, I am not sure if this new model should live in dcim or ipam for the purposes of where/how to define the API endpoints for this?

@jeremystretch thoughts on this? I am more than happy to work this out and submit a WIP PR if we can agree on the model.

@lampwins commented on GitHub (Jun 10, 2017): My idea for this model is to allow a "VLAN Configuration" on a per interface level. Each `dcim.Interface` will have a 1-to-1 relationship to the new `InterfaceVLANConfiguration` model. This model contains an attribute for the `native_vlan` and a `vlan_members` attribute which is a many-to-many relationship to `ipam.VLAN`. In the UI, the user adds this `InterfaceVLANConfiguration` model to an interface by clicking a new button next to the rest. They filter the vlans like today, by site/vlan group. They are allowed to add multiple vlans to the vlan members section though (I am not sure they is any sort of similar functionality in the UI today?). At this point though, I am not sure if this new model should live in dcim or ipam for the purposes of where/how to define the API endpoints for this? @jeremystretch thoughts on this? I am more than happy to work this out and submit a WIP PR if we can agree on the model.

adam commented

2025-12-29 15:33:35 +01:00

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

If you just want to keep a track of VLAN membership on a port, as a workaround you could create an interface of type "virtual" for each enabled VLAN.

GigabitEthernet0/1 type 1000BASE-T
GigabitEthernet0/1.100 type Virtual
GigabitEthernet0/1.101 type Virtual
... etc

This is after all how you would model a router with separate layer 3 subinterfaces, or a virtual machine which has different IP addresses on eth0.100 and eth0.101. It would however get tedious for many VLANs on many ports.

There is no explicit link from a virtual interface to its parent (apart from a physical interface to parent LAG), so it is only implied from the naming.

There's not a simple way I can see to record that GigabitEthernet0/1 is untagged vlan 200.

@candlerb commented on GitHub (Sep 20, 2017): If you just want to keep a track of VLAN membership on a port, as a workaround you could create an interface of type "virtual" for each enabled VLAN. * `GigabitEthernet0/1` type 1000BASE-T * `GigabitEthernet0/1.100` type Virtual * `GigabitEthernet0/1.101` type Virtual * ... etc This is after all how you would model a router with separate layer 3 subinterfaces, or a virtual machine which has different IP addresses on eth0.100 and eth0.101. It would however get tedious for many VLANs on many ports. There is no explicit link from a virtual interface to its parent (apart from a physical interface to parent LAG), so it is only implied from the naming. There's not a simple way I can see to record that GigabitEthernet0/1 is untagged vlan 200.

adam commented

2025-12-29 15:33:36 +01:00

@awerner commented on GitHub (Sep 27, 2017):

@candlerb, as you already mentioned, your workaround is unfortunately only feasible if the number of VLANs assigned to an interface is relatively low.
My use case is a number of 48 port switches with about 80-100 different VLANs configured on some of its ports, so were talking thousands of interfaces (on a single switch) here....
A good way of displaying the VLANs mapped to a port is therefore also quite important, I like the idea of having an indented collapsible view.

@awerner commented on GitHub (Sep 27, 2017): @candlerb, as you already mentioned, your workaround is unfortunately only feasible if the number of VLANs assigned to an interface is relatively low. My use case is a number of 48 port switches with about 80-100 different VLANs configured on some of its ports, so were talking thousands of interfaces (on a single switch) here.... A good way of displaying the VLANs mapped to a port is therefore also quite important, I like the idea of having an indented collapsible view.

adam referenced this issue

2025-12-29 16:23:40 +01:00

ip space / pools #597

adam referenced this issue

2025-12-29 16:23:41 +01:00

ip space / pools #597

adam referenced this issue

2025-12-29 16:23:55 +01:00

Add possibility to limit API response fields #620

adam referenced this issue

2025-12-29 16:24:32 +01:00

Enable CORS on API #662