Allow assigning of VLAN(s) to device ports

[justinhippen]

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

[ryanmerolle]

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.

[cstueckrath]

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

[specialcircumstances]

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!

[Beiriz]

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

[InsaneSplash]

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.

[lampwins]

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.

[InsaneSplash]

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

[jeremystretch]

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?

[specialcircumstances]

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

[lampwins]

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.

[candlerb]

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.

[awerner]

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