starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add "general" mode to 802.1Q VLAN #10257

New Issue
Closed
opened 2025-12-29 21:29:02 +01:00 by adam · 3 comments
adam commented 2025-12-29 21:29:02 +01:00
Owner
Copy Link

Originally created by @dreng on GitHub (Sep 17, 2024).

NetBox version

v4.1.1

Feature type

Change to existing functionality

Proposed functionality

When editing interfaces you may select one of the following 802.1Q Modes: Access, Tagged or Tagged (All). I propose to add a mode "General" and a PVID field and to allow to assign more than one untagged VLAN.

Use case

I'm not sure if this is part of the 802.1Q standard, but a couple of switches (e.g. cisco, dell) support a "general" mode, where you are able to configure more than one untagged VLAN (egress) to a port. Ingress VLAN is always the PVID in this case. It is reasonable to be able to document if general mode has been configured for a port and which untagged VLANs belong to that port.

See also https://www.cisco.com/c/en/us/td/docs/switches/lan/csbss/CBS220/CLI-Guide/b_220CLI/vlan_commands.html#ID-00005845

Database changes

  • The current one-to-many-field "Untagged VLAN" has to become a many-to-many-field named "Untagged VLANs".
  • A new one-to-many-field "PVID" has to be added.

Alternatively, the following change can also be made (less work and probably backwards compatible):

  • Rename the current one-to-many-field "Untagged VLAN" to "PVID"
  • Add a new many-to-many-field named "Untagged VLANs"

External dependencies

None

Originally created by @dreng on GitHub (Sep 17, 2024). ### NetBox version v4.1.1 ### Feature type Change to existing functionality ### Proposed functionality When editing interfaces you may select one of the following 802.1Q Modes: Access, Tagged or Tagged (All). I propose to add a mode "General" and a PVID field and to allow to assign more than one untagged VLAN. ### Use case I'm not sure if this is part of the 802.1Q standard, but a couple of switches (e.g. cisco, dell) support a "general" mode, where you are able to configure more than one untagged VLAN (egress) to a port. Ingress VLAN is always the PVID in this case. It is reasonable to be able to document if general mode has been configured for a port and which untagged VLANs belong to that port. See also https://www.cisco.com/c/en/us/td/docs/switches/lan/csbss/CBS220/CLI-Guide/b_220CLI/vlan_commands.html#ID-00005845 ### Database changes - The current one-to-many-field "Untagged VLAN" has to become a many-to-many-field named "Untagged VLANs". - A new one-to-many-field "PVID" has to be added. Alternatively, the following change can also be made (less work and probably backwards compatible): - Rename the current one-to-many-field "Untagged VLAN" to "PVID" - Add a new many-to-many-field named "Untagged VLANs" ### External dependencies None
adam added the type: featurenetbox labels 2025-12-29 21:29:02 +01:00
adam closed this issue 2025-12-29 21:29:02 +01:00
adam commented 2025-12-29 21:29:03 +01:00
Author
Owner
Copy Link

@v0tti commented on GitHub (Sep 19, 2024):

Although I think that setting multiple untagged VLANs should be supported by NetBox (because vendors support it on their devices, not because I can think of any real-world use case for it), I would opt not to name the mode "general" in NetBox. This seems to imply some sort of default mode, which it is absolutely not. Many users who are not familiar with the concept of multiple untagged VLANs will probably be confused by this.

@v0tti commented on GitHub (Sep 19, 2024): Although I think that setting multiple untagged VLANs should be supported by NetBox (because vendors support it on their devices, not because I can think of any real-world use case for it), I would opt not to name the mode "general" in NetBox. This seems to imply some sort of default mode, which it is absolutely not. Many users who are not familiar with the concept of multiple untagged VLANs will probably be confused by this.
adam commented 2025-12-29 21:29:03 +01:00
Author
Owner
Copy Link

@dreng commented on GitHub (Sep 19, 2024):

I agree that "general" might be confusing. It did indeed, when I first stumbled upon this term on a Cisco switch. I'm completely open to other terms. If there's an official term, we should use it (as said before, I don't know if general VLAN complies to the standard anyway). That said, I think there should be a recognition value in the switches that you work on.

Suggestions welcome!

As for a real-world example: Imagine you want to receive traffic on your desktop PC (VLAN 10) from a switchport you are not connected to (and you are not even connected to the same switch). This can be done with RSPAN. You set the source port to the port you want to sniff and the destination to a special VLAN, let's say 666. In order to receive traffic from the mirrored port on VLAN 666, you have to either use tagged VLAN and configure you network card to receive packets that are tagged with 666. Or you configure the switchport to be untagged 666 instead of 10. The latter would kick you out of the "normal" VLAN. The former would require your network card and OS/driver to support this and that you have enough permissions on your desktop PC.
With general VLAN you could receive traffic from a second VLAN (666) easily. Sent packets would always be sent on the PVID (10), but that's not a problem, because you just want to receive packets (for Wireshark e.g.).

@dreng commented on GitHub (Sep 19, 2024): I agree that "general" might be confusing. It did indeed, when I first stumbled upon this term on a Cisco switch. I'm completely open to other terms. If there's an official term, we should use it (as said before, I don't know if general VLAN complies to the standard anyway). That said, I think there should be a recognition value in the switches that you work on. Suggestions welcome! As for a real-world example: Imagine you want to receive traffic on your desktop PC (VLAN 10) from a switchport you are not connected to (and you are not even connected to the same switch). This can be done with RSPAN. You set the source port to the port you want to sniff and the destination to a special VLAN, let's say 666. In order to receive traffic from the mirrored port on VLAN 666, you have to either use tagged VLAN and configure you network card to receive packets that are tagged with 666. Or you configure the switchport to be untagged 666 instead of 10. The latter would kick you out of the "normal" VLAN. The former would require your network card and OS/driver to support this and that you have enough permissions on your desktop PC. With general VLAN you could receive traffic from a second VLAN (666) easily. Sent packets would always be sent on the PVID (10), but that's not a problem, because you just want to receive packets (for Wireshark e.g.).
adam commented 2025-12-29 21:29:03 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 23, 2025):

This sounds like some vendor-proprietary magic, and probably doesn't belong in NetBox. It's not possible AFAIK to have multiple untagged VLANs, at least per the 802.1Q specification, which is what NetBox models. The keyword "general" in the referenced documentation appears to be sort of alias for some more complex configuration, rather than a discrete functional mode.

@jeremystretch commented on GitHub (Jan 23, 2025): This sounds like some vendor-proprietary magic, and probably doesn't belong in NetBox. It's not possible AFAIK to have multiple untagged VLANs, at least per the 802.1Q specification, which is what NetBox models. The keyword "general" in the referenced documentation appears to be sort of alias for some more complex configuration, rather than a discrete functional mode.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label netbox type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#10257
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?