Allow terminating circuit on VLAN subinterface

[mjclancyau]

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

[nonsbe]

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.

[jeremystretch]

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.

[InsaneSplash]

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]

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

[mjclancyau]

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

[nonsbe]

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

[InsaneSplash]

@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.

[jeremystretch]

@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.