EVPN sobre IPv6: como preparar o underlay do futuro na sua rede ISP
A maioria dos ISPs que operam EVPN/VXLAN em produção faz isso sobre um underlay IPv4. É a configuração testada, bem documentada e suportada sem surpresas por todos os principais fornecedores. Mas à medida que a indústria avança para redes nativas IPv6, surge uma pergunta prática que cada vez mais equipes de engenharia enfrentam: quando e como migrar o underlay EVPN para IPv6?
Este artigo não propõe fazer isso já, sem mais. Propõe entender o estado atual do suporte, identificar onde estão os riscos reais de interoperabilidade e construir um critério para tomar essa decisão na sua rede com base técnica sólida.
O que o underlay faz em EVPN/VXLAN
EVPN (Ethernet VPN) roda sobre BGP e usa VXLAN para encapsular tráfego de camada 2 sobre uma rede de camada 3. Nessa arquitetura há dois planos claros:
- Plano de controle (overlay): BGP iBGP ou eBGP entre VTEPs (VXLAN Tunnel Endpoints) para distribuir informação de alcançabilidade MAC/IP e pertença a VNIs.
- Plano de dados (underlay): a rede IP que transporta os pacotes VXLAN encapsulados entre VTEPs. É basicamente IP com UDP 4789 por cima.
O underlay é transparente para o overlay: ao BGP EVPN não importa se os VTEPs se falam por IPv4 ou IPv6. O que importa é que os next-hops anunciados nas rotas EVPN sejam alcançáveis e que o transporte UDP funcione corretamente entre os VTEPs.
Num underlay IPv4, os VTEPs têm IPs de loopback IPv4 (tipicamente /32) que são source/destination dos túneis VXLAN. Num underlay IPv6, essas mesmas loopbacks seriam endereços IPv6, e os túneis VXLAN rodariam sobre IPv6.
O protocolo VXLAN padrão (RFC 7348) foi definido originalmente para rodar sobre IPv4. A extensão a IPv6 como transporte de underlay é tecnicamente direta —UDP sobre IPv6 funciona igual— mas a implementação no plano de controle (como os VTEPs comunicam suas loopbacks IPv6 via BGP EVPN) exige suporte explícito em cada plataforma.
Por que considerar underlay IPv6 hoje
A motivação não é adotar IPv6 por princípio. É operacional:
Simplificação do plano de endereçamento. Um ISP que já migrou o acesso dos assinantes para IPv6 e opera o core em Dual Stack tem oportunidade de simplificar: se o underlay EVPN também roda em IPv6, o plano de gerenciamento e monitoramento pode ser unificado. Uma única família de protocolos para todo o plano de transporte reduz a superfície de configuração e o número de protocolos de roteamento em paralelo.
Eliminação de NAT no plano de transporte do data center. Em arquiteturas onde o fabric do data center está diretamente conectado à rede ISP, manter IPv4 no underlay EVPN significa conservar espaço IPv4 privado (RFC 1918) para loopbacks de VTEPs. À medida que o espaço IPv4 encarece, eliminar essa dependência tem valor.
Alinhamento com a direção da indústria. As plataformas de rede mais modernas estão investindo em suporte a underlay IPv6 para EVPN. Operadores que não avaliam essa capacidade hoje vão se ver tomando decisões de arquitetura sem ter analisado as implicações.
Preparação para ambientes IoT e 5G. Em redes de acesso para dispositivos massivos (IoT, sensores, small cells 5G), os VTEPs na borda podem ser plataformas leves que no futuro só suportem IPv6. Um underlay nativo IPv6 em EVPN é a base para essa arquitetura.
Estado atual por plataforma
Esta é a parte mais importante: o suporte a underlay IPv6 em EVPN varia significativamente entre fornecedores, e a interoperabilidade entre eles ainda apresenta atritos.
Huawei VRP
A Huawei tem suporte a underlay IPv6 em EVPN documentado para suas plataformas de switches de data center (série CE) e roteadores de core (série NE) desde versões recentes do VRP. A configuração segue o mesmo modelo que IPv4: loopbacks IPv6, IGP IPv6 (OSPFv3 ou IS-IS com TLVs IPv6) e BGP EVPN com next-hops em IPv6.
Um detalhe importante para equipes Huawei: verificar a versão exata do VRP do equipamento antes de planejar a implantação. O suporte aparece nas release notes como “EVPN IPv6 Underlay” e a disponibilidade varia entre as famílias CE6800, CE8800 e as plataformas NE.
Cisco IOS-XE / NX-OS
No NX-OS, a Cisco suporta underlay IPv6 em EVPN para a família Nexus 9000 desde versões 9.3.x em diante, com algumas funcionalidades completando-se nas versões 10.x. O suporte para NX-OS em outras plataformas (Nexus 7000, plataformas de campus) é mais limitado.
No IOS-XE (Cat9k, plataformas de campus com EVPN), o suporte a underlay IPv6 é mais recente e menos maduro que no NX-OS. Recomendamos verificar as release notes específicas da versão em uso.
Juniper Junos
O Junos suporta underlay IPv6 em EVPN nas plataformas QFX e MX. A implementação é tecnicamente completa: BGP EVPN pode anunciar next-hops IPv6, e o encapsulamento VXLAN sobre IPv6 funciona. A documentação do Junos detalha a configuração para EVPN com “extended next-hop encoding” que habilita o anúncio de next-hops IPv6 nas rotas EVPN.
O Junos tem vantagem nesse ponto: sua pilha BGP é consistente entre plataformas e o suporte a IPv6 no plano de controle EVPN é estável.
FRRouting (ambientes Linux / white-box)
O FRRouting, a pilha de roteamento open source usada em switches white-box e deployments Linux, incorporou suporte experimental para VTEPs IPv6 em EVPN nas versões mais recentes (10.x). O suporte existe e funciona em ambientes controlados, mas a estabilidade em produção em grande escala ainda está sendo validada pela comunidade.
Uma área em que o FRRouting encontrou problemas recentemente: a interoperabilidade com plataformas comerciais quando o underlay é IPv6. Especificamente, documentaram-se casos em que a negociação de capabilities BGP EVPN entre FRRouting e equipamentos de fornecedores comerciais não funciona corretamente para o caso de next-hops IPv6, mesmo quando ambas as extremidades declaram suporte à funcionalidade.
O problema real: interoperabilidade entre fornecedores
Este é o aspecto mais crítico para redes ISP, que tipicamente têm ambientes multi-fornecedor: o suporte declarado a uma funcionalidade por um fornecedor não garante que funcione em interoperabilidade com outro fornecedor que também a declara suportada.
EVPN com underlay IPv6 envolve vários mecanismos de plano de controle que precisam ser negociados corretamente entre peers BGP:
-
Extended Next Hop Encoding (RFC 8950): permite anunciar next-hops IPv6 em atualizações BGP da família IPv4 (necessário em algumas topologias). Ambos os peers precisam negociar essa capability corretamente.
-
Codificação do source VTEP em rotas EVPN Type-3 (IMET): o endereço do VTEP anunciado nas rotas de pertença à VNI deve ser IPv6 quando o underlay é IPv6. A forma como isso é codificado varia entre implementações.
-
Resolução do next-hop para encapsulamento VXLAN: quando um VTEP recebe uma rota EVPN com next-hop IPv6, precisa resolver esse IPv6 ao próximo salto no underlay para encapsular corretamente o pacote VXLAN. Esse processo pode ser implementado de formas ligeiramente diferentes entre fornecedores.
Os problemas de interoperabilidade tipicamente não aparecem em labs controlados (mesmo fornecedor nas duas extremidades), mas em ambientes reais multi-fornecedor. A recomendação é testar explicitamente a combinação de fornecedores que você tem na rede antes de comprometer underlay IPv6 em produção.
O que avaliar antes de migrar
Se você está considerando underlay IPv6 para EVPN na sua rede ISP, este é o checklist mínimo de avaliação técnica:
1. Versão de firmware / software em todos os VTEPs. Documente as versões exatas de todos os equipamentos que farão parte do underlay. Verifique nas release notes de cada fornecedor se o suporte a underlay IPv6 está marcado como “GA” (Generally Available) ou “experimental”. Não misture versões de firmware num mesmo fabric se houver dúvidas sobre compatibilidade.
2. Teste de interoperabilidade em lab antes da produção. Se você tem mais de um fornecedor de switches no seu fabric EVPN, construa um lab de teste que replique exatamente a combinação de fornecedores e versões que tem em produção. Estabeleça sessões BGP EVPN entre os VTEPs, ative VNIs de teste e verifique se o tráfego VXLAN flui corretamente sobre IPv6.
3. Validação do plano de monitoramento e observabilidade. Seu sistema de monitoramento atual (NetFlow, sFlow, SNMP traps, logs de BGP) trata corretamente endereços IPv6 nos campos de next-hop e origem? Sistemas de monitoramento que não foram atualizados para IPv6 podem perder visibilidade de parte do tráfego ou mostrar dados incorretos.
4. Impacto no plano de roteamento do underlay. O underlay EVPN precisa de um IGP para distribuir as rotas de loopback dos VTEPs. Se hoje você usa OSPF, precisará de OSPFv3 ou IS-IS com TLVs IPv6 para o underlay IPv6. Avalie se seu IGP atual suporta a configuração e se o plano de numeração IPv6 está definido.
5. Plano de rollback. Toda migração de underlay precisa de um plano de rollback executável em menos de 30 minutos. Antes de migrar, documente o procedimento exato para reverter a underlay IPv4 se a migração IPv6 falhar. Num fabric EVPN em produção, não há margem para improvisar um rollback.
A postura correta hoje: avaliar, não migrar precipitadamente
O underlay IPv6 em EVPN é tecnicamente viável em plataformas de fornecedores maduros (Cisco, Juniper, Huawei) em versões recentes. O suporte open source (FRRouting) está em processo de maturação.
Mas “tecnicamente viável num fornecedor” não equivale a “pronto para produção no seu ambiente multi-fornecedor específico”. Os problemas de interoperabilidade são reais e podem aparecer em combinações de plataformas que parecem atualizadas quanto ao suporte da funcionalidade.
A postura correta para um ISP hoje é:
- Auditar o suporte da sua combinação específica de fornecedores e versões.
- Montar o lab que replica seu fabric e testar underlay IPv6 antes de tocar em produção.
- Estabelecer critérios claros para decidir quando migrar: percentual de tráfego IPv6 na rede de assinantes, ciclo de renovação de hardware, convergência do suporte dos fornecedores.
- Incluir na folha de rota de modernização do core, junto com a migração de assinantes para IPv6.
Não há urgência de migrar o underlay EVPN para IPv6 hoje se o underlay IPv4 funciona corretamente. Mas há urgência de entender o que seu equipamento atual suporta, para que quando a decisão chegue, seja tomada com base em dados técnicos, não em suposições.
Como a Ayuda.LA pode ajudar
Na Ayuda.LA trabalhamos com ISPs e operadores na América Latina em auditorias e desenho de arquiteturas EVPN/VXLAN, incluindo avaliação de prontidão para migração a underlay IPv6:
- Auditoria do fabric EVPN atual: revisamos versões de firmware, configuração de VTEPs e compatibilidade com underlay IPv6 na sua combinação de fornecedores.
- Lab de teste de interoperabilidade: desenhamos e executamos testes de interoperabilidade underlay IPv6 em ambientes que replicam seu fabric de produção.
- Desenho de folha de rota de modernização IPv6: integramos a migração do underlay EVPN num plano coerente de adoção IPv6 para toda a rede ISP.
Se sua rede opera EVPN/VXLAN e você está pensando na folha de rota IPv6, é o momento de fazer a avaliação técnica com critério.
Opera EVPN na sua rede ISP e quer avaliar o estado do seu equipamento para underlay IPv6? Escreva para [email protected] — respondemos todas as mensagens.