Redes en centros de datos: EVPN VXLAN

Las redes han cambiado, no lo podemos negar.

Vivimos tiempos en los que los cambios están a la orden del día, y con el avance de la IA los cambios ya no llevan meses o años, llevan días.

Hace un par de años salió el borrador de Ultraethernet, del cual Eduardo Collado hizo un podcast muy bueno.

Ahora tenemos SCION.

Y esto no va a acabar.

En centros de datos (también llamados datacenters o CPD en España, de Centro de Procesamiento de Datos) e ISP el cambio llegó hace un tiempo, pero aunque fue implementándose poco a poco, ya se ha instaurado.

Las infraestructuras crecen: tenemos más servicios, más servidores... Y por ello las redes escalan.

Hasta el cambio de paradigma en los centros de datos, y en el 90% de las empresas a día de hoy, las redes siguen el esquema de 3 capas: Core, Distribución, Acceso.

Pero con la necesidad de escalabilidad se modificó esta visión.

Ahora se implementa una arquitectura spine-leaf, totalmente escalable horizontalmente y que permite la migración de un sitio a otro sin tener que hacer reconfiguraciones en multitud de dispositivos.

---

EVPN VXLAN: La tecnología detrás de los datacenters

Lo primero: ¿qué es EVPN VXLAN?

EVPN VXLAN es la combinación de dos tecnologías que resuelven el problema de escalar las redes L2/L3 en centros de datos modernos.

Este concepto no es algo que se lleve a cabo en pequeñas o medianas empresas, incluso en las grandes. Prácticamente esta relegado a ser usado por ISP o por datacenters en los que se requiere alta disponibilidad y escalabilidad horizontal.

Las tecnologías que usa son las siguientes:

VXLAN (Virtual eXtensible LAN): Es el plano de datos. Se trata de un mecanismo de encapsulación que mete las tramas Ethernet dentro de paquetes UDP/IP, permitiendo así extender dominios L2 sobre una infraestructura IP L3 subyacente, conocida como underlay. De esta forma se puede superar el límite clásico de 4096 VLANs, llegando a un espacio de 16 millones de VNIs (VXLAN Network Identifiers). En este proceso de encapsulación/desencapsulación son los VTEP de llevarlo a cabo, siendo el VTEP el punto final al que llega la VXLAN (un router o un switch L3).

EVPN (Ethernet VPN): Se trata del plano de control. Usa BGP para distribuir información de alcanzabilidad MAC e IP entre los VTEPs.

En Cisco sería el address-family l2vpn evpn. 

Sin EVPN, VXLAN dependía de flood-and-learn o multicast para descubrir MACs remotas, lo cual no escala.

---

Tráfico BUM: cosas a tener en cuenta

Para entender el por qué usamos BGP en el overlay primero hay que explicar algo llamado BUM.

BUM son las siglas de Broadcast, Unknown Unicast y Multicast. Este tráfico es el que se transporta constantemente a través de la red. Cuando tratamos de conectar de un host en un leaf a otro host en otro leaf se envía tráfico BUM para averiguar detrás de qué VTEP se encuentra. Si usaramos flood-and-learn, la tabla CAM guardaría la dirección y dónde se encuentra, pero al aprenderlo por dataplane y no por control plane tiene un aging timeout, por lo que cuando caduca se vuelve a hacer flood.Con EVPN, al hacer un ARP gratuito o al encender la máquina la tabla CAM local aprende su MAC y mediante BGP Route Type 2 se anuncia a los spine y se reenvia a los leaf.

---

Manos a la obra: el laboratorio

Tenemos un escenario en el que hay 3 leaf y dos spine. Vamos a hacer uso de ECMP para que la carga se distribuya entre ambos enlaces.

En el leaf1 tenemos la vlan10 con IP 192.168.10.1/24 y un host con IP 192.168.10.2, mientras que en leaf3 tenemos la vlan10 con IP 192.168.10.1/24 y un host con IP 192.168.10.3.

Configuración de hostname y direcciones IP loopback

En primer lugar deberemos hacer las configuraciones básicas, como el hostname y las direcciones IP que van a entrar en funcionamiento en el underlay. Esto incluye las direcciones IP en las interfaces de loopback.

SPINE1:

configure
hostname spine1
!
interface e1/1
ip address 10.0.0.1/30
mtu 9216
no shutdown
!
interface e1/2
ip address 10.0.1.1/30
mtu 9216
no shutdown
!
interface e1/3
ip address 10.0.2.1/30
mtu 9216
no shutdown
!
interface loopback 0
ip address 1.1.1.1/32
!

SPINE2:

configure
hostname spine2
!
interface e1/1
ip address 10.1.0.1/30
mtu 9216
no shutdown
!
interface e1/2
ip address 10.1.1.1/30
mtu 9216
no shutdown
!
interface e1/3
ip address 10.1.2.1/30
mtu 9216
no shutdown
!
interface loopback 0
ip address 1.1.1.2/32
!

En los leaf, como van a ir conectados dispositivos finales con vlan, deberemos habilitar la feature que permite crear interfaces SVI, o interfaces de VLAN.

LEAF1:

configure
hostname leaf1
!
feature interface-vlan
!
interface Vlan10
no shutdown
ip address 192.168.10.1/24
fabric forwarding mode anycast-gateway
!
interface Ethernet1/1
mtu 9216
ip address 10.0.0.2/30
no shutdown
!
interface Ethernet1/2
mtu 9216
ip address 10.1.0.2/30
!
interface Ethernet1/3
switchport
switchport access vlan 10
no shutdown
!

LEAF3:

configure
hostname leaf3
!
feature interface-vlan
!
interface Vlan10
no shutdown
ip address 192.168.10.1/24
fabric forwarding mode anycast-gateway
!
interface Ethernet1/1
mtu 9216
ip address 10.1.2.2/30
no shutdown
!
interface Ethernet1/2
mtu 9216
ip address 10.0.2.2/30
!
interface Ethernet1/3
switchport
switchport access vlan 10
no shutdown
!

Como podemos comprobar, hemos aumentado el MTU para disponer de Jumboframes, ya que VXLAN añade cabeceras que pueden no funcionar con un MTU de 1500.

El siguiente paso que debemos seguir es el de crear la red subyacente mediante la que se van a compartir las rutas para saber donde tienen que llegar los paquetes. La red underlay.

Red underlay: configuración de OSPF

Para hacer esto haremos uso de las interfaces loopback y las redistribuiremos mediante OSPF.

Deberemos habilitar la feature correspondiente y configurar OSPF, añadiendo las interfaces que pertenecerán a la red OSPF.

SPINE1:

configure
feature ospf
!
router ospf UNDERLAY
router-id 1.1.1.1
!
int lo0
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/1
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/2
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/3
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!

SPINE2:

configure
feature ospf
!
router ospf UNDERLAY
router-id 1.1.1.1
!
int lo0
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/1
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/2
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/3
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!

LEAF1:

configure
feature ospf
!
router ospf UNDERLAY
router-id 2.2.2.2
!
int lo0
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/1
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/2
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!

LEAF3:

configure
feature ospf
!
router ospf UNDERLAY
router-id 4.4.4.4
!
int lo0
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/1
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!
int e1/2
ip ospf network point-to-point
ip router ospf UNDERLAY area 0.0.0.0
!

Y podremos comprobar como ya se han creado las adyacencias con los router que tenemos conectados.

Configuración de EVPN

Como se ha comentado anteriormente, EVPN hace uso de BGP como plano de control, por lo que deberemos habilitar la feature correspondiente. 

En todos los equipos de la fabric:

configure
feature bgp

Y en los leaf, además, deberemos habilitar las feature para usar vxlan:

configure
feature vn-segment-vlan-based
feature nv overlay

Y deberemos habilitar la address-family l2vpn evpn mediante el comando en todos los equipos de la fabric:

nv overlay vpn

Configuramos BGP con la correspondiente address-family:

SPINE1:

router bgp 100
  bestpath as-path multipath-relax
  address-family l2vpn evpn
    maximum-paths 4
    retain route-target all
!
  neighbor 2.2.2.2 remote-as 200
    update-source loopback0
    ebgp-multihop 2
    address-family l2vpn evpn
      send-community
      send-community extended
      route-map EVPN_NHS out
!
  neighbor 3.3.3.3
    remote-as 300
    update-source loopback0
    ebgp-multihop 2
    address-family l2vpn evpn
      send-community
      send-community extended
      route-map EVPN_NHS out
!
  neighbor 4.4.4.4
    remote-as 400
    update-source loopback0
    ebgp-multihop 2
    address-family l2vpn evpn
      send-community
      send-community extended
      route-map EVPN_NHS out
!

SPINE2:

router bgp 100
  bestpath as-path multipath-relax
  address-family l2vpn evpn
    maximum-paths 4
    retain route-target all
!
  neighbor 2.2.2.2 remote-as 200
    update-source loopback0
    ebgp-multihop 2
    address-family l2vpn evpn
      send-community
      send-community extended
      route-map EVPN_NHS out
!
  neighbor 3.3.3.3
    remote-as 300
    update-source loopback0
    ebgp-multihop 2
    address-family l2vpn evpn
      send-community
      send-community extended
      route-map EVPN_NHS out
!
  neighbor 4.4.4.4
    remote-as 400
    update-source loopback0
    ebgp-multihop 2
	address-family l2vpn evpn
      send-community
      send-community extended
      route-map EVPN_NHS out
!

LEAF1:

router bgp 200
  bestpath as-path multipath-relax
  address-family ipv4 l2vpn evpn
    maximum-paths 4
! 
  neighbor 1.1.1.1
    remote-as 100
    update-source loopback0
    ebgp-multihop 2
    address-family l2vpn evpn
      send-community
      send-community extended
! 
  neighbor 1.1.1.2
    remote-as 100
    update-source loopback0
    ebgp-multihop 2
    address-family l2vpn evpn
      send-community
      send-community extended
!

LEAF3:

router bgp 400
  bestpath as-path multipath-relax
  address-family ipv4 l2vpn evpn
    maximum-paths 4
! 
  neighbor 1.1.1.1
    remote-as 100
    update-source loopback0
    ebgp-multihop 2
    address-family l2vpn evpn
      send-community
      send-community extended
! 
  neighbor 1.1.1.2
    remote-as 100
    update-source loopback0
    ebgp-multihop 2
    address-family l2vpn evpn
      send-community
      send-community extended
!

Para poder proceder deberemos crear primero un route-map en los spine:

route-map EVPN_NHS permit 10
  set ip next-hop unchanged

Con este route-map le decimos a los spine que no sobreescriban el next-hop por sí mismos, ya que los leaf intentarían encapsular VXLAN hacia el spine en lugar del leaf remoto.

Afinando BGP: parámetros a tener en cuenta

Como se ve en los bloques de configuración de arriba se han puesto algunos parámetros que se explican a continuación:

bestpath as-path multipath-relax 

Permite que BGP considere como equivalentes paths con distinto AS-path para ECMP.

maximum-paths 4 

Instala hasta 4 paths en la tabla para una misma ruta EVPN. Sin esto, solo el best path se instala aunque haya varios equivalentes.

retain route-target all

El spine no tiene VNIs ni VRFs configurados, así que por defecto descartaría las rutas EVPN porque no tiene ningún RT importado localmente. Esto le dice que se quede con las rutas EVPN sin importar el RT para poder reenviarlas a los leafs.

update-source loopback0

Establece la sesión BGP desde la loopback en lugar de la IP física. Es un estándar para que la sesión no dependa de una interfaz concreta.

ebgp-multihop 2 

Permite que la sesión eBGP funcione entre loopbacks. El TTL por defecto de eBGP es de 1. Con esto lo subimos a dos, ya que son los saltos que realiza hasta llegar a la interfaz loopback.

send-community
send-community extended 

Envía las communities estándar y extendidas al vecino. EVPN necesita las extended communities para transportar los Route Targets (Import/Export). Si esto, los leaf reciben las rutas pero sin RT y no saben a qué VNI las debe importar.

route-map EVPN_NHS out 

Aplica el route-map especificado.

Creando la VXLAN y su interfaz

Primero, en la vlan que queremos asignar a una VXLAN:

vlan 10
  vn-segment 1010

Aquí le estamos diciendo que la vlan 10 pertenece a la vxlan 1010.

Luego procedemos a crear la interfaz nve.

interface nve1
  no shutdown
  host-reachability protocol bgp
  source-interface loopback0
  member vni 1010
    ingress-replication protocol bgp

Una interfaz NVE es la interfaz lógica que representa al VTEP. Es el punto donde se encapsula y desencapsula la VXLAN.

host-reachability protocol bgp 

Usa BGP para aprender MACs/IPs remotas en lugar de flood-and-learn.

source-interface loopback0

La IP de la loopback que se usa como dirección origen/destino de los túneles VXLAN.

member vni 1010 Asocia el VNI 1010 (la VXLAN) a esta NVE.

ingress-replication protocol bgp 

Para tráfico BUM (broadcast, unknown unicast, multicast) descubre dinámicamente vía BGP a qué VTEPs replicar en vez de listarlo a mano.

Si no usaramos EVPN podríamos usar el comando anterior pero en lugar de BGP podríamos poner static y no haría falta hacer uso de host-reachabilty protocol bgp.

Exportando e importando rutas

Las VXLAN deben importar y exportar los mismos RT (Route Target). Los Route Target son etiquetas de import/export para decidir qué rutas van a qué VNI o VRF.

En ambos leaf configuramos:

evpn
  vni 1010 l2
    rd auto
    route-target import 65000:1010
    route-target export 65000:1010
!

Comprobación de rutas aprendidas por EVPN

Tan solo encendiendo los hosts en cada leaf ya se distribuyen las rutas por EVPN

---

Comandos útiles para troubleshooting

show bgp ipv4 unicast summary 

Comprobar la adyacencia de BGP

show bgp ipv4 unicast 

Ver prefijos aprendidos por BGP

show bgp l2vpn evpn summary 

Ver los prefijos aprendidos por BGP mediante EVPN

show ip ospf neighbors 

Ver la adyacencia de OSPF

show ip route ospf 

Ver las rutas aprendidas por OSPF

show nve peers 

Comprobar el estado de los peer VTEP

show nve vni 

Comprobar los VNI activos y asociados

¡Nos vemos en siguientes entradas!