Muchos centros de datos crecieron durante años a base de añadir VLAN, enlaces trunk y parejas de switches con agregación multichasis. Sigue siendo un modelo perfectamente válido para entornos pequeños y medianos, y no hay ninguna necesidad de tocarlo si funciona. La cosa se complica cuando hay que conectar cientos de racks, aislar decenas de clientes o mover cargas entre zonas sin ampliar el dominio de fallo con cada cambio.
EVPN-VXLAN cambia la pregunta de partida. En vez de buscar cómo llevar cada VLAN hasta el último rincón del datacenter, plantea dónde tiene que existir realmente cada servicio y cómo anunciarlo sobre una red IP que ya es estable.
Una red Ethernet clásica aprende dónde está cada equipo mirando las direcciones MAC de las tramas que le llegan. Si no sabe dónde vive un destino, replica el tráfico por los puertos que toca. Los broadcast y parte del multicast se reparten por todo el dominio de capa 2.
Mientras el entorno es pequeño, esto no molesta a nadie. El problema aparece cuando una misma VLAN atraviesa veinte racks o dos edificios:
El problema no es Ethernet, sino convertir el datacenter entero en una gran red conmutada. La capa 2 sigue haciendo falta en el acceso de los servidores y en servicios concretos, pero no tiene por qué ser también la red de transporte entre todos los switches.
Ahí es donde EVPN-VXLAN separa las dos cosas: la conectividad entre nodos se resuelve con routing IP, y los servicios Ethernet o IP de cada cliente van por encima, encapsulados y aislados.
El underlay es la red física que interconecta los switches. En un datacenter suele ser una topología leaf-spine basada en arquitectura Clos:
Con esa topología tienes varios caminos de coste equivalente, así que el tráfico se reparte con ECMP (Equal-Cost Multi-Path): usas todos los enlaces a la vez y te quedan rutas alternativas si cae uno.
El protocolo del underlay puede ser eBGP, OSPF o IS-IS según la plataforma y el gusto del que diseñe. Lo único imprescindible es que dé conectividad IP estable entre los VTEP (VXLAN Tunnel Endpoints), que normalmente usan direcciones de loopback como extremo de túnel.
El underlay tiene que funcionar antes de montar nada encima. Si dos VTEP no se ven por IP, VXLAN no va a transportar servicios entre ellos por mucho EVPN que configures.
El overlay son las redes virtuales que consumen servidores y clientes: conectividad de capa 2 donde haga falta, routing entre subredes y separación por VRF.
Los leaf que hacen de VTEP encapsulan el tráfico al entrar y lo desencapsulan al salir. Para los spine, eso es tráfico IP corriente; ni saben ni les importa qué MAC, VLAN o cliente viaja dentro.
Esa independencia es lo que permite tocar los servicios del overlay sin rediseñar la topología física, y reutilizar un mismo fabric IP para muchos clientes aislados entre sí. Es exactamente el mismo principio que aplica la microsegmentación con SDN, un piso más arriba.
VXLAN (Virtual eXtensible Local Area Network) mete una trama Ethernet dentro de un paquete UDP. La cabecera exterior lleva las IP de los VTEP de origen y destino, así que el underlay lo enruta como cualquier otro paquete.
Cada segmento usa un VNI (VXLAN Network Identifier) de 24 bits: cerca de 16,7 millones de identificadores posibles, frente a los 12 bits de las VLAN 802.1Q, que en la práctica se quedan en 4.094 utilizables. Cuando alojas muchos clientes, ese techo se nota antes de lo que parece.
La equivalencia mental es bastante directa:
| 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 solo el plano de datos: dice cómo se transporta el tráfico, no dónde está cada endpoint. El diseño original de la RFC 7348 admite flood and learn, donde la red replica tráfico para ir descubriendo destinos. Funciona, pero escala regular.
BGP EVPN es lo que aporta el plano de control para ahorrarse buena parte de ese aprendizaje por inundación.
EVPN (Ethernet VPN) usa Multiprotocol BGP para intercambiar información sobre los servicios del overlay. Cada VTEP anuncia qué tiene colgado y el resto del fabric aprende cómo llegar.
Los tipos de ruta que más vas a ver:
Las rutas llevan atributos como Route Distinguisher y Route Target. El primero hace únicas dentro de BGP rutas que de otro modo serían idénticas. Los Route Target controlan qué VRF o instancia EVPN importa y exporta cada cosa; es donde se cometen la mitad de los errores de configuración de un fabric multi-tenant.
En un fabric de cierto tamaño no interesa mallar sesiones BGP entre todos los leaf. Los spine hacen de route reflectors, recibiendo y redistribuyendo rutas EVPN sin tener que participar como VTEP en el plano de datos.
Esta separación también se agradece al depurar: puedes preguntarle a BGP dónde se anunció una MAC, qué VTEP la origina y a qué VNI pertenece, en lugar de ir saltando de tabla en tabla por seis switches.
El servidor A cuelga del leaf 1 y el servidor B del leaf 4. Los dos están en el VNI 10100.
Desde el punto de vista de los servidores, los dos siguen en el mismo segmento lógico. Pero los enlaces entre racks no transportan esa VLAN por trunks Ethernet: transportan paquetes IP encapsulados.
Por eso conviene precisar que EVPN-VXLAN evita extender físicamente la capa 2 por todo el fabric. La extensión lógica sigue estando disponible cuando una aplicación la necesita, que es justo lo que salva muchas migraciones de aplicaciones antiguas.
BGP EVPN reduce la inundación, no la elimina.
El tráfico BUM (broadcast, unknown unicast y multicast) sigue necesitando un método de distribución: multicast en el underlay, o ingress replication, donde el VTEP de entrada manda una copia a cada VTEP interesado. La segunda opción es más sencilla de operar y la más habitual en fabrics medianos, a costa de replicar en el borde.
EVPN también permite suprimir ARP y Neighbor Discovery. Como las rutas de tipo 2 ya relacionan IP y MAC, un VTEP puede contestar localmente a ciertas consultas en vez de replicarlas por todo el segmento. Cuánto ahorras depende de la implementación, de la configuración y de la calidad de lo aprendido. Activar el protocolo y dar por hecho que el flooding desaparece es una forma estupenda de llevarse un susto en producción.
Una de las cosas más útiles es poner el gateway de cada subred directamente en los leaf.
Con un anycast gateway, varios leaf presentan a los servidores la misma IP y la misma MAC virtual como puerta de enlace. Cada carga usa su gateway local, así que el tráfico entre subredes se enruta cerca del origen sin subir hasta un par central de routers y volver a bajar.
El estándar de Integrated Routing and Bridging (IRB) define modelos asimétricos y simétricos. En fabrics grandes multi-tenant lo normal es el IRB simétrico:
Así evitas que todos los leaf tengan que alojar todas las VLAN de una VRF, y la escalabilidad queda más ordenada. A cambio hay que tener muy claro qué es un VNI de capa 2, qué es uno de capa 3, cómo se mapean las VRF y qué política de importación y exportación aplica a cada una.
EVPN también cubre la conexión redundante de un servidor, un firewall o un switch contra más de un leaf. Con un ESI (Ethernet Segment Identifier), los VTEP anuncian que comparten el mismo segmento.
El modo all-active aprovecha los dos enlaces a la vez y coordina cosas como:
Es la alternativa estandarizada a los diseños con MLAG propietario. Ni MLAG deja de ser útil ni todos los equipos implementan las mismas funciones EVPN, pero desaparece la necesidad de construir el fabric alrededor de un gran dominio STP. Spanning Tree puede seguir vivo en el borde, frente a equipos que puedan generar bucles; lo que pierde es su papel de árbitro sobre qué enlaces del backbone están activos. Si vienes de diseñar clusters en alta disponibilidad, el cambio de mentalidad es parecido: la redundancia deja de ser un par y pasa a ser un conjunto.
VXLAN añade cabeceras. Sobre IPv4, la sobrecarga ronda los 50 bytes, con variaciones según el escenario. Si el underlay va con MTU de 1.500 y los servidores envían tramas de ese tamaño, el paquete encapsulado se pasa del límite.
Como muchos switches de datacenter no fragmentan VXLAN de la forma que uno esperaría, una MTU incoherente provoca pérdidas raras: sesiones que se cuelgan con transferencias grandes mientras el ping va perfecto. De ahí que el underlay se configure con jumbo frames y se valide de extremo a extremo antes de desplegar el overlay. Si un día te toca depurar un fabric ajeno, empieza por aquí.
También hay que planificar:
Las RFC definen los procedimientos, pero cada plataforma tiene sus capacidades, sus escalas, sus valores por defecto y sus funciones opcionales. La interoperabilidad se prueba con las versiones exactas que vas a llevar a producción, no con la tabla comparativa del fabricante.
EVPN-VXLAN organiza la red en capas, y el diagnóstico va en el mismo orden.
1. El underlay primero. Vecindades del protocolo de routing, rutas hacia las loopbacks de los VTEP, caminos ECMP disponibles, MTU, pérdida de paquetes, latencia y errores físicos.
2. Luego el plano de control EVPN. Sesiones MP-BGP, familias de direcciones activas, rutas de tipo 2, 3 y 5, Route Target importados y exportados, próximo salto y VTEP originador, retirada y movilidad de rutas.
3. Al final el overlay. Asociación entre VLAN, bridge domain y VNI; VNI de capa 3 y VRF; anycast gateway; tablas MAC e IP; supresión de ARP o ND; encapsulación y desencapsulación; lista de VTEP en cada segmento.
La complejidad no desaparece: pasa de ser una capa 2 enorme y difícil de acotar a varios planos con responsabilidades definidas. Localizar el fallo es más rápido, siempre que el equipo tenga telemetría, procedimientos y formación. Sin eso, lo único que has hecho es cambiar de tipo de problema.
Encaja bien cuando el datacenter necesita:
Y no compensa en un entorno pequeño, con pocas VLAN, requisitos estables y un par de switches. Meter BGP EVPN, VTEP, VRF y políticas de importación sin necesidad real multiplica el coste operativo y la superficie de error, sobre todo si la red la lleva una persona que además hace otras cinco cosas.
La decisión no depende solo del tamaño de hoy, sino del crecimiento previsto, de la capacidad del equipo técnico y de qué funciones soporta de verdad el hardware que ya tienes. EVPN-VXLAN no se adopta porque sea moderno, sino cuando separar underlay y overlay resuelve un problema concreto de escala, redundancia, aislamiento u operación.
En los centros de datos con los que trabajamos conviven las dos cosas: fabrics EVPN-VXLAN para plataformas multi-tenant y diseños clásicos donde la escala no lo justifica. Si estás dimensionando la red de tu cloud privado y no tienes claro dónde está tu caso, cuéntanoslo y lo revisamos contigo.
¿EVPN-VXLAN elimina del todo la capa 2?
No. Los servidores siguen usando Ethernet y pueden estar en el mismo segmento lógico. La diferencia es que esa VLAN no tiene que atravesar físicamente el fabric por trunks: VXLAN la transporta sobre una red IP.
¿VXLAN y EVPN son lo mismo?
No. VXLAN define el encapsulado y es el plano de datos. EVPN usa BGP como plano de control para repartir MAC, IP, prefijos y pertenencia a segmentos. Puedes tener VXLAN sin EVPN (con flood and learn), pero escala peor.
¿Desaparece Spanning Tree?
Dentro del fabric pierde su papel, porque el underlay va con routing IP y ECMP. STP puede seguir haciendo falta en segmentos de acceso o frente a equipos externos que puedan montar un bucle.
¿Qué miro primero cuando un túnel VXLAN no pasa tráfico?
Conectividad IP entre los VTEP, rutas hacia sus loopbacks y MTU del underlay. Después, sesiones BGP EVPN, VNI y rutas anunciadas. En ese orden, que ahorra horas.
¿Necesito hardware específico?
Necesitas equipos que hagan VXLAN en el ASIC y soporten la familia EVPN en BGP, con escalas de MAC, VNI y VRF suficientes para tu caso. La mayoría de switches de datacenter actuales lo hacen, pero las cifras máximas varían mucho entre gamas.
Proxmox VE 9.2 estrena versión oficial para ARM64 (AArch64), la primera fuera de x86-64 en la historia del producto. Misma base de código, mismos repositorios y mismo soporte, con NVIDIA Grace y NVIDIA Vera como plataformas certificadas de salida. Repasamos qué hardware cumple los requisitos, qué funciones se quedan en x86 y qué cambia (poco, de momento) para quien ya tiene un clúster en producción.
Haces backup de la VM cada noche y duermes tranquilo. Hasta que restauras y la base de datos arranca corrupta o pierde las últimas transacciones. Un snapshot de disco no es lo mismo que un backup consistente de una base de datos. Explicamos la diferencia entre backup consistente por caída, por sistema de ficheros y por aplicación, y cómo conseguir el bueno en Proxmox con el agente invitado, hooks y volcados nativos.
Entrenar o servir modelos de IA en tu propio cloud privado pasa por una pieza técnica concreta: entregar una GPU física a una máquina virtual con rendimiento casi nativo. Explicamos qué es el passthrough con VFIO e IOMMU, cómo se hace en Proxmox VE 9.2, dónde están las trampas (grupos IOMMU, la GPU de arranque, licencias) y cuándo compensa frente a alquilar GPU en un hiperescalar.