vapor-ware / netbox-virtual-circuit-plugin

A plugin for NetBox that supports Virtual Circuit management
GNU General Public License v3.0
57 stars 19 forks source link

Add support for VC's between interfaces #24

Open WillIrvine opened 4 years ago

WillIrvine commented 4 years ago

Hi vapor-ware team,

Great plugin. This is something I've been looking for in netbox for sometime. In an MPLS environment we generally pop the tags and create virtual circuits between interfaces / sub-interfaces. Would you look to expand the feature set to support the creation of VC's between interfaces? Or would you accept a PR that creates this functionality?

I understand if you would prefer to keep this plugin limited to your own use case, but happy to contribute should you be willing to expand it.

Thanks

marcoceppi commented 4 years ago

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 commented 4 years ago

+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 👍

nzjc commented 4 years ago

+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 commented 3 years ago

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

howard-2020 commented 3 years ago

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:

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.