search

netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
16.07k stars 2.58k forks source link

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

Closed howard-2020 closed 2 years ago

howard-2020 commented 2 years ago

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.

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.

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

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

This is all I want for Christmas :)

DanSheps commented 2 years ago

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.

apellini commented 2 years ago

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

ChrisDeh commented 2 years ago

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

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

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

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

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

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.

decoupca commented 2 years ago

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

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.