netlab
netlab copied to clipboard
ipspace
Initial VXLAN implementation on Junos
8f3e5a4ebe41c8b0203a41e972c47a99ee3a673d added support for VLAN-to-VXLAN bridging. I decided to make it as simple as possible -- it uses static (configured) ingress replication and supports extending a selected subset of VLANs across a VXLAN domain.
Adding VXLAN routing seems to be a no-brainer on Arista EOS, anycast gateway will be implemented in another module together with HSRP/VRRP (because it's not VXLAN-specific), and we'll eventually integrate EVPN control plane (I'm pretty sure we'll have to add L2VRFs when we get there, or add RD/RT parameters to VLANs).
It's currently implemented on Arista EOS, and it was just a few lines of configuration. Implementations on other devices would be most welcome -- I might be able to do a Nexus OS or Cumulus Linux implementation, but neither one of them has a VLAN implementation at the moment, so we need to fix that first.
cc: @jbemmel @ssasso @petercrocker @ddutt
On SR Linux they're called macvrfs, see e.g rfc8365; they're conceptually different than VLANs, as you can have multiple VLANs attached to a single macvrf.
My preference would be to create a 'macvrf' module, and implement RT/RD and VNI parameters there. Macvrfs can exist in isolation, or within the context of a L3 vrf; both a top-level 'macvrfs:' element and an optional element under each vrf in vrfs: seem appropriate
RFC 7432 defines multiple EVPN service types. At the moment, I plan to implement only "VLAN-based Service Interface" (one-to-one mapping between VLAN tags, VXLAN VNIs and EVPN RT/RDs), which does not need an intermediate MAC-VRF construct in the data model regardless of how it needs to be configured on any particular device.
Furthermore, RFC 8365 makes no data-plane difference between "VLAN-aware Bundle Service" and "VLAN-based Service" -- in both cases, each VLAN needs a VNI, which means that we could implement MAC-VRF within EVPN module, because it's a pure control-plane construct (multiple independent VLANs share RT/RD).
Beyond those two service types, we're entering the murky land of 802.1Q-in-VXLAN encapsulation, and I don't want to go there; that would be best solved with a totally separate set of modules.
As for "MAC VRF" EVPN construct, I feel like we could solve it within the existing framework by using VLAN-in-VRF setup and set VLAN mode to "bridge" for pure L2VRF, or leave it at "irb" for IRB. Have to check how that would translate into device configurations for a few platforms (I don't want to look just at Arista EOS).
Asymmetric IRB would be solved automatically with the current setup (using existing VRF, VLAN, and VXLAN modules you get it out of the box), for symmetric IRB we'd need "transit_vni" VRF attribute.
