Configure EVPN Route Types and Their Functions on IOS XR Routers

Introduction

This document describes Ethernet VPN (EVPN) route types for Layer 2/3 control plane reachability, using Border Gateway Protocol (BGP) L2VPN AFI 25 and SAFI 70.

Prerequisites

Requirements

Cisco recommends that you have basic knowledge of MultIProtocol Label Switching (MPLS) and L2VPN.

Components Used

The information in this document is based on Device: Aggregation Services Router 9000 (ASR9K).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Terminologies Used

This table provides a brief overview of the terminologies used in this document.

Table 1. Key EVPN Terminologies

EVPN Route Types on Cisco IOS XR Routers

This table lists the summary of EVPN routes advertised in L2 and L3 services.

Table 2. EVPN Route Types

Network Topology Diagram

Use the network topology diagram in order to highlight the importance and functionality of EVPN routes.

Figure 1. EVPN Network Topology

Generic Configuration

This configuration is required for single or multihomed EVPN Networks on all the Provider Edges (PEs).

BGP:

router bgp 100
 bgp router-id 10.10.33.33
 address-family l2vpn evpn  

Note: This address family configuration enables the propagation of EVPN routes.

EVPN:

evpn

 ethernet-segment

 !

 evi 1  

Note: This EVI number is unique to a customer. All PEs participating in this EVPN instance must have the same number.

L2VPN:

l2vpn

 bridge group EVPN

  bridge-domain EVPN

   interface < TenGigE0/0/0/45.10 /BE20.10>

   !

   evi 1

Note: This configuration associates the EVI and Attachment Circuit (AC) over the bridge domain (BD), The significance of BD remains the same as in Virtual Private LAN Service (VPLS), which enables us to learn remote MAC and flooding of BUM traffic within the BD.

Access interface:

interface < TenGigE0/0/0/45.10 /BE20.10> l2transport
 encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric

Route Type 1 and its Significance

In a multihomed scenario when the Customer End (CE) device is connected to multiple PEs through a Link Aggregation Control Protocol (LACP) bundle, from the perceptive of CE, it is connected virtually to only one PE. This can be emulated using this configuration on both PE1 and PE2.

 lacp system MAC aaaa.aaaa.aaaa

Note: The system MAC 'aaaa.aaaa.aaaa' must be the same on all the PE bundles sharing the same ESI, that is, on PE1 and PE2 in this case.

evpn

interface Bundle-Ether20

  ethernet-segment

   identifier type 0 00.21.21.21.21.21.21.21.21  

The configuration establishes (all active) redundancy for CE1, allowing both PE1 and PE2 to actively forward traffic to CE1. When the remote PE3 needs to send traffic to CE1, it can choose to route it via either PE1 or PE2. This redundancy is achieved by PE1 and PE2 advertising the relevant EVPN routes to PE3, ensuring efficient traffic distribution.

Ethernet Auto-Discovery Route

It is used to advertise ESI, an ethernet tag ID, and the EVI information.

There are two types of Ethernet Auto-Discovery routes:

- Per ESI and Per EVI:

RP/0/RSP0/CPU0:ASR9910-3-PE1#show bgp l2vpn evpn rd  10.10.11.11:1   route-type 1

Route Distinguisher: 10.10.11.11:1 (default for vrf EVPN)

*> [1][0000.2121.2121.2121.2121][0]/120

                       0.0.0.0                                0 i

* i                    10.10.22.22                   100      0 i

*>i[1][0000.2121.2121.2121.2121][4294967295]/120

                       10.10.22.22                   100      0 i

Per ESI

This route is crucial as it notifies PE3 and other remote EVPN peers that PE1 and PE2 share the same ESI configuration.

RP/0/RSP0/CPU0:PE2-9001-2#show bgp l2vpn evpn rd 10.10.22.22:0 [1][10.10.22.22:1][0000.2121.2121.2121.2121][4294967295]/184 detail
Sat Aug  5 09:00:46.410 UTC

