VXLAN to EVPN conversion

[waqas gondal]

Hello,

I have a VXLAN configuration that is just flood and learn and was wondering if it is possible to migrate this to an EVPN.

What I have is 2 Nexus 9k VTEPs at one site and the same at the remote site. There is no multicast, only static ingress replication between sites because they are only back to back.

In my research for EVPN designs I found the architecture requires an additional layer of nexus switches where the VTEPs become the leaf and the new Nexus switches become the spine. 

Basically my question is, do I need to purchase additional switches to be the spine or can the VTEPs I already have be the spine and leaf?

If they can be the spine and leaf what would the configuration look like to have a distributed gateway with anycast RP?

Thanks,

Waqas

[Hector Gustavo Serrano Gutierrez]

Hi @waqas gondal,

If you already have VXLAN Flood & Learn (F&L) up and running, the addition of BGP EVPN to your devices will bring many advantages to your VXLAN network like Control Plane MAC and IP distribution (via BGP EVPN), enable Routing on your fabric in the form of Anycast Gateway, Tenant Multicast Routing, Layer 3 connectivity to WAN Routers on the Border Leaf Switches, etc etc etc.

VXLAN F&L only provides the fundamental functionality which is Layer 2 forwarding over a Layer 3 network using Data Plane MAC address learning.

So, in my opinion it is better to add BGP EVPN to an existing VXLAN F&L network environment.

I do not have the details of how you have your existing Switches connected, what exact hardware model they are nor the software version running on them to know if they indeed support BGP EVPN but that can be figured out quickly doing some research on public documentation.

As per the design, the most common topology is CLOS (Leaf and Spines) where Leaf switches (aka VTEPs) connect only to the Spines and End hosts (i.e. Servers) connect to the Leaf Switches.

About the configuration, VXLAN Network with MP-BGP EVPN Control Plane Design Guide is a wonderful resource, but let me know if you have any questions.

Cheers.

[waqas gondal]

Hi Hector

Our topology is simple, see attached.

The configs also don't have any vrf.

I was wondering if HSRP over VXLAN would be an easier solution to moving everything to EVPN. HSRP over VXLAN is only supported with flood and learn.

[Hector Gustavo Serrano Gutierrez]

Hi @waqas gondal,

Both VXLAN (F&L and BGP EVPN) are most commonly seen in a CLOS topology (Spines & Leaf switches).

I see BGP EVPN more like an enhancement to F&L.

You do not have a CLOS topology but you can still add BGP EVPN to your existing switches if you wish.

So, going back to your original question, you don't really have to purchase additional equipment to enable BGP EVPN.

With BGP EVPN you can have your Leaf switches (aka VTEPs) be the Default Gateway of your hosts in the vlans.

With F&L the Default Gateway should be a device connected to the VTEPs but not the VTEP itself.

I hope this helps.

Best Regards.

[waqas gondal]

Thanks Hector,

In our case we are using the VTEPs as the gateway for the server subnets. I reviewed the F&L config with TAC and it is supported.

I guess now I will need to learn how to configure the VTEPs as spine and leaf or if HSRP is the simpler solution.

Thanks for your help!

Waqas

[Brandon Rumer (Cisco)]

Keep in mind that since the VTEPs are close to the edge devices, that configuring an anycast gateway greatly standardizes your VTEP configuration. Furthermore, you have the benefit of a gateway on every edge device (VTEP) vs kinda faking the funk with HSRP in this scenario. IMO, using HSRP in this configuration would be a bit odd vs implementing anycast gateway.

[waqas gondal]

Thanks brumer.

What I am trying to understand with our topology is what the configuration would look like if the VTEPs had both the spine and leaf roles.

Also if it requires a major disruption to change all the SVIs to use VRF forwarding it would be difficult to justify. 

Regards,

Waqas

[Hector Gustavo Serrano Gutierrez]

I agree with @Brandon Rumer (Cisco),

The Anycast Gateway approach in VXLAN BGP EVPN is more beneficial than the Centralized Layer 3 gateway supported in VXLAN Flood & Learn.

"For flood and learn mode (7.0(3)I2(1) and later), only a centralized Layer 3 gateway is supported. Anycast gateway is not supported. The recommended Layer 3 gateway design would be a pair of switches in VPC to be the Layer 3 centralized gateway with FHRP protocol running on the SVIs. The same SVI's cannot span across multiple VTEPs even with different IP addresses used in the same subnet."

Cisco Nexus 9000 Series NX-OS VXLAN Configuration Guide, Release 7.x
Chapter: Configuring VXLAN

Yes, the Anycast Gateway approach in VXLAN BGP EVPN requires to have the SVIs facing the Servers in a specific VRF and not in the Default VRF.

The role of the Spine is mainly to be a Layer 3 hop interconnecting the Leaf Switches in the CLOS topology. The Spines also host some Control-Plane functionalities like act as the PIM Rendezvous Point (RP) and BGP EVPN Route Reflectors (RR) for the VXLAN fabric.

So, if you do not have a CLOS topology and chose to add BGP EVPN to your VXLAN fabric, you can either have a full mesh of iBGP EVPN sessions between your Leaf Switches or chose one or two of them to act as Route Reflectors.

This document contains a template of how the VXLAN configuration looks like on Leaf and Spines.

Configure Centralized Route Leak Feature in VXLAN BGP EVPN

Hope this helps.

Regards.

[waqas gondal]

Thanks Hector,

We are using static ingress replication instead of multicast. Would that have any change in EVPN design?

[Hector Gustavo Serrano Gutierrez]

Hi @waqas gondal,

With ingress replication you do not need to have Multicast PIM in the underlay.

BGP EVPN can use ingress replication too so no need to take any additional considerations if you stick with ingress replication.

Cheers.