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

Allow terminating circuit on VLAN subinterface #619

New Issue
Closed
opened 2025-12-29 16:23:54 +01:00 by adam · 8 comments
adam commented 2025-12-29 16:23:54 +01:00
Owner
Copy Link

Originally created by @mjclancyau on GitHub (Jan 11, 2017).

We often have multiple carrier circuits terminated on a single aggregated headend interface, separated by VLAN id. Currently this seems awkward to map into NetBox without setting the Form Factor of the interface to Other (Virtual does not seem to be an allowed form factor type for terminating a circuit). Is it possible to perhaps separate the concept of Virtual into VLAN sub-interface, Loopback, and any others that are reasonably common and likely, allowing circuit termination on VLAN sub-interfaces at least?

I'm not 100% sure that I am full bottle on the Circuit data model, but I hope this makes sense. Any clarification you can provide would be greatly appreciated.

Kind regards,
Matt

Originally created by @mjclancyau on GitHub (Jan 11, 2017). We often have multiple carrier circuits terminated on a single aggregated headend interface, separated by VLAN id. Currently this seems awkward to map into NetBox without setting the _Form Factor_ of the interface to _Other_ (_Virtual_ does not seem to be an allowed form factor type for terminating a circuit). Is it possible to perhaps separate the concept of _Virtual_ into _VLAN sub-interface_, _Loopback_, and any others that are reasonably common and likely, allowing circuit termination on _VLAN sub-interfaces_ at least? I'm not 100% sure that I am full bottle on the Circuit data model, but I hope this makes sense. Any clarification you can provide would be greatly appreciated. Kind regards, Matt
adam closed this issue 2025-12-29 16:23:54 +01:00
adam commented 2025-12-29 16:23:55 +01:00
Author
Owner
Copy Link

@nonsbe commented on GitHub (Jan 16, 2017):

I agree with this opinion as well. We have the same configuration terminating multiple VLAN based circuits on a central point. It would be nice to be able to aggregate these Z-ends in a common bundled way.

Adding sub-interfaces towards an interface is more likely for Layer3/routed interfaces with dot1Q enabled.

Eg. Gi1/9.333 -> which is a routed interface for dot1q-tagged vlan 333 containing an IP address).

We mainly use the VLAN Trunk mode to add L2 VLANs in the aggregate interface towards the ISP. Anyway your suggested solution is better than nothing, but further fine-tuning would be nice. Since I don't know the datamodel of this project enough I suggest other people can make further suggestions.

I believe some issues have already been raised according this #150 / #755.

Kr,
N.D.

@nonsbe commented on GitHub (Jan 16, 2017): I agree with this opinion as well. We have the same configuration terminating multiple VLAN based circuits on a central point. It would be nice to be able to aggregate these Z-ends in a common bundled way. Adding sub-interfaces towards an interface is more likely for Layer3/routed interfaces with dot1Q enabled. `` Eg. Gi1/9.333 -> which is a routed interface for dot1q-tagged vlan 333 containing an IP address). `` We mainly use the VLAN Trunk mode to add L2 VLANs in the aggregate interface towards the ISP. Anyway your suggested solution is better than nothing, but further fine-tuning would be nice. Since I don't know the datamodel of this project enough I suggest other people can make further suggestions. I believe some issues have already been raised according this #150 / #755. Kr, N.D.
adam commented 2025-12-29 16:23:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 17, 2017):

We often have multiple carrier circuits terminated on a single aggregated headend interface, separated by VLAN id.

To be clear, a circuit is a physical entity that carries a signal from one point to another. What you're describing is the delivery of multiple virtual circuits across a common physical circuit, which has its own ID, connecting the site to an ISP. The circuit model in NetBox pertains only to the physical carrier. Virtual circuits are not mapped in NetBox because it would not be practical to support the myriad manners in which they can be deployed.

@jeremystretch commented on GitHub (Jan 17, 2017): > We often have multiple carrier circuits terminated on a single aggregated headend interface, separated by VLAN id. To be clear, a circuit is a physical entity that carries a signal from one point to another. What you're describing is the delivery of multiple _virtual_ circuits across a common _physical_ circuit, which has its own ID, connecting the site to an ISP. The circuit model in NetBox pertains only to the physical carrier. Virtual circuits are not mapped in NetBox because it would not be practical to support the myriad manners in which they can be deployed.
adam commented 2025-12-29 16:23:55 +01:00
Author
Owner
Copy Link

@InsaneSplash commented on GitHub (Jan 17, 2017):

Sorry for jumping in late, but I feel there are cases where the provider terminates their circuits over a vlan. i.e some wireless providers. Agreed that the physical connection is there, but the VLAN attached to the circuit holds the IP information.

Having the ability to at least assign a VLAN to a port, would allow for situations such as this or when one connection to a switched network runs both a voice and data VLAN. (IPAM per vlan). With the VLAN information available within Netbox, it would be a great advantage to, when required, link a vlan to a port on a device...

just an idea.....

@InsaneSplash commented on GitHub (Jan 17, 2017): Sorry for jumping in late, but I feel there are cases where the provider terminates their circuits over a vlan. i.e some wireless providers. Agreed that the physical connection is there, but the VLAN attached to the circuit holds the IP information. Having the ability to at least assign a VLAN to a port, would allow for situations such as this or when one connection to a switched network runs both a voice and data VLAN. (IPAM per vlan). With the VLAN information available within Netbox, it would be a great advantage to, when required, link a vlan to a port on a device... just an idea.....
adam commented 2025-12-29 16:23:55 +01:00
Author
Owner
Copy Link

@InsaneSplash commented on GitHub (Jan 17, 2017):

