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 L2VPN Support - ELINE, ELAN, ETREE, Bridge Domain via VPLS, EVPN, VXLAN #8157

Closed
howard-2020 opened this issue Dec 22, 2021 · 11 comments · Fixed by #9631
Closed

Add L2VPN Support - ELINE, ELAN, ETREE, Bridge Domain via VPLS, EVPN, VXLAN #8157

howard-2020 opened this issue Dec 22, 2021 · 11 comments · Fixed by #9631
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@howard-2020
Copy link

NetBox version

v3.1.0

Feature type

New functionality

Proposed functionality

New data model to support tracking of L2VPNs such as VPLS, EVPN, VXLAN, and other tunneling protocols. This would require two major items.

  1. New L2VPN data model
  2. Ability to link any vlan and/or interface to the L2VPN.

The proposed functionality would rely on a new data model for L2VPNs. Since there are many different methods to deliver L2VPN service I also propose a new model for "L2VPN Types", similar to prefix/vlan roles, otherwise a drop down with pre-defined L2VPN Types would suffice or we could also use custom fields if we did not want to create the additional "L2VPN Types" model. Creating "L2VPN Types" add some context and it's flexibile so the user can define them according to whats important to them. For instance you could simply define ELINE, ELAN, ETREE... On the other hand you might be interested in technologies such as VPLS or EVPN-IRB.

1) Create new data models under IPAM.

  • L2VPNs
    • Name (required and unique)
    • L2VPN Type (required and select from drop-down from model "L2VPN Types" or create predefined list)
    • Description
    • Status (required and select from drop-down)
      *Active
      *Planned
      *Inactive
    • Tags
    • Tenancy Assignment
    • Comments
    • Journal and Change Log.
    • Allow custom fields (This will be useful for PW-ID, EVI, RTs, etc-depending on your environment)
  • L2VPN Types
    • Name (required and unique)
    • Weight
    • Description
    • Tags

2) Link Interfaces and Vlans
Link Interfaces -
There will only be one L2VPN ever assigned to an interface and we could do this in the same way you will be able to assign an interface to a VRF(Request #7852). You should be able to assign a L3 interface to a VRF and also to a L2VPN. In the case where the interface has multiple L2VPNs, such as a trunk, each L2VPN would have different encapsulation so you would not link at the interface level and only link underlying vlans to the L2VPN. There can be multiple physical or virtual interfaces from any device assigned to a single L2VPN instance.

  • On the L2VPN page provide a function to search for existing interfaces and add any interface to the L2VPN instance.
  • On the interface page provide a row to associate L2VPNs - much like the upcoming Feature Request Interface to VRF Associations #7852.

Link Vlans -
There will only be one L2VPN ever assigned to a vlan but there can be multiple vlans assigned to one L2VPN.

  • On the L2VPN page provide a function to search for existing vlans and add any vlan to the L2VPN instance.
  • On the vlan object provide a row to associate L2VPNs - much like how you assign a prefix to a VRF.

The L2VPN page would show you all the information about the L2VPN and all vlans and/or interfaces that are assigned to this L2VPN so you could easily know all the interfaces. In case of vlans you would need to drill down to the Vlan->Device Interfaces Tab to see the interfaces.

Ideally we would be able to look at the Tenant in Netbox and see a number of L2VPNs assigned to the Tenant. We would then click on the L2VPN icon where it list all the L2VPNs assigned to the Tenant. You would then be able to select the L2VPN of interest.

Use case

Netbox does a great job at documenting L3VPNs. I hope Netbox can do something similar for L2VPNs. Netbox will only model a L2 domain as one flat vlan. In ISP and Data Center environments we use MPLS, EVPN, VXLAN, etc. each having different vlan IDs and we even bridge vlan ranges together. We need Netbox to document the L2VPN attributes and all the end-points. It would be very powerful to be able to find all interfaces within a L2VPN in a few seconds.

We have tenants that have multiple L2VPN services that use a mix of vlans and/or interfaces(untagged). An L2VPN can span across multiple routers as tagged or untagged traffic at the edge ports. These ports may be physical or virtual or there may be a vlan on trunk interface. In an Integrated-Routing-and-Bridging(IRB) scenario there will be L3 virtual interfaces assigned to an L2VPN or even multiple Distributed Anycast gateways(in EVPN-IRB). Netbox has all the underlying pieces of the L2VPN already documented, we just need a way to link these pieces together to construct an L2VPN. We have VPLS and EVPN mainly in our network but I think the proposed functionality will be flexible enough to document any L2VPN technology.

NOTE: I am familiar with the netbox-virtual-circuit-plugin from vapor-ware. Aside from the project being outdated and not maintained, the biggest deal-breaker is it only supports grouping of vlans and not interfaces. Another important item is that we need to assign these L2VPNs to a Tenant.

Database changes

New tables for L2VPN models.

External dependencies

None

@howard-2020 howard-2020 added the type: feature Introduction of new functionality to the application label Dec 22, 2021
@howard-2020
Copy link
Author

This is all I want for Christmas :)

@DanSheps
Copy link
Member

DanSheps commented Dec 23, 2021

