After reading the L2 Vxlan On Catalyst blog post, I decided to add EVPN configuration templates to netlab-supported Cisco IOS/XE devices. It wasn’t the easiest EVPN implementation I encountered; here’s what I learned (hoping you’ll find it helpful).

Starting with the trivial hiccups:

• Use software release 17.16.01a or later. It looks like you can configure EVPN-with-VXLAN in some prior releases, but it doesn’t work (well?)
• I was able to make EVPN with VXLAN work on Catalyst 8000v, Cisco IOL, and Cisco IOL layer-2 image. The CSR image is not new enough (IOS/XE 17.13 supports EVPN over MPLS but not over VXLAN)
• Catalyst 8000v and CSR can do VXLAN with static ingress replication. The exact same configuration is accepted by Cisco IOL, but does not work.

Next, the mandatory router-versus-switch brouhaha:

IOS/XE routers (Cisco IOL)	IOS/XE switches (Cisco IOL L2)
Has BDI interface	Has vlan interface
Use bridge-domain configuration	Use vlan configuration
Use service instance for access VLAN	Use switchport access vlan for access VLAN
Add service instance to bridge-domain	VLAN is built from switchport VLAN values

That brings us to the EVPN bits:

• You create an EVPN MAC VRF with the l2vpn evpn instance configuration block in which you specify the EVPN instance ID (EVI), RT/RD values, and the encapsulation.
• After creating the MAC VRF instance, you can add it as a member of a bridge-domain or vlan configuration. That’s also where you specify EVI-to-VNI (VXLAN Network Identifier) mapping (totally obvious, right?).
• Oh, the member evpn-instance command does not work¹ until you configure host-reachability protocol bgp on the NVE (VXLAN) interface.

That worked well for L2-only scenarios, as well as asymmetric IRB and centralized routing on IOL. IOL layer-2 image (IOLL2) failed those tests – the VLAN interfaces are down unless an Ethernet interface belonging to that VLAN is up². You have to disable the autostate test on the VLAN interfaces to make many IRB scenarios work.

But wait, it only gets better if you want to be a member of the Kool GIFEE crowd and run EVPN-over-EBGP (even the sane direct EBGP sessions scenario):

• The EBGP EVPN routes with loopbacks as the next hop (the usual setup) are not accepted unless the EBGP session is configured as an ebgp-multihop session. I found no other nerd knob that would say “EBGP next hop could be anything.”
• IOS/XE EVPN implementation desperately tries to change the EVPN BGP next hop on the EBGP sessions. The neighbor next-hop-unchanged (the usual fix) command didn’t work for me; I had to create a route map that set the ip next-hop to unchanged and apply it to outbound EVPN updates.

On the positive side, once you figure things out, even the crazy EBGP-over-EBGP and IBGP-over-EBGP scenarios work flawlessly.

Finally, I haven’t mustered the courage yet to try out the transit VNI and symmetrical IRB. I find the idea of configuring a full-blown VLAN for the transit VNI instead of a single command within the BGP IP VRF configuration a bit disgusting. More to come…