Add support for VC's between interfaces

[vapor-ware]

Add support for VC's between interfaces

[howard-2020]

I'm an engineer for an ISP and we are starting to use Netbox. We do alot of L2VPN and this virtual circuit plugin is a great but it's limited since it is based on vlans. A virtual circuit can span across multiple routers and have multiple interfaces(tagged or untagged) on each router, including virtual connections facing the core such as a MPLS pseudo-wire or an EVPN-EVI.

For the virtual circuit model to work in our environment we would need it to be based on vlan and/or interface. We could get by just adding the ability for interfaces.

If it were to be tailored for ISP environments it would also include:

• You would need to record Name, Description, MTU, assign to a tenant, include comments, and Circuit ID under the main virtual circuit.
• Select type: Point-to-point(ELINE), Bridge domain (ELAN). Maybe a drop-down for technology - VXLAN, VPLS, EVPN.
• Ability to add any interface(L2 or L3) from any device as a member and optionally select a vlan on that interface.
• A field for Psuedowire IDs or EVP EVIs but this could go in the comments too.

Here is an bridge-domain example across three routers using MPLS:

Router01:

bridge-domain ACME_CUSTOMER_BD
  interface Bundle-Ether20.45   <---vlan 45
  interface BVI45               <---L3 routed interface
  !
  neighbor 2.2.2.2 pw-id 45     <---pseudo-wire ID for MPLS peering with R2
  neighbor 3.3.3.3 pw-id 45     <---pseudo-wire ID for MPLS peering with R3

Router02:

bridge-domain ACME_CUSTOMER_BD
  interface TenGigE0/1/0/2      <---untagged
  interface Bundle-Ether60.45   <---vlan 45
  !
  neighbor 1.1.1.1 pw-id 45     <---pseudo-wire ID for MPLS peering with R1

Router03:

bridge-domain ACME_CUSTOMER_BD
  interface TenGigE0/0/0/13      <---untagged
  interface Bundle-Ether60.45    <---vlan 45
  !
  neighbor 1.1.1.1 pw-id 45     <---pseudo-wire ID for MPLS peering with R1

For EVPN you would simply replace the neighbor statements with a single EVI command under each bridge domain which would contain an EVI ID.

We would need to create a Virtual Circuit named "ACME_CUSTOMER_BD" and add all the interfaces above on all three routers. We could use the comments or custom field for the pseudo-wire ID (or in EVPN, the EVI ID). Then when the customer calls I can search by Tenant, Click on the Virtual Circuit stats, and then quickly find all interfaces which are a part of the L2VPN.

I don't know a good way to document the core facing elements(Pws, EVI, Tunnels) since technologies would vary across users of Netbox so I think it would be sufficient to document these via comments.

Adding interfaces would be a HUGE improvement. Thanks for your hard work in maintaining this plugin.

[nzjc]

+1 and I agree with semaja2

Our Juniper network can have a virtual circuit, or "service" like VPLS that spans multiple devices, and terminates on either an interface or sub-interface (logical unit) - so this request would fit really well. The standard Netbox concept of a VLAN doesn't really work that well for routed networks where the VLAN X on one interface might be nothing to do with VLAN X on an other...

[XioNoX]

That usecase would probably also works to document our backup GRE and IPsec tunnels.

gr-0/0/1 on router1 is "connected" to gr-0/0/1 on router2 through VC1
Or even to 3rd parties (only know one side): only gr-0/0/2 on router1 uses VC2

[marcoceppi]

While it's not a focus at the moment to create VCs between interfaces. Adding a Virtual Circuit "mode" drop down and choosing between VLAN/MPLS which would then let you select interfaces vs VLANs seems reasonable. I'm not sure if we'll have time to complete that soon but we'd welcome a contribution to expand that!

[semaja2]

+1 on this feature request, assigning subinterfaces (virtual) would suit much better as our circuits are terminated on multiple devices inside the same rack/site so the VLAN option does not scale past one device

Fantastic start however 👍