É hora de deixar o spanning tree: redes overlay com MPLS e VXLAN para ISPs pequenos
Há uma conversa que se repete nas equipes de rede de ISPs pequenos e médios da América Latina: o NOC detecta um loop de camada 2 no backbone de distribuição —um daqueles que o Spanning Tree deveria ter evitado mas não conteve—, alguém precisa rastrear manualmente a porta que causou o problema, e enquanto isso uma parte dos assinantes fica sem serviço. O incidente se encerra, acrescenta-se um comentário no wiki, e todos sabem que vai acontecer de novo.
Esse padrão não é problema de configuração. É problema de arquitetura. E tem solução.
A raiz do problema: redes comutadas em escala ISP
Redes comutadas com VLANs e Spanning Tree Protocol (STP/RSTP/MSTP) foram desenhadas para um contexto específico: redes de área local de campus, onde a camada 2 precisa chegar aos dispositivos do usuário final e os domínios de broadcast são relativamente pequenos.
Quando um ISP cresce e passa a usar essa mesma arquitetura para interconectar nós de distribuição, sites remotos ou transportar serviços de cliente, os problemas emergem de forma previsível:
Spanning Tree não escala bem com a topologia física. Numa rede com múltiplos anéis de fibra e redundância ativo/standby, o STP bloqueia portas para quebrar loops. Isso significa que parte da capacidade instalada fica inativa. A convergência quando há mudança de topologia —mesmo com RSTP— introduz cortes medidos em segundos ou dezenas de segundos.
O domínio de broadcast é um blast radius. Uma tempestade de broadcast num segmento afeta todos os dispositivos no mesmo domínio de VLANs. Numa rede ISP em que esse domínio cruza múltiplos nós, um único equipamento mal comportado pode degradar o serviço a centenas de assinantes.
A separação de serviços com VLANs tem um teto. O espaço de IDs de VLAN (802.1Q) é de 4094 etiquetas. Para um ISP que cresce e precisa isolar serviços, clientes enterprise e segmentos de gerenciamento, esse teto chega antes do que parece.
A operação é manual e frágil. Cada nova VLAN é configurada manualmente em cada switch ao longo do path. Um erro de configuração em qualquer ponto quebra a conectividade dessa VLAN no segmento. Sem automação, a probabilidade de erro cresce com o tamanho da rede.
A alternativa: levar os serviços para o overlay
A arquitetura correta para um ISP —independentemente do tamanho— é separar o plano de transporte do plano de serviços:
- O underlay é uma rede IP simples: cada nó tem um endereço IP de loopback, os nós se interconectam com enlaces ponto a ponto sobre IP, e um protocolo de roteamento (OSPF, IS-IS ou eBGP) distribui a alcançabilidade de todos os loopbacks.
- O overlay são os serviços que rodam sobre esse underlay: circuitos L2 de cliente, VPNs de camada 3, segmentos de serviços próprios. Esses serviços usam túneis sobre IP —MPLS, VXLAN ou ambos— em vez de depender da camada 2 do underlay.
O resultado é uma rede em que:
- Não há spanning tree no backbone
- A redundância é ativo-ativo com ECMP (Equal-Cost Multipath)
- Um loop no underlay tem o mesmo impacto que qualquer falha de roteamento —convergência em segundos com IGP fast-reroute, sem broadcast storms
- Os serviços de cliente ficam completamente isolados entre si no overlay
- Adicionar um novo serviço ou cliente não exige tocar a configuração dos switches de transporte
MPLS: a opção testada para ISPs
MPLS (Multiprotocol Label Switching) é a tecnologia de overlay mais madura para redes de provedores. Permite transportar serviços L2 (pseudowires, VPLS) e L3 (L3VPN) sobre um underlay IP com eficiência e escala demonstradas em redes de grandes carriers durante décadas.
Para um ISP pequeno, o MPLS habilita dois casos de uso imediatos:
VPLS ou EVPN-VPLS para transporte L2 de cliente: em vez de estender uma VLAN por múltiplos switches físicos, o tráfego do cliente entra na borda do ISP e é encapsulado num pseudowire MPLS até a outra extremidade do serviço. O backbone vê só rótulos MPLS, não tráfego de cliente.
L3VPN para serviços de conectividade empresarial: cada cliente enterprise tem seu próprio plano de roteamento no ISP, isolado de outros clientes e da rede de infraestrutura do ISP. O PE (Provider Edge) mantém uma tabela de roteamento por cliente (VRF), e o tráfego é encaminhado entre PEs com MPLS.
MPLS na Huawei VRP
Os equipamentos Huawei das famílias CE (data center), NE (core routing) e AR (acesso enterprise) suportam MPLS com pilha completa. No VRP da Huawei, habilitar MPLS no underlay requer:
mpls lsr-id <loopback-ip>
mpls
mpls ldp
E em cada interface do underlay:
interface GigabitEthernet1/0/0
mpls
mpls ldp
Com LDP rodando sobre OSPF ou OSPFv3, os equipamentos descobrem automaticamente os caminhos MPLS entre todos os LSRs da rede. A mesma pilha suporta depois serviços L2 via Martini (pseudowires) ou EVPN.
MPLS no MikroTik RouterOS
O MikroTik suporta MPLS desde o RouterOS 2.9 e está disponível em todos os equipamentos com RouterOS, incluindo os CCR (Cloud Core Router) amplamente usados em ISPs da região. O suporte inclui LDP, VPLS (com sinalização LDP) e pseudowires básicos.
Configurar LDP no RouterOS é direto pelo Winbox ou terminal:
/mpls ldp
set enabled=yes lsr-id=<loopback-ip> transport-address=<loopback-ip>
/mpls ldp interface
add interface=ether1
add interface=ether2
Com OSPF rodando no underlay e LDP habilitado nas interfaces de backbone, os roteadores MikroTik estabelecem sessões LDP automaticamente e podem transportar VPLS entre sites.
Limitação importante do MikroTik: o suporte a MPLS no RouterOS é funcional para casos de uso básicos (VPLS, pseudowires LDP), mas a pilha não inclui RSVP-TE (traffic engineering) nem EVPN sobre MPLS nas versões atuais. Para ISPs que só precisam de transporte L2 de cliente ou VPNs simples, isso costuma ser suficiente.
VXLAN: o overlay moderno para ambientes multi-fornecedor
VXLAN (Virtual Extensible LAN) usa UDP como transporte em vez de MPLS e foi desenhado originalmente para ambientes de data center, mas sua adoção em redes de acesso e distribuição de ISPs cresceu forte nos últimos anos. Suas vantagens sobre MPLS em ISPs pequenos:
Sem plano de controle separado para o underlay. VXLAN roda sobre IP pura com UDP 4789. Não requer LDP nem RSVP. O underlay só precisa de conectividade IP entre os VTEPs (VXLAN Tunnel Endpoints).
Escala de segmentos. O VNI (VXLAN Network Identifier) tem 24 bits — mais de 16 milhões de identificadores de rede, contra os 4094 das VLANs.
Integração com EVPN para plano de controle distribuído. EVPN sobre VXLAN (RFC 7432 + RFC 8365) usa BGP para distribuir informação de alcançabilidade MAC/IP entre VTEPs, eliminando a necessidade de flooding de BUM (Broadcast, Unknown unicast, Multicast) no overlay. Isso é chave para escalar VXLAN a redes médias.
VXLAN na Huawei
Os equipamentos Huawei das séries CE6800, CE8800 e NE suportam VXLAN com EVPN (embora algumas funcionalidades possam exigir certas licenças).
Parte da configuração base de um VTEP pode ser algo como:
interface Nve1
source <loopback-ip>
vni <id> head-end peer-list protocol bgp
Combinado com BGP EVPN para o plano de controle, a Huawei implementa um fabric VXLAN com distribuição automática de MACs e supressão de ARP.
VXLAN no MikroTik
No v7, o MikroTik acrescentou suporte a VXLAN com flooding controlado e melhorias no plano de dados.
A limitação atual: EVPN sobre VXLAN (BGP EVPN como plano de controle) tem suporte parcial no RouterOS 7.x. Para implementações de produção multi-fornecedor com EVPN completo, o MikroTik funciona melhor como VTEP em topologias em que outro equipamento atua como route reflector EVPN (por exemplo um equipamento Huawei).
Para ISPs que só têm MikroTik, VXLAN com flooding estático (lista de peers explícita) é alternativa funcional para redes pequenas:
/interface vxlan
add name=vxlan10 vni=10 port=4789
/interface vxlan vteps
add interface=vxlan10 remote-ip=<vtep-remoto>
O caminho de migração: como fazer a mudança sem cortar o serviço
Migrar de uma rede comutada para overlay não exige mudança big-bang. A abordagem recomendada para ISPs pequenos:
Fase 1: Construir o underlay IP (sem tocar nos serviços)
Habilitar OSPF ou IS-IS nas interfaces de backbone, atribuir loopbacks a cada nó e verificar que a conectividade IP funciona corretamente entre todos os nós. Neste ponto, a rede de camada 2 continua a mesma — o underlay IP roda em paralelo.
Fase 2: Subir o overlay para serviços novos
Os primeiros serviços que vão para o overlay são os novos: novos clientes L2, novas VPNs. Configuram-se VPLS ou VXLAN para esses serviços desde o primeiro dia. Os serviços existentes continuam em VLANs.
Fase 3: Migrar serviços existentes um a um
Com o overlay funcionando e validado, os serviços existentes migram de VLANs para overlay em janelas de manutenção. Cada migração é atômica: configura-se o serviço no overlay, verifica-se e elimina-se a VLAN correspondente.
Fase 4: Eliminar spanning tree do backbone
Quando todos os serviços estão no overlay, o backbone deixa de precisar de spanning tree. Pode-se desabilitar STP nas interfaces de backbone e converter os switches de distribuição em roteadores de overlay.
Quando essa arquitetura faz sentido
Essa migração vale a pena quando:
- O ISP tem mais de 2-3 nós de distribuição interconectados
- Há incidentes recorrentes relacionados a STP ou loops de camada 2
- A rede precisa escalar o número de serviços de cliente sem aumentar a complexidade operativa na mesma proporção
- Está-se avaliando acrescentar serviços enterprise (MPLS L3VPN) ao portfólio
Não vale a pena se o ISP tem um único nó central sem topologia física redundante. Nesse caso, uma rede plana com VLANs bem desenhada é suficiente e mais simples de operar.
Como ajudamos na Ayuda.LA
Na Ayuda.LA trabalhamos com ISPs na América Latina —incluindo operadores com equipamento MikroTik e Huawei— no desenho e na implementação de arquiteturas overlay:
- Auditoria da arquitetura atual: identificamos os riscos operacionais da rede existente e as oportunidades de melhoria com overlay.
- Desenho de underlay e overlay: definimos o plano de numeração, a topologia de roteamento, o modelo de serviços MPLS ou VXLAN e os mecanismos de redundância.
- Migração sem corte de serviço: desenhamos a sequência de migração por fases, serviço a serviço, com validação em cada passo.
- Capacitação do NOC: a equipe aprende a operar uma rede overlay —como diagnosticar, como adicionar serviços, como escalar— antes do sistema estar em produção.
Se sua rede tem spanning tree no backbone e quer avaliar a alternativa, o primeiro passo é uma auditoria de arquitetura.
Quer saber se sua rede está pronta para um overlay? Escreva para [email protected] — respondemos todas as mensagens.