Add ability to assign VLAN to L2VPN (type EVPN-VXLAN)

[erdems]

NetBox version

v3.3.1

Feature type

New functionality

Proposed functionality

EVPN provides sandboxed VLAN allocation, especially by means of (not limited to) MAC-vrf as Juniper Networks call it (RFC7432).

It is therefore possible to have the same VLAN ID in different VRFs, just like the prefixes.

Use case

In a multi-tenant provider environment, especially with DCaaS.

Database changes

1. Add a l2vpn_id field in VLAN table.
2. Add vlan_id and vlan_group fields to ipam_l2vpn table.
3. Add enforce_unique field to ipam_l2vpn table, referring to VLANs.

External dependencies

None.

[DanSheps]

Thank you for your interest in extending NetBox. Unfortunately, the information you have provided does not constitute an actionable feature request. Per our contributing guide, a feature request must include a thorough description of the proposed functionality, including any database changes, new views or API endpoints, and so on. It must also include a detailed use case justifying its implementation. If you would like to elaborate on your proposal, please modify your post above. If sufficient detail is not added, this issue will be closed.

[erdems]

Hello, edited as best as I could.

[robertlynch3]

I believe this is already possible, but it's somewhat confusing. You can link a VXLAN termination to vlan directly, and netbox allows you to have multiple VLANs with the same VLAN ID. The hard part is determining where that vlan (not the ID necessarily but that specific layer2 domain) is.

I'd love to be able to say vxlan VNI 1234 is terminate on switch1 as vlan-id 1, and on switch2 as vlan-id 2 (which is possible as I said above, but its hardish).

[DanSheps]

I believe this is already possible, but it's somewhat confusing. You can link a VXLAN termination to vlan directly, and netbox allows you to have multiple VLANs with the same VLAN ID. The hard part is determining where that vlan (not the ID necessarily but that specific layer2 domain) is.

Are you talking about filtering? We could possibly expand the filtering on the vlan portion.

[erdems]

I believe with the current model, it's near impossible to properly plan (or reflect) a many-to-many L2VPN; such as a MAC VRF or EVPN/VXLAN. These are almost always used for multiple endpoints, so almost never as P2P 'terminations'.

I have tried @rml596 's suggestion and got even more confused :)

My proposal is that the relation between a prefix/ip address and VRF should be mimicked between a VLAN and certain L2VPN types, at least the ones that support P2MP modeling.

[DanSheps]

How-to for a Many-to-many L2VPN:

1. Create your sites(Site 1, Site 2), device types, device roles, etc
2. Create 3 devices (Device 1, Device 2, Device 3; with Device 1 and Device 2 being in Site 1 and Device 3 being in Site 2)
3. Create 3 vlans (VID 1, VID 2, VID 3; VID 1 and 2 can be in Site 1, VID 3 in Site 2)
4. Create a L2VPN (Type: VXLAN-EVPN)
5. Create a L2VPN Termination for VLAN 1 to the L2VPN
6. Create a L2VPN Termination for VLAN 2 to the L2VPN
7. Create a L2VPN Termination for VLAN 3 to the L2VPN
8. Associate these VLAN's to the device in whatever manner is appropriate (access port, trunk port, etc)

[DanSheps]

To add:

I looked into the documentation a little more, and I understand you are looking to use the same VID on the same device (and by extension the same site). That is currently not possible and would be outside of the scope of this FR as written it is currently not possible to have the same VID in the same site/vlan group.

You can do the exact method as above, but using vlan groups with the same VID to obtain the desired effect.

[DanSheps]

I converted this to a discussion as what is desired is all ready do-able.

[erdems]

Thank you very much Daniel, for taking the time to go through the workflow and suggest an alternative to the original suggestion of mine. I'm calling it an alternative because although the VLAN groups would indeed be one way to go, they'd miss (unless one uses notes etc.) to capture crucial elements of a MAC-VRF.

Maybe I have not entirely correctly articulated my proposal; I should perhaps say that the current L2vpn implementation does not cover "instance-type mac-vrf", part of RFC7432.

At the risk of stating the obvious (or preaching to the choir), a MAC-VRF is very similar to Layer-3 VRF's as in both have a vrf-target and RD. Just as you'd make a prefix/IP part of a Layer-3 VRF, the same is technically possible for a VLAN and MAC-VRF. You can have vlan 100 repeated n times inside the same switch providing all belong to separate MAC-VRFs, for instance.

I'm afraid I don't see how the termination approach would be able to capture this.

[DanSheps]

