EVPN IRB
Load evpn.irb.init.cfg
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
Explanation
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 BDIn, 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.
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.
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.
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.
Verification
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.
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.
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.
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.
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.
On PE1-PE3, we import the INET RT which is 65000:100. Now the CEs have reachability to 8.8.8.8:
Summary
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.
Last updated
