EVPN-VXLAN permite construir redes de datacenter donde la infraestructura física funciona de extremo a extremo sobre IP, mientras los segmentos de clientes, las redes virtuales y las políticas se crean en un plano superpuesto. El resultado no elimina la capa 2, pero evita extenderla físicamente por todos los switches, reduce la dependencia de Spanning Tree Protocol (STP) y proporciona un plano de control capaz de distribuir direcciones MAC, IP y prefijos mediante BGP.

Las claves de EVPN-VXLAN en 30 segundos

• El underlay es una red IP enrutada, normalmente con una topología leaf-spine.
• VXLAN encapsula Ethernet sobre UDP y asigna un identificador VNI a cada red virtual.
• BGP EVPN distribuye la localización de endpoints, gateways y prefijos entre los VTEP.
• El fabric puede usar todos los enlaces disponibles mediante ECMP, sin bloquear caminos como haría STP.
• EVPN-VXLAN mejora el aislamiento y la escalabilidad, pero exige cuidar la MTU, el diseño BGP, el tráfico BUM y la automatización.

Durante años, muchos datacenters crecieron añadiendo VLAN, enlaces trunk y pares de switches con tecnologías de agregación multichasis. El modelo sigue siendo válido para entornos pequeños y medianos, pero empieza a mostrar limitaciones cuando deben conectarse cientos de racks, alojar numerosos clientes o mantener movilidad de cargas sin ampliar el dominio de fallo.

EVPN-VXLAN cambia la pregunta. En lugar de buscar cómo llevar cada VLAN a todos los rincones del datacenter, plantea dónde necesita existir cada servicio y cómo anunciarlo sobre una red IP estable.

El problema de los grandes dominios de capa 2

Una red Ethernet tradicional aprende la ubicación de los equipos observando las direcciones MAC de las tramas que recibe. Cuando desconoce dónde se encuentra un destino, replica el tráfico por los puertos correspondientes. Los mensajes de broadcast y parte del multicast también se distribuyen por el dominio de capa 2.

Mientras el entorno permanece acotado, este comportamiento resulta manejable. Las dificultades aumentan cuando una misma VLAN atraviesa numerosos racks o incluso varios edificios:

• Crece el alcance de los broadcasts.
• Un error de configuración puede afectar a una zona mayor.
• Aumenta el tráfico de destino desconocido.
• STP puede dejar enlaces sin utilizar para prevenir bucles.
• El diagnóstico depende de seguir VLAN, trunks y tablas MAC por muchos equipos.
• Los cambios afectan a un dominio operativo cada vez más amplio.

El problema no es la existencia de Ethernet, sino convertir todo el datacenter en una gran red conmutada. La capa 2 continúa siendo necesaria en el acceso de los servidores y en servicios concretos, pero no tiene por qué formar también la red de transporte entre todos los switches.

EVPN-VXLAN establece esa separación. La conectividad física entre nodos se resuelve mediante routing IP. Los servicios Ethernet o IP de cada cliente circulan por encima, encapsulados y aislados.

Underlay y overlay: dos redes con funciones distintas

La arquitectura se entiende mejor al dividirla en dos planos.

El underlay IP

El underlay es la red física que interconecta los switches. En un datacenter suele adoptar una topología leaf-spine basada en una arquitectura Clos:

• Los switches leaf conectan servidores, cabinas, firewalls u otros equipos.
• Cada leaf se enlaza con todos los spine.
• Los spine transportan tráfico entre leaf y no necesitan conocer las VLAN de los clientes.

Esta topología ofrece varios caminos de coste equivalente. El tráfico puede distribuirse mediante Equal-Cost Multi-Path (ECMP), lo que permite utilizar simultáneamente los enlaces disponibles y conservar rutas alternativas ante una avería.

El protocolo del underlay puede ser eBGP, OSPF o IS-IS, según la plataforma y el diseño. Su requisito esencial es proporcionar conectividad IP estable entre los VXLAN Tunnel Endpoints (VTEP), que normalmente utilizan direcciones de loopback como extremos de los túneles.

El underlay debe funcionar antes de construir el overlay. Si dos VTEP no pueden comunicarse por IP, VXLAN tampoco podrá transportar los servicios entre ellos.

