An Ethernet Virtual Private Network (EVPN) encompasses a fairly large group of technologies that make it possible to use Ethernet over an IP network.
The success of different SDN platforms has convinced many engineers that overlay networks are the way forward. Tunneling L2 over L3 means the physical network is simplified and reliable, and gives us a foundation for trust and predictability.
Of course, we still need to build an Ethernet-compatible overlay that supports the features that we have today. Flood’n’learn, MAC forwarding tables, BUM handling … the list is substantial.
In this sponsored show with Cisco Systems, we dive into EVPN to find out why it’s attracting the attention of both enterprises and carriers. Our guests from Cisco are Nicolas Breton, Product Manager; and Patrice Brissette, Principal Engineer.
We’ll explore the basics of EVPN and then look at three use cases: data center overlays, data center interconnect, and Carrier Ethernet.
Show Links:
Ethernet VPN (EVPN) – Cisco Systems
Ethernet VPN – just one more protocol to consider or dismiss? – Cisco Blog
Ethernet VPN – What’s the big deal about it? – Cisco Blog
Very good discussion.Kind of confused here if EVPN can do all this why its not adopted for SD-WAN, Think about having a single SDN controller controlling DC+WAN.
EVPN is a controller-less method of doing overlays. That being said, you may very well see controller based implementations of overlays like NSX and Nuage doing the exact thing you are talking about.
Its possible however BGP is a low/poor quality method for configuring network paths. I suspect that YANG/gRPC or Open/R is much more capable way to configure an overlay network and have greater reliability. BGP EVPN is useful tool as a transition method for overlay and getting customer acceptance and for the current capabilities of network devices. Importantly, its something that product teams inside vendors can sell to executives because it reuses sunk investments.
Long term, say over a 10 year period, its just a transition that the most of the legacy technology because real change is too hard.
So, the suggestion is to have a VLAN shared a long all your pods and evpn from the pods create a huge L2 overlay network shared between two DCs and when there is a L2 loop to say yay my core isn’t dead (hopefully)
Thanks but no thanks.
I think L3 separated DCs are better and it’s better to solve it with a more complicated solution (anycast? DNS load sharing?) rather than having a two DCs share fate
What would be or what is the issue to implement EVPN at the hypervisor (OVS or vswitch) level ?
Integrating the signalling/control plane with end point is unpredictable idea. For example, getting BGP code into Linux isn’t hard but modifying the network configuration to use that is a practical challenge when most sysadmins have limited networking knowledge.
This is changing of course. Project Calico & Juniper Contrail are attempting to do this with limited success to date. Changing network drivers to includes path management and path operations remains ‘unnatural’ for now although I think this will change with containers as the idea of intelligent networking is embraced there.