In previous posts I described VXLAN using flood and learn behavior using multicast or ingress replication. The drawback to flood and learn is that frames need to be flooded/replicated for the VTEPs to learn of each other and for learning what MAC addresses are available through each VTEP. This isn’t very efficient. Isn’t there a better way of learning this information? This is where Ethernet VPN (EVPN) comes into play. What is it? As you know, BGP can carry all sorts of information and EVPN is just BGP with support to carry information about VTEPs, MAC addresses, IP addresses, VRFs, and some other stuff. What does EVPN provide us?
- Ability to discover VTEPs.
- Messaging of MAC prefixes and IP prefixes.
- Reduced amount of flooding.
- Optionally ARP suppression.
Note that the use of EVPN doesn’t entirely remove the need for flooding using multicast or ingress replication. Hosts still need to use ARP/ND to find the MAC address of each other, although ARP suppression could potentially help with that. There may also be protocols such as DHCP that leverage broadcast for some messages. In addition, there may be silent hosts in the fabric where VTEP is not aware that the host is connected. Therefore, EVPN reduces flooding but does not remove it.
BGP considerations
When deploying EVPN, there are three main designs that are used:
- iBGP on top of IGP.
- iBGP on top of eBGP.
- eBGP on top of eBGP.
There are pros and cons to each of these. One important consideration is that eBGP by default modifies the next-hop when advertising Network Layer Reachability Information (NLRI). This can cause issues as the IP of the VTEP should be retained for VXLAN to work. There are usually some nerd knobs to change this behavior. Similarly, eBGP in some NOS such as NX-OS does not by default advertise BGP NLRI with route target that is not used locally. This means that route from leaf when going to spine is not advertised to another leaf since spine does not have VNI locally configured. There is usually a knob to affect this behavior as well.
Address family
Address families are commonly used in BGP to enable the advertisement of different forms of NLRI, for example VPNv4, IPv6, multicast, etc. The Address Family Indicator (AFI) identifies the primary network protocol such as IPv4, IPv6, L2VPN. To further distinguish within the AFI, there is the Subsequent Address Family Indicator (SAFI). EVPN is a SAFI under the AFI of L2VPN. Hence EVPN’s AFI/SAFI is L2VPN/EVPN.
Route distinguisher and route target
With virtual networks there is a need to distinguish between IP- and MAC addresses that are the same. The same network or MAC address may be used in different virtual networks. For those familiar with MPLS, the route distinguisher (RD) and route target (RT) should be familiar. The purpose of RD is to take something that is not unique, such as IP- or MAC address, and prepend an 8-byte value to it that makes it unique. There are three different formats the RD can take:
The most common format used with VXLAN is Type 1 where the 4-byte IP is the IP address of the VTEP (normally a loopback).
RT is an extended BGP community used to control the import and export of routes into VRFs. Think of it as a tag appended to routes where a router exporting with a RT of 65500:50000 would import a RT of 65500:50000:
RT uses the same type of format as RD, where IP or ASN can be used. Many networking operating systems support automating the generation of RD and RT. The RD could be based on the BGP RID and VRF ID and the RT on BGP ASN and VNI. Note that automaticallly generating RT could pose some challenges when running eBGP in the underlay as every leaf would have different ASN. There may be knobs to make auto RT work in such a topology.
Route types
EVPN supports several route types to carry information such as MAC- and IP prefixes. We will take a look at these in detail in a future post but there are currently six route types that are used:
In the next post we’ll start configuring EVPN so that we can explore the different route types. See you in the next one!
Thank you, Daniel! Looking for the next one.
excellent resume!
Thank you!
Thank you
Thanks Daniel. Clear and concise. Really appreciate your years of posting and sharing knowledge. Kudos!
Thanks, Neil!