El overlay de servicios

El overlay contiene las redes virtuales que consumen los servidores y clientes. Puede ofrecer conectividad de capa 2, routing entre subredes y separación mediante VRF.

Los leaf que actúan como VTEP encapsulan el tráfico al entrar en el overlay y lo desencapsulan al llegar al destino. Para los spine, esos paquetes son tráfico IP ordinario: no necesitan saber qué MAC, VLAN o cliente viaja dentro.

Esta independencia permite modificar los servicios del overlay sin rediseñar la topología física. También facilita reutilizar un mismo fabric IP para numerosos clientes aislados.

Qué aporta VXLAN

VXLAN, acrónimo de Virtual eXtensible Local Area Network, encapsula una trama Ethernet dentro de un paquete UDP. El encabezado exterior contiene las direcciones IP de los VTEP de origen y destino, de modo que el underlay puede enrutarlo como cualquier otro paquete.

Cada segmento utiliza un VXLAN Network Identifier (VNI) de 24 bits. Esto proporciona cerca de 16,7 millones de identificadores posibles, frente al espacio de 12 bits de las VLAN IEEE 802.1Q, limitado en la práctica a 4.094 valores utilizables.

Una asociación sencilla podría ser:

Elemento tradicional	Equivalente en el overlay
VLAN	VNI de capa 2
Dominio de broadcast	Bridge domain
Tabla de routing del cliente	VRF
Transporte por trunks	Túneles VXLAN sobre IP
Switch que encapsula	VTEP

VXLAN es el plano de datos. Indica cómo transportar el tráfico, pero por sí solo no determina de forma eficiente dónde está cada endpoint. El diseño original descrito en la RFC 7348 admite mecanismos de flood and learn, donde la red replica parte del tráfico para descubrir destinos.

BGP EVPN incorpora el plano de control que permite evitar buena parte de ese aprendizaje por inundación.

Cómo funciona BGP EVPN

Ethernet VPN (EVPN) utiliza Multiprotocol BGP para intercambiar información sobre los servicios del overlay. Los VTEP anuncian qué endpoints tienen conectados y el resto del fabric aprende cómo alcanzarlos.

Entre los tipos de rutas más habituales se encuentran:

• Tipo 2, MAC/IP Advertisement: anuncia una dirección MAC y, cuando está disponible, su IP asociada.
• Tipo 3, Inclusive Multicast Ethernet Tag: informa de la pertenencia de un VTEP a un dominio y ayuda a construir la distribución del tráfico broadcast, unknown unicast y multicast.
• Tipo 5, IP Prefix: publica prefijos IP de una VRF sin necesidad de asociarlos a una dirección MAC de host.

Las rutas llevan atributos como Route Distinguisher y Route Target. El primero permite que rutas potencialmente idénticas sean únicas dentro de BGP. Los Route Target controlan qué VRF o instancia EVPN importa y exporta cada información.

En un fabric de cierto tamaño no suele resultar conveniente crear una sesión BGP completa entre todos los leaf. Los spine pueden actuar como route reflectors, recibiendo y redistribuyendo las rutas EVPN sin participar necesariamente como VTEP en el tráfico de datos.

Esta separación también mejora la observabilidad. El operador puede consultar en BGP dónde se anunció una MAC, qué VTEP la origina y a qué VNI pertenece, en lugar de depender únicamente de tablas aprendidas salto a salto.

Un ejemplo de comunicación entre dos racks

Supongamos que el servidor A está conectado al leaf 1 y el servidor B al leaf 4. Ambos pertenecen al VNI 10100.

El proceso simplificado es el siguiente:

1. El leaf 1 aprende localmente la MAC y la IP del servidor A.
2. Publica esa información mediante una ruta EVPN de tipo 2.
3. El leaf 4 hace lo mismo con el servidor B.
4. Ambos VTEP conocen así la ubicación remota de cada endpoint.
5. Cuando A envía una trama a B, el leaf 1 la asocia al VNI 10100.
6. El leaf encapsula la trama en VXLAN y añade las IP exteriores de los VTEP.
7. El underlay enruta el paquete por uno de los caminos ECMP disponibles.
8. El leaf 4 elimina la encapsulación y entrega la trama al servidor B.