Related: #7847 #7588 #3738 #3033 #2800 #1800 #1725 #1324 #1058 #825 #777

This is a pretty good FR, as far as detail goes and it has been asked for a lot, so for now it can stay open for feedback.

@DanSheps DanSheps added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Dec 23, 2021
@apellini
Copy link
Contributor

Also it is possible to use also for SDN Controller specific for example Cisco ACI

@ChrisDeh
Copy link

Thats a great PR - The abstraction Level meets the sweet spot in my opinion.
It would improve NetBox usage for Carrier Networks a lot and solves a lot of problems.
As we would definitly profit from that, i can offer help when it comes to implementation!

@kvondersaar
Copy link

I think this FR is great and I'm glad to see it left open for comment. Hopefully we can get some traction on finally getting solid VPN modeling in NetBox.

I like the idea of creating a generic model for the VPN that allows attachment of other participating objects. Some considerations for the this FR:

  1. The VPN object has an "Identifier" field, which is optional, but can be used to store a VNI, Tunnel ID, whatever else identifies the overlay.
  2. Add RTs to the VPN object. Again, optional, but since RTs are a first class object in NetBox we should allow for quality relationships if possible.
  3. Add VRFs the the list of objects that may be bound to the VPN.
  4. Possibly consider a field that defines encapsulation protocol: MPLS, VXLAN, Geneve, etc.
  5. Perhaps the name should be changed to "Overlays" which (this is my opinion at least) more generically describes what is being modeled.

I'm curious what the the intend purpose of the "Weight" field is on the Type object?

All that said if the community can agree at least on a basic level that this is the way forward I would be happy to implement for trial and review.

@howard-2020
Copy link
Author

kvondersaar is right - Importing/Exporting Route Targets would be useful for EVPN models. Since Route Targets are already models this may be easy.

As for adding VRFs - I think there is a feature already in the works to link a vrf to an interface. Then in this L2VPN model you would be able to add any interface which would then inherit the VRF on that interface. I think linking a VRF directly to this L2VPN model would start to get a little redundant.

I like the name as L2VPN or something that clearly indicates layer 2 modeling. The goal of the FR was to abstract the L2VPN from all VPN overlays and to see all the interfaces and vlans in a L2 domain regardless of how they get there. We can expand the L2VPN Types to accommodate more overlay documentation.

Weight is for ordering the list of L2VPN Types - it's optional.

@kvondersaar
Copy link

I appreciate the desire to model L2VPNs specifically. However I think that being able to do so in a generic way would benefit more users, and thus gain more traction for acceptance as a core set of models. Especially given that a request for EVPN/VXLAN related functionality comes up often but nobody wants to tackle the complexity.

In the EVPN use case a generic overlays model can be used to define an L2 EVPN, which would be a collection of L2 interfaces, bridges, etc. But also the ability to model EVPN Symmetric IRB which is inclusive of an L3VNI and VRFs. If you have no need for that, because you're trying to model VPLS, or even a Martini pseudowire, then you'd select the appropriate type for the overlay, and only add in the pertinent L2 objects.

With regard to the FR that linked VRFs to interfaces, I'm not sure what the actual purpose was there, because the relationship of a VRF to an interface was already done via an IP address. In this case the point is not to link a VRF to the overlay, but to link the overlay's L3 VNI to the VRF. I'll confess this is EVPN specific, though may be useful for other overlays in the future as well. If the relationship were established via L2 semantics only, that is overlay->interface(->?ip-address)->vrf, then you would have to keep the L3 VNI on the VRF object which spreads out the functional properties of the overlay across multiple objects outside of the feature.

@jeremystretch jeremystretch added needs milestone Awaiting prioritization for inclusion with a future NetBox release and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Apr 6, 2022
@jeremystretch
Copy link
Member

I haven't dug into the proposed model for this yet, but I've moved it to "needs milestone" as I think it's a given that we'll implement something roughly matching the proposal in the near future.

@DanSheps
Copy link
Member

DanSheps commented Apr 6, 2022

I have a partial plugin for this already, when we are good to go with this we could maybe expand on that.

It roughly follows the same data model.

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed needs milestone Awaiting prioritization for inclusion with a future NetBox release labels May 6, 2022
@jeremystretch jeremystretch added this to the v3.3 milestone May 6, 2022
DanSheps added a commit that referenced this issue Jun 29, 2022
@DanSheps DanSheps linked a pull request Jun 30, 2022 that will close this issue
@decoupca
Copy link
Contributor

decoupca commented Jul 1, 2022

Can we bind or associate somehow a circuit type to an L2VPN so we can capture the physical side of things and show where it goes much like we do today with ethernet or is the Interface type going to be (seems like it is) along with vlan to an L2VPN type…. but .. how do I see the relationship of all of the associated VPNs that comprise that service? Like a common VNI for example… and speaking of which, where is the VNI documented ?

@DanSheps
Copy link
Member

DanSheps commented Jul 1, 2022

A circuit type or a circuit?

We could add a "related VPN" field or similar. I guess the question is how is this normally associated (an actual config would be helpful). We could also just allow linking the VPN to circuits directly.

VNI can be documented in the identifier field.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants