# EVPN IRB

Load **evpn.irb.init.cfg**

```
#IOS-XE (PE1-4, CE1,3,4,5)
config replace flash:evpn.irb.init.cfg
 
#IOS-XR (P1-2)
configure
load evpn.irb.init.cfg
commit replace
y
```



#### Background

Two EVIs, 10 and 20, are preconfigured. CE1 and CE3 belong to EVI 10, which is 192.168.10.0/24. CE4 belongs to EVI 20 in 192.168.20.0/24.



CE5 is preconfigured with 8.8.8.8, which is reachable via PE4 in a VRF. All CEs are preconfigured with default routing, using a gateway of 192.168.X.254. CE5 uses a BGP-learned 0/0 route.



P1 is a RR for l2vpn/evpn, and P2 is a RR for vpnv4/unicast. P2 configures only PE4 as a RR client. This prevents PE1-PE3 from learning routes from each other for 192.168.X.0/24 via vpnv4. (This is just to prove that EVPN IRB works with L2VPN/EVPN alone).



#### Instructions

Configure EVPN IRB so that EVIs 10 and 20 have reachability via routed EVPN. Use a VRF called “VRF A” using import/export of RT 65000:50. Additionally, configure EVPN-VPNv4 interworking so that the CEs can ping 8.8.8.8, which is on CE5.









































## Answer <a href="#b493170c-723d-41f4-bc3b-1468346cd8c1" id="b493170c-723d-41f4-bc3b-1468346cd8c1"></a>

```
#PE1, PE2
vrf def A
 rd 65000:50
 add ipv4
  route-target both 65000:50
  route-target both 65000:50 stitching
  route-target import 65000:100
!
int bdi 10
 vrf forwarding A
 ip add 192.168.10.254 255.255.255.0
 mac-address 0000.1111.2222
 no shut
!
router bgp 65000
 add ipv4 vrf A
  advertise l2vpn evpn
  redistribute connected

#PE3
vrf def A
 rd 65000:50
 add ipv4
  route-target both 65000:50
  route-target both 65000:50 stitching
  route-target import 65000:100
!
int bdi 20
 vrf forwarding A
 ip add 192.168.20.254 255.255.255.0
 mac-address 0000.2222.3333
 no shut
!
router bgp 65000
 add ipv4 vrf A
  advertise l2vpn evpn
  redistribute connected

#PE4
vrf def INET
 add ipv4
  route-target import 65000:50
```



## Explanation <a href="#id-2c48b0f9-022d-44bc-b7b0-3485e4d68742" id="id-2c48b0f9-022d-44bc-b7b0-3485e4d68742"></a>

EVPN IRB (Integrated Routing and Bridging) allows for routing between EVIs within EVPN itself. This uses type 5 routes, which are IP prefix routes. These are basically a one-for-one replacement for VPNv4, and in fact, the IOS-XE implementation seems to rely on translating type 5 routes into VPNv4 routes internally to make this work.



EVPN IRB involves two things: distributed anycast gateway (abbreviated DAG) among all PEs for each EVI, and advertisement of prefixes. To implement the anycast gateway, we configure the gateway IP address on all PEs participating in each EVI, along with the same MAC address.



Cisco only supports EVPN IRB with single-homing using DAG with symmetric IRB. Symmetric IRB means that both the ingress and egress PE preforming bridging and routing. The workflow looks like this:

* The frame is received from a CE and bridged to the ingress BDI
* The ingress PE performs a routing lookup, and the ingress PE uses L3VPN to route the packet to the egress PE
* The egress PE receives an L3VPN packet and does a routing lookup
* The egress PE finds that the final destination is directly connected at L2, and the egress PE does a bridging operation to switch the frame to the destination CE



PE1 and PE2 are participating in EVI 10, so we configure the CEs’ default gateway on interface BD&#x49;_&#x6E;_, where _n_ is the bridge-domain number. We need to ensure the MAC address is the same on all PEs in case a host moves from one PE to another.

```
int BDI10
 vrf forwarding A
 ip add 192.168.10.254 255.255.255.0
 mac-address 0000.1111.2222
 no shut
```



Second, we need to place the BDIs for all EVIs for which we want L3 reachability into the same VRF. In this lab we simply used vrf “A.” The VRF requires VPNv4 RTs and EVPN RTs. The EVPN RTs are configured using the **stitching** keyword. Think of this as stitching EVPN into VPNv4 functionality. Also notice above that the BDIs belong to this VRF.

```
vrf def A
 rd 65000:50
 add ipv4
  route-target both 65000:50
  route-target both 65000:50 stitching
```



Finally we must redistribute the connected route into VPNv4 and configure the router to generate an EVPN type 5 route. The type 5 route is generated using the **advertise l2vpn evpn** command.

```
router bgp 65000
 add ipv4 vrf A
  advertise l2vpn evpn
  redistribute connected
```



You may be wondering what happens if we leave out parts of this configuration:

* If **advertise l2vpn evpn** is left out, the router only generates VPNv4 routes. It does not generate type 5 EVPN routes.
* If the **stitching** RTs are not defined, the router does not put an RT on advertised type 5 routes, but continues generating them. It will not import any EVPN type 5 routes either.
* The VPNv4 RTs and EVPN RTs can be different values
* If we do not use VPNv4 RTs and only define **stitching** RTs, the locally generated/advertised VPNv4 routes will be missing an RT, but the EVPN type 5 routes will continue to work. The matching remote EVPN type 5 routes will still be translated into local VPNv4 routes and imported into the RIB. Therefore, EVPN IRB can work with only **stitching** RTs alone.



