EVPN Route Targets, Route Distinguishers, and VXLAN Network IDs
Got this interesting question from one of my readers:
BGP EVPN message carries both VNI and RT. In importing the route, is it enough either to have VNI ID or RT to import to the respective VRF?. When importing routes in a VRF, which is considered first, RT or the VNI ID?
A bit of terminology first (which you’d be very familiar with if you ever had to study how MPLS/VPN works):
- RT = Route Target - a VPN-identifying extended BGP community used to tag BGP routes. You might need more than one route target per VPN in complex scenarios.
- RD = Route Distinguisher - a prefix prepended to tenant prefixes to make them globally unique, otherwise we couldn’t use BGP to carry them around.
- VNI = VXLAN Network Identifier - a 24-bit layer-2 segment ID used in VXLAN headers the same way VLAN ID is used in 802.1q headers. VNI is carried in EVPN routes in MPLS label field together with BGP Encapsulation extended community saying “MPLS label is really a VNI”
RT and RD are control-plane constructs used to make BGP prefixes unique (RD) and to control route import from global BGP table into per-tenant forwarding table (RT).
VNI is data-plane construct used to select local MAC address table or IP forwarding table.
Now it should be really easy to answer the original question:
- Like with MPLS/VPN, Route Target is used when importing EVPN routes into local routing/forwarding tables;
- Like MPLS labels are not used to import MPLS/VPN or MPLS-based EVPN routes, VNI is not used during the route import process;
- VNI is used when processing incoming VXLAN packets to select the tenant forwarding table.
An Interesting Aside
In theory, VNI (like MPLS labels) has local significance, which means that different remote VTEPs within the same MAC address table could use different VNI values. In practice, I don’t know if any ASIC supports that… and meanwhile (trying to address both) RFC 8365 talks about globally-significant and locally-significant VNI.
Do you need locally-significant VNI to implement PVLAN-like hub-and-spoke VPN, or could you do it with a globally-significant VNI? Let’s leave that as an exercise for the reader ;)
More information
You could get tons of relevant EVPN details from our EVPN Technical Deep Dive webinar or go straight to the source:
- A Network Virtualization Overlay Solution Using Ethernet VPN (EVPN) (RFC 8365)
- BGP MPLS-Based Ethernet VPN (RFC 7432)
- The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute (RFC 5512)
Many thanks to Dinesh Dutt, Nicola Modena and Lukas Krattiger for fact-checking and improving the blog post.
It looks like there is an exception to the EVPN import rule based on the RT only if I understood well the (juniper's at least) implementation of "VLAN-Aware Bundle Service Interface" (see RFC 7432 par 6.3 @ https://tools.ietf.org/html/rfc7432#section-6.3). In that case in fact it looks like the route is imported within the right Bridge/Bcast Domain (i.e. within the right vlan if we assume a scenario where there is a vlan per Bridge domain and there are N Bridge Domanins within the same EVI) within the EVI by the import combination of the RT identifying the whole EVI/MAC-VRF and the ETHERNET TAG ID field (in the EVPN NLRI of the RT-2 in particular) whose value must carry that of the L2VNI (identifying the right bridge/vlan import) which in turn must be the same on all PEs for a particular VN in this case I guess.
Hope it makes sense. It'd be important if anyone could actually confirm this as it's pretty convoluted/complex. As far as I have seen there is not even that much public literature around on the implementation of the EVPN "VLAN-Aware Bundle Service Interface".
Cheers
Andrea
@Andrea - no, the import is still performed based on RT, note that every ET-ID within is advertised with its unique VNI and has a forwarding entry in the data plane, so when the receiving PE looks up the packet, VNI value yields right MAC-VRF+VLAN
Going back to your answer, while it makes absolute sense on the forwarding plane, I still have no clear how it can work on the control plane at the receiving PE.
What I mean is that in an EVPN VLAN-Aware Bundle Service Interface scenario with VxLAN control plane, the receiving PE has, say, 1 x EVI/MAC-VRF containing N x BDs with one VLAN per BD. If the RT-match only identifies the landing EVI/MAC-VRF, how does the receiving PE import the received EVPN route in the right BRIDGE/VLAN within the identified EVI/MAC-VRF ? does by any chance the RT identify not just the EVI/MAC-VRF but actually the BRIDGE/VLAN within the EVI/MAC-VRF ?
On Table A1 @ p.237 at the following link [https://www.juniper.net/documentation/en_US/day-one-books/TW_DCDeployment.v2.pdf] Juniper seems to have implemented, as I said in the previous reply, a match on the RT and on the L2VNI (not on the Ethernet-tag carrying the L2VNI value as I said before sorry, my bad) to identify the right BRIDGE/VLAN where to import the EVPN routeā¦.
I think I have just understood how it can always work with just RT-based import as Jeff was pointing out. Just realised in fact that the Route-Target format for the EVPNoVxLAN (RFC 8365) includes a 3B Service ID carrying the VNI value in case of VxLAN encapsulation. This means that RT-IMPORT allows to import EVPN routes in the right bridge even in a scenario of EVPN "VLAN-Aware Bundle Service Interface". Hope you guys can confirm it.
This poses now though a further question as this requires the VNI value to be globally rather than locally significant I guess ?
Cheers
Andrea