Preference-Based and Non-Revertive DF Election

In addition to the ES service-carving modes auto and off, the manual mode also supports the preference-based algorithm with the non-revertive option, as described in draft-rabadan-bess-evpn-pref-df.

When ES is configured to use the preference-based algorithm, the ES route is advertised with the Designated Forwarder (DF) election extended community (sub-type 0x06). Figure 1 shows the DF election extended community.

Figure 1. DF Election Extended Community

In the extended community, a DF type 2 preference algorithm is advertised with a 2-byte preference value (32767 by default) if the preference-based manual mode is configured. The Don't Preempt Me (DP) bit is set if the non-revertive option is enabled.

The following CLI excerpt shows the relevant commands to enable the preference-based DF election on a specific ES (regular or virtual):

config>service>system>bgp-evpn>ethernet-segment#
...
service-carving mode {manual|auto|off}
  service-carving manual
    [no] preference [create] [non-revertive]
      value <value>
    exit
  [no] evi <evi> [to <evi>] 
  [no] isid <isid> [to <isid>]
# value 0..65535; default 32767
...

Where:

The following configuration example shows the use of the preference-based algorithm and non-revertive option in an ES defined in PE1 and PE2.

*A:PE-1>config>service>system>bgp-evpn# info 
----------------------------------------------
 ethernet-segment "ES1" create
   esi 01:00:00:00:00:12:00:00:00:01
   service-carving manual
       preference non-revertive create
         value 10000
       exit
       evi 2001 to 4000 
   exit
   multi-homing single-active
   port 1/1/1
   no shutdown
   
/* example of vpls 1 - similar config exists for evis 2-4000 */
*A:PE-1>config>service>vpls# info 
----------------------------------------------
 vxlan vni 1 create
 exit
 bgp-evpn
   evi 1
   mpls bgp 1
     ecmp 2
     auto-bind-tunnel
       resolution any
     exit
 sap 1/1/1:1 create
 no shutdown
----------------------------------------------
*A:PE-2>config>service>system>bgp-evpn# info 
----------------------------------------------
 ethernet-segment "ES1" create
   esi 01:00:00:00:00:12:00:00:00:01
   service-carving manual
       preference non-revertive create
         value 5000
       exit
       evi 2001 to 4000 
   exit
   multi-homing single-active
   port 1/1/1
   no shutdown
   
*A:PE-2>config>service>vpls# info 
----------------------------------------------
 vxlan vni 1 create
 exit
 bgp-evpn
   evi 1
   mpls bgp 1
     ecmp 2
     auto-bind-tunnel
       resolution any
     exit
 sap 1/1/1:1 create
 no shutdown
----------------------------------------------

Based on the configuration in the preceding example, the PE behavior is as follows:

  1. Assuming the ES is no shutdown on both PE1 and PE2, the PEs exchange ES routes, including the [Pref, DP-bit] in the DF election extended community.

  2. For EVIs 1 to 2000, PE2 is immediately promoted to NDF, whereas PE1 becomes the DF, and (following the es-activation-timer) brings up its SAP in EVIs 1 to 2000.

    For EVIs 2001 to 4000, the result is the opposite and PE2 becomes the DF.

  3. If port 1/1/1 on PE1 goes down, PE1 withdraws its ES route and PE2 becomes the DF for EVIs 1 to 2000.

  4. When port 1/1/1 on PE1 comes back up, PE1 compares its ES1 preference with the preferences in the remote PEs in ES1. PE1 advertises the ES route with an ‟in-use operational” Pref = 5000 and DP=0. Because PE2's Pref is the same as PE1's operational value, but PE2's DP=1, PE2 continues to be the DF for EVIs 1 to 4000.

    Note: The DP bit is the tiebreaker in case of equal Pref and regardless of the choice of highest or lowest preference algorithm.

  5. PE1's ‟in-use” Pref and DP continue to be [5000,0] until one of the following conditions is true:

    1. PE2 withdraws its ES route, in which case PE1 re-advertises its admin Pref and DP [10000,DP=1]

    2. The user changes PE1's Pref configuration