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

Allow Vlan 4095 #10547

New Issue
Open
opened 2025-12-29 21:32:59 +01:00 by adam · 2 comments
adam commented 2025-12-29 21:32:59 +01:00
Owner
Copy Link

Originally created by @Nexis81 on GitHub (Dec 6, 2024).

NetBox version

v4.1.6

Feature type

Change to existing functionality

Triage priority

N/A

Proposed functionality

The proposed functionality is to enable the use of VLAN ID 4095 within NetBox, specifically for VMware environments or other specialized use cases. This change would include:

Validation Updates:
Modify the validation logic in NetBox to allow the configuration of VLAN 4095.
Ensure VLAN 4095 is treated as a valid VLAN ID when defining VLANs in the database, API, and UI.

Documentation Support:
Permit users to document VMware environments where VLAN 4095 is used for monitoring purposes (e.g., IDS/IPS traffic monitoring).

API Integration:
Ensure that NetBox's API supports VLAN 4095, allowing VMware-related automation and integration tools to use this VLAN ID when configuring or syncing data.

Optional Role/Scope Restriction:
Optionally restrict VLAN 4095 to specific use cases, such as:
VMware devices or configurations.
Special roles like "monitoring" or "trunking."
This change would allow NetBox to support organizations that use VLAN 4095 for valid and critical purposes, enabling more accurate network documentation and improved automation with platforms like VMware.

Use case

Scenario:
An organization deploys an IDS/IPS solution that relies on virtual sensors (vSensors) installed on all VMware vCenter hosts. These vSensors are configured to use VLAN 4095, which is a reserved VLAN in VMware environments, to monitor traffic across all VLANs on an internal vSwitch. This configuration allows the IDS/IPS system to analyze and secure network traffic efficiently.

Challenges:
- Documentation Gaps:
NetBox currently prohibits the use of VLAN 4095, making it impossible to accurately document VMware setups that utilize this VLAN for traffic monitoring.
As a result, the representation of VMware network configurations in NetBox is incomplete or inaccurate.

Automation Limitations:
Many organizations rely on APIs to integrate NetBox with VMware for automated network configuration and synchronization. The restriction on VLAN 4095 in NetBox prevents full automation, as configurations requiring this VLAN cannot be generated or applied through NetBox.

- Consistency and Accuracy:
Inconsistent documentation or manual workarounds, such as adding VLAN 4095 directly to the database via tools like pgAdmin, creates potential for errors and undermines NetBox’s value as a "source of truth."

Database changes

None

External dependencies

None

Originally created by @Nexis81 on GitHub (Dec 6, 2024). ### NetBox version v4.1.6 ### Feature type Change to existing functionality ### Triage priority N/A ### Proposed functionality The proposed functionality is to enable the use of VLAN ID 4095 within NetBox, specifically for VMware environments or other specialized use cases. This change would include: **Validation Updates:** Modify the validation logic in NetBox to allow the configuration of VLAN 4095. Ensure VLAN 4095 is treated as a valid VLAN ID when defining VLANs in the database, API, and UI. **Documentation Support:** Permit users to document VMware environments where VLAN 4095 is used for monitoring purposes (e.g., IDS/IPS traffic monitoring). **API Integration:** Ensure that NetBox's API supports VLAN 4095, allowing VMware-related automation and integration tools to use this VLAN ID when configuring or syncing data. **Optional Role/Scope Restriction:** Optionally restrict VLAN 4095 to specific use cases, such as: VMware devices or configurations. Special roles like "monitoring" or "trunking." This change would allow NetBox to support organizations that use VLAN 4095 for valid and critical purposes, enabling more accurate network documentation and improved automation with platforms like VMware. ### Use case **Scenario:** An organization deploys an IDS/IPS solution that relies on virtual sensors (vSensors) installed on all VMware vCenter hosts. These vSensors are configured to use VLAN 4095, which is a reserved VLAN in VMware environments, to monitor traffic across all VLANs on an internal vSwitch. This configuration allows the IDS/IPS system to analyze and secure network traffic efficiently. **Challenges:** **- Documentation Gaps:** NetBox currently prohibits the use of VLAN 4095, making it impossible to accurately document VMware setups that utilize this VLAN for traffic monitoring. As a result, the representation of VMware network configurations in NetBox is incomplete or inaccurate. **Automation Limitations:** Many organizations rely on APIs to integrate NetBox with VMware for automated network configuration and synchronization. The restriction on VLAN 4095 in NetBox prevents full automation, as configurations requiring this VLAN cannot be generated or applied through NetBox. **- Consistency and Accuracy:** Inconsistent documentation or manual workarounds, such as adding VLAN 4095 directly to the database via tools like pgAdmin, creates potential for errors and undermines NetBox’s value as a "source of truth." ### Database changes None ### External dependencies None
adam added the type: featurenetboxneeds milestonestatus: backlogcomplexity: low labels 2025-12-29 21:32:59 +01:00
adam commented 2025-12-29 21:33:00 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 10, 2025):

Came across this when looking into something else.

What does VLAN 4095 get you that "Tagged All" does not get you? VLAN 4095 is not part of the standard, so adding something outside of the standard can result in inconsistent data in other aspects.

"Tagged All" means "all vlans are tagged" and can include the "native vlan" if there is no vlan set as untagged, so I am dubious of the benefit of this proposal as there are typically only 2 options beyond entering in the VID ("0" for None and "4095" for All). It seems like "Tagged All" would accomplish what you are trying to get at and you don't address why that is insufficient.

@DanSheps commented on GitHub (Mar 10, 2025): Came across this when looking into something else. What does VLAN 4095 get you that "Tagged All" does not get you? VLAN 4095 is not part of the standard, so adding something outside of the standard can result in inconsistent data in other aspects. "Tagged All" means "all vlans are tagged" and can include the "native vlan" if there is no vlan set as untagged, so I am dubious of the benefit of this proposal as there are typically only 2 options beyond entering in the VID ("0" for None and "4095" for All). It seems like "Tagged All" would accomplish what you are trying to get at and you don't address why that is insufficient.
adam commented 2025-12-29 21:33:00 +01:00
Author
Owner
Copy Link

@cronicded commented on GitHub (May 15, 2025):

From IEEE Standard - 9.6 - VLAN Tag Control Information [IEEE Std 802.1Q™-2005] - Virtual Bridged Local Area Networks:

0xFFF - Reserved for implementation use. This VID value shall not be configured as a PVID or a member of a VID Set, or transmitted in a tag header.

Ensure VLAN 4095 is treated as a valid VLAN ID

0xFFF is not a valid ID in representing a functional, non-experimental implementation, and would not be transmitted across a network. This is a VMWare specific implementation, I believe in violation of 8021.q standards if utilized between network devices, and probably outside of the scope of Netbox?

@cronicded commented on GitHub (May 15, 2025): From IEEE Standard - 9.6 - VLAN Tag Control Information [IEEE Std 802.1Q™-2005] - Virtual Bridged Local Area Networks: `0xFFF - Reserved for implementation use. This VID value shall not be configured as a PVID or a member of a VID Set, or transmitted in a tag header.` > Ensure VLAN 4095 is treated as a valid VLAN ID 0xFFF is not a valid ID in representing a functional, non-experimental implementation, and would not be transmitted across a network. This is a VMWare specific implementation, I believe in violation of 8021.q standards if utilized between network devices, and probably outside of the scope of Netbox?
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 complexity: low needs milestone netbox status: backlog 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#10547
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?