Can you perhaps give me an example configuration, because from what I can tell on the Juniper site, they all need to be part of a separate bridge-domain ("VLAN"), even on the same switch.

[PieterL75]

On the MX series, you can create a routing-instance of the type 'virtual-switch' (or in this case mac-vrf).
the name 'routing-instance' (RI) is a little confusing, but it means that it separates the data in the RI from all other RI's.
you can have a bridge-domain on the RI 'cust1' with vlan 100, and then have another bridge-domain on RI 'cust2' with also vlan 100.
But both vlan100's are totally separated and not linked to eachother in any way.

In fact, it might be benficial to see of FR #7854 could cover this. An RI is a 'virtual' part inside the MX.
by using the shared interfaces of the FR, it could be nicely separated and still linked together (with lt's for example)

[DanSheps]

On the MX series, you can create a routing-instance of the type 'virtual-switch' (or in this case mac-vrf). the name 'routing-instance' (RI) is a little confusing, but it means that it separates the data in the RI from all other RI's. you can have a bridge-domain on the RI 'cust1' with vlan 100, and then have another bridge-domain on RI 'cust2' with also vlan 100. But both vlan100's are totally separated and not linked to eachother in any way.

I understand how RI's work, it seems like erdems is saying this isn't needed though and I want to understand how.

In fact, it might be benficial to see of FR #7854 could cover this. An RI is a 'virtual' part inside the MX. by using the shared interfaces of the FR, it could be nicely separated and still linked together (with lt's for example)

VDC's would likely cover all similar methods (RIs, etc)

Even if VDC's covered this, you would likely still need a VLAN group for the seperate L2 domain within the same site, since vlans are assigned a scope that doesn't get down to "routing instances". So you would still need:

1 additional Vlan Group
x additional Vlans associated to the Vlan group

I honestly don't see a need to change the method. Sure, it can be clunky but we can try and smooth that out. We likely won't change the data model itself, however.

I do want to see a config of this, because perhaps there is something that we missed.

[erdems]

Apologies for the delayed reply. It's true that within the same switch, in most cases the VLAN ID would have to be unique, even in case of different MAC-VRF RI's.

However, across an EVPN/VXLAN infrastructure, VID100 for "default-switch"a and VID100 that's in a MAC-VRF will be treated as two separate broadcast domains.

A sample / minimalist config would look like the one below. Note the "route-distinguisher" and "vrf-target" statements that provide separation across nodes.

erdem@anakin# show routing-instances vlan-aware-RI 
protocols {
    evpn {
        extended-vni-list [ 510009 510056 ];
        encapsulation vxlan;
        default-gateway no-gateway-community;
    }
}
vtep-source-interface lo0.0;
instance-type mac-vrf;
service-type vlan-aware;
route-distinguisher 1.2.3.4:3131;
vrf-target target:65530:3131;
vlans {
    VLAN_9 {
        vlan-id 9;
        interface ae10.9;
        vxlan {
            vni 510009;
        }
    }
    VLAN_10 {
        vlan-id 10;
        interface ae10.10;
        vxlan {
            vni 510010;
        }
    }
}

Although I understand and agree VLAN groups would be one way to do, it would be IMHO difficult to keep track of vrf-like elements and potential import/export rules with groups alone.

[DanSheps]

Unfortunately, making VLAN VID's none unique (outside the bounds of a VLAN group) would severely damage our data model's integrity and I don't think it is something we are going to take on.

VLAN groups allow you to build non-unique VIDs, so that requirement is covered.

L2VPN's support VNI's and route-targets. RD is a L2VPN identifier which we could potentially look at adding to the L2VPN model. You can associate VLANs to the L2VPN through a L2VPN Termination (effectively a ManyToOne Generic Relation).

Not ever VLAN has a l2vpn, so I don't see any value adding a direct link to the l2vpn model from the vlan model. The reason it is setup like this is every platform does everything differently, a MAC-VRF isn't a "vlan evpn" either, 1 end of the MAC-VRF can be vlan based, another could be a service on a fixed interface. It all depends on on the platform capabilities, which is why this model was chosen and no direct link on the interface/vlan was added.

[erdems]

Thanks Daniel, that's a fair point indeed. Enhancing the L2VPN model to support RD etc. is a good idea as well since for now it seems the "identifier" doesn't have the 'any format' flexibility as RD does.

I'm not sure if a given MAC-VRF can have different service types among nodes, this could be rather RI but I may be wrong. Either way, it's true different platforms can and probably tackle things differently.