EVPN sobre IPv6: cómo preparar el underlay del futuro en tu red ISP
La mayoría de los ISPs que operan EVPN/VXLAN en producción lo hacen sobre un underlay IPv4. Es la configuración probada, bien documentada, y soportada sin sorpresas por todos los vendors principales. Pero a medida que la industria avanza hacia redes IPv6-nativas, surge una pregunta práctica que cada vez más equipos de ingeniería están enfrentando: ¿cuándo y cómo migrar el underlay EVPN a IPv6?
Este artículo no propone hacerlo ahora sin más. Propone entender el estado actual del soporte, identificar dónde están los riesgos reales de interoperabilidad, y construir un criterio para tomar esa decisión en tu red con información técnica sólida.
Qué hace el underlay en EVPN/VXLAN
EVPN (Ethernet VPN) corre sobre BGP y usa VXLAN para encapsular tráfico de capa 2 sobre una red de capa 3. En esta arquitectura hay dos planos claros:
- Plano de control (overlay): BGP iBGP o eBGP entre VTEPs (VXLAN Tunnel Endpoints) para distribuir información de accesibilidad MAC/IP y membresía en VNIs.
- Plano de datos (underlay): la red IP que transporta los paquetes VXLAN encapsulados entre VTEPs. Es básicamente IP con UDP 4789 encima.
El underlay es transparente para el overlay: a BGP EVPN no le importa si los VTEPs se hablan por IPv4 o IPv6. Lo que importa es que los next-hops que se anuncian en las rutas EVPN sean accesibles, y que el transporte UDP funcione correctamente entre los VTEPs.
En un underlay IPv4, los VTEPs tienen IPs de loopback IPv4 (típicamente /32) que son los source/destination de los túneles VXLAN. En un underlay IPv6, esas mismas loopbacks serían direcciones IPv6, y los túneles VXLAN correrían sobre IPv6.
El protocolo VXLAN estándar (RFC 7348) fue definido originalmente para correr sobre IPv4. La extensión a IPv6 como transporte de underlay es técnicamente directa —UDP sobre IPv6 funciona igual— pero la implementación en el plano de control (cómo los VTEPs se comunican sus loopbacks IPv6 vía BGP EVPN) requiere soporte explícito en cada plataforma.
Por qué plantearse IPv6 underlay hoy
La motivación no es adoptar IPv6 por principio. Es operativa:
Simplificación del plano de direccionamiento. Un ISP que ya migró el acceso de suscriptores a IPv6 y opera el core en Dual Stack tiene una oportunidad de simplificar: si el underlay EVPN también corre en IPv6, el plano de management y monitoreo puede unificarse. Una sola familia de protocolos para todo el plano de transporte reduce la superficie de configuración y el número de protocolos de enrutamiento corriendo en paralelo.
Eliminación de NAT en el plano de transporte de data center. En arquitecturas donde el fabric de data center está directamente conectado a la red ISP, mantener IPv4 en el underlay EVPN significa conservar espacio IPv4 privado (RFC 1918) para loopbacks de VTEPs. A medida que el espacio IPv4 se encarece, eliminar esta dependencia tiene valor.
Alineación con la dirección de la industria. Las plataformas de red más modernas están invirtiendo en soporte de IPv6 underlay para EVPN. Los operadores que no evalúan esta capacidad hoy se van a encontrar tomando decisiones de arquitectura sin haber analizado las implicaciones.
Preparación para entornos IoT y 5G. En redes de acceso para dispositivos masivos (IoT, sensores, small cells 5G), los VTEPs en el edge pueden ser plataformas livianas que en el futuro solo soporten IPv6. Un underlay IPv6-nativo en EVPN es la base para esa arquitectura.
Estado actual por plataforma
Esta es la parte más importante: el soporte de IPv6 underlay en EVPN varía significativamente entre vendors, y la interoperabilidad entre ellos todavía presenta fricciones.
Huawei VRP
Huawei tiene soporte de IPv6 underlay en EVPN documentado para sus plataformas de switches de data center (CE series) y routers de core (NE series) desde versiones recientes de VRP. La configuración sigue el mismo modelo que IPv4: loopbacks IPv6, IGP IPv6 (OSPFv3 o IS-IS con IPv6 TLVs), y BGP EVPN con next-hops en IPv6.
Un detalle importante para equipos Huawei: verificar la versión de VRP exacta del equipo antes de planear el despliegue. El soporte aparece en release notes como “EVPN IPv6 Underlay” y la disponibilidad varía entre la familia CE6800, CE8800 y las plataformas NE.
Cisco IOS-XE / NX-OS
En NX-OS, Cisco soporta IPv6 underlay en EVPN para la familia Nexus 9000 desde versiones 9.3.x en adelante, con algunas funcionalidades completándose en versiones 10.x. El soporte para NX-OS en otras plataformas (Nexus 7000, plataformas de campus) es más limitado.
En IOS-XE (Cat9k, plataformas de campus con EVPN), el soporte de IPv6 underlay es más reciente y menos maduro que en NX-OS. Recomendamos verificar las release notes específicas de la versión en uso.
Juniper Junos
Junos soporta IPv6 underlay en EVPN en las plataformas QFX y MX. La implementación es técnicamente completa: BGP EVPN puede anunciar next-hops IPv6, y el encapsulamiento VXLAN sobre IPv6 funciona. La documentación de Junos detalla la configuración para EVPN con “extended next-hop encoding” que habilita el anuncio de next-hops IPv6 en las rutas EVPN.
Junos tiene una ventaja en este punto: su stack BGP es consistente entre plataformas y el soporte de IPv6 en el plano de control EVPN es estable.
FRRouting (entornos Linux / white-box)
FRRouting, el stack de routing open-source usado en switches white-box y deployments Linux, incorporó soporte experimental para VTEPs IPv6 en EVPN en sus versiones más recientes (10.x). El soporte existe y funciona en entornos controlados, pero la estabilidad en producción a gran escala todavía está siendo validada por la comunidad.
Un área donde FRRouting encontró problemas recientemente: la interoperabilidad con plataformas comerciales cuando el underlay es IPv6. Específicamente, se han documentado casos donde la negociación de capabilities BGP EVPN entre FRRouting y equipos de vendors comerciales no funciona correctamente para el caso de next-hops IPv6, incluso cuando ambos extremos declaran soporte de la funcionalidad.
El problema real: interoperabilidad entre vendors
Este es el aspecto más crítico para redes ISP, que típicamente tienen entornos multi-vendor: el soporte declarado de una funcionalidad por un vendor no garantiza que funcione en interoperabilidad con otro vendor que también la declara soportada.
EVPN IPv6 underlay involucra varios mecanismos de plano de control que deben negociarse correctamente entre peers BGP:
-
Extended Next Hop Encoding (RFC 8950): permite anunciar next-hops IPv6 en actualizaciones BGP de familia IPv4 (necesario en algunas topologías). Ambos peers deben negociar esta capability correctamente.
-
Codificación del VTEP source en rutas EVPN Type-3 (IMET): la dirección del VTEP que se anuncia en las rutas de pertenencia a VNI debe ser IPv6 cuando el underlay es IPv6. La forma en que se codifica varía entre implementaciones.
-
Resolución del next-hop para encapsulamiento VXLAN: cuando un VTEP recibe una ruta EVPN con next-hop IPv6, necesita resolver ese IPv6 al siguiente salto en el underlay para encapsular correctamente el paquete VXLAN. Este proceso puede implementarse de formas ligeramente diferentes entre vendors.
Los problemas de interoperabilidad típicamente no aparecen en labs controlados (mismo vendor en ambos extremos) sino en entornos reales multi-vendor. La recomendación es testear explícitamente la combinación de vendors que tenés en tu red antes de comprometer IPv6 underlay en producción.
Qué evaluar antes de migrar
Si estás considerando IPv6 underlay para EVPN en tu red ISP, este es el checklist de evaluación técnica mínimo:
1. Versión de firmware / software en todos los VTEPs. Documentá las versiones exactas de todos los equipos que formarán parte del underlay. Verificá en las release notes de cada vendor si el soporte de IPv6 underlay está marcado como “GA” (Generally Available) o “experimental”. No mixes versiones de firmware en un mismo fabric si tenés dudas sobre compatibilidad.
2. Prueba de interoperabilidad en lab antes de producción. Si tenés más de un vendor de switches en tu fabric EVPN, construí un lab de prueba que replique exactamente la combinación de vendors y versiones que tenés en producción. Establece sesiones BGP EVPN entre los VTEPs, activa VNIs de prueba, y verifica que el tráfico VXLAN fluye correctamente sobre IPv6.
3. Validación del plano de monitoreo y observabilidad. ¿Tu sistema de monitoreo actual (NetFlow, sFlow, SNMP traps, logs de BGP) maneja correctamente direcciones IPv6 en los campos de next-hop y origen? Los sistemas de monitoreo que no fueron actualizados para IPv6 pueden perder visibilidad de parte del tráfico o mostrar datos incorrectos.
4. Impacto en el plano de routing del underlay. El underlay EVPN necesita un IGP para distribuir las rutas de loopback de los VTEPs. Si hoy usás OSPF, necesitarás OSPFv3 o IS-IS con IPv6 TLVs para el underlay IPv6. Evaluá si tu IGP actual soporta la configuración y si el plan de numeración IPv6 está definido.
5. Plan de rollback. Toda migración de underlay necesita un plan de rollback ejecutable en menos de 30 minutos. Antes de migrar, documentá el procedimiento exacto para revertir a underlay IPv4 si la migración IPv6 falla. En un fabric EVPN en producción, no hay margen para improvisar un rollback.
La postura correcta hoy: evaluar, no migrar precipitadamente
El underlay IPv6 en EVPN es técnicamente viable en plataformas de vendors maduros (Cisco, Juniper, Huawei) en versiones recientes. El soporte open-source (FRRouting) está en proceso de maduración.
Pero “técnicamente viable en un vendor” no equivale a “listo para producción en tu entorno multi-vendor específico”. Los problemas de interoperabilidad son reales y pueden aparecer en combinaciones de plataformas que parecen estar al día con el soporte de la funcionalidad.
La postura correcta para un ISP hoy es:
- Auditá el soporte de tu combinación específica de vendors y versiones.
- Armá el lab que replique tu fabric y probá IPv6 underlay antes de tocarlo en producción.
- Establecé criterios claros para decidir cuándo migrás: porcentaje de tráfico IPv6 en la red de suscriptores, ciclo de renovación de hardware, convergencia del soporte de vendors.
- Incluilo en la hoja de ruta de modernización del core, junto con la migración de suscriptores a IPv6.
No hay urgencia de migrar el underlay EVPN a IPv6 hoy si el underlay IPv4 funciona correctamente. Pero sí hay urgencia de entender qué soporta tu equipamiento actual, para que cuando la decisión llegue, esté tomada sobre datos técnicos, no sobre suposiciones.
Cómo puede ayudar Ayuda.LA
En Ayuda.LA trabajamos con ISPs y operadores en Latinoamérica en auditorías y diseño de arquitecturas EVPN/VXLAN, incluyendo evaluación de readiness para migración a IPv6 underlay:
- Auditoría de fabric EVPN actual: revisamos versiones de firmware, configuración de VTEPs, y compatibilidad con IPv6 underlay en tu combinación de vendors.
- Lab de prueba de interoperabilidad: diseñamos y ejecutamos pruebas de interoperabilidad IPv6 underlay en entornos que replican tu fabric de producción.
- Diseño de hoja de ruta de modernización IPv6: integramos la migración de underlay EVPN en un plan de adopción IPv6 coherente para toda la red ISP.
Si tu red opera EVPN/VXLAN y estás pensando en la hoja de ruta IPv6, es el momento de hacer la evaluación técnica con criterio.
Hablemos sobre tu arquitectura →
¿Operás EVPN en tu red ISP y querés evaluar el estado de tu equipamiento para IPv6 underlay? Escribinos a [email protected] — respondemos todos los mensajes.