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 still facing some interoperability challenges (I love to call it SIP of networking).
To make matters worse, EVPN can easily get even more confusing if you follow some convoluted designs propagated on the ‘net… and the best antidote to that is to invest time into understanding the fundamentals, and to slowly work through more complex scenarios after mastering the basics.
We did exactly 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 brief 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 MPLS data plane to replace VPLS in service provider networks, and got adopted (with VXLAN encapsulation) as the control plane used by the Network Virtualization Overlays (NVO) IETF workgroup.
- In theory you could use EVPN 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 or VXLAN.
- 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 IP-address-based format, Route Targets usually use ASN-based format.
- EVPN defines a mechanism to generate RD and RT values automatically from VLAN or VXLAN identifiers.
- EVPN replaces flood-and-learn behavior of traditional Ethernet bridges (or VPLS or simpler VXLAN implementations) with 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.
- You can use EVPN to implement end-to-end bridging, integrated bridging and routing, 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.