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

QinQ Vlan support #5239

New Issue
Closed
opened 2025-12-29 19:25:47 +01:00 by adam · 8 comments
adam commented 2025-12-29 19:25:47 +01:00
Owner
Copy Link

Originally created by @kovalev94 on GitHub (Aug 30, 2021).

NetBox version

v1.2.0

Feature type

Change to existing functionality

Proposed functionality

Add QinQ vlan support. It can be made on nested vlan groups base.
For example we will create a vlan group with checkbox QinQ and Pvid field. After that all vlans in this group will have outer tag property.
You may bind the vlan group to some site or device, also you may bind inner vlan to some site or device.
More complex things, as QinQinQ can be supported if we add support for nested vlan(qinq) groups.(This feature is optional, but it will be cool)
I know that there were such feature request, but please don't close it with words - "Too complex", I think that if we spend some time, especially with ISP guys help, we can realize this feature.
If you want we can vote for this feature.

Use case

This ability will help many ISPs. Because some providers use QinQ vlan to identify subscribers.

Database changes

No response

External dependencies

No response

Originally created by @kovalev94 on GitHub (Aug 30, 2021). ### NetBox version v1.2.0 ### Feature type Change to existing functionality ### Proposed functionality Add QinQ vlan support. It can be made on nested vlan groups base. For example we will create a vlan group with checkbox QinQ and Pvid field. After that all vlans in this group will have outer tag property. You may bind the vlan group to some site or device, also you may bind inner vlan to some site or device. More complex things, as QinQinQ can be supported if we add support for nested vlan(qinq) groups.(This feature is optional, but it will be cool) I know that there were such feature request, but please don't close it with words - "Too complex", I think that if we spend some time, especially with ISP guys help, we can realize this feature. If you want we can vote for this feature. ### Use case This ability will help many ISPs. Because some providers use QinQ vlan to identify subscribers. ### Database changes _No response_ ### External dependencies _No response_
adam added the type: featurepending closure labels 2025-12-29 19:25:47 +01:00
adam closed this issue 2025-12-29 19:25:47 +01:00
adam commented 2025-12-29 19:25:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 30, 2021):

This is just a high level description of a feature you want to see. You haven't proposed any actual implementation, or even noted anything under proposed database changes. I'm happy to consider a proposed implementation, but you need to put in the effort to figure out what that might look like first.

I suggest getting started by familiarizing yourself with the current data model, and then evaluating each feasible implementation option for impact on complexity and performance. Then you can share your findings and explain which approach you believe is most promising, and any significant caveats or blockers for it.

@jeremystretch commented on GitHub (Aug 30, 2021): This is just a high level description of a feature you want to see. You haven't proposed any actual implementation, or even noted _anything_ under proposed database changes. I'm happy to consider a proposed implementation, but you need to put in the effort to figure out what that might look like first. I suggest getting started by familiarizing yourself with the current data model, and then evaluating each feasible implementation option for impact on complexity and performance. Then you can share your findings and explain which approach you believe is most promising, and any significant caveats or blockers for it.
adam commented 2025-12-29 19:25:48 +01:00
Author
Owner
Copy Link

@lucasw-eng commented on GitHub (Sep 2, 2021):

Proposed functionality

Not sure if it's feasible as I'm just getting familiar with the DB myself, but could we add a new 802.1q mode called QinQ in the drop down field in the UI (This would specifically be the 'mode' field in dcim_interface table). This will then require some new columns to be added to the dcim_interface_tagged_vlans table (changes marked down below). These new columns only need to be shown in the 'UI' when 'QinQ' mode is selected otherwise they can be hidden.

Database changes

Add some columns to the dcim_interface_tagged_vlans table. One for the stag_id, one for the ingress transform behavior (push, pop, stamp), and one for the egress transform behavior.

The stag_id can easily be a bigint data type, but I'm not entirely sure how best it would be to encapsulate the ingress/egress interface behavior. One idea I was thinking is it could be a pattern string i.e.

push-[8100/88a8].[vlan-id]

That way the ui could have a drop-down for the first section and the 2nd section could just be a vlan choice from the defined DB vlans.

Let me know what your thoughts are on this.

