What Is EVPN?
EVPN might be the next big thing in networking… or at least all the major networking vendors think so. It’s also a pretty complex technology that still faces some interoperability challenges (I love to call it SIP of networking).
To make matters worse, EVPN can easily become even more confusing if you follow some convoluted designs propagated on the ’net. The best antidote to that is to invest time into understanding the fundamentals and slowly work through more complex scenarios after mastering the basics.
We did precisely that in the EVPN Technical Deep Dive webinar (after laying the data center groundwork in the Leaf-and-Spine Fabric Architectures webinar); here’s a summary of the What Is EVPN part of EVPN Fundamentals section:
- EVPN is a multi-tenant BGP-based control plane for layer-2 (bridging) and layer-3 (routing) VPNs. It’s the unifying L2+L3 equivalent of the traditional L3-only MPLS/VPN control plane.
- EVPN was designed to be used with an MPLS data plane to replace VPLS in service provider networks. It was adopted (with VXLAN encapsulation) as the control plane used by the Network Virtualization Overlays (NVO) IETF workgroup.
- In theory, EVPN could be used with almost any data-plane encapsulation (RFCs define extended BGP community values for MPLS, VXLAN, MPLS-over-GRE, MPLS-over-UDP, NVGRE…). In practice, it’s used with either MPLS in Service Provider networks or VXLAN in IP-based Service Provider networks or data center fabrics.
- Like MPLS/VPN, EVPN uses Route Distinguishers to make locally significant identifiers globally unique and Route Targets to indicate VPN membership. Route Distinguishers usually use an IP-address-based format, and Route Targets usually use an ASN-based format.
- EVPN defines a mechanism to automatically generate RD and RT values from VLAN or VXLAN identifiers.
- EVPN replaces the flood-and-learn behavior of traditional Ethernet bridges (or VPLS or simpler VXLAN implementations) with a BGP control plane. MAC addresses are propagated as BGP prefixes within the EVPN address family.
- EVPN implementations could use dynamic IP address discovery using DHCP reply snooping, ARP request snooping, or IP packet header gleaning and advertise IP-to-MAC bindings in EVPN BGP updates.
- EVPN can be used to implement end-to-end bridging, integrated-bridging-and-routing (IRB), or routing-only fabrics.
- EVPN supports MAC and IP address mobility (available in most implementations) and a standard-based MLAG functionality (available in Junos and recent NX-OS).
- Decent EVPN implementations can reduce flooding by turning off unknown unicast flooding and eliminating ARP flooding with local ARP proxy.
Want to know more? Start here.
Hi, There is something that i am wondering for a while, and trying hard to find any resources without success so far.
Does it make sense and are there any inherent problems from design perspective to actually use the Underlay not only for transport of Overlay packets, but also for some services. For example: VMWare cluster, vmotion, VXLAN traffic, some basic infrastructure services that are prerequisite for the rest - e.g. DNS. To me this looks like a great idea because this is what the L3 underlay really is - simple and robust, and with least dependencies, and this is what these basic infrastructure need. Nowadays you don't need stretched VLANs and subnets between the racks to run your VMWare, vSAN and etc.
Continuing this line of thought, i was wondering about reasons for decision on placing the L3 underlay interfaces in default routing table or a VRF, i would really appreciate a meaningful conversation on that topic as well!
While you could use the underlay network for all the purposes you mentioned, those traffic types usually have different security requirements, so one would put them in different VLANs or VRFs anyway.
Running them on top of EVPN is thus easier to set up.
More details in a blog post (probably coming in early September).
Hi, Thanks for your reply! I completely agree on both points you raised (on top of EVPN is easier & different VRF due to security), however here is why would feel more comfortable running them in the underlay: This particular project is a small "public cloud" so overlay is expected to be more or less "dynamic" - new VRFs, SVIs, BGP configurations, etc.. On the other hand underlay is completely static - both in terms of configuration and "state"
So if something fails for some reason - software defect, bad config pushed by the (quasi)-automation, overload.. i expect it to be in the overlay.
Am i making sense to you?
You should always start with "what problem am I trying to solve?" followed by "what is the best tool for the job?"
In your particular case, the answers obviously depend on what technology you plan to use for your public cloud. That technology will have specific limitations or expectations that will dictate the best way to build the transport network technology.