BGP routing table entry for [1][10.10.22.22:1][0000.2121.2121.2121.2121][4294967295]/184, Route Distinguisher: 10.10.22.22:0

<snIP>

Local Label: 0 (no rewrite);

<snIP>

Local

    0.0.0.0 from 0.0.0.0 (10.10.22.22), if-handle 0x00000000

      Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate, rib-install

      Received Path ID 0, Local Path ID 1, version 61

      Extended community: EVPN ESI Label:0x00:24014 RT:100:1

Note: [4294967295] – it is a per ESI route

         10.10.22.22:0 – RD set by PE IP address generating this route

         EVPN ESI Label:24014 – it is also called the split horizon label

         0x00 – all-active setup

         0x01- single-active

         RT:100:1- Auto-tagged Route Target value indicates that this ESI belongs to EVI 1

The two important functions of this route Per ESI are:

Mass-MAC Withdrawal

Figure 2. Mass-MAC Withdrawal

As per Figure 2., the CE (C1) device MAC address reachability information is advertised from the local PE (L1 and L2) to remote PEs (L3 and L4) via the BGP control plane over the MPLS cloud. When an access interface goes down, the associated Network Layer Reachability Information (NLRI) must be withdrawn. In large-scale networks, the time taken to withdraw all MAC/IP routes associated with an ESI can lead to significant dataflow disruption. In order to ensure faster convergence, when the access interface on a PE (for example, L1) goes down, a per-ESI route withdrawal is sent from L1 to its peer PEs (L2, L3, and L4). These peers then update the next-hop address for the ESI to the L2 address with an active ESI interface, ensuring fast convergence for all MAC addresses associated with that ESI.

Split Horizon Mechanism

Within the same ESI, the Split horizon mechanism helps stop BUM traffic looping back to the originated CE through a different PE.

Figure 3. Split-Horizon Mechanism

In this example:

• C1 is connected to both L1 and L2, C2 is only connected to L2.
• C1 and C2 belong to EVI-1.
• When Broadcast (ARP request for C2 IP address) traffic originates from C1, it is sent to L1. Now, L1 has to send this traffic to all the EVPN peers including L2 as L2 is also hosting C2 which needs the ARP request, but L2 hosts both C1 and C2.
• L2 must not send the ARP request back to C1 as this can cause traffic looping.
• Hence, in order to avoid traffic looping, when this ARP request is sent from L1 to L2 it is sent along with this EVPN ESI. Label:0x00:24014 (this label is advertised by L2 to L1 for this ESI configured on the access interface in the Per ESI route).
• When L2 sees the packet with EVPN ESI LABEL (also called the Spilt Horizon Label) it refrains from sending it to C1 and sends this request to all the CE devices connected to L2.
• This way the traffic looping is avoided, and this mechanism is called the Split Horizon Mechanism.

Per EVI

The significance of this route is to advertise the aliasing label, which is used by the other PE in order to load balance the traffic across multiple PE owning the ESI.

RP/0/RSP0/CPU0:PE2-9001-2#show bgp l2vpn evpn rd 10.10.22.22:1 [1][0000.2121.2121.2121.2121][0]/120 detail
BGP routing table entry for [1][0000.2121.2121.2121.2121][0]/120, Route Distinguisher: 10.10.22.22:1

<snIP>

Local Label: 24012 (no rewrite);

<snIP>

Local

    0.0.0.0 from 0.0.0.0 (10.10.22.22), if-handle 0x00000000

      Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate, rib-install

      Received Path ID 0, Local Path ID 1, version 8

      Extended community: RT:100:1

      Dependency List:

       EVPN

Note: 0000.2121.2121.2121.2121- per EVI route for this ESI

          Local Label: 24012 – this label must be used to send unicast traffic to CE1 via PE2

          RT:100:1 – this is to indicate that this route must be imported to EVI 1

Route Type 2 MAC/IP Advertisement Route

