MPLS — Multiprotocol Label Switching
Do fundamento ao nível especialista — comutação por rótulos, VPNs de operadora e engenharia de tráfego, com o padrão internacional e a prática real de backbone brasileiro.
Nesta página
1. Nível Básico — Fundamentos Básico
Pré-requisito recomendado: OSPF ou IS-IS — MPLS precisa de um IGP link-state funcionando por baixo pra fazer sentido.
1.1 O problema que o MPLS resolve
Num roteador IP tradicional, cada pacote que chega é analisado individualmente: o roteador olha o endereço de destino, consulta a tabela de roteamento (busca pelo prefixo mais específico — "longest prefix match") e decide a próxima interface. Isso se repete, do zero, em cada roteador do caminho. O MPLS propõe algo diferente: na borda da rede, um rótulo (label) curto e de tamanho fixo é anexado ao pacote, representando a decisão de encaminhamento já tomada. Os roteadores do núcleo da rede não olham mais o endereço IP — só o rótulo, numa operação muito mais simples e rápida (troca o rótulo, encaminha).
Analogia: é a diferença entre um carteiro que lê o endereço completo em cada esquina pra decidir o caminho (roteamento IP puro) e um sistema de etiquetas de código de barras num centro de distribuição — a etiqueta já diz "vai pro caminhão 4, doca 12", sem precisar reler o endereço completo em cada ponto da esteira.
"Multiprotocol" no nome existe porque o MPLS foi desenhado pra encapsular qualquer protocolo de camada 3 (originalmente também outros, daí o nome) — na prática de hoje, majoritariamente IPv4 e IPv6, além de tráfego de camada 2 inteiro (ver seção 3).
1.2 Onde o MPLS fica na pilha de protocolos
É comum descrever o MPLS como "camada 2,5" — não é bem uma camada OSI oficial, mas a expressão captura bem a ideia: o cabeçalho MPLS fica entre o cabeçalho de camada 2 (Ethernet) e o de camada 3 (IP). Isso é o que permite ao MPLS transportar tanto tráfego IP (L3VPN) quanto quadros Ethernet inteiros (L2VPN) da mesma forma — o núcleo da rede nem precisa saber o que está "dentro" do rótulo.
1.3 Terminologia básica
| Termo | Significado |
|---|---|
| LSR | Label Switch Router — qualquer roteador que participa da comutação por rótulos |
| LER | Label Edge Router — roteador de borda, que adiciona (push) ou remove (pop) o rótulo pela primeira/última vez |
| PE | Provider Edge — LER que fica na borda da rede do operador, conectado ao cliente |
| P (Provider/Core) | Roteador de núcleo — só comuta rótulo, não conhece detalhes de VPN de cliente |
| CE | Customer Edge — roteador do cliente, fora da rede MPLS do operador |
| LSP | Label Switched Path — o "caminho" fim-a-fim definido pela sequência de rótulos |
1.4 Quando um ISP realmente precisa de MPLS
Três motivos típicos: VPNs de cliente (segregar tráfego de múltiplos clientes corporativos sobre o mesmo backbone físico, sem misturar rotas — seção 3), engenharia de tráfego (controlar exatamente por onde o tráfego passa, além do que o IGP decidiria sozinho — seção 4), e simplicidade operacional de core (roteador de núcleo não precisa manter rota de cliente nenhuma, só rótulos — escala melhor). Um ISP pequeno, só revendendo internet residencial sem VPN corporativa nem exigência de engenharia de tráfego fina, pode operar perfeitamente sem MPLS.
2. Nível Intermediário — Sinalização de rótulos Intermediário
2.1 Anatomia do rótulo (RFC 3032)
O cabeçalho MPLS tem 4 bytes (32 bits):
| Campo | Tamanho | Função |
|---|---|---|
| Label | 20 bits | O valor do rótulo em si — tem significado só local, entre dois roteadores adjacentes |
| TC (antigo EXP) | 3 bits | Traffic Class — usado pra QoS/priorização |
| S (Bottom of Stack) | 1 bit | Marca "1" no último rótulo da pilha — é assim que o roteador sabe onde a pilha de labels termina |
| TTL | 8 bits | Time To Live — mesma função do TTL do IP, previne loop infinito |
O bit S é o que viabiliza pilha de rótulos (label stack) — um pacote pode carregar múltiplos rótulos empilhados (ex: um rótulo de transporte + um rótulo de serviço numa L3VPN, ver seção 3). O roteador de núcleo só olha o rótulo do topo da pilha.
2.2 Operações: Push, Swap, Pop
- Push — adiciona um rótulo (acontece no LER de entrada/Ingress)
- Swap — troca o rótulo atual por outro (acontece nos roteadores P do meio do caminho)
- Pop — remove o rótulo do topo (acontece no LER de saída/Egress, ou no penúltimo salto — ver PHP abaixo)
2.3 PHP — Penultimate Hop Popping
Otimização comum: em vez do último roteador do LSP fazer 2 operações (olhar o rótulo de transporte, removê-lo, depois olhar o que sobrou), o penúltimo roteador já remove o rótulo de transporte antes de entregar ao último salto — que recebe o pacote praticamente pronto pra processar diretamente. Reduz uma etapa de processamento no roteador de borda de saída, que costuma ser o mais carregado (processa tráfego de múltiplos clientes/serviços).
2.4 LDP vs. RSVP-TE — como o rótulo é distribuído
Um roteador não "inventa" o rótulo sozinho — ele é sinalizado entre vizinhos por um protocolo de distribuição de rótulos:
- LDP (Label Distribution Protocol, RFC 5036) — mais simples, segue automaticamente o caminho que o IGP já calculou (segue a topologia, sem engenharia de tráfego). Rótulos distribuídos hop-by-hop a partir da adjacência de vizinhos LDP.
- RSVP-TE (RFC 3209) — sinaliza um caminho explícito, não necessariamente o mesmo que o IGP escolheria, com reserva de banda associada ao túnel. É a base do MPLS-TE (seção 4).
Regra prática: se você só precisa que o núcleo comute rótulo seguindo o caminho do IGP (típico em L3VPN/L2VPN sem exigência de TE), LDP resolve com muito menos complexidade operacional que RSVP-TE.
2.5 FEC — Forwarding Equivalence Class
Um FEC é um grupo de pacotes tratados da mesma forma pelo LSR — tipicamente, todo tráfego destinado a um mesmo prefixo IP (via LDP) ou associado a um mesmo túnel de engenharia de tráfego (via RSVP-TE) pertence à mesma FEC, e por isso recebe o mesmo rótulo. É o conceito que conecta "decisão de roteamento tradicional" com "rótulo MPLS".
3. Nível Avançado — VPNs de operadora Avançado
É aqui que o MPLS se torna produto vendável — VPN de camada 3 e camada 2 sobre backbone compartilhado.
3.1 L3VPN — RFC 4364 (antiga RFC 2547)
Permite que múltiplos clientes compartilhem o mesmo backbone MPLS, cada um com sua tabela de roteamento completamente isolada — mesmo que dois clientes usem o mesmo range de IP privado (RFC 1918), não há conflito. Peças-chave:
- VRF (VPN Routing and Forwarding) — instância de roteamento isolada no PE, uma por cliente
- Route Distinguisher (RD) — valor único que, prefixado ao endereço IPv4 do cliente, cria um endereço VPNv4 globalmente único (resolve o problema de IPs sobrepostos entre clientes)
- Route Target (RT) — extended community BGP que controla quais VRFs importam/exportam rota de qual outra VRF — é o que viabiliza topologias complexas (hub-and-spoke, full-mesh, extranet entre clientes específicos)
- MP-BGP (Multiprotocol BGP) — os PEs trocam rotas VPNv4/VPNv6 entre si via BGP (tipicamente iBGP, com Route Reflector), carregando RD+prefixo+RT
Fluxo de rótulos numa L3VPN: pacote recebe 2 rótulos empilhados — o rótulo de transporte (define o caminho LSP até o PE remoto, distribuído por LDP/RSVP-TE) e o rótulo de serviço/VPN (identifica pra qual VRF entregar no PE de saída, distribuído junto com a rota via MP-BGP).
3.2 L2VPN — transportando Ethernet inteiro
Em vez de rotear IP do cliente, o L2VPN transporta o quadro Ethernet inteiro — o cliente enxerga a rede do operador como um cabo virtual (ou switch virtual) entre seus próprios sites, sem participar de roteamento nenhum com o operador:
- VPWS (Virtual Private Wire Service, "pseudowire" ponto a ponto) — emula um cabo dedicado entre 2 pontos
- VPLS (Virtual Private LAN Service) — emula um switch Ethernet multiponto entre 3+ sites, incluindo aprendizado de MAC no núcleo da rede
- EVPN (Ethernet VPN) — evolução mais moderna, usa BGP (em vez de LDP) pra distribuir informação de MAC/topologia, muito mais eficiente e flexível que VPLS clássico — tendência de substituição gradual do VPLS tradicional
Detalhe operacional relevante em L2VPN corporativo: o cliente frequentemente espera que protocolos de controle de camada 2 (Spanning-Tree, LLDP, LACP entre os próprios equipamentos dele) atravessem a rede do operador como se fosse um cabo direto. Isso exige um mecanismo de tunelamento de protocolos de camada 2 (às vezes chamado L2PT), que passa esses quadros de controle "por dentro" do túnel MPLS sem o operador processá-los como se fossem dele.
3.3 Unified MPLS — escalando pra rede muito grande
Redes de operadora de grande porte tendem a ter múltiplos domínios IGP (ex: por região) que não formariam uma única área OSPF/IS-IS de forma prática. Unified MPLS é a abordagem de arquitetura que permite manter LSPs fim-a-fim através de múltiplos domínios IGP interligados, tipicamente redistribuindo loopbacks dos PEs entre domínios via BGP (usando o próprio MP-BGP da L3VPN como "cola" entre domínios), em vez de forçar tudo numa única e gigantesca instância de IGP.
4. Engenharia de tráfego (MPLS-TE) Avançado
Por padrão, um IGP escolhe o caminho de menor custo — ponto final. Isso pode deixar alguns links do backbone congestionados enquanto outros ficam ociosos, porque o IGP não tem noção de quanta banda já está em uso em cada link, só do custo estático configurado. MPLS-TE resolve isso construindo túneis RSVP-TE com caminho explícito e reserva de banda — o operador pode forçar deliberadamente que certas classes de tráfego usem um caminho diferente do que o IGP escolheria sozinho, distribuindo carga de forma mais equilibrada pelo backbone inteiro.
Isso é tecnicamente mais flexível e previsível do que tentar obter o mesmo resultado manipulando métrica de IGP (prática desaconselhada — ver seção de boas práticas do OSPF) — a métrica do IGP afeta o roteamento inteiro da rede de uma vez, enquanto um túnel TE afeta só o tráfego especificamente direcionado pra ele.
Fast Reroute (FRR) é um recurso complementar do MPLS-TE: pré-calcula um caminho alternativo de backup pra cada segmento protegido do túnel, permitindo failover na casa de dezenas de milissegundos em caso de falha de link — muito mais rápido que esperar a reconvergência normal do IGP.
5. Segment Routing — o futuro do MPLS Especialista
Segment Routing (RFC 8402) é a evolução que vem gradualmente substituindo LDP e RSVP-TE clássicos em redes novas. A ideia central: em vez de sinalizar rótulos hop-by-hop via um protocolo dedicado (LDP) ou reservar caminho explícito via outro protocolo dedicado (RSVP-TE), o caminho inteiro é codificado como uma lista de segmentos (rótulos) diretamente no cabeçote do pacote pelo roteador de origem — os roteadores intermediários não precisam manter estado de sessão nenhum sobre aquele caminho específico, só executam a instrução do segmento no topo da pilha.
Dois modos de encapsulamento: SR-MPLS (reaproveita o formato de rótulo MPLS clássico de 20 bits, mais fácil de adotar em rede já MPLS) e SRv6 (usa endereçamento IPv6 nativo como segmento, sem depender de rótulo MPLS tradicional).
Por que a indústria está migrando: elimina a necessidade de manter LDP e RSVP-TE como protocolos de sinalização separados (menos estado pra manter em cada roteador do núcleo), e se integra naturalmente com controle centralizado via PCE (Path Computation Element) e SDN — a distribuição de segmentos passa a acontecer diretamente pelas extensões do próprio IGP (OSPF/IS-IS), sem protocolo extra dedicado a isso.
6. Boas práticas de ISP Avançado
Temas e conceitos de referência: material técnico do Brasil Peering Forum sobre MPLS pra provedores (Leonardo Furtado) — organização e redação próprias desta página.
Um LSP fim-a-fim depende de rota específica pro loopback de cada roteador. Sumarização de rota IGP no meio do caminho quebra a continuidade do LSP e derruba os serviços L2VPN/L3VPN que passam por ali — mesmo problema já discutido na página de OSPF, mas com consequência ainda mais direta em backbone MPLS.
RSVP-TE agrega complexidade operacional real (estado de sessão por túnel, manutenção de reserva de banda). Se o objetivo é só ter LSP seguindo o IGP pra viabilizar L3VPN/L2VPN, LDP entrega isso com muito menos superfície de configuração e troubleshooting.
Como o núcleo só olha o rótulo (não o IP interno), balancear tráfego por ECMP dentro do MPLS puro é menos trivial que em IP — soluções usam rótulos/campos adicionais (ex: Flow Label específico) pra dar ao core informação suficiente de entropia pra balancear corretamente entre múltiplos caminhos de igual custo.
A necessidade de equilibrar carga entre links existe em qualquer topologia (L2 ou L3, com ou sem MPLS) — o diferencial do MPLS-TE é ser mais flexível e menos arriscado que as alternativas de gambiarra tradicionais (manipulação de métrica, rota estática, PBR isolado).
VPLS clássico tem limitações reais de escala (flood-and-learn no núcleo, ausência de multi-homing ativo/ativo eficiente) que o EVPN resolve — operadoras com L2VPN corporativo relevante devem tratar essa migração como parte do roadmap, não reação tardia a um limite sendo atingido.
7. Segurança Avançado
MPLS por si só já entrega isolamento razoável entre VPNs de clientes diferentes (VRFs separadas, sem visibilidade cruzada por padrão) — mas isso não substitui cuidados básicos: autenticação de sessão LDP/RSVP-TE (evita que um roteador não autorizado injete rótulo falso e desvie tráfego), filtragem de Route Target no PE (evita importação acidental de rota entre VRFs que não deveriam se comunicar), e proteção do plano de controle (CoPP — Control Plane Policing, limitando taxa de pacotes de controle MPLS/LDP/RSVP que chegam ao processador do roteador, mitigando ataque de exaustão de CPU).
8. Configuração de referência — multi-fabricante Intermediário
Cenário: habilitar MPLS+LDP numa interface de core, entre dois roteadores P.
Cisco IOS-XE
mpls label protocol ldp
mpls ldp router-id Loopback0 force
!
interface GigabitEthernet0/1
mpls ip
mpls label protocol ldpJuniper JunOS
set protocols mpls interface ge-0/0/1.0
set protocols ldp interface ge-0/0/1.0
set interfaces ge-0/0/1 unit 0 family mplsMikrotik RouterOS
/mpls ldp
set enabled=yes lsr-id=203.0.113.1 transport-address=203.0.113.1
/mpls ldp interface
add interface=ether1 disabled=noSuporte MPLS/LDP no RouterOS é mais limitado que nos demais fabricantes desta comparação — verificar recursos suportados (L3VPN completo, RSVP-TE) na versão/plataforma específica antes de projetar backbone crítico sobre ele.
FRRouting (Linux)
mpls ldp
router-id 203.0.113.1
!
address-family ipv4
interface eth1
exit-address-family
!
interface eth1
mpls enable9. Comandos de verificação e teste Intermediário
| O que checar | Cisco / FRR | JunOS |
|---|---|---|
| Vizinhos LDP | show mpls ldp neighbor | show ldp neighbor |
| Tabela de rótulos (LFIB) | show mpls forwarding-table | show route table mpls.0 |
| Traceroute com rótulos visíveis | traceroute mpls ipv4 ... | traceroute mpls ldp ... |
| VRFs configuradas (L3VPN) | show ip vrf | show route instance |
| Túneis RSVP-TE | show mpls traffic-eng tunnels | show mpls lsp |
Checklist mínimo de "MPLS pronto pra serviço":
- Sessão LDP estabelecida com todos os vizinhos de core esperados
- Rótulo presente na LFIB pro loopback de todo PE remoto relevante
traceroute mplsfim-a-fim confirmando o LSP inteiro, não só ping IP- Se L3VPN: rota do cliente presente na VRF correta no PE remoto, com RT esperado
- Se MPLS-TE: túnel em estado "up", com banda reservada dentro do previsto
10. Indicadores de operação (KPIs) Avançado
| Indicador | O que revela | Sinal de alerta |
|---|---|---|
| Sessões LDP up vs. esperadas | Saúde do plano de sinalização | Qualquer sessão fora do estado Operational |
| Utilização de banda por link de core | Necessidade real de TE | Links próximos da saturação enquanto outros ficam ociosos |
| Estado dos túneis RSVP-TE | Estabilidade da engenharia de tráfego | Túnel caindo/resinalizando com frequência |
| Tempo de failover do Fast Reroute | Eficácia da proteção configurada | Tempo muito acima da casa de dezenas de milissegundos esperada |
| Nº de VRFs / rotas por VRF no PE | Capacidade de hardware sendo consumida | Aproximando do limite de TCAM/memória da plataforma |
11. Exercícios práticos Intermediário
Resolva antes de olhar o gabarito.
Exercício 1. Dois clientes L3VPN diferentes usam o mesmo range de IP privado (10.0.0.0/24) no mesmo backbone MPLS do seu ISP. Isso vai causar conflito? Por quê?
Ver gabarito
Não causa conflito. Cada VRF é uma instância de roteamento completamente isolada — o Route Distinguisher (RD) de cada cliente, prefixado ao endereço IPv4 dele, cria um endereço VPNv4 globalmente único dentro do MP-BGP do backbone, mesmo que os dois usem exatamente o mesmo range 10.0.0.0/24. É justamente esse mecanismo que permite reaproveitar espaço de endereçamento privado entre clientes diferentes sem conflito.
Exercício 2. Você quer distribuir rótulo pra viabilizar L3VPN, seguindo simplesmente o caminho que o IGP já calcula — sem necessidade de engenharia de tráfego. Qual protocolo de sinalização de rótulo faz mais sentido, LDP ou RSVP-TE, e por quê?
Ver gabarito
LDP. Ele distribui rótulos automaticamente seguindo o caminho que o IGP já calculou, sem exigir configuração de caminho explícito nem reserva de banda — muito mais simples operacionalmente. RSVP-TE só se justifica quando você precisa de caminho explícito diferente do IGP e/ou reserva de banda garantida (MPLS-TE de verdade).
Exercício 3. Um cliente corporativo tem 3 sites e quer que todos se enxerguem como se estivessem no mesmo switch Ethernet, incluindo broadcast/multicast entre eles. Qual serviço MPLS atende isso: L3VPN, VPWS ou VPLS?
Ver gabarito
VPLS (ou seu sucessor, EVPN). L3VPN roteia IP, não emula switch Ethernet. VPWS é ponto a ponto (só 2 sites), não multiponto. VPLS é especificamente desenhado pra emular um switch Ethernet multiponto entre 3+ sites, incluindo aprendizado de MAC e propagação de broadcast/multicast como um domínio de camada 2 único.
Exercício 4. Um engenheiro sumariza o bloco de loopbacks dos roteadores de core, achando que vai "limpar" a tabela de rotas do backbone. Que problema isso provavelmente vai causar nos serviços MPLS que já estão em produção?
Ver gabarito
Vai quebrar os LSPs fim-a-fim que dependiam de rota específica pra cada loopback individual — os serviços L2VPN/L3VPN que passam por esses LSPs perdem conectividade, porque o rótulo de transporte não consegue mais ser resolvido corretamente até o loopback exato do PE remoto. É por isso que a boa prática (seção 6) recomenda nunca sumarizar especificamente esse bloco.
12. Troubleshooting comum Intermediário
Checar: MPLS habilitado na interface física correta dos dois lados, IGP já convergido entre os dois roteadores (LDP depende do IGP funcionando primeiro), Router ID/Transport Address configurados de forma consistente.
Causa mais comum: sumarização de rota IGP em algum ponto do backbone escondendo o loopback específico de um roteador do meio do caminho (ver Exercício 4). Use traceroute mpls pra identificar exatamente em qual salto o rótulo some.
Checar Route Target — import/export mal configurado numa das VRFs é a causa mais comum. Confirme que o RT exportado por um lado bate exatamente com o RT importado pelo outro.
Causa comum: banda solicitada pelo túnel maior do que o disponível/anunciado em algum link do caminho calculado — o CSPF (Constrained SPF) não encontra caminho viável dentro da restrição de banda pedida.
Como o core só vê o rótulo (não o IP interno), confirme se há informação de entropia suficiente (hash baseado em label + campos adicionais) configurada — sem isso, o balanceamento pode concentrar fluxos de forma desigual mesmo com múltiplos caminhos de igual custo disponíveis.
13. Glossário
Perguntas da Comunidade sobre MPLS
LSP quebrado, Route Target não bate, dúvida sobre VPLS vs. EVPN? Pergunte pra quem já passou por isso.
Fazer pergunta sobre MPLS14. Referências
Padrões internacionais (IETF)
- RFC 3031 — Multiprotocol Label Switching Architecture
- RFC 3032 — MPLS Label Stack Encoding
- RFC 5036 — LDP Specification
- RFC 3209 — RSVP-TE: Extensions to RSVP for LSP Tunnels
- RFC 4364 — BGP/MPLS IP Virtual Private Networks (L3VPN)
- RFC 4448 — Encapsulation Methods for Transport of Ethernet over MPLS (pseudowire)
- RFC 4761 / RFC 4762 — Virtual Private LAN Service (VPLS)
- RFC 8402 — Segment Routing Architecture
Contexto nacional (Brasil)
- Redes MPLS para Provedores, Engenharia de Tráfego com MPLS TE, Introdução ao Unified MPLS, Transição de Soluções L2VPN MPLS Tradicionais para o EVPN, Balanceamento de Tráfego em Redes MPLS
Conteúdo técnico independente, contextualizado para o cenário brasileiro.