Desde el punto de vista de los servidores, ambos pueden seguir dentro del mismo segmento lógico. Sin embargo, los enlaces entre racks no transportan esa VLAN mediante trunks Ethernet: transportan paquetes IP encapsulados.

Por eso resulta más preciso decir que EVPN-VXLAN evita extender físicamente la capa 2 por todo el fabric. El overlay todavía puede ofrecer una extensión lógica de capa 2 cuando una aplicación la necesita.

Menos flooding, pero no flooding cero

BGP EVPN reduce la inundación de tráfico, aunque no la elimina por completo.

El tráfico BUM, correspondiente a broadcast, unknown unicast y multicast, sigue necesitando un método de distribución. Puede resolverse mediante multicast en el underlay o mediante ingress replication, donde el VTEP de entrada envía una copia a cada VTEP interesado.

EVPN también puede facilitar la supresión de ARP y Neighbor Discovery. Al conocer mediante rutas de tipo 2 la relación entre direcciones IP y MAC, un VTEP puede responder localmente a determinadas consultas en lugar de replicarlas por todo el segmento.

No obstante, la eficacia depende de la implementación, la configuración y la calidad de la información aprendida. Diseñar EVPN-VXLAN no consiste en activar un protocolo y asumir que cualquier flooding desaparecerá.

Routing distribuido y gateway anycast

Una de las capacidades más útiles es situar el gateway de una subred directamente en los leaf.

Con un anycast gateway, varios leaf presentan a los servidores la misma dirección IP y la misma MAC virtual como puerta de enlace. Cada carga utiliza el gateway local, por lo que el tráfico entre subredes puede enrutarse cerca de su origen sin atravesar un par central de routers.

El estándar de Integrated Routing and Bridging (IRB) contempla modelos asimétricos y simétricos. En grandes fabric multi-tenant suele resultar habitual el IRB simétrico:

• El VTEP de entrada enruta el paquete hacia la VRF correspondiente.
• El tráfico cruza el overlay mediante un VNI de capa 3.
• El VTEP de salida lo entrega al segmento del destinatario.

Este modelo evita que todos los leaf tengan que alojar todas las VLAN de una VRF y suele ofrecer una escalabilidad más ordenada. Su diseño exige entender bien los VNI de capa 2, los VNI de capa 3, las VRF y las políticas de importación y exportación.

Multihoming activo-activo sin depender de STP

EVPN también contempla conexiones redundantes de un servidor, firewall o switch hacia más de un leaf. Mediante un Ethernet Segment Identifier (ESI), los VTEP pueden anunciar que comparten el mismo segmento.

El modo all-active permite aprovechar simultáneamente los enlaces y coordinar funciones como:

• Selección del Designated Forwarder para determinado tráfico BUM.
• Evitación de duplicados.
• Aprendizaje coordinado de MAC.
• Retirada rápida de rutas cuando falla un enlace o un leaf.

Esto ofrece una alternativa estandarizada a ciertos diseños basados en MLAG propietarios. No significa que MLAG deje de tener utilidad ni que todos los equipos soporten las mismas funciones EVPN, pero reduce la necesidad de construir el fabric alrededor de grandes dominios STP.

STP puede seguir existiendo en el borde, por ejemplo ante equipos Ethernet que puedan crear bucles. Lo que desaparece es su papel como mecanismo principal para decidir qué enlaces del backbone permanecen activos.

La MTU y otros detalles que pueden romper el fabric

VXLAN añade encabezados al paquete original. En un transporte IPv4, la sobrecarga suele rondar los 50 bytes, aunque puede variar según el escenario. Si el underlay mantiene una MTU de 1.500 bytes y los servidores también envían tramas de ese tamaño, el paquete encapsulado puede superar el límite.

Como muchos switches de datacenter no fragmentan VXLAN de la forma que podría esperarse, una MTU incoherente puede provocar pérdidas difíciles de interpretar. Por eso el underlay suele configurarse con jumbo frames y se valida de extremo a extremo antes de desplegar el overlay.

También deben planificarse:

• Direccionamiento de loopbacks y enlaces punto a punto.
• ASN utilizados en el underlay y el overlay.
• Route reflectors y redundancia del plano de control.
• Límites de MAC, rutas, VNI y VRF del hardware.
• Distribución de tráfico BUM.
• Convergencia ante fallos.
• Filtrado de rutas y políticas entre clientes.
• Compatibilidad real entre fabricantes.
• Automatización y consistencia de configuración.

Las RFC definen los procedimientos, pero las plataformas pueden presentar diferencias en capacidades, escalas, valores predeterminados y funciones opcionales. La interoperabilidad debe probarse con las versiones exactas que se utilizarán en producción.

Cómo cambia el diagnóstico de incidencias

EVPN-VXLAN organiza la red en capas, y el diagnóstico debe seguir el mismo orden.

1. Comprobar el underlay

Antes de analizar EVPN conviene verificar:

• Vecindades del protocolo de routing.
• Rutas hacia las loopbacks de los VTEP.
• ECMP y caminos disponibles.
• MTU y pérdida de paquetes.
• Latencia y errores físicos.

2. Revisar el plano de control EVPN

Después se comprueban:

• Sesiones MP-BGP.
• Familias de direcciones EVPN activas.
• Rutas tipo 2, 3 y 5.
• Route Target importados y exportados.
• Próximo salto y VTEP originador.
• Retirada y movilidad de rutas.

3. Validar el overlay

Finalmente se revisan:

• Asociación entre VLAN, bridge domain y VNI.
• VNI de capa 3 y VRF.
• Anycast gateway.
• Tablas MAC e IP.
• ARP o ND suppression.
• Encapsulación y desencapsulación VXLAN.
• Listas de VTEP participantes en cada segmento.

La complejidad no desaparece. Pasa de una gran capa 2 difícil de acotar a varios planos con responsabilidades definidas. Esa separación facilita localizar el fallo siempre que el equipo de operación disponga de telemetría, procedimientos y formación adecuados.

Cuándo merece la pena desplegar EVPN-VXLAN

La arquitectura resulta especialmente apropiada cuando el datacenter necesita:

• Numerosos segmentos o clientes aislados.
• Crecimiento horizontal mediante nuevos racks.
• Aprovechamiento activo de múltiples caminos.
• Gateways distribuidos.
• Multihoming activo-activo.
• Automatización mediante modelos repetibles.
• Movilidad controlada de cargas.
• Separación entre infraestructura física y servicios.

No siempre es la respuesta adecuada. Un entorno pequeño con pocas VLAN, requisitos estables y un par de switches puede funcionar perfectamente con una arquitectura convencional. Introducir BGP EVPN, VTEP, VRF y políticas de importación sin una necesidad real puede aumentar el coste operativo.

La decisión debe considerar no solo el tamaño actual, sino el crecimiento previsto, la capacidad del equipo técnico y las funciones soportadas por el hardware.

EVPN-VXLAN no debería adoptarse porque sea una tecnología moderna, sino cuando la separación entre underlay y overlay resuelve problemas concretos de escala, redundancia, aislamiento u operación.

Preguntas frecuentes

¿EVPN-VXLAN elimina por completo la capa 2?

No. Los servidores pueden seguir utilizando Ethernet y pertenecer a un mismo segmento lógico. La diferencia es que la VLAN no necesita atravesar físicamente todo el fabric mediante trunks: VXLAN la transporta sobre una red IP.

¿VXLAN y EVPN son la misma tecnología?

No. VXLAN define el encapsulado y actúa como plano de datos. EVPN utiliza BGP como plano de control para distribuir información de MAC, IP, prefijos y pertenencia a los segmentos.

¿EVPN-VXLAN elimina STP?

Reduce su función dentro del fabric porque el underlay utiliza routing IP y ECMP. STP puede seguir siendo necesario en determinados segmentos de acceso o ante equipos externos que puedan originar bucles.

¿Qué debe comprobarse primero cuando falla un túnel VXLAN?

La conectividad IP entre los VTEP, las rutas hacia sus loopbacks y la MTU del underlay. Después deben revisarse las sesiones BGP EVPN, los VNI y las rutas anunciadas.