The significance of this route lies in its ability to advertise locally learned MAC/IP addresses to other PEs along with a unicast label. This route type 2 is imported into EVI 1 of the peer PE, as the import Route Target for EVI 1 across all PEs in AS 100 is 100:1.

evpn

 ethernet-segment

 !

 evi 1

  advertise-MAC

The advertise-MAC command must be configured in order to enable the advertisement of the MAC address learned locally on that AC interface as route type 2.

MAC Route

Single-Homed CE MAC Address Advertisement

RP/0/RSP0/CPU0:PE3-9006-1#show bgp l2vpn evpn rd 10.10.33.33:1 [2][0][48][c8f9.f98c.0bbf][0]/104
BGP routing table entry for [2][0][48][c8f9.f98c.0bbf][0]/104, Route Distinguisher: 10.10.33.33:1

<snIP>

Local label:24012(no rewrite);

Path #1: Received by speaker 0

Flags: 0x202000000504000b+0x00, import: 0x000, EVPN: 0x1

Advertised to update-groups (with more than one peer):

    0.2

  Local

    0.0.0.0 from 0.0.0.0 (10.10.33.33), if-handle 0x00000000

      Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate, rib-install

      Received Path ID 0, Local Path ID 1, version 399

      Extended community: SoO:10.10..33.33:1 0x060e:0000.0000.000a RT:100:1

      EVPN ESI: 0000.0000.0000.0000.0000 >> the ESI value is set to 0 when there is no ESI configured on the access interface

Note: EVPN: 0x1 >> EVI number

EVPN ESI: 0000.0000.0000.0000.0000 >> The ESI value is set to 0 when there is no ESI configured on the access interface.

Multi-Homed CE MAC Address Advertisement

The difference between route type 2 when advertised by a non-ESI configured access interface and ESI configured access interface is, that this ESI value is included in route type 2 as an extended community. This helps in load balancing the traffic among all the PEs having the same ESI configured.

RP/0/RSP0/CPU0:PE2-9001-2#show bgp l2vpn evpn

<snIP>

*> [2][0][48][1833.9d3d.193f][0]/104

                                      0.0.0.0                                      0 i

* i                                   10.10.11.11                         100      0 i

