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

Various implementations might have several intermediate steps where the tenant routes would be collected in BGP table before being copied into per-tenant routing table and finally into per-tenant forwarding table (see also: RIB and FIB).

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:


Many thanks to Dinesh Dutt, Nicola Modena and Lukas Krattiger for fact-checking and improving the blog post.

6 comments:

  1. If I'm not mistaken, some existing merchant ASICs support only a single VXLAN VNI per bridge table and require/enforce these on both ingress and egress tunnels for L2. At a minimum it's a limitation of the SDK for these chips. The reason, as I understand it, is that these chips were developed for multicast-based flood-and-learn VXLAN which mandates global VXLAN VNI. EVPN implementations have had this to contend with on these chips even though EVPN doesn't really care what the VNIs for a VPN are are so long as they represent the correct bridge table contexts that make up the VPN (as we see with EVPN MPLS). With newer merchant ASICs I think locally significant VXLAN VNI for bridge tables are possible.
  2. Hi there,

    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
  3. @Aldrin in the current incarnation of EVPN implementations it is widely agreed that VNI's are domain unique. While it should indeed be possible to make them locally significant, the power of legacy (aka ossification) will not let that happen for quite some time ;-)
    @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
    Replies
    1. Thank you Jeff !! I actually remember following your work/discussions @ Redback when I joined Ericsson in the UK back in 2007- always great stuff !

      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….
    2. Hi there,

      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
  4. @Andrea - basically, with VLAN-Aware Bundle Service Interface you'd use a single RD/RT per bundle but different VNI's as per VLAN within the bundle. What Juniper is doing is an optimization (RT per VNI), so you could import as per VNI.
Add comment
Sidebar