EVPN Auto-Rd and Duplicate MAC Addresses

Another EVPN reader question, this time focusing on auto-RD functionality and how it works with duplicate MAC addresses:

If set to Auto, the RD generated for the same VNI across the EVPN switches will be different. If the same route (MAC/IP) is present under different leaves of the same L2VNI, there is no best path selection (since the RD is different), and both will be considered. This is a misconfiguration and shouldn’t be allowed. How will the BGP deal with this?

If the above sentence sounded like Latin, go through the short EVPN terminology first (and I would suggest watching the EVPN Technical Deep Dive webinar).

Let’s start with an interesting fact: while we usually had to specify VRF RD values in MPLS/VPN, EVPN standard defined a procedure where RD would be auto-generated from a PE IP address and VLAN ID. That means that the same MAC address would appear as two distinct EVPN Type-2 prefixes when coming from two different PE devices. BGP will happily process the two prefixes and tag them for inclusion into the local MAC table… and that’s where it gets interesting:

  • If an EVPN PE device figures out it has learned the same MAC address locally (through dynamic MAC learning) and through an EVPN BGP update, the observed MAC address duplication might have been caused by a MAC (VM) move. MAC mobility procedures kick in, and eventually, we’re left with a single MAC address.
  • In case of true misconfiguration, the MAC mobility procedure goes into an endless loop, and EVPN RFC addresses that with a duplicate-MAC timer.

Long story short: BGP has nothing to do with duplicate MAC addresses; it just passes prefixes around the network. The EVPN devices discover duplicate MAC addresses when importing Type-2 EVPN routes into local MAC-VRF tables and try to rectify the situation using MAC mobility procedures defined in RFC 7432.

For more details, watch our EVPN Technical Deep Dive webinar or go straight to the source (RFC 7432).

Recent posts in the same categories

2 comments:

  1. Jeff Tantsura 16 January 2020 01:27
    This comment has been removed by the author.
  2. Andrea Di Donato 23 January 2020 17:55
    HI ALL,

    PRETTY INTERESTING

    TO BE HONEST THE THING I DO NOT UNDERSTAND IS WHAT DIFFERENCE THE SAME OR DIFFERENT RDS DO IN THIS CASE.

    - IF THE RDs WERE THE SAME THEN THE RR WOULD ONLY REFLECT THE BEST PATH AND THUS ONLY ONE PATH WOULD REACH THE PES AT ANY ONE TIME.

    - IF THE RDS WERE DIFFERENT THEN IT IS THE PES THEMSELVES TO SELECT THE BEST PATH OUT OF N RECEIVED PATHS AS THEY ARE STRIPPED OFF OF THEIR RDs ONCE THEY ARE IMPORTED BASED ON RT-MATCH.

    SO, IN ANY CASE (SAME RD OR DIFFERENT RD) ONLY ONE PATH IS BEST AT ANY ONE TIME ON ANY PE.

    VARIOUS USE CASES I CAN THINK OF FOLLOW FOR THE SCENARIO DEPICTED OF COEXISTENCE OF MHOMING, MAC-MOBILITY AND NASTY MAC DUPLICATES:

    1A) IN CASE OF SAME-ESI AND GENUINE MHOMING, TRAFFIC IS LOADBALANCED ON A PER-FLOW BASIS OVER THE ESI AND THUS OVER BOTH EXIT PES (I AM ASSUMING SUPPORT OF RT-1 IN PARTICULAR AND RT-4)

    2A) IN CASE OF SAME-ESI AND EITHER NASTY DUPLICATE MCAST OR GENUINE MAC MOVE THE NETWORK KEEPS BEHAVING AS PER POINT 1A AS, IN A SAME-ESI SCENARIO, A GENUINE MAC MOVE AND A NASTY DUPLICATE MAC ARE ALL INDISTINGUISHABLE AS FAR AS I KNOW FROM A GENUINE MHOMING BUT PLEASE CORRECT ME SHOULD I BE WRONG.

    1B) IN CASE OF DIFFERENT-ESI AND LEGITIMATE MAC MOVE, THE MAC MOBILITY PROCEDURE KICKS IN AND ALLOWS TO INSTALL THE MOST RECENT PATH STRAIGHT AWAY WITHOUT HAVING TO WAIT FOR A WITHDRAW AND AN UPDATE.

    2B) IN CASE OF DIFFERENT-ESI AND NASTY MAC DUPLICATE, THE MAC MOBILITY PROCEDURE KICKS IN AND THE DUPLICATE-MAC TIMER AVOIDS HAVING TO COUNT THE SN TO INFINITY AND THUS ENDLESSLY RE-LEARNING THE MAC ADDRESS.

    CHEERS,
    ANDREA
Add comment
Home
Sidebar