Sorry I see this has been marked as a minor feature - #150

@InsaneSplash commented on GitHub (Jan 17, 2017): Sorry I see this has been marked as a minor feature - #150
adam commented 2025-12-29 16:23:56 +01:00
Author
Owner
Copy Link

@mjclancyau commented on GitHub (Jan 18, 2017):

Thanks for the response Jeremy,

I agree that they are virtual circuits in the sense that they are aggregated at the head-end, where they are handed off to us separated by VLAN IDs, but the last mile tail-end is indeed a distinct physical circuit with it's own circuit ID and access media. To that extent they still do represent a physical circuit, only that the aggregation and handoff to us is transparent due to the carrier terminating the last mile segment and aggregating the upstream network. The only meaningful headend termination point in this case is the VLAN sub-interface on the applicable PE router.

What I was suggesting is not a significant change, merely allowing an interface type of routed VLAN sub-interface (or similar terminology) to be the termination point of a circuit. Currently I'm using the Other interface type and naming the interface appropriately (e.g. gig-0/0/1.1321) to achieve the same effect, but the nomenclature is non-intuitive for others.

I understand if this is a bit outside the scope of what you expect Netbox to be able to capture, but my view is that the requirement may not be as esoteric as you initially indicated. Thanks for your consideration.

Kind regards,

Matt

@mjclancyau commented on GitHub (Jan 18, 2017): Thanks for the response Jeremy, I agree that they are virtual circuits in the sense that they are aggregated at the head-end, where they are handed off to us separated by VLAN IDs, but the last mile tail-end is indeed a distinct physical circuit with it's own circuit ID and access media. To that extent they still do represent a physical circuit, only that the aggregation and handoff to us is transparent due to the carrier terminating the last mile segment and aggregating the upstream network. The only meaningful headend termination point in this case is the VLAN sub-interface on the applicable PE router. What I was suggesting is not a significant change, merely allowing an interface type of routed VLAN sub-interface (or similar terminology) to be the termination point of a circuit. Currently I'm using the _Other_ interface type and naming the interface appropriately (e.g. gig-0/0/1.1321) to achieve the same effect, but the nomenclature is non-intuitive for others. I understand if this is a bit outside the scope of what you expect Netbox to be able to capture, but my view is that the requirement may not be as esoteric as you initially indicated. Thanks for your consideration. Kind regards, Matt
adam commented 2025-12-29 16:23:56 +01:00
Author
Owner
Copy Link

@nonsbe commented on GitHub (Jan 18, 2017):

Thank for the response @jeremystretch, but I do not entirely agree with that:

What you're describing is the delivery of multiple virtual circuits across a common physical circuit, which has its own ID, connecting the site to an ISP.

Our virtual circuits have an own Circuit IDs well at our ISP. For example:

Central Datacenter site:

  • Switch Interface for ISP A configured trunk mode with VLANs 10,20,30
  • Each of these VLANs has its own Circuit ID

Customer Site 1:

  • Local Physical Interface untagged Circuit ID A for central VLAN10

Customer Site 2:

  • Local Physical Interface untagged Circuit ID B for central VLAN20

Customer Site 3:

  • Local Physical Interface untagged Circuit ID C for central VLAN30
@nonsbe commented on GitHub (Jan 18, 2017): Thank for the response @jeremystretch, but I do not entirely agree with that: > What you're describing is the delivery of multiple virtual circuits across a common physical circuit, which has its own ID, connecting the site to an ISP. Our virtual circuits have an own Circuit IDs well at our ISP. For example: Central Datacenter site: - Switch Interface for ISP A configured trunk mode with VLANs 10,20,30 - Each of these VLANs has its own Circuit ID Customer Site 1: - Local Physical Interface untagged Circuit ID A for central VLAN10 Customer Site 2: - Local Physical Interface untagged Circuit ID B for central VLAN20 Customer Site 3: - Local Physical Interface untagged Circuit ID C for central VLAN30
adam commented 2025-12-29 16:23:56 +01:00
Author
Owner
Copy Link

@InsaneSplash commented on GitHub (Jan 18, 2017):

@nonsbe I have to agree with you as we use the same type of deployment topology. This is especially true with interconnects between ISP's where separate circuits are provided over VLANs rather than separate links.

@InsaneSplash commented on GitHub (Jan 18, 2017): @nonsbe I have to agree with you as we use the same type of deployment topology. This is especially true with interconnects between ISP's where separate circuits are provided over VLANs rather than separate links.
adam commented 2025-12-29 16:23:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 18, 2017):

@nonsbe What you're describing are four physical circuits, one to each site from your provider, each with its own ID and A/Z terminations. This is what NetBox models. The assignment of virtual circuits on top of this physical infrastructure is an entirely separate concept which can be implemented in many different ways (point-to-point, multipoint, MPLS/VPN, etc.).

NetBox does not model virtual circuit overlays because it would be impractical to support the myriad potential topologies, at least at this nascent stage of development. In this particular instance, you could very simply create virtual subinterfaces with their respective 802.1Q tags and assign a description to each.

@jeremystretch commented on GitHub (Jan 18, 2017): @nonsbe What you're describing are four physical circuits, one to each site from your provider, each with its own ID and A/Z terminations. This is what NetBox models. The assignment of _virtual_ circuits on top of this physical infrastructure is an entirely separate concept which can be implemented in many different ways (point-to-point, multipoint, MPLS/VPN, etc.). NetBox does not model virtual circuit overlays because it would be impractical to support the myriad potential topologies, at least at this nascent stage of development. In this particular instance, you could very simply create virtual subinterfaces with their respective 802.1Q tags and assign a description to each.
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
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#619
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?