Introdução
MPLS vs SD‑WAN é uma das decisões arquiteturais mais críticas para redes corporativas e industriais que suportam voz, aplicações SaaS, telemetria OT e acessos a data centers. Neste artigo, como Estrategista de Conteúdo Técnico da IRD.Net, unimos conceitos de arquitetura de rede, métricas de desempenho (latência, jitter, perda), normas relevantes (por exemplo, MEF, RFC 4364, e referências de segurança como IEC 62368-1 quando aplicável a hardware) e vocabulário técnico que você, engenheiro ou integrador, usa diariamente. Desde protocolos (BGP, LDP, OSPF, IPsec, DTLS) até indicadores de disponibilidade (MTBF, SLA), cobre-se o espectro necessário para decisões seguras.
A leitura é orientada para decisões práticas: entender o que cada tecnologia faz, por que importa para KPIs e TCO, como avaliar seu ambiente e como projetar uma migração com coexistência hybrid WAN. O texto usa analogias técnicas pontuais (por exemplo, comparar o MPLS a uma ferrovia tarifada com bilhetes e o SD‑WAN a uma frota multi‑modal com roteamento dinâmico) sem perder precisão numérica e operacional.
Para navegação e aprofundamento, este pilar inclui checklists, parâmetros de PoC, comandos/outputs típicos e recomendações operacionais (1–3 anos). Consulte também artigos do blog da IRD.Net para conteúdos relacionados: https://blog.ird.net.br/?s=SD-WAN e https://blog.ird.net.br/?s=MPLS. Para mais artigos técnicos consulte: https://blog.ird.net.br/
O que são MPLS e SD‑WAN: arquitetura, componentes e diferenças fundamentais (MPLS vs SD‑WAN)
Arquitetura e componentes principais
MPLS (Multiprotocol Label Switching) é uma tecnologia de encaminhamento que utiliza labels para determinar caminhos dentro de uma rede provida por um carrier. Componentes típicos incluem PE/CE routers, P routers, protocolos de sinalização como LDP e RSVP‑TE (para Traffic Engineering), e a interconexão com BGP para VPNs (RFC 4364). Em um diagrama mental, imagine um backbone com caminhos pré‑definidos e SLAs por classe de serviço.
SD‑WAN (Software‑Defined WAN) é uma camada de controle e orquestração que abstrai o transporte subjacente (MPLS, Internet banda larga, LTE/5G). Seus componentes são controllers/orchestrators, edge appliances (appliances físicos ou virtualizados), e agentes de telemetria que realizam path selection com base em métricas em tempo real (latência, jitter, perda). Protocolos proprietários (ex.: OMP da Viptela) ou padrões (BGP+IPsec) são usados para data plane e controle.
Diferenças técnicas que impactam operações
Diferenças essenciais: encaminhamento (label switching vs routing IP dinâmico), QoS (classes rígidas em MPLS vs QoS aplicada por políticas e granularidade por aplicação em SD‑WAN), controle (provedor‑centric em MPLS vs controller‑centric em SD‑WAN), e pontos de presença (PoPs do carrier para MPLS contra orquestração centralizada e edge distribuído em SD‑WAN). Esses elementos afetam provisionamento, tempo de resolução de falhas e governança.
Protocolos, topologias e exemplos de tráfego
Protocolos envolvidos: BGP, OSPF, LDP/RFC5036, RSVP‑TE, IPsec/IKEv2, DTLS, BFD para detecção rápida de falhas e NetFlow/sFlow para telemetria. Topologias típicas: hub‑and‑spoke MPLS, full mesh sobre SD‑WAN com túnel IPsec, e modelos híbridos. Exemplos práticos: tráfego de voz (sensível a jitter e perda) frequentemente prefere caminhos MPLS ou paths SD‑WAN com SLA rigoroso; SaaS/Internet breakout é otimizado no edge via SD‑WAN.
Por que isso importa: impacto em performance, custo, segurança e SLA ao comparar MPLS vs SD‑WAN
Impacto em KPIs de rede
A escolha entre MPLS vs SD‑WAN afeta diretamente latência, jitter, perda e disponibilidade. MPLS costuma entregar latência previsível e SLAs quantificáveis (ex.: 99,95% com limites de jitter), enquanto SD‑WAN otimiza caminhos sobre múltiplos links e usa técnicas de forward error correction e re‑routing para reduzir perda percebida, porém a variabilidade do transporte público pode afetar garantias estritas.
TCO e modelos de custo
Modelos de custo típicos: MPLS tende a ter maior OPEX por circuitos dedicados e preços por largura de banda por site; SD‑WAN reduz OPEX ao usar Internet pública e permite maior granularidade em CAPEX (appliances/VMs). Importante quantificar: custo por Mbps, custo de gerenciamento (NOC), custo de falhas (MTTR), e economias com cloud on‑ramp. Faça uma TCO 3–5 anos incluindo custo de hardware, licenças, links e equipe.
Segurança, compliance e SLAs
Segurança: SD‑WAN frequentemente integra SASE (Secure Access Service Edge) e inspeção de tráfego distribuída; MPLS fornece isolamento lógico por VPNs, útil para requisitos de compliance mais rígidos. Normas e compliance a considerar: requisitos de disponibilidade e segurança de setores regulados (ex.: saúde, energia). Para hardware e infraestrutura, considere normas aplicáveis como IEC 62368‑1 para segurança elétrica e MTBF para disponibilidade esperada de appliances.
Como decidir: checklist técnico e critérios de decisão para migrar (avaliação realista para MPLS vs SD‑WAN)
Inventário e mapeamento de aplicações
Comece com inventário: liste aplicações críticas, requisitos de QoS, portas, protocolos e sensibilidade a latência/jitter. Exemplos: VoIP (≤150 ms ideal), SCADA/RTU (determinismo de entrega), ERP/SaaS (dependente de throughput e burst). Mapear tráfego atual (NetFlow/IPFIX) por site e horários pico é mandatório.
Checklist prático de avaliação
Checklist acionável:
- Inventário de links e capacidades (MPLS, Internet, LTE)
- Mapas de tráfego por aplicação e hora
- Requisitos de QoS/class of service (CoS) e conversão para classes SD‑WAN
- Avaliação de fornecedores (SLAs, PoPs, suporte 24/7)
- Dependências de fornecedores e lock‑in (hardware, controller)
- Plano de PoC: KPIs a medir (latência média/95º perc., jitter, perda, MTTR)
PoC e critérios de aceitação
Defina PoC com duração mínima de 4 semanas em sites representativos. KPIs a medir: latência média e 95º perc., perda, jitter, tempo de failover e impacto em aplicações críticas (MOS para voz). Critérios de aceitação: melhorias claras de TCO e não degradação de SLA percebido; autorização de rollback documentada.
Como fazer a migração/integração: projeto, testes e rollout prático de SD‑WAN com coexistência MPLS
Planejamento de arquitetura híbrida
Projetos híbridos (hybrid WAN) são padrão: manter MPLS para sites com SLAs críticos e usar SD‑WAN para otimizar SaaS e Internet breakout. Defina políticas de routing: route‑maps BGP para preferir MPLS para DC/voz e SD‑WAN para SaaS. Mapear classes de serviço entre PHB/DSCP em MPLS e políticas SD‑WAN é essencial para preservar QoS.
Testes, failover e policy translation
Tradução de classes de serviço: crie uma tabela de correspondência DSCP→Classe SD‑WAN→PHB MPLS. Configure path selection e failover com timers (BFD < 50 ms para detecção). Implemente PoC com tráfego sintético (iperf) e real (SIP calls, replicação de DB) e monitore com NetFlow, SNMP e métricas do controller. Tenha plano de rollback e janelas de manutenção.
Rollout passo a passo
Roteiro mínimo:
- PoC em 2–3 sites críticos e 2 remotos por 4–6 semanas.
- Validação de KPIs e ajustes de políticas (QoS, firewall).
- Rollout por ondas (10–20% dos sites) com automação de templates.
- Monitoramento pós‑go‑live (30–90 dias) e revisão de SLA.
Para aplicações que exigem robustez e integração com MPLS, verifique soluções de hardware e serviços na página de produtos da IRD.Net: https://www.ird.net.br/produtos/. Para projetos com necessidade de orquestração e suporte avançado, a página de soluções da IRD.Net contém ofertas e serviços gerenciados: https://www.ird.net.br/solucoes/.
Avançado: comparações técnicas detalhadas, erros comuns e troubleshooting em migrações MPLS vs SD‑WAN
Problemas frequentes e suas causas
Erro comum: discrepâncias de QoS entre domínios que causam jitter em voz. Causa típica: tradução DSCP faltante ou policers incorrretos em dispositivo de borda. Outro problema: rotas inconsistentes devido a múltiplos BGP e políticas de preferência; aqui, RIB/policy debugging e BGP AS path/preference são críticos.
Logs, métricas e playbooks de mitigação
Monitore: BFD sessions, latência 1/5/15 min, jitter, perda por caminho, contadores de retransmissão TCP, e MTU (fragmentação pode interromper IPSec). Playbook de mitigação:
- Se perda em Internet: habilitar FEC/replicate ou encaminhar via MPLS até resolução.
- Se BGP flaps: verificar timers, BFD e políticas de route‑reflector.
- MTU issues: testar com ping mtu (DF bit) e ajustar IPsec overhead.
Comandos úteis (exemplos genéricos): show ip route, show mpls forwarding, show bgp summary, show sdwan policy, show bfd sessions.
Integração com segurança e NOC/SDN
Integração com SASE e inspeção no edge muda o fluxo: aplicar políticas de security service chaining (FW→IPS→CASB) e garantir latência adicional aceitável. Para operações, centralizar alertas em NOC via syslog/NETCONF/REST API e correlacionar eventos com observability (traces, distributed metrics). Escolha stacks de fornecedores considerando interoperabilidade BGP/MPLS e APIs abertas.
Estratégia e roadmap: recomendações operacionais, modelos híbridos e o futuro de WAN (roadmap 1–3 anos para MPLS vs SD‑WAN)
Roadmap operacional (0–12 meses)
Curto prazo: implementar PoC, consolidar políticas de QoS/CoS e automatizar deploys com templates. Defina KPIs de sucesso (latência 95º perc., perda < 0,5% para voz) e crie governança de fornecedores (SLA, RTO/RPO). Reavalie contratos MPLS para flexibilidade e margens de burst.
Roadmap tático (12–24 meses)
Médio prazo: ampliar SD‑WAN para mais sites, implementar SASE cloud‑delivered para security on‑demand e iniciar eliminação gradual de circuits MPLS onde SLAs permitirem. Investir em automação (Ansible, Terraform) e observability (distributed tracing, AI/ML para anomalias).
Roadmap estratégico (24–36 meses)
Longo prazo: consolidar arquitetura híbrida com cloud on‑ramp otimizado, adotar políticas de zero‑trust e planejar descomissionamento de cores MPLS com garantias de failback. KPIs de sucesso pós‑migração: redução de TCO, melhoria de experiência de usuário (UX) e redução de MTTR. Governança: revisão anual de arquitetura, contratos e planos de capacidade.
Conclusão
A decisão entre MPLS vs SD‑WAN não é binária; trata‑se de alinhar requisitos técnicos (latência, jitter, perda), operacionais (SLAs, TCO) e estratégicos (cloud adoption, SASE). Para sites críticos com SLAs rígidos, MPLS ainda é justificável; para agilidade, otimização de SaaS e redução de custos, SD‑WAN traz ganhos claros. Projetos efetivos adotam modelos híbridos e um PoC bem definido com KPIs mensuráveis.
Se desejar, eu posso:
- Gerar o esqueleto expandido de cada sessão com subseções (H3) e bullets técnicos específicos (com exemplos de comandos, métricas e templates de PoC).
- Criar um checklist operacional em formato pronto para usar (CSV/markdown) para a Sessão 3 e um playbook de troubleshooting para a Sessão 5.
Qual opção prefere? Pergunte nos comentários abaixo ou solicite o material pronto para seu ambiente — sua dúvida técnica ajudará a customizar o PoC e o checklist para o seu parque de redes.
Para mais artigos técnicos consulte: https://blog.ird.net.br/