RP/0/RSP0/CPU0:PE3-9006-1#show bgp l2vpn evpn rd 10.10.33.33:1 [2][0][48][183
BGP routing table entry for [2][0][48][1833.9d3d.193f][0]/104, Route Distinguisher: 10.10.33.33:1
Paths: (2 available, best #2)

Local

    10.10.11.11 (metric 20) from 10.10.11.11 (10.10.11.11)

      Received Label 24012

      Origin IGP, localpref 100, valid, internal, import-candidate, imported, rib-install

      Received Path ID 0, Local Path ID 0, version 0

      Extended community: SoO:10.10.11.11:1 0x060e:0000.0000.000a RT:100:1

      EVPN ESI: 0000.2121.2121.2121.2121>>> this MAC route is tag with the ESI

      Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 10.10.11.11:1

Path #2: Received by speaker 0

  Not advertised to any peer

  Local

    10.10.22.22 (metric 10) from 10.10.22.22 (10.10.22.22)

      Received Label 24012

      Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install

      Received Path ID 0, Local Path ID 1, version 797

      Extended community: SoO:10.10.22.22:1 0x060e:0000.0000.000a RT:100:1

      EVPN ESI: 0000.2121.2121.2121.2121>> this MAC route is tag with the ESI

      Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 10.10.22.22:1

Note: EVPN ESI: 0000.2121.2121.2121.2121>>> This MAC route is tagged with the ESI.

MAC/IP Route

vrf TEST

 rd 10.10.33.33:3000

 address-family IPv4 unicast

  import route-target

   100:100

   200:200

  !

  export route-target

   100:100

Note: 100:100 is the Route Target added to the Route-Type 2.

interface BVI3000

 host-routing

 vrf TEST

 IPv4 address 192.168.10.1 255.255.255.0

 MAC-address aaaa.aaaa.aaaa

Note: The host-routing command adds the VPNv4 export Route Target to MAC-IP route type 2.

'192.168.10.1, aaaa.aaaa.aaaa' this IP and MAC address is referred to as anycast Integrated Routing and Bridging (IRB) IP and MAC address which must be the same on PE1 and PE2 in Anycast distributed IRB setup. Distributed IRB is the design used in this replication.

router bgp 100

 bgp router-id 10.10.33.33

!

address-family vpnv4 unicast

 !

 address-family l2vpn evpn


vrf TEST

  rd 10.10.33.33:3000

  address-family IPv4 unicast

   redistribute connected

Note:  The redistribute connected command under the Virtual Routing and Forwarding (VRF) generates an L3VPN label for EVPN routes.

l2vpn

 bridge group vESI-TEST

  bridge-domain vESI-TEST

   interface Bundle-Ether30.3000

   !

   routed interface BVI3000

   !

   evi 3000

RP/0/RSP0/CPU0:PE2#show bgp l2vpn evpn
<snIP>
Route Distinguisher: 10.10.33.33:3000

*>i[2][0][48][d46a.35eb.400c][32][192.168.20.3]/136

                         10.10.33.33                   100      0 i


RP/0/RSP0/CPU0:PE2#show bgp l2vpn evpn rd 10.10.22.22:3000 [2][0][48][d46a.35eb.400c][32][192.168.20.3]/136 detail 
Tue Nov 28 08:59:36.085 UTC
BGP routing table entry for [2][0][48][d46a.35eb.400c][32][192.168.20.3]/136, Route Distinguisher: 10.10.22.22:3000

<snIP>

  Flags: 0x2000020005060005+0x00, import: 0x080, EVPN: 0x3

  Not advertised to any peer

  Local

    10.10.33.33 (metric 3) from 10.10.33.33 (10.10.33.33), if-handle 0x00000000

      Received Label 24005, Second Label 24006

      Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, imported, rib-install

      Received Path ID 0, Local Path ID 1, version 19279

      Extended community: SoO:10.10.33.33:3000 0x060e:0000.0000.0fa0 RT:100:100

      EVPN ESI: 0000.0000.0000.0000.0000

      Source AFI: L2VPN EVPN, Source VRF: default, Source Route Distinguisher: 10.10.33.33:3000

Note: [48][d46a.35eb.400c][32][192.168.20.3]>> the MAC and IP address of the host attached to PE2 is advertised.

          Received Label 24005- Bridge-Domain/EVI label

          Second Label 24006- IP VRF label

When a host is discovered through ARP, the MAC and IP route type 2 are advertised with the Bridge-Domain/EVI and IP VRF labels with their respective route targets. The VRF route targets and IP VPN labels are associated with route type 2 in order to achieve Leaf-Leaf IP routing similar to traditional L3VPNs. For Layer-2 forwarding between Leaf-Leaf, the Bridge-Domain/EVI route targets and labels associated with route type 2 are used.

Propagation of MAC Address from Bridge-Domain to BGP

When the CE-facing interface is up and the router receives the first packet from the CE, the MAC address learning and advertisement happens using the platform components workflow:

Bridge Domain MAC table > L2FIB > EVPN > BGP 

• Learnt on the Bridge-Domain – PE-CE (L2FIB) - it is the first component that learns the MAC address.

RP/0/RSP1/CPU0:ASR-9904-5-PE2#show l2vpn forwarding bridge-domain EVPN:EVPN MAC-address location 0/1/CPU0

Fri Jul 31 17:12:53.515 UTC

 To Resynchronize MAC table from the Network Processors, use the command...

    l2vpn resynchronize forwarding MAC-address-table location <r/s/i>

MAC Address    Type     Learned from/Filtered on   LC learned  Resync Age/Last Change   Mapped  to 

-----------    -----   ------------------------    ----------  ----------------------   ---------

C8f9.f98c.0bbf dynamic Te0/0/0/45.10                N/A         31 Jul 17:03:54            N/A

• L2RIB: the MAC moves from the BD to the L2 route table, where the MAC is checked if it is duplicate or not, and accordingly the flags are set as per the status.
  
  

RP/0/RSP1/CPU0:ASR9906-1-PE1#show l2route evpn MAC all detail

Topo ID      MAC Address    Producer    Next Hop(s)              Seq No    Flags   Slot             

-------      -----------    ---------   ---------------          -------   ------  ----   

0           003c.1018.f5fe  LOCAL       TenGigE0/0/0/4.100, N/A   0        BLRcv   0/0/CPU0   

• EVPN

RP/0/RSP1/CPU0:ASR-9904-5-PE2#show evpn evi vpn-id 1 MAC
Fri Sep 20 08:21:44.128 UTC
VPN-ID  Encap    MAC address    IP address   Nexthop           Label    SID                                   

------  ------   -----------    ----------   --------          -----    ---

1       MPLS     1833.9d3d.193f   ::         10.10.11.11       24012

1       MPLS     1833.9d3d.193f   ::         10.10.22.22       24012

1       MPLS     c8f9.f98c.0bbf   ::         tengig0/0/0/45.10 24012

• From EVPN it propagates to BGP.

RP/0/RSP0/CPU0:PE2-9001-2#show bgp l2vpn evpn
<snIP>
*>  [2][0][48][1833.9d3d.193f][0]/104
                                 0.0.0.0                                           0 i
* i                              10.10.11.11                        100            0 i

When the PE receives a route type 2 for EVI 1 it is propagated through these components:

• BGP route type 2 with the Route Target value of 100:1 is received
• Due to the matching Route Target, it  is imported into the EVPN -EVI 1 table with the next-hop IP address set to the PE advertising that route and the label is also imported from route type 2
• It is then installed in the L2RIB table in order to check for the uniqueness of the MAC address and the flags are set accordingly
• Post which MAC address is installed in the BD MAC- address table

Route Type 3 Inclusive Multicast Ethernet Tag (IMET) Route

This route is required for BUM traffic delivery across EVPN networks. This route is used to tell the other PEs (PE1) which label to use if they must send BUM traffic to PE3 for EVI 1.

RP/0/RSP0/CPU0:PE3-9006-1#show bgp l2vpn evpn rd 10.10.33.33:1 [3][0][32][10.10.33.33]/80 private
BGP routing table entry for [3][0][32][10.10.33.33]/80, Route Distinguisher: 10.10.33.33:1
Paths: (1 available, best #1)

  Advertised to update-groups (with more than one peer):

    0.2

  Path #1: Received by speaker 0

  Flags: 0x202000000504000b+0x00, import: 0x000, EVPN: 0x0

  Advertised to update-groups (with more than one peer):

    0.2

  Local

    0.0.0.0 from 0.0.0.0 (10.10.33.33), if-handle 0x00000000

      Origin IGP, localpref 100, valid, redistributed, best, group-best, import-candidate

      Received Path ID 0, Local Path ID 1, version 2

      Extended community: RT:100:1

      PMSI: flags 0x00, type 6, label 24013, ID 0x0a0a2121

      Dependency List:

      EVPN

Note: Type 6 - ingress replication – when a PE receives BUM traffic from CE it replicates it to all the other PE participating in that EVI (the egress PE here is the replication node):

label 24013 – this is the local BUM label advertised by PE3

RT:100:1-Route target of EVI 1

Route Type 4 Ethernet Segment Route

Route type 4 enables multi-homing PE detection based on the ES import Route Target and DF election. This route is only imported by PEs configured with the same ESI value, as controlled by the ES import: 0021.2121.2121. This auto-generated Route Target is unique to the corresponding ESI identifier.

PE2 and PE1 generate this route as they have an ESI configured on the access interface Figure 1. EVPN Network Topology.

RP/0/RSP0/CPU0:PE1-9001-1#show bgp l2vpn evpn
<snIP>

Route Distinguisher: 10.10.11.11:0 (default for vrf ES:GLOBAL)

*> [4][0000.2121.2121.2121.2121][32][10.10.11.11]/128

                                        0.0.0.0                                 0 I

*>i[4][0000.2121.2121.2121.2121][32][10.10.22.22]/128

                                        10.10.22.22                    100      0 I

RP/0/RSP0/CPU0:PE2-9001-2#show bgp l2vpn evpn rd 10.10.11.11:0 [4][0000.2121.2121.2121.2121][32][10.10.11.11]/128 detail
Sat Aug  5 08:26:04.628 UTC
BGP routing table entry for [4][0000.2121.2121.2121.2121][32][10.10.11.11]/128, Route Distinguisher: 10.10.11.11:0

Local

    10.10.11.11 (metric 10) from 10.10.11.11 (10.10.11.11), if-handle 0x00000000

      Origin IGP, localpref 100, valid, internal, best, group-best, import-candidate, not-in-vrf

      Received Path ID 0, Local Path ID 1, version 10

      Extended community: EVPN ES Import:0021.2121.2121 DF Election:0:0x0008:0

Note: 0000.2121.2121.2121.2121]- ESI identifier

         10.10.11.11 – advertised by PE1

         0021.2121.2121 – this ES import RT Extended Community value is unique to an ESI and PEs configured with the same ESI             identifier import this route.

DF Election

Figure 4. Designated Forwarder Behaviour

Here, the DF Behaviour C2 is multihomed to L3 and L4 Only the L4 which is elected as a DF is responsible for forwarding the BUM traffic (identified by the BUM label) from the core towards the C2, the non-DF device drops this traffic.

Route Type 5 IP Prefix Advertisement Route

The significance of this route type 5 is to advertise the IRB IP address along with the subnet mask in order to peer EVPN PEs. It is used when host routes (32 advertised by Route-Type 2) do not need to be shared with peers, as they do not host the VLAN. However, in order to facilitate inter-subnet communication, route type 5 is advertised.

router bgp 100

 bgp router-id 10.10.5.5

 address-family IPv4 unicast

 !

 address-family vpnv4 unicast

 !

 address-family l2vpn evpn

neighbor 10.10.22.22

  remote-as 100

  update-source Loopback1

  address-family l2vpn evpn

   advertise vpnv4 unicast

Note: The configuration advertise vpnv4 unicast is used to generate route type 5.

RP/0/RSP0/CPU0:PE1-9001-1#show bgp l2vpn evpn rd 10.10.5.5:0 [5][0][24][192.168.200.200.0]/80 detail
Wed Aug 10 19:29:34.439 PDT
BGP routing table entry for [5][0][24][192.168.200.0]/80, Route Distinguisher: 10.10.5.5:0
<snIP>

    Local Label: 24006 (with rewrite);

      10.10.22.22 from 10.10.22.22 (10.10.22.22), if-handle 0x00000000

      Received Label 24012

      Origin incomplete, metric 0  localpref 100, valid, external, best, group-best, import-candidate, not-in-vrf

      Received Path ID 0, Local Path ID 1, version 846

      Extended community: Flags 0x6: RT:1000:1000

      EVPN ESI: 0000.0000.0000.0000.0000, Gateway Address : 0.0.0.0

Note: [192.168.200.0]- IP address of the IRB

          [24] - subnet mask

         24012 - this is the VRF label used to send the packet to this IRB

         RT:1000:1000 - the import route target configured on the VRF in order to import this route

Conclusion

On Cisco IOS XR routers, understanding EVPN route types and correctly configuring EVPN features is crucial for achieving optimal network performance. This allows service providers to build scalable, flexible, and resilient Layer 2 and Layer 3 services, ensuring efficient communication between distributed data centers, cloud services, and end-users.