Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for VC's between interfaces #24

Open
WillIrvine opened this issue Jun 28, 2020 · 5 comments
Open

Add support for VC's between interfaces #24

WillIrvine opened this issue Jun 28, 2020 · 5 comments

Comments

@WillIrvine
Copy link

WillIrvine commented Jun 28, 2020

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
Copy link
Contributor

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
Copy link

semaja2 commented Aug 21, 2020

+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
Copy link

nzjc commented Aug 21, 2020

+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
Copy link

XioNoX commented Mar 11, 2021

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants