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.

5 comments:

  1. They abused BGP for another control plane. BGP is now known as BGP everything. VXLAN is just another encapsulation for a specific purpose. Will it solve all problems? No of course not.
  2. Agree with Anonymous, another kludge(with the automation bla bla on top of it too) use for BGP without researches, vendors and application folks thinking new designs of application and protocols.
    Replies
    1. EVPN specifications define a set of network layer services whose procedures are open for anyone to implement. MP-BGP specification was created to extend BGP to serve as an open signaling layer between network devices for network services, like EVPN, IPVPN, MVPN, etc. No abuse. For new application infrastructure design, check out service meshes.
  3. EVPN was actually conceived as a DC protocol. It was standardized in L2VPN WG because there was no DC IETF WG at the time. It's a good replacement for VPLS because, aside from integration with TE, WAN overlay requirements are mostly a subset of DC overlay requirements.
  4. Another side benny? Rapid adoption and solving real problems today. Instead of languishing away in the IETF as yet another pie-in-the-sky radical idea because it’s too foreign and not well understood, here was a relatively easy win for a protocol less than 5-years running in production. Almost like they meant for it to happen ��
  5. 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!

    Replies
    1. 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).

    2. 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?

    3. 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.

Add comment
Sidebar