@lucasw-eng commented on GitHub (Sep 2, 2021): ### Proposed functionality Not sure if it's feasible as I'm just getting familiar with the DB myself, but could we add a new 802.1q mode called QinQ in the drop down field in the UI (This would specifically be the 'mode' field in dcim_interface table). This will then require some new columns to be added to the dcim_interface_tagged_vlans table (changes marked down below). These new columns only need to be shown in the 'UI' when 'QinQ' mode is selected otherwise they can be hidden. ### Database changes Add some columns to the dcim_interface_tagged_vlans table. One for the stag_id, one for the ingress transform behavior (push, pop, stamp), and one for the egress transform behavior. The stag_id can easily be a bigint data type, but I'm not entirely sure how best it would be to encapsulate the ingress/egress interface behavior. One idea I was thinking is it could be a pattern string i.e. > push-[8100/88a8].[vlan-id] That way the ui could have a drop-down for the first section and the 2nd section could just be a vlan choice from the defined DB vlans. Let me know what your thoughts are on this.
adam commented 2025-12-29 19:25:48 +01:00
Author
Owner
Copy Link

@bkakakym commented on GitHub (Sep 10, 2021):

As i think in can be added like a parent/child relationship - like a prefixes or vlan groups:

where 2 field in DB needed - one of them is 'vlan_type' for setting parent(Svlan) or child(cvlan) type, and the second one is null for Svlan ore interger field for id of parent vlan.

@bkakakym commented on GitHub (Sep 10, 2021): As i think in can be added like a parent/child relationship - like a prefixes or vlan groups: where 2 field in DB needed - one of them is 'vlan_type' for setting parent(Svlan) or child(cvlan) type, and the second one is null for Svlan ore interger field for id of parent vlan.
adam commented 2025-12-29 19:25:49 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Nov 10, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Nov 10, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:25:49 +01:00
Author
Owner
Copy Link

@julianze commented on GitHub (Nov 13, 2021):

This feature request is still very useful.
We are using QinQ in several use cases, like a transport vlan of a customers's traffic and then having inside tagged vlans of the customer infrastructure. We often pull one inner vlan out of the QinQ at the datacenter to bridge the customer vlan to the virtualization servers.

In another use case we are using inner vlans to isolate customer internet access (pppoe packets) on the access/backbone infrastructure to the BRAS.

@julianze commented on GitHub (Nov 13, 2021): This feature request is still very useful. We are using QinQ in several use cases, like a transport vlan of a customers's traffic and then having inside tagged vlans of the customer infrastructure. We often pull one inner vlan out of the QinQ at the datacenter to bridge the customer vlan to the virtualization servers. In another use case we are using inner vlans to isolate customer internet access (pppoe packets) on the access/backbone infrastructure to the BRAS.
adam commented 2025-12-29 19:25:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 18, 2021):

Useful or not, unfortunately no actionable implementation has been proposed. Unless someone volunteers to own this and come up with a thorough proposal, including not only the proposed data model but also the intended workflow and how it will be presented for consumption by users, this FR will go stale and eventually be closed.

@jeremystretch commented on GitHub (Nov 18, 2021): Useful or not, unfortunately no actionable implementation has been proposed. Unless someone volunteers to own this and come up with a thorough proposal, including not only the proposed data model but also the intended workflow and how it will be presented for consumption by users, this FR will go stale and eventually be closed.
adam commented 2025-12-29 19:25:49 +01:00
Author
Owner
Copy Link

@lucasw-eng commented on GitHub (Nov 18, 2021):

I'm willing to own the FR, though I thought my write up from September 1st covered most of what you're asking for in terms of workflow/data modeling changes. If you need me to go further in detail I can probably include some screenshots of what I'm thinking in terms of UI changes. If I'm missing a glaring issue with what I proposed just let me know.

My python and PostgreSQL skills are quite rusty, but I may be able to do some of the coding too thats required

@lucasw-eng commented on GitHub (Nov 18, 2021): I'm willing to own the FR, though I thought my write up from September 1st covered most of what you're asking for in terms of workflow/data modeling changes. If you need me to go further in detail I can probably include some screenshots of what I'm thinking in terms of UI changes. If I'm missing a glaring issue with what I proposed just let me know. My python and PostgreSQL skills are quite rusty, but I may be able to do some of the coding too thats required
adam commented 2025-12-29 19:25:49 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Dec 22, 2021):

Closing this out as no one has made an earnest effort to propose a reasonably detailed implementation. If anyone would like to take a real shot at this, please feel welcome to do so in a new feature request. (Please review our contributing guidelines for feature requests before doing so.)

@jeremystretch commented on GitHub (Dec 22, 2021): Closing this out as no one has made an earnest effort to propose a reasonably detailed implementation. If anyone would like to take a real shot at this, please feel welcome to do so in a new feature request. (Please review our [contributing guidelines](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md) for feature requests before doing so.)
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 pending closure 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#5239
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?