The second requirement is for the L3VPN on PE4 to interwork with the EVPN VRF. To achieve this we use basic VPNv4 RT import statements. We import the INET VRF RT on PE1-3 and import the EVPN RT on PE4.

```
#PE1-3
vrf def A
 rd 65000:50
 add ipv4
  route-target import 65000:100

#PE4
vrf def INET
 add ipv4
  route-target import 65000:50
```



## Verification <a href="#a42547d5-d1bd-44bd-9ead-ce3483f582e1" id="a42547d5-d1bd-44bd-9ead-ce3483f582e1"></a>

On PE1 we should see two type 5 routes. One for 192.168.10.0/24 generated locally, and one for 192.168.20.0/24 generated by PE3.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2F2Wc4DwAM1RrUgecXI2W2%2Fimage.png?alt=media&#x26;token=310f40e9-0efd-40dd-812d-adf755f52b14" alt=""><figcaption></figcaption></figure></div>



The local 192.168.10.0/24 was generated using **advertise l2vpn evpn**. The remote 192.168.20.0/24 route is imported from the EVPN table into the local VPNv4 table. This allows the prefix to then be injected into the RIB just like any normal VPNv4 route. The label learned in the type 5 route is used for the local VPNv4 route. Notice that the VPNv4 route says “**imported path from \<EVPN NLRI>**.” This VPNv4 route is not learned via BGP, because PE1 and PE3 are not RR clients for VPNv4.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FED71PheA6vgcMGuzhNsU%2Fimage.png?alt=media&#x26;token=40966a42-7c9a-4c63-8adc-98997501fdf8" alt=""><figcaption></figcaption></figure></div>



Once these routes are imported, CE1 should have reachability to CE4. The path is no different than if we were using normal L3VPN. The service label in this case is 39, and the transport label is 24002.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FMshS6iESdKfvwpBAMDun%2Fimage.png?alt=media&#x26;token=f305a101-e261-420d-8d29-0029663203c5" alt=""><figcaption></figcaption></figure></div>



Because EVPN type 5 routes are literally translated into VPNv4 routes, you can achieve the same result using only regular L3VPN, and not using EVPN. However, the “special sauce” of EVPN IRB is the anycast gateway. (Which is the identical BDI interface on all PEs for a given EVI). It seems that using EVPN route-type 5 is only useful when supporting a DC infrastructure with leafs that do not run VPNv4/v6.



On IOS-XE, type 2 routes still do not have IP addresses associated. This is a limitation of the current version of CSR1000v. Also, this version does not support IRB with multi-homed CEs. Notice that PE1 will not learn MACs for EVI 20, because it does not participate in EVI 20. All it knows is a L3 route for 192.168.20.0/24 via PE3.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FtZLv0fpMeSi6Ydey2FRY%2Fimage.png?alt=media&#x26;token=ca2474e4-08ae-43df-b5f6-ad3795d29e48" alt=""><figcaption></figcaption></figure></div>

* CE3 has been silent, so this locally-inject MAC route is the only type 2 route in PE1’s EVPN BGP table.



Reachability between the CEs and 8.8.8.8 is achieved via normal L3VPN RT configuration. On PE4, we must import the EVPN RT which is 65000:50.

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FQUthsN2Bpi1SQ7tp3bR4%2Fimage.png?alt=media&#x26;token=25eb99d8-3599-49f2-9a27-0c69dc9136d9" alt=""><figcaption></figcaption></figure></div>



On PE1-PE3, we import the INET RT which is 65000:100. Now the CEs have reachability to 8.8.8.8:

<div align="left"><figure><img src="https://3072390383-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FkUz2C3GqnZcWhoVL6jfk%2Fuploads%2FhSUpk2UxWXgstvqIm7ah%2Fimage.png?alt=media&#x26;token=616efad2-7c26-4430-b6f9-ad7d0275ca02" alt=""><figcaption></figcaption></figure></div>



## Summary <a href="#e7eed367-9de1-4e9a-899f-3ef063c15857" id="e7eed367-9de1-4e9a-899f-3ef063c15857"></a>

EVPN IRB involves these high-level tasks:

* Configure a normal VRF on all PEs
  * The normal RTs are used for L3VPN (VPNv4/v6 unicast)
  * The **stitching** RTs are used for EVPN
* Configure a BDI for the EVI on all PEs using anycast IP and the same MAC. This BDI must belong to the VRF.
  * This is called DAG (distributed anycast gateway)
* Advertise routes via VPNv4/v6 as normal. The normal RTs are used for import/export with VPNv4/v6. The **advertise l2vpn evpn** command under the BGP VRF causes VPN routes to be translated into EVPN type 5 routes. The **stitching** RTs are used for the EVPN type 5 routes.

```
vrf def A
 rd 65000:50
 add ipv4
  route-target both 65000:50                ! VPNv4/v6 RTs
  route-target both 65000:50 stitching      ! EVPN RTs
!
int bdi 10
 vrf forwarding A
 ip add 192.168.10.254 255.255.255.0        ! Anycast IP
 mac-address 0000.1111.2222                 ! Same on all PEs
 no shut
!
router bgp 65000
 add ipv4 vrf A
  advertise l2vpn evpn                      ! Causes VPN routes to be translated into EVPN routes
  ! network/redist statements go here as usual
```
