Introdução
No comparativo técnico entre MPLS vs Ethernet comparacao tecnica para redes corporativas, abordaremos em profundidade arquiteturas, KPIs e requisitos de projeto para Engenheiros Eletricistas, Projetistas de Produtos (OEMs), Integradores e Gerentes de Manutenção. Usarei termos como PE/CE, LSP, VPLS, EVPN, e métricas como RTT, jitter, perda de pacote, MTTR e TCO, além de relacionar normas aplicáveis a equipamentos de borda como IEC/EN 62368-1 e IEC 60601-1 quando pertinente ao fornecimento e certificação de hardware.
Este artigo tem objetivo prático: mostrar onde cada tecnologia atua na pilha de rede, como afeta SLAs e custos, e fornecer um roteiro de projeto, migração e operação. Haverá exemplos de configuração, políticas de QoS, procedimentos de OAM (BFD, LSP ping, Y.1731) e playbooks de recuperação.
Convido você a comentar dúvidas específicas ou casos de uso complexos ao final; essa interação ajuda a refinar recomendações arquiteturais e a transformar o conteúdo em um guia aplicável ao seu ambiente industrial ou corporativo.
1) O que são MPLS e Ethernet — Fundamentos essenciais para redes corporativas
Fundamentos e modelo de operação
O MPLS (Multiprotocol Label Switching) é uma tecnologia de comutação baseada em rótulos que opera entre as camadas 2 e 3 do modelo OSI, usada para encaminhamento determinístico e serviços L2/L3 (por exemplo, L3VPN, VPLS, EVPN). O MPLS encapsula pacotes com labels que permitem trajetórias chamadas LSP (Label Switched Paths), reduzindo a complexidade das decisões de roteamento em cada nó.
A Ethernet convencional é uma tecnologia de camada 2 que transporta frames e hoje é amplamente utilizada em MAN/WAN com variantes de serviço (E-Line, E-LAN via pseudowires, EVPN). Em ambientes corporativos, Ethernet fornece alta largura de banda e baixo custo por bit, sendo comum em topologias metro/fitas de agregação.
Analogicamente, pense no MPLS como etiquetas postais que dizem exatamente por qual rota o envelope deve seguir, enquanto a Ethernet é o próprio envelope que transporta o conteúdo — a diferença entre label e frame determina latência de decisão, escalabilidade e modelo de serviço.
Topologias típicas e terminologia chave
Topologias MPLS típicas incluem full-mesh entre PE, modelos hub-and-spoke (centro de dados como hub) e redes em camadas com core de service provider. Terminologia crítica: PE (Provider Edge), CE (Customer Edge), LSP, VRF, RT e BGP/MPLS VPN. Para Ethernet, vemos topologias point-to-point, ring, e meshed com tecnologies de proteção como RSTP, MSTP ou características de carrier como LACP e Q-in-Q.
Serviços Ethernet evoluíram para suportar modelos L2 VPN (pseudowire, VPLS) e overlays como EVPN-VXLAN que unem controle BGP com encapsulamento L2 sobre L3, ideal para data centers e multi-tenant. Em MPLS, o controle de caminho e priorização de tráfego (Traffic Engineering) é nativo via RSVP-TE ou Segment Routing (SR-MPLS).
A escolha entre MPLS e Ethernet impacta diretamente protocolos de controle (BGP, OSPF, ISIS), requisitos de equipamentos (PE com capacidade de label switch), e necessidades de interworking quando coexistem (MPLS sobre transportes Ethernet ou vice-versa).
Quadro rápido de capacidades
- MPLS: SLAs determinísticos, suporte a QoS granular, Traffic Engineering avançado, recuperação rápida com FRR/LFA e suporte natural a VPNs segmentadas (L2/L3).
- Ethernet: Maior largura de banda por custo, simplicidade de operação, ideal para agregação e serviços de alta capacidade; quando combinado com EVPN entrega segmentação mais flexível em DC.
- Ambos: podem coexistir — MPLS sobre Ethernet ou EVPN-VXLAN para unificar DC e WAN. Para mais leitura sobre interoperabilidade e SD-WAN, veja o artigo do blog: https://blog.ird.net.br/mpls-vs-sd-wan.
2) Por que a escolha importa — Benefícios, trade-offs e KPIs para redes corporativas
Impactos em latência, jitter e SLAs
A seleção entre MPLS e Ethernet altera diretamente métricas como RTT, jitter e perda de pacotes, que são críticas para voz, vídeo e aplicações industriais determinísticas. MPLS tende a oferecer caminhos mais estáveis e apoio a QoS fim-a-fim garantido pelo provedor, reduzindo jitter e perda em cenários multihop. Ethernet pode atingir menor latência em enlaces diretos de alta capacidade, mas sem políticas de SLA por fluxo, a performance pode variar em congestionamentos.
Para aplicações sensíveis (SCADA, telefonia crítica, telemetria), métricas típicas de aceitação: RTT < 50 ms, jitter < 20 ms, perda < 0.1%. Esses valores devem ser negociados no SLA e testados em condições de carga. KPIs a monitorar: RTT, jitter, perda, disponibilidade (níveis de “nove” – 99.9% etc.), MTTR, e custo por site.
Comparar essas métricas exige testes controlados (iperf, ping com timestamp, MOS para voz), além de simular falhas para medir recuperação e comportamento de QoS em situações degradadas.
Trade-offs comerciais e operacionais
Do ponto de vista comercial, Ethernet normalmente oferece menor TCO em links de alta largura (fibra metro), enquanto MPLS traz vantagem na garantia de SLAs e serviços gerenciados com suporte ao cliente. O trade-off é entre custo e previsibilidade: MPLS tem maior custo por Mbps, mas compensa quando exigência de disponibilidade e prioridade de tráfego é crítica.
Operacionalmente, Ethernet requer menos especialização em label-switching, mas pode precisar de controle adicional (EVPN, VXLAN, QOS) para igualar funcionalidades de isolamento e multitenancy providas nativamente pelo MPLS. Integradores devem avaliar CAPEX (equipamento, switches, roteadores) vs OPEX (contratos, monitoração, equipe).
KPIs financeiros: custo por Mbps, custo por site para garantia de 99.95% vs 99.99%, e impacto do downtime medido em MTTR e custo por hora de indisponibilidade — fatores essenciais ao decidir entre modelos.
Quando cada tecnologia entrega valor
Escolha MPLS quando houver necessidade de SLAs estreitos, prioridade de tráfego por fluxo, e suporte a VPNs L3/VPN com roteamento centralizado. Exemplos: redes bancárias, backhaul crítico, interconexão de data centers com requisitos de segurança e segmentação forte.
Escolha Ethernet (com EVPN quando necessário) para ambientes com demanda massiva de banda, custo sensível e topologias metro/edge, como aggregadores de filiais, campus e redes de backup. Quando combinado com SD‑WAN, Ethernet pode prover flexibilidade e redução de custos para tráfego não crítico.
Para projetos híbridos, considere MPLS+Ethernet onde MPLS garante o núcleo crítico e Ethernet suporta agregação e alta capacidade local — essa combinação equilibra custo, desempenho e escalabilidade.
3) Como projetar e migrar — Guia prático passo a passo para implementar MPLS ou Ethernet em ambientes corporativos
Levantamento de requisitos e seleção de serviços
Comece com um inventário detalhado: aplicações, requisitos de RTT/jitter/perda por aplicação, horários de pico, topologia atual, capacidade de portas e redundância elétrica (observando normas de hardware como IEC/EN 62368-1 e parâmetros de confiabilidade como MTBF). Mapear fluxos leste-oeste e norte-sul é essencial para dimensionar links e políticas de QoS.
Defina prioridades de negócio e mapeie para KPIs técnicos. Por exemplo, aplicações de voz/SCADA → prioridade alta, RTT e jitter estritos; backups e sincronização → prioridade média/baixa. Escolha serviços: L3VPN (BGP/MPLS) para isolamento de roteamento, VPLS/EVPN para L2 multiponto, EVPN-VXLAN em data centers.
Checklist inicial: link budgets, SLA desejado por site, equipamentos CE com suporte a BGP/MPLS/EVPN, tabelas de rota esperadas, e políticas de QoS. Documente interfaces físicas, horários de manutenção e fallback.
Topologias de referência e decision tree
Modelos de referência: branch-to-DC (filiais conectadas a DC via MPLS/EVPN), hub-and-spoke (centro de serviços centralizado), e meshed (para baixa latência entre sites críticos). Use hub-and-spoke para simplificar roteamento e meshed quando baixa latência entre filiais for necessária.
Decision tree prática: se SLA crítico e suporte a QoS por fluxo → considerar MPLS L3VPN; se necessidade de alto throughput e custo reduzido → Ethernet/EVPN; se mobilidade e conectividade multi-link → SD‑WAN com ou sem MPLS como underlay. Inclua condições de fallback e testes A/B.
Diagrama típico (simplificado): Filiais —(CE)— ISP/MPLS — PE — Core DC (VRF) — serviços. Para EVPN-VXLAN: Leaf/Spine com EVPN control plane para distribuição de MAC/IP.
Plano de migração e cutover
Planeje migração por ondas (pilot → 10% → 50% → 100%), iniciando por sites não-críticos. Estabeleça janela de cutover, rollback plan e testscripts (checar BFD, LSP ping, tabelas VRF, QoS counters). Utilizar simulação de tráfego em lab é obrigatório para validar políticas.
Checklist de cutover inclui validar adjacências BGP/OSPF, ativar MPLS/CEF, verificar labels, validar QoS (policies e class-maps), configurar OAM (Y.1731 para Ethernet, LSP ping para MPLS). Automatize testes com scripts (ex.: Ansible + pytest) para reduzir erro humano.
Defina critérios de aceitação (KPIs) por site: RTT/jitter/perda dentro de limites, rotas propagadas corretamente, e recuperação de falha testada (simular link down e medir FRR/BFD).
Para aplicações que exigem essa robustez, a série de roteadores industriais da IRD.Net é a solução ideal: https://www.ird.net.br/produtos/roteadores-industriais. Para agregação e switches com suporte a EVPN e QoS industrial, veja: https://www.ird.net.br/produtos/switches-ethernet-industriais.
4) Implementação e operações — Configurações, QoS, OAM e rotina de troubleshooting (MPLS vs Ethernet)
Comandos e exemplos essenciais (exemplo genérico)
Exemplo rápido (pseudocódigo Cisco-like) para ativar MPLS e VPN no PE:
- ip cef
- mpls ip
- router bgp 65000
- neighbor X remote-as Y
- address-family vpnv4
- redistribute connected
Configuração CE simples (BGP):
- router bgp 65001
- neighbor PE_IP remote-as 65000
- neighbor PE_IP activate
Esses exemplos são base; adapte para Juniper/Cumulus e valide distribuição de labels e VRF.
Para EVPN-VXLAN (control-plane BGP/EVPN), ative EVPN address-family e associe VNIs nos Leafs/Spines, com flood-control via EVPN Type-2/Type-5. Documente rotas, RD/RT e políticas de import/export.
Políticas de QoS e OAM
Estruture QoS em três etapas: classificação (class-map), marcação (policy-map), e enfileiramento (queuing/shaping). Exemplo de classes: latência crítica (VoIP/SCADA), priorizada (ERP), best-effort. Use remarking para MPLS EXP/TC bits e para DSCP em underlay.
Implemente OAM regulamentado: BFD para detecção rápida de falhas (sub-50 ms), LSP ping e LSP traceroute para MPLS, e Y.1731 para continuidade de serviço em Ethernet com métricas de delay e jitter. Configure thresholds e alarmes de integração com NMS.
Monitore counters de QoS, drops por interface, utilização por fila e latências por hop. Integre com sistemas de telemetry (gNMI/RESTCONF) para coleta contínua e alertas pró-ativos.
Troubleshooting e runbooks
Crie runbooks para falhas comuns: perda de rota BGP, labels ausentes, saturação de fila e loop L2. Procedimento padrão: validar conectividade física, checar logs OSPF/BGP, verificar tabelas de labels (show mpls forwarding), e checar counters de QoS.
Scripts exemplares de verificação: ping com timestamp, traceroute MPLS/LSP, checagem de BFD session, e teste de perf (iperf3) para validar throughput e latência sob carga. Documente RTs esperados e gatilhos de escalonamento.
Para recuperação, automatize rollback (config snippets mantidos no versionamento), e utilize isolamento de falhas com testes incremental; treine equipe de NOC para procedimentos de escalonamento e comunicação com provedores.
5) Comparação técnica avançada e erros comuns — Latência, redundância, segurança, custos e integração (MPLS vs Ethernet)
Medições de desempenho e modelos de custo
Estudos de medição mostram que MPLS fornece recuperação rápida (FRR < 50 ms com configuração adequada) e latência previsível, enquanto Ethernet em enlaces diretos pode apresentar latências menores em tabela, mas maior variabilidade sem QoS. Tabelas comparativas típicas incluem: RTT médio (ms), jitter (ms), perda (%) e tempo de recuperação (s).
Modelos de custo devem considerar CAPEX (equipamentos PE/CE, WAN accelerators) e OPEX (links, manutenção, SLAs). Calcule custo por Mbps e custo por site para níveis de disponibilidade (ex.: custo adicional para 99.99% vs 99.95%). Faça TCO em 3–5 anos e inclua custos de mão de obra e treinamento.
Ferramentas de benchmarking: IETF RFCs para medição, iperf, BWP, e sondas OAM. Comparar resultados em cenários de pico e falha é essencial para decisões racionais.
Coexistência e integração (armadilhas)
Coexistência típica: MPLS sobre Ethernet em provedores que usam transportes Ethernet para o core, ou EVPN-VXLAN para unificar DC e WAN. Armadilhas comuns incluem mismatch de MTU (VXLAN adiciona overhead), inconsistências de QoS entre domains (EXP vs DSCP), e problemas de ARP/ARP-flapping em VPLS.
Integração BGP entre domínios exige planejamento de RD/RT e políticas de import/export; erros podem causar vazamento de rotas ou loops. Ao migrar para EVPN, ajuste timers e stabilize MAC learning para evitar tempestades.
Recomendações: padronize MTU, harmonize políticas de QoS end-to-end, use filtros de controle de rota, e documente transformação de marcação de pacotes entre domínios (remarking).
Estudo de caso e mitigação
Cenário: falha de link em backbone Ethernet sem MPLS, causando flutuações de latência e perda temporária de serviços. Mitigação: introduzir EVPN com proteção multi-homing e BFD para detecção rápida, ou migrar links críticos para MPLS com SLA.
Outro caso: provedor entrega Ethernet sem QoS e tráfego de backup congestiona link de voz. Solução: implementar policing/shaping no CE, ou mover voz para MPLS com contractual QoS. Teste cada mitigação em ambiente controlado antes do cutover.
Conclusão técnica: escolha híbrida frequentemente oferece melhor custo-benefício — MPLS para serviços críticos e Ethernet/EVPN para agregação e alta capacidade.
6) Decisão estratégica e roadmap futuro — Quando optar por MPLS, Ethernet ou SD‑WAN; recomendações acionáveis
Matriz de decisão e recomendações iniciais
Matriz simplificada:
- Necessidade de SLA estrito, isolação por VPN e Traffic Engineering → MPLS L3VPN
- Alta largura de banda, custo sensível, integração DC → Ethernet/EVPN
- Agilidade, múltiplos underlays e políticas de encaminhamento por aplicação → SD‑WAN com/sem MPLS
Use essa matriz como ponto de partida e ajuste para requisitos de latência, segurança e conformidade. Priorize provas de conceito (PoC) por 3–6 meses para validar solução em seu tráfego real.
Inclua stakeholders de segurança, operações e finanças na tomada de decisão. Estime impacto financeiro com cenários “com” e “sem” migração, incluindo riscos de continuidade.
Roadmap 0–36 meses
- 0–6 meses: PoC em 2–3 sites, padronização de equipamentos CE/PE, validar QoS e OAM.
- 6–18 meses: Migração faseada por ondas, implementação de monitoramento por telemetry, capacitação da equipe.
- 18–36 meses: Otimização (segment routing, EVPN-VXLAN, SD‑WAN integração), revisão de contrato com provedores e otimização de TCO.
KPIs para cada fase: disponibilidade, RTT médio, custo por Mbps, MTTR, e satisfação do usuário (NPS interno).
Passos imediatos para piloto e engajamento
- Defina 2–3 aplicações críticas e KPIs mensuráveis.
- Selecione sites para PoC que representem diversidade de condições (backhaul, fibra, rádio).
- Use ferramentas de automação (Ansible) para deploy e scripts de verificação.
Inicie contato com fornecedores certificados e integre a solução com plataformas de NOC/NMS existentes. Para suportar implementações industriais com robustez e certificação, avalie os equipamentos de roteamento e switches industriais da IRD.Net.
Conclusão
A escolha entre MPLS e Ethernet (e suas combinações com EVPN, VXLAN e SD‑WAN) deve ser guiada por requisitos técnicos mensuráveis (RTT, jitter, perda, disponibilidade), custos totais e capacidade operacional da equipe. MPLS permanece a opção robusta para SLAs rigorosos; Ethernet/E VPN é superior em custo por bit e escalabilidade de banda em ambientes metro/DC.
Projetar corretamente exige levantamento detalhado, PoC controlado, políticas de QoS e OAM bem definidas, e um plano de migração faseado com rollback. Integração e harmonização de marcações/MTU/QoS entre domínios é crítico para evitar problemas.
Pergunte nos comentários sobre seu caso específico: descreva aplicações, topologia atual e objetivos de SLA — responderemos com recomendações práticas. Para mais artigos técnicos consulte: https://blog.ird.net.br/
