Support modelling of access interfaces with auxiliary tagged VLANs (e.g. voice VLAN) #240

New Issue

MrUnknownDE · 2026-04-05T16:23:24+02:00

MrUnknownDE commented

2026-04-05 16:23:24 +02:00

Originally created by @miki5421 on 3/3/2026

NetBox version

V4.5.3

Feature type

Data model extension

Proposed functionality

Currently, when an interface in NetBox is configured with 802.1Q mode "Access", only a single untagged VLAN can be assigned. Tagged VLANs are only available when the interface mode is set to "Tagged", which models a trunk interface.

However, many real-world network designs use hybrid access ports that carry:

One untagged VLAN for data traffic
One tagged VLANs for auxiliary services

A common example is an IP phone deployment where:

The connected workstation uses an untagged data VLAN
The phone sends voice traffic using an 802.1Q tagged VLAN

On Cisco platforms this is implemented using:

switchport mode access
switchport access vlan <DATA>
switchport voice vlan <VOICE>

This does not represent a trunk port from an operational standpoint, and modelling the interface as "Tagged" in NetBox causes downstream configuration templates to treat it as a trunk.

Proposed change:

Allow assignment of one or more tagged VLANs to interfaces in "Access" mode while retaining the untagged VLAN designation.

Possible implementation approaches:

Option A (minimal UI change)

Allow the existing "Tagged VLANs" field to appear when mode = Access
Untagged VLAN remains mandatory
Tagged VLANs become optional auxiliary VLANs

Option B (more explicit model)

Introduce a new optional field:
auxiliary_vlans (ManyToMany -> VLAN)

UI example:

Mode: Access
Untagged VLAN: 100
Auxiliary VLANs: [200]

This would allow NetBox to model the actual Layer-2 behaviour on the wire:

Untagged frames → VLAN 100
Tagged frames → VLAN 200

Templates can then decide how to render this for different vendors (Cisco voice VLAN, hybrid ports on other platforms, etc.).

Use case

Hybrid access ports are extremely common in enterprise networks.

Typical examples include:

IP phone + workstation ports
- Data VLAN (untagged)
- Voice VLAN (tagged)
Access ports carrying auxiliary tagged VLANs for IoT or device management
Platforms that support hybrid ports (not strictly trunk or access)

Currently, NetBox users must choose between two imperfect modelling approaches:

Set the interface to "Tagged" mode
- This incorrectly models the interface as a trunk
- Configuration templates may render trunk configurations instead of access ports
Use custom fields to store the voice VLAN
- This breaks consistency with the existing VLAN model
- Templates require special logic
- VLAN relationships are not visible in the normal interface VLAN fields

Allowing auxiliary tagged VLANs on access interfaces would:

Better reflect actual Layer-2 behaviour
Improve vendor-agnostic modelling
Simplify configuration template logic
Reduce reliance on custom fields

Database changes

This feature could potentially be implemented without introducing a new model.

Option A:
Reuse the existing tagged_vlans ManyToMany relationship and allow it when mode = access.

Option B:
Introduce a new field on dcim.Interface:

auxiliary_vlans = ManyToManyField(VLAN)

This field would represent tagged VLANs permitted on an access interface.

No existing data model changes would be required for VLANs themselves.
Migration impact would be minimal.

External dependencies

No response

*Originally created by @miki5421 on 3/3/2026* ### NetBox version V4.5.3 ### Feature type Data model extension ### Proposed functionality Currently, when an interface in NetBox is configured with 802.1Q mode "Access", only a single untagged VLAN can be assigned. Tagged VLANs are only available when the interface mode is set to "Tagged", which models a trunk interface. However, many real-world network designs use hybrid access ports that carry: - One untagged VLAN for data traffic - One tagged VLANs for auxiliary services A common example is an IP phone deployment where: - The connected workstation uses an untagged data VLAN - The phone sends voice traffic using an 802.1Q tagged VLAN On Cisco platforms this is implemented using: switchport mode access switchport access vlan <DATA> switchport voice vlan <VOICE> This does not represent a trunk port from an operational standpoint, and modelling the interface as "Tagged" in NetBox causes downstream configuration templates to treat it as a trunk. Proposed change: Allow assignment of one or more tagged VLANs to interfaces in "Access" mode while retaining the untagged VLAN designation. Possible implementation approaches: Option A (minimal UI change) - Allow the existing "Tagged VLANs" field to appear when mode = Access - Untagged VLAN remains mandatory - Tagged VLANs become optional auxiliary VLANs Option B (more explicit model) - Introduce a new optional field: auxiliary_vlans (ManyToMany -> VLAN) UI example: Mode: Access Untagged VLAN: 100 Auxiliary VLANs: [200] This would allow NetBox to model the actual Layer-2 behaviour on the wire: - Untagged frames → VLAN 100 - Tagged frames → VLAN 200 Templates can then decide how to render this for different vendors (Cisco voice VLAN, hybrid ports on other platforms, etc.). ### Use case Hybrid access ports are extremely common in enterprise networks. Typical examples include: 1. IP phone + workstation ports - Data VLAN (untagged) - Voice VLAN (tagged) 2. Access ports carrying auxiliary tagged VLANs for IoT or device management 3. Platforms that support hybrid ports (not strictly trunk or access) Currently, NetBox users must choose between two imperfect modelling approaches: 1. Set the interface to "Tagged" mode - This incorrectly models the interface as a trunk - Configuration templates may render trunk configurations instead of access ports 2. Use custom fields to store the voice VLAN - This breaks consistency with the existing VLAN model - Templates require special logic - VLAN relationships are not visible in the normal interface VLAN fields Allowing auxiliary tagged VLANs on access interfaces would: - Better reflect actual Layer-2 behaviour - Improve vendor-agnostic modelling - Simplify configuration template logic - Reduce reliance on custom fields ### Database changes This feature could potentially be implemented without introducing a new model. Option A: Reuse the existing tagged_vlans ManyToMany relationship and allow it when mode = access. Option B: Introduce a new field on dcim.Interface: auxiliary_vlans = ManyToManyField(VLAN) This field would represent tagged VLANs permitted on an access interface. No existing data model changes would be required for VLANs themselves. Migration impact would be minimal. ### External dependencies _No response_

MrUnknownDE closed this issue

2026-04-05 16:23:24 +02:00

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

No Label netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#240