Wiki BPF - Contribuições do(a) usuário(a) [pt-br]

O NAT do Futuro: a Internet está deixando o IPv4 para trás. Seu provedor está preparado?

2026-07-09T19:47:36Z

DanielTecnet: Criou página com '= O NAT do Futuro: Como NAT64, DNS64, CLAT e 464XLAT estão levando a Internet para um mundo IPv6 = ''Autor: Daniel Mendes'' Arquivo:663936b3-fefc-4800-9094-0d38a83acf08.p...'

= O NAT do Futuro: Como NAT64, DNS64, CLAT e 464XLAT estão levando a Internet para um mundo IPv6 =

''Autor: Daniel Mendes''

[[Arquivo:663936b3-fefc-4800-9094-0d38a83acf08.png|centro|1200px|O NAT do Futuro - IPv6-only com acesso ao legado IPv4]]

== Introdução ==

Durante muitos anos o NAT44 (CGNAT) foi o principal aliado das operadoras para enfrentar a escassez de endereços IPv4. Entretanto, o crescimento do IPv6 mudou completamente o cenário.

Hoje a pergunta deixou de ser ''"como economizar IPv4?"'' e passou a ser:

'''Como oferecer uma rede IPv6-only sem perder acesso aos bilhões de serviços que ainda existem apenas em IPv4?'''

É justamente aí que entram tecnologias como '''NAT64''', '''DNS64''', '''CLAT''' e '''464XLAT'''. Embora muitas vezes sejam tratadas como se fossem a mesma solução, cada uma possui um papel específico dentro da arquitetura de transição para IPv6.

Neste artigo vamos entender como cada tecnologia funciona e por que elas são consideradas por muitos como o verdadeiro "NAT do futuro".

== O problema ==

Imagine um cliente conectado apenas por IPv6.

Esse cliente tenta acessar um serviço que existe somente em IPv4.

Sem algum mecanismo de tradução, essa comunicação simplesmente não acontece.

Diferentemente do CGNAT, que traduz IPv4 para IPv4, agora precisamos traduzir protocolos diferentes.

Ou seja:

IPv6 → IPv4

Essa é a missão do NAT64.

== NAT64 ==

O NAT64 é responsável por traduzir o tráfego IPv6 para IPv4.

Todo o cliente permanece utilizando IPv6 normalmente, enquanto a tradução acontece dentro da rede da operadora.

Fluxo simplificado:

Cliente IPv6
│
▼
NAT64
│
▼
Servidor IPv4

O NAT64 mantém estado das conexões, portas e sessões de maneira semelhante ao NAT tradicional.

'''Onde normalmente roda'''

* BNG
* BRAS
* Appliances dedicados
* Firewalls
* Plataformas CGNAT

'''O que resolve'''

Permite que clientes IPv6-only acessem serviços disponíveis apenas em IPv4.

== DNS64 ==

Mas existe outro desafio.

Imagine que um domínio possua apenas um registro DNS do tipo A.

Exemplo:

www.exemplo.com
A = 198.51.100.25

O cliente IPv6 procura um registro AAAA.

Como ele não existe, a comunicação falharia.

É aí que entra o DNS64.

O DNS64 sintetiza um endereço IPv6 utilizando normalmente o prefixo:

64:ff9b::/96

Assim o cliente recebe um endereço IPv6 válido, que posteriormente será tratado pelo NAT64.

'''Onde roda'''

* Servidores DNS da operadora
* Resolver DNS

'''O que resolve'''

Permite que clientes IPv6 encontrem serviços IPv4 através de um endereço IPv6 sintetizado.

== CLAT ==

Nem toda aplicação utiliza DNS corretamente.

Muitas aplicações antigas continuam gerando tráfego IPv4 diretamente através da pilha de rede do sistema operacional.

Se o dispositivo estiver conectado em uma rede IPv6-only, essas aplicações deixam de funcionar.

O CLAT resolve exatamente esse problema.

Ele roda dentro do próprio dispositivo do usuário e converte IPv4 em IPv6 antes mesmo que o pacote saia para a rede.

Fluxo:

Aplicação IPv4
│
▼
CLAT
│
▼
IPv6

Para a aplicação nada muda.

Ela continua acreditando que existe uma pilha IPv4 disponível.

'''Onde roda'''

* Android
* iOS (algumas implementações)
* Windows
* Equipamentos CPE

'''O que resolve'''

Mantém compatibilidade de aplicações IPv4 em redes IPv6-only.

== 464XLAT ==

O 464XLAT não é uma tecnologia isolada.

Na verdade ele representa uma arquitetura.

Ela combina duas traduções:

* CLAT no cliente
* NAT64 na operadora

Fluxo completo:

Aplicação IPv4
│
CLAT
│
IPv6
│
NAT64
│
IPv4
│
Servidor IPv4

Essa arquitetura é utilizada atualmente por diversas operadoras móveis ao redor do mundo.

Ela permite que toda a rede opere em IPv6, mantendo compatibilidade praticamente transparente com conteúdos legados em IPv4.

== Comparativo ==

{| class="wikitable"
! Tecnologia
! Onde roda
! O que faz
! Resolve qual problema
|-
| NAT64
| Rede da operadora
| Traduz IPv6 para IPv4
| Acesso a serviços IPv4
|-
| DNS64
| Servidor DNS
| Sintetiza registros AAAA
| Descoberta de hosts IPv4
|-
| CLAT
| Dispositivo do usuário
| Traduz IPv4 da aplicação para IPv6
| Compatibilidade de aplicações legadas
|-
| 464XLAT
| Cliente + Operadora
| Combina CLAT e NAT64
| Rede IPv6-only totalmente funcional
|}

== Conclusão ==

Durante muito tempo associamos NAT apenas ao IPv4.

Entretanto, o futuro aponta para outro caminho.

À medida que as operadoras evoluem suas redes para IPv6-only, tecnologias como NAT64, DNS64, CLAT e 464XLAT deixam de ser apenas mecanismos de transição e passam a ser componentes fundamentais da infraestrutura moderna.

O NAT do futuro não traduz apenas endereços.

Ele conecta dois mundos diferentes, permitindo que a Internet continue funcionando enquanto a migração para IPv6 acontece de forma gradual.

== Referências ==

* RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators
* RFC 6146 - Stateful NAT64
* RFC 6147 - DNS64
* RFC 6877 - 464XLAT
Daniel Melo
Network Eng.

Arquivo:663936b3-fefc-4800-9094-0d38a83acf08.png

2026-07-09T19:45:20Z

DanielTecnet:

Backbone Seamless MPLS Options A, B, C e BGP-LU

2026-06-30T16:29:13Z

DanielTecnet:

= Integração de Backbones MPLS: Option A, Option B, Option C e Seamless MPLS =

[[Arquivo:Topolo 123456.jpg|1200px|center]]
''Figura 1 – Comparação entre as arquiteturas Inter-AS MPLS VPN: Option A, Option B e Option C.''

[[Arquivo:Topolo 1234567.jpg|1200px|center]]
''Figura 2 – Exemplo conceitual de integração entre dois domínios MPLS independentes utilizando Seamless MPLS e BGP-LU para transporte de serviços MPLS.''

== Introdução ==

Quem trabalha em operadoras ou provedores de Internet sabe que, mais cedo ou mais tarde, surge um desafio comum: integrar redes que nasceram separadas.

Isso acontece em processos de aquisição de ISPs, expansão regional, consolidação de operações ou simplesmente quando duas infraestruturas precisam passar a transportar serviços entre si.

A primeira ideia normalmente é bastante simples: unir todos os equipamentos em um único domínio OSPF ou IS-IS. Dependendo do tamanho da rede, essa abordagem pode funcionar muito bem.

Porém, à medida que o backbone cresce, também crescem alguns desafios importantes:

* aumento da LSDB do IGP;
* maior tempo de convergência;
* troubleshooting mais complexo;
* maior domínio de falhas;
* janelas de manutenção mais críticas;
* menor flexibilidade para futuras expansões.

Foi justamente para atender esses cenários que surgiram diferentes arquiteturas de integração entre domínios MPLS.

== O desafio da integração de redes ==

Durante processos de fusão, aquisição ou expansão geográfica, normalmente cada backbone já possui sua própria arquitetura, protocolos de roteamento, planejamento de endereçamento e serviços MPLS em produção.

Na maioria das vezes não é interessante desmontar toda essa infraestrutura para reconstruí-la em um único domínio.

A abordagem mais utilizada é permitir que cada backbone continue operando de forma independente enquanto os serviços passam a trafegar entre os domínios de forma transparente.

Dependendo da necessidade de escalabilidade, diferentes arquiteturas podem ser utilizadas.

== Option A ==

A Option A é considerada a arquitetura mais simples de implementar.

Nesse modelo, os roteadores ASBR funcionam praticamente como equipamentos de borda (CE) um para o outro. Cada VPN termina no ASBR e é entregue ao domínio vizinho.

=== Vantagens ===

* Simplicidade de configuração.
* Fácil operação e troubleshooting.
* Baixo requisito de funcionalidades dos equipamentos.
* Excelente para ambientes pequenos.

=== Desvantagens ===

* Escalabilidade limitada.
* Cada VPN precisa existir nos ASBRs.
* Cresce mal quando o número de clientes aumenta.

=== Cenários indicados ===

* Pequenos provedores.
* Integrações temporárias.
* Poucas VPNs entre domínios.

== Option B ==

Na Option B os ASBRs passam a trocar rotas VPNv4/VPNv6 utilizando MP-BGP.

Os PEs permanecem isolados e os ASBRs tornam-se responsáveis pela troca das informações das VPNs.

=== Vantagens ===

* Muito mais escalável que a Option A.
* Redução da quantidade de configurações por VPN.
* Boa separação entre os domínios.

=== Desvantagens ===

* Os ASBRs continuam armazenando informações das VPNs.
* Maior consumo de memória e processamento.
* Troubleshooting mais elaborado.

=== Cenários indicados ===

* Operadoras médias.
* Backbones com quantidade moderada de serviços MPLS.
* Ambientes onde os ASBRs possuem capacidade suficiente para manter todas as VPNs.

== Option C ==

A Option C representa o modelo de maior escalabilidade.

Nesse cenário, quem efetivamente troca informações são os próprios PEs. Os ASBRs deixam de conhecer as VPNs e passam a atuar apenas como elementos de transporte.

Para isso normalmente utiliza-se '''BGP Labeled Unicast (BGP-LU)''', permitindo que labels MPLS sejam distribuídos através do BGP.

=== Vantagens ===

* Excelente escalabilidade.
* Menor carga sobre os ASBRs.
* Separação clara entre transporte e serviços.
* Melhor aproveitamento da infraestrutura.
* Ideal para ambientes Carrier Grade.

=== Desvantagens ===

* Projeto mais complexo.
* Necessidade de equipamentos com suporte completo às funcionalidades de BGP-LU.
* Troubleshooting mais avançado.

=== Cenários indicados ===

* Grandes operadoras.
* Backbones nacionais.
* Processos de fusão e aquisição.
* Ambientes com milhares de VPNs.

== Seamless MPLS ==

O conceito de Seamless MPLS surgiu para permitir que diversos domínios MPLS funcionem de forma integrada sem que seja necessário transformar toda a rede em um único domínio IGP.

Cada região pode continuar utilizando seu próprio OSPF ou IS-IS, enquanto os serviços MPLS são transportados entre os domínios de maneira transparente.

Essa arquitetura reduz impactos operacionais, facilita expansões e torna processos de aquisição muito mais simples.

== O papel do BGP-LU ==

O BGP-Labeled Unicast (BGP-LU) adiciona ao BGP a capacidade de anunciar prefixos juntamente com seus respectivos labels MPLS.

Dessa forma, além da informação de roteamento, os equipamentos passam a conhecer também o label necessário para encaminhar o tráfego através dos diferentes domínios MPLS.

Essa separação entre plano de transporte e plano de roteamento é um dos principais pilares do Seamless MPLS.

Vale destacar que a disponibilidade dessa funcionalidade depende do fabricante, da plataforma e da versão de software utilizada. Embora o conceito seja padronizado por RFCs, a implementação pode variar entre diferentes vendors.

== Boas práticas ==

Durante o planejamento de uma integração entre backbones MPLS, algumas recomendações costumam trazer melhores resultados:

* manter cada domínio IGP independente sempre que possível;
* utilizar blocos dedicados para loopbacks dos PEs;
* anunciar apenas os prefixos necessários para o transporte;
* evitar redistribuições indiscriminadas entre BGP e IGP;
* utilizar políticas claras de importação e exportação de rotas;
* validar previamente o suporte do fabricante às funcionalidades necessárias;
* documentar toda a arquitetura antes da implantação.

== Como escolher a arquitetura ideal ==

Não existe uma única arquitetura correta para todos os cenários.

Cada modelo possui vantagens e limitações próprias.

De forma geral:

* '''Option A''' prioriza simplicidade.
* '''Option B''' oferece um equilíbrio entre simplicidade e escalabilidade.
* '''Option C''' entrega o maior nível de escalabilidade e normalmente é utilizada em grandes operadoras.
* '''Seamless MPLS''' permite integrar múltiplos domínios mantendo cada backbone relativamente independente durante todo o processo de expansão.

A escolha deve considerar fatores como quantidade de serviços, expectativa de crescimento, capacidade dos equipamentos, equipe operacional e estratégia de evolução da rede.

== Considerações finais ==

A integração entre backbones MPLS deixou de ser um cenário exclusivo de grandes operadoras. Atualmente, processos de expansão, aquisição e consolidação fazem parte da realidade de muitos provedores de Internet.

Conhecer as diferenças entre Option A, Option B, Option C e Seamless MPLS permite escolher a arquitetura mais adequada para cada projeto, reduzindo riscos operacionais e preparando a infraestrutura para futuras expansões.

Independentemente do fabricante utilizado, compreender esses conceitos é um passo importante para construir redes mais escaláveis, resilientes e preparadas para o crescimento.

== Referências ==

* RFC 4364 — BGP/MPLS IP Virtual Private Networks (VPNs)
* RFC 3107 — Carrying Label Information in BGP-4
* RFC 8277 — Using BGP to Bind MPLS Labels to Address Prefixes
* RFC 4577 — OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP VPNs
* Documentações oficiais Cisco, Huawei, Juniper e Nokia sobre MPLS, Inter-AS VPN e BGP-LU.
----

'''Autor'''

'''Daniel Melo'''

Especialista em Redes • Consolidação de Redes • Operações • Backbone • Core IP • RAN 5G • Arquitetura Multivendor • Tecnólogo em Redes

''Compartilhando conhecimento e experiências em infraestrutura de redes para fortalecer a comunidade técnica brasileira.''

Backbone Seamless MPLS Options A, B, C e BGP-LU

2026-06-30T16:26:07Z

DanielTecnet: Criou página com '= Integração de Backbones MPLS: Option A, Option B, Option C e Seamless MPLS = center ''Figura 1 – Comparação entre as arquiteturas...'

Arquivo:Topolo 1234567.jpg

2026-06-30T16:20:58Z

DanielTecnet:

Arquivo:Topolo 123456.jpg

2026-06-30T16:20:35Z

DanielTecnet:

IPv6-Mostly: Será este o verdadeiro próximo passo da Internet?

2026-06-25T16:40:40Z

DanielTecnet:

= IPv6-Mostly: Será este o verdadeiro próximo passo da Internet? =

Durante muitos anos, a comunidade técnica discutiu o '''IPv6-Only''' como o destino natural da Internet. Afinal, o esgotamento dos endereços IPv4 e a crescente adoção do IPv6 apontavam para um cenário onde o IPv4 deixaria de existir.

Mas será que essa transição acontecerá de forma tão direta?

Observando a evolução dos sistemas operacionais, das operadoras, dos grandes provedores de conteúdo e da própria arquitetura das redes, comecei a refletir sobre uma possibilidade que, na minha opinião, parece cada vez mais provável:

'''Antes de uma Internet totalmente IPv6-Only, poderemos viver uma longa fase de IPv6-Mostly.'''

== O modelo atual ==

Hoje, praticamente todos os ISPs operam em '''Dual Stack''', entregando simultaneamente IPv4 e IPv6 aos seus clientes.

Essa arquitetura foi fundamental para permitir a evolução da Internet sem comprometer a compatibilidade dos serviços existentes.

Entretanto, ela também aumenta significativamente a complexidade operacional.

Na prática administramos:

* Duas pilhas completas de protocolos;
* Duas tabelas de roteamento;
* Duas políticas de segurança;
* Dois ambientes de troubleshooting;
* Dois planos de monitoramento;
* Dois protocolos convivendo permanentemente.

À medida que o IPv6 cresce e passa a representar uma parcela cada vez maior do tráfego da Internet, surge uma pergunta interessante:

'''Será que ainda faz sentido manter o Dual Stack para sempre?'''

== O conceito de IPv6-Mostly ==

O conceito de '''IPv6-Mostly''' propõe uma mudança importante na arquitetura das redes.

Em vez de fornecer IPv4 e IPv6 durante toda a vida útil da infraestrutura, o IPv6 passa a ser o protocolo principal.

O IPv4 continua existindo, porém apenas como mecanismo de interoperabilidade para aplicações e serviços legados.

[[Arquivo:Figura 1 .png|thumb|center|850px|'''Figura 1''' – Exemplo simplificado de uma arquitetura IPv6-Mostly.]]

== Talvez a maior mudança esteja no NAT ==

Na minha opinião, esse é um dos pontos mais interessantes dessa evolução.

Durante décadas utilizamos o NAT para resolver um problema muito específico:

'''Traduzir endereços IPv4 privados para IPv4 públicos.'''

Exemplos conhecidos:

* NAT44
* PAT
* CGNAT

Sempre trabalhando da seguinte forma:

'''IPv4 Privado → IPv4 Público'''

Em uma arquitetura IPv6-Mostly esse conceito muda completamente.

O NAT deixa de ser apenas um mecanismo para economizar endereços IPv4 públicos e passa a atuar como uma camada de interoperabilidade entre protocolos.

Agora ele passa a permitir cenários como:

* Cliente IPv6 acessando servidores disponíveis apenas em IPv4;
* Aplicações IPv4 funcionando sobre redes predominantemente IPv6;
* Tradução transparente entre IPv6 e IPv4.

Ou seja, o NAT deixa de traduzir apenas endereços IPv4 e passa a traduzir protocolos.

Essa mudança é possível graças a um conjunto de tecnologias que já estão presentes em diversos ambientes de produção.

== As tecnologias que tornam isso possível ==

* '''NAT64''' – Permite que clientes IPv6 acessem serviços disponíveis apenas em IPv4.
* '''DNS64''' – Sintetiza registros AAAA quando um domínio possui apenas registros A.
* '''CLAT''' – Executa a tradução no dispositivo do usuário, permitindo que aplicações IPv4 continuem funcionando normalmente.
* '''464XLAT''' – Combina CLAT no cliente com NAT64 na operadora, sendo atualmente uma das arquiteturas mais utilizadas por operadoras móveis.
* '''SIIT-DC''' – Utilizado em cenários específicos de Data Centers para tradução entre IPv6 e IPv4.

[[Arquivo:Figurrr 2.png|thumb|center|850px|'''Figura 2''' – Comparação entre NAT44/CGNAT e as tecnologias de tradução utilizadas em ambientes IPv6-Mostly.]]

== E os grandes provedores de conteúdo? ==

Hoje, Google, Meta, Netflix, Cloudflare, Amazon e diversos outros provedores continuam oferecendo seus serviços em Dual Stack.

Até o momento, não existem anúncios públicos indicando uma migração ampla para operação exclusivamente em IPv6 em seus CDNs ou plataformas de entrega de conteúdo.

Entretanto, observa-se um crescimento contínuo da utilização do IPv6 e uma forte evolução do ecossistema em direção a arquiteturas onde o IPv6 passa a ser o protocolo preferencial.

Isso levanta uma discussão interessante:

'''Será que veremos primeiro os CDNs operando em IPv6-Only ou veremos os ISPs adotando arquiteturas IPv6-Mostly como etapa intermediária?'''

== Minha visão ==

Na minha opinião, antes de uma Internet totalmente IPv6-Only, veremos alguns movimentos importantes:

* Backbones operando predominantemente em IPv6;
* Clientes utilizando IPv6 como protocolo principal;
* Maior adoção de NAT64, DNS64 e 464XLAT pelos ISPs;
* Expansão do suporte ao CLAT nos sistemas operacionais;
* IPv4 permanecendo apenas como camada de interoperabilidade.

Isso não representa o fim do IPv4.

Representa apenas uma mudança de papel dentro da arquitetura da Internet.

== Conclusão ==

Durante muitos anos, o desafio foi implantar IPv6.

Talvez o próximo grande desafio seja ainda mais interessante:

'''Operar redes onde o IPv6 seja o protocolo principal e o IPv4 exista apenas para garantir compatibilidade com aplicações legadas.'''

Não se trata de prever o fim do IPv4, mas de discutir como as arquiteturas poderão evoluir nos próximos anos.

Gostaria de ouvir a opinião da comunidade.

'''Vocês acreditam que caminharemos diretamente para uma Internet IPv6-Only ou enxergam o IPv6-Mostly como a etapa natural dessa evolução?'''
----
'''Daniel Melo'''

Engenheiro de Redes – G3 Telecom

Especialista em Backbone IP, BGP, MPLS, IPv6 e Peering.

''Este artigo tem como objetivo fomentar a discussão técnica sobre a evolução das arquiteturas IPv6 para ISPs brasileiros.''

IPv6-Mostly: Será este o verdadeiro próximo passo da Internet?

2026-06-25T16:38:22Z

DanielTecnet: Criou página com '= IPv6-Mostly: Será este o verdadeiro próximo passo da Internet? = Durante muitos anos, a comunidade técnica discutiu o '''IPv6-Only''' como o destino natural da Internet....'

= IPv6-Mostly: Será este o verdadeiro próximo passo da Internet? =

Durante muitos anos, a comunidade técnica discutiu o '''IPv6-Only''' como o destino natural da Internet. Afinal, o esgotamento dos endereços IPv4 e a crescente adoção do IPv6 apontavam para um cenário onde o IPv4 deixaria de existir.

Mas será que essa transição acontecerá de forma tão direta?

Observando a evolução dos sistemas operacionais, das operadoras, dos grandes provedores de conteúdo e da própria arquitetura das redes, comecei a refletir sobre uma possibilidade que, na minha opinião, parece cada vez mais provável:

'''Antes de uma Internet totalmente IPv6-Only, poderemos viver uma longa fase de IPv6-Mostly.'''

== O modelo atual ==

Hoje, praticamente todos os ISPs operam em '''Dual Stack''', entregando simultaneamente IPv4 e IPv6 aos seus clientes.

Essa arquitetura foi fundamental para permitir a evolução da Internet sem comprometer a compatibilidade dos serviços existentes.

Entretanto, ela também aumenta significativamente a complexidade operacional.

Na prática administramos:

* Duas pilhas completas de protocolos;
* Duas tabelas de roteamento;
* Duas políticas de segurança;
* Dois ambientes de troubleshooting;
* Dois planos de monitoramento;
* Dois protocolos convivendo permanentemente.

À medida que o IPv6 cresce e passa a representar uma parcela cada vez maior do tráfego da Internet, surge uma pergunta interessante:

'''Será que ainda faz sentido manter o Dual Stack para sempre?'''

== O conceito de IPv6-Mostly ==

O conceito de '''IPv6-Mostly''' propõe uma mudança importante na arquitetura das redes.

Em vez de fornecer IPv4 e IPv6 durante toda a vida útil da infraestrutura, o IPv6 passa a ser o protocolo principal.

O IPv4 continua existindo, porém apenas como mecanismo de interoperabilidade para aplicações e serviços legados.

[[Arquivo:Figura 1 .png|thumb|center|850px|'''Figura 1''' – Exemplo simplificado de uma arquitetura IPv6-Mostly.]]

== Talvez a maior mudança esteja no NAT ==

Na minha opinião, esse é um dos pontos mais interessantes dessa evolução.

Durante décadas utilizamos o NAT para resolver um problema muito específico:

'''Traduzir endereços IPv4 privados para IPv4 públicos.'''

Exemplos conhecidos:

* NAT44
* PAT
* CGNAT

Sempre trabalhando da seguinte forma:

'''IPv4 Privado → IPv4 Público'''

Em uma arquitetura IPv6-Mostly esse conceito muda completamente.

O NAT deixa de ser apenas um mecanismo para economizar endereços IPv4 públicos e passa a atuar como uma camada de interoperabilidade entre protocolos.

Agora ele passa a permitir cenários como:

* Cliente IPv6 acessando servidores disponíveis apenas em IPv4;
* Aplicações IPv4 funcionando sobre redes predominantemente IPv6;
* Tradução transparente entre IPv6 e IPv4.

Ou seja, o NAT deixa de traduzir apenas endereços IPv4 e passa a traduzir protocolos.

Essa mudança é possível graças a um conjunto de tecnologias que já estão presentes em diversos ambientes de produção.

== As tecnologias que tornam isso possível ==

* '''NAT64''' – Permite que clientes IPv6 acessem serviços disponíveis apenas em IPv4.
* '''DNS64''' – Sintetiza registros AAAA quando um domínio possui apenas registros A.
* '''CLAT''' – Executa a tradução no dispositivo do usuário, permitindo que aplicações IPv4 continuem funcionando normalmente.
* '''464XLAT''' – Combina CLAT no cliente com NAT64 na operadora, sendo atualmente uma das arquiteturas mais utilizadas por operadoras móveis.
* '''SIIT-DC''' – Utilizado em cenários específicos de Data Centers para tradução entre IPv6 e IPv4.

[[Arquivo:Figurrr 2.png|thumb|center|850px|'''Figura 2''' – Comparação entre NAT44/CGNAT e as tecnologias de tradução utilizadas em ambientes IPv6-Mostly.]]

== E os grandes provedores de conteúdo? ==

Hoje, Google, Meta, Netflix, Cloudflare, Amazon e diversos outros provedores continuam oferecendo seus serviços em Dual Stack.

Até o momento, não existem anúncios públicos indicando uma migração ampla para operação exclusivamente em IPv6 em seus CDNs ou plataformas de entrega de conteúdo.

Entretanto, observa-se um crescimento contínuo da utilização do IPv6 e uma forte evolução do ecossistema em direção a arquiteturas onde o IPv6 passa a ser o protocolo preferencial.

Isso levanta uma discussão interessante:

'''Será que veremos primeiro os CDNs operando em IPv6-Only ou veremos os ISPs adotando arquiteturas IPv6-Mostly como etapa intermediária?'''

== Minha visão ==

Na minha opinião, antes de uma Internet totalmente IPv6-Only, veremos alguns movimentos importantes:

* Backbones operando predominantemente em IPv6;
* Clientes utilizando IPv6 como protocolo principal;
* Maior adoção de NAT64, DNS64 e 464XLAT pelos ISPs;
* Expansão do suporte ao CLAT nos sistemas operacionais;
* IPv4 permanecendo apenas como camada de interoperabilidade.

Isso não representa o fim do IPv4.

Representa apenas uma mudança de papel dentro da arquitetura da Internet.

== Conclusão ==

Durante muitos anos, o desafio foi implantar IPv6.

Talvez o próximo grande desafio seja ainda mais interessante:

'''Operar redes onde o IPv6 seja o protocolo principal e o IPv4 exista apenas para garantir compatibilidade com aplicações legadas.'''

Não se trata de prever o fim do IPv4, mas de discutir como as arquiteturas poderão evoluir nos próximos anos.

Gostaria de ouvir a opinião da comunidade.

'''Vocês acreditam que caminharemos diretamente para uma Internet IPv6-Only ou enxergam o IPv6-Mostly como a etapa natural dessa evolução?'''
----
'''Daniel Mendes'''

Engenheiro de Redes – G3 Telecom

Especialista em Backbone IP, BGP, MPLS, IPv6 e Peering.

''Este artigo tem como objetivo fomentar a discussão técnica sobre a evolução das arquiteturas IPv6 para ISPs brasileiros.''

Arquivo:Figurrr 2.png

2026-06-25T16:18:33Z

DanielTecnet:

Arquivo:Figura 1 .png

2026-06-25T16:16:27Z

DanielTecnet:

Geofeed no Registro.br: uma boa prática que todo ISP deveria implementar

2026-06-19T15:35:03Z

DanielTecnet: Criação de Geofeed no Registro.br e sua Importancia

= Geofeed no Registro.br: uma boa prática que todo ISP deveria implementar =

''Como melhorar a precisão da geolocalização dos seus endereços IPv4 e IPv6 utilizando Geofeed e os recursos disponíveis no Registro.br.''

== Introdução ==

Imagine a seguinte situação:

O cliente mora em Teresina.

O aplicativo do banco entende que ele está em Fortaleza.

O serviço de streaming entrega conteúdo da região errada.

Uma plataforma antifraude interpreta o acesso como suspeito.

O suporte recebe a reclamação.

Na maioria das vezes não existe qualquer problema na rede " camada 1 to 3 ".

O BGP está correto.

O DNS está funcionando.

A latência está adequada.

O problema está na forma como a Internet entende a localização dos endereços IP utilizados pelo assinante.

É justamente nesse cenário que o Geofeed se torna uma ferramenta extremamente importante.

== O que é Geofeed? ==

Geofeed é um padrão definido pela IETF através das RFC 8805 e RFC 9632 que permite ao detentor dos recursos IP publicar oficialmente a localização geográfica de seus prefixos.

Na prática, trata-se de um arquivo CSV hospedado em HTTPS contendo informações sobre onde cada bloco IPv4 ou IPv6 está sendo utilizado.

Esse arquivo pode ser consumido por diversos provedores de dados e plataformas da Internet, tais como:

* MaxMind
* IPInfo
* Cloudflare
* Google
* Plataformas antifraude
* Bancos
* Aplicativos de geolocalização
* Sistemas de segurança

O objetivo é reduzir inconsistências e melhorar a precisão das informações de localização utilizadas pelos serviços da Internet.

== Como funciona? ==

[[Arquivo:Geofeed_fluxo_registrobr.png|center|1000px|Fluxo simplificado do funcionamento do Geofeed]]

O processo é relativamente simples:

# O ISP cria um arquivo Geofeed.

# O arquivo é publicado em HTTPS.

# A URL é associada ao bloco IP no Registro.br.

# Bases de geolocalização consomem essas informações.

# Aplicações passam a identificar corretamente a localização dos usuários.

== Por que isso é importante para os provedores? ==

Muitos ISPs investem continuamente em:

* Backbone próprio
* MPLS
* IX.br
* PNI
* CDNs
* RPKI
* Segurança de roteamento

Porém, acabam negligenciando uma informação extremamente importante: a localização dos recursos IP perante a Internet.

A ausência de um Geofeed bem configurado pode gerar:

* Erros em sistemas antifraude
* Bloqueios indevidos em bancos
* Conteúdo regional incorreto
* Publicidade geográfica errada
* Aumento de chamados no suporte
* Dificuldades em processos de troubleshooting

Em muitos casos, o assinante percebe o problema como uma falha da rede, quando na realidade trata-se apenas de uma geolocalização incorreta.

== Exemplo de arquivo Geofeed ==

Para fins de documentação e treinamento, devem ser utilizados blocos reservados para documentação conforme RFC 5737 e RFC 3849.

Exemplo:

<pre>
# prefix,country,subdivision,city

192.0.2.0/24,BR,BR-PI,Teresina
198.51.100.0/24,BR,BR-CE,Fortaleza
203.0.113.0/24,BR,BR-MA,Sao Luis
2001:db8:100::/48,BR,BR-PI,Teresina
</pre>

Após criado, o arquivo pode ser publicado em:

<pre>
https://geo.seuprovedor.com.br/geofeed.csv
</pre>

== Como configurar no Registro.br ==

[[Arquivo:Geofeed_passo_a_passo_registrobr.png|center|1200px|Passo a passo para configuração do Geofeed no Registro.br]]

O Registro.br incorporou suporte ao Geofeed dentro da área de recursos de numeração, tornando o processo bastante simples.

O procedimento consiste em:

# Acessar sua conta no Registro.br.

# Entrar na área de Numeração.

# Selecionar o bloco IPv4 ou IPv6 desejado.

# Clicar em "Configurar Geofeed".

# Informar a URL HTTPS onde o arquivo CSV está hospedado.

# Salvar a configuração.

# Aguardar a propagação das informações.

== Um erro muito comum: configurar apenas o IPv4 ==

Durante implementações de Geofeed, um erro bastante frequente é publicar apenas os prefixos IPv4 e esquecer completamente os prefixos IPv6.

Embora muitos operadores ainda associem geolocalização principalmente ao IPv4, a realidade é que diversas aplicações modernas operam em Dual Stack e realizam consultas independentes para IPv4 e IPv6.

Isso significa que o mesmo assinante pode apresentar localizações diferentes dependendo do protocolo utilizado.

Exemplo:

<pre>
IPv4: 198.51.100.25
Localização: Teresina/PI

IPv6: 2001:db8:100::25
Localização: Fortaleza/CE
</pre>

Nesse cenário, uma plataforma pode identificar o usuário em Teresina enquanto outra o identifica em Fortaleza.

As consequências incluem:

* Conteúdo regional inconsistente
* Erros em plataformas antifraude
* Problemas em bancos e aplicativos financeiros
* Publicidade incorreta
* Dificuldades de troubleshooting

Por esse motivo, sempre que um Geofeed for implementado, todos os recursos públicos devem ser contemplados:

* Prefixos IPv4
* Prefixos IPv6
* Blocos de clientes corporativos (quando aplicável)
* Prefixos utilizados em diferentes cidades ou regiões

A regra é simples:

'''Se um prefixo é anunciado na Internet, ele deve possuir uma localização consistente no Geofeed.'''

== Geofeed não substitui um bom planejamento de endereçamento ==

Outra observação importante é que o Geofeed não corrige problemas de alocação.

Se um mesmo bloco IP é utilizado simultaneamente em diversas cidades, a precisão da geolocalização será naturalmente reduzida.

Quanto mais organizada for a distribuição dos blocos IPv4 e IPv6 por POP, cidade ou região, melhores serão os resultados obtidos.

Exemplo:

<pre>
198.51.100.0/24 → Teresina/PI
198.51.101.0/24 → Parnaíba/PI
198.51.102.0/24 → Picos/PI

2001:db8:100::/48 → Teresina/PI
2001:db8:200::/48 → Parnaíba/PI
2001:db8:300::/48 → Picos/PI
</pre>

== Geofeed faz parte do ecossistema de boas práticas ==

Hoje os operadores já reconhecem a importância de diversas boas práticas operacionais:

{| class="wikitable"
! Recurso

| ! Finalidade |
| ------------------------------------------ |
| IRR |
| Define quem pode anunciar os prefixos |
| - |
| RPKI / ROA |
| Valida a autorização dos anúncios |
| - |
| PeeringDB |
| Informa como conectar à rede |
| - |
| Whois |
| Identifica os responsáveis pelos recursos |
| - |
| Geofeed |
| Informa onde os IPs estão sendo utilizados |
| } |

Assim como mantemos IRR, RPKI, PeeringDB e informações de Whois atualizadas, também devemos manter a geolocalização dos recursos consistente e atualizada.

== Considerações importantes ==

A publicação do Geofeed não garante atualização imediata em todas as plataformas.

Cada fornecedor possui seu próprio ciclo de coleta e atualização.

Dependendo da plataforma, a propagação pode levar de alguns dias até algumas semanas.

Além disso, em determinados casos ainda pode ser necessário solicitar correções diretamente aos provedores das bases de geolocalização.

== Conclusão ==

Assim como o RPKI ajuda a proteger os anúncios BGP, o Geofeed ajuda a melhorar a forma como a Internet enxerga sua rede.

Não basta apenas anunciar seus prefixos corretamente.

Também é importante informar ao ecossistema onde esses recursos estão sendo utilizados.

Em um cenário cada vez mais dependente de geolocalização, segurança e experiência do usuário, manter informações consistentes para IPv4 e IPv6 deixou de ser um diferencial e passou a ser uma boa prática operacional para qualquer ISP moderno.

A Internet já sabe quem você é.

Já sabe quais prefixos você anuncia.

Agora ela também pode saber onde eles estão.

== Referências ==

* RFC 8805 - A Format for Self-Published IP Geolocation Feeds
* RFC 9632 - Geofeed Update
* Registro.br
* NIC.br
* Brasil Peering Forum
== Autor ==

Daniel Melo
Engenheiro de Redes

Arquivo:Geofeed passo a passo registrobr.png

2026-06-19T15:20:12Z

DanielTecnet:

Arquivo:Geofeed fluxo registrobr.png

2026-06-19T15:18:26Z

DanielTecnet:

Guia Operacional MPLS para ISPs

2026-06-08T17:53:27Z

DanielTecnet:

= Guia Operacional MPLS para ISPs =

Este guia tem como objetivo padronizar o troubleshooting MPLS em ambientes de provedores de Internet (ISPs), com foco principal em equipamentos Huawei, mas aplicável a ambientes multivendor.

== Objetivo e Público-Alvo ==

Este documento foi elaborado para auxiliar equipes NOC, N2, N3 e Engenharia na identificação, análise e correção de falhas relacionadas a MPLS.

=== Público-Alvo ===

* Analistas NOC/N1
* Analistas N2/N3
* Engenheiros de Redes
* Operadores de Backbone MPLS

=== Regra Fundamental ===

O troubleshooting MPLS deve seguir uma sequência lógica:

# Camada Física

# Conectividade IP

# OSPF

# MPLS

# LDP

# Serviço (L2VC/VSI)

# MTU

Uma falha em qualquer etapa anterior compromete as etapas seguintes.

== Como o MPLS Funciona na Prática ==

MPLS não deve ser tratado como uma tecnologia isolada. Em uma rede ISP, o MPLS depende inicialmente da conectividade IP e de um protocolo IGP, normalmente OSPF ou IS-IS.

O IGP garante o alcance entre as loopbacks dos roteadores. Em seguida, o LDP utiliza essa conectividade para distribuir labels. Somente após essas etapas os serviços L2VPN, como VPWS (L2VC) e VPLS (VSI), conseguem operar corretamente.

=== Resumo Prático ===

* OSPF encontra o caminho.
* LDP distribui as labels.
* MPLS encaminha usando labels.
* L2VC e VSI utilizam essa infraestrutura para transportar serviços Ethernet.
== Diagramas de Referência ==

[[Arquivo:MPLS Diagramas BPF v1.png|1200px|center|Diagramas MPLS para referência operacional]]

== Função dos Protocolos ==

=== OSPF ===

O OSPF é responsável por garantir a conectividade IP entre os roteadores do backbone. Em ambientes MPLS, normalmente são anunciadas as interfaces de transporte e as loopbacks utilizadas como Router-ID e LSR-ID.

Sem alcance IP entre as loopbacks dos roteadores, o MPLS e o LDP não conseguem estabelecer suas adjacências corretamente.

=== MPLS ===

O MPLS (Multiprotocol Label Switching) adiciona um rótulo (label) aos pacotes para permitir o encaminhamento baseado em labels ao invés de consultas sucessivas à tabela de roteamento IP.

Os principais serviços suportados incluem:

* L2VPN (VPWS/L2VC)
* VPLS (VSI)
* Engenharia de Tráfego
* VPNs de Camada 3

=== LDP ===

O LDP (Label Distribution Protocol) é responsável pela distribuição das labels entre os roteadores MPLS.

Após a conectividade IP ser estabelecida pelo OSPF, os roteadores formam vizinhanças LDP e trocam informações de labels para cada prefixo conhecido.

Caso o LDP apresente falhas, os serviços MPLS dependentes serão impactados.

=== Targeted LDP ===

O Targeted LDP (tLDP) permite estabelecer sessões LDP diretamente entre roteadores não adjacentes.

É amplamente utilizado em serviços VPWS (L2VC), onde os PEs precisam trocar informações de pseudowires através de sessões remotas.

A ausência ou falha do Targeted LDP normalmente resulta em serviços L2VC inoperantes, mesmo que o MPLS e o OSPF estejam funcionando corretamente.
== L2VC versus VSI ==

=== L2VC (VPWS) ===

O L2VC (Layer 2 Virtual Circuit), também conhecido como VPWS (Virtual Private Wire Service), cria uma conexão ponto a ponto entre dois equipamentos PE através da rede MPLS.

Características:

* Serviço ponto a ponto.
* Menor consumo de recursos.
* Simplicidade operacional.
* Amplamente utilizado para transporte de VLANs entre localidades.

Fluxo simplificado:

=== VSI (VPLS) ===

A VSI (Virtual Switch Instance), utilizada em implementações VPLS, cria um domínio Ethernet multiponto sobre a rede MPLS.

Características:

* Serviço multiponto.
* Comportamento semelhante a um switch Ethernet.
* Permite múltiplos sites na mesma LAN virtual.
* Maior consumo de recursos em comparação ao L2VC.

=== Comparativo ===

{| class="wikitable"
! Característica
! L2VC (VPWS)
! VSI (VPLS)
|-
| Topologia
| Ponto a ponto
| Multiponto
|-
| Complexidade
| Baixa
| Média
|-
| Escalabilidade
| Alta
| Muito alta
|-
| Consumo de recursos
| Menor
| Maior
|-
| Caso de uso
| Transporte de VLANs
| LAN estendida entre múltiplos sites
|}

Quando um L2VC ou VSI apresenta falhas:

# Validar interfaces físicas.

# Confirmar alcance IP entre as loopbacks.

# Verificar OSPF.

# Verificar MPLS.

# Verificar LDP.

# Verificar sessões Targeted LDP.

# Validar MTU ponta a ponta.

# Confirmar estado do serviço (VC ou VSI).

== MTU em Ambientes MPLS ==
[[Arquivo:MTU Explicacao Caixa MPLS.png|1000px|center|Comparação visual de MTU em ambientes MPLS]]
=== Conceitos Fundamentais ===

Em redes MPLS, a MTU deve ser planejada considerando o overhead adicional introduzido pelas labels MPLS.

Cada label MPLS adiciona 4 bytes ao pacote.

Exemplos:

* 1 Label = +4 bytes
* 2 Labels = +8 bytes
* 3 Labels = +12 bytes

Dependendo da tecnologia utilizada (L2VC, VSI, QinQ, PPPoE, VXLAN, etc.), o overhead total pode aumentar significativamente.

=== Exemplo Prático ===

Uma rede Ethernet tradicional normalmente opera com MTU 1500 bytes.

Ao adicionar MPLS:

* Payload IP = 1500 bytes
* 2 Labels MPLS = +8 bytes
* Cabeçalho Ethernet = +18 bytes

O enlace precisa suportar uma MTU superior a 1500 bytes para evitar fragmentação ou descarte de pacotes.

=== Sintomas de Problemas de MTU ===

Problemas de MTU podem gerar sintomas como:

* L2VC sobe, mas não passa tráfego.
* VSI apresenta instabilidade.
* Aplicações específicas não funcionam.
* Sites abrem parcialmente.
* Perda de pacotes para tráfego maior.
* PPPoE conecta, mas navegação apresenta falhas.
* OSPF e BGP estabelecem normalmente, porém o tráfego de usuário apresenta problemas.

=== Validação de MTU ===

Uma das formas mais simples de validação é utilizar ping com DF-bit (Don't Fragment).

Exemplo:

<pre>
ping -f -s 1472 X.X.X.X
</pre>

ou em equipamentos Huawei:

<pre>
ping -a LoopBack0 X.X.X.X -f -s 1472
</pre>

O objetivo é identificar o maior tamanho de pacote que consegue atravessar toda a rede sem fragmentação.

=== Troubleshooting ===

Ao investigar problemas relacionados a MTU:

# Validar MTU física das interfaces.
# Verificar MTU do backbone MPLS.
# Confirmar MTU dos serviços L2VC ou VSI.
# Testar ping com DF-bit.
# Verificar QinQ e encapsulamentos adicionais.
# Confirmar configuração fim a fim.

=== Boas Práticas ===

* Padronizar MTU do backbone.
* Documentar MTU de serviços especiais.
* Validar MTU durante ativações.
* Incluir testes de MTU nos procedimentos operacionais.
* Considerar expansões futuras de encapsulamento.
== Procedimento de Troubleshooting MPLS ==

=== Fluxo de Validação ===

Sempre execute o troubleshooting seguindo a sequência abaixo.

Uma falha identificada em qualquer etapa deve ser corrigida antes de prosseguir.

=== Etapa 1 - Camada Física ===

Validar:

* Interface UP/UP.
* Potência óptica dentro dos limites.
* Ausência de CRC e erros físicos.
* Negociação correta da interface.

Comandos Huawei:

<pre>
display interface brief
display interface GigabitEthernet 0/0/0
</pre>

=== Etapa 2 - Conectividade IP ===

Validar:

* Endereçamento IP.
* Rotas presentes.
* Ping entre vizinhos diretos.

Comandos Huawei:

<pre>
display ip interface brief
display ip routing-table
ping X.X.X.X
</pre>

=== Etapa 3 - OSPF ===

Validar:

* Vizinhanças estabelecidas.
* Loopbacks anunciadas.
* Rotas presentes na tabela.

Comandos Huawei:

<pre>
display ospf peer
display ospf routing
display ip routing-table protocol ospf
</pre>

=== Etapa 4 - MPLS ===

Validar:

* MPLS habilitado nas interfaces.
* LSR-ID configurado.
* Tabela MPLS populada.

Comandos Huawei:

<pre>
display mpls interface
display mpls lsr-id
display mpls forwarding-table
</pre>

=== Etapa 5 - LDP ===

Validar:

* Sessões LDP estabelecidas.
* Troca de labels funcionando.

Comandos Huawei:

<pre>
display mpls ldp session
display mpls ldp peer
display mpls ldp lsp
</pre>

=== Etapa 6 - Targeted LDP ===

Validar:

* Sessões remotas estabelecidas.
* Remote Peer alcançável.

Comandos Huawei:

<pre>
display mpls ldp remote-peer
display mpls ldp session
</pre>

=== Etapa 7 - Serviço ===

Para L2VC:

<pre>
display mpls l2vc
</pre>

Para VSI:

<pre>
display vsi
display vsi verbose
</pre>

Validar:

* Estado UP.
* Labels aprendidas.
* Peer correto.

=== Etapa 8 - MTU ===

Validar:

* MTU física.
* MTU MPLS.
* MTU do serviço.

Executar testes com DF-bit sempre que houver suspeita de fragmentação.

=== Checklist Final ===

{| class="wikitable"
! Item
! Status
|-
| Interface Física
| OK / NOK
|-
| Conectividade IP
| OK / NOK
|-
| OSPF
| OK / NOK
|-
| MPLS
| OK / NOK
|-
| LDP
| OK / NOK
|-
| Targeted LDP
| OK / NOK
|-
| Serviço
| OK / NOK
|-
| MTU
| OK / NOK
|}

== Comandos de Troubleshooting Huawei ==
== Casos Reais de Troubleshooting ==

=== Caso 1 - OSPF UP e LDP DOWN ===

Sintoma:

* OSPF estabelecido.
* Loopbacks alcançáveis.
* LDP não sobe.

Possíveis causas:

* MPLS não habilitado na interface.
* LSR-ID incorreto.
* ACL bloqueando TCP 646.

Comandos:

display mpls interface
display mpls ldp peer

=== Caso 2 - LDP UP e L2VC DOWN ===

Sintoma:

* LDP operacional.
* VC State Down.

Possíveis causas:

* Targeted LDP Down.
* VC-ID divergente.
* Peer incorreto.

Comandos:

display mpls l2vc
display mpls ldp remote-peer

=== Caso 3 - L2VC UP sem tráfego ===

Sintoma:

* VC State UP.
* Cliente sem comunicação.

Possíveis causas:

* MTU.
* VLAN incorreta.
* QinQ inconsistente.

Comandos:

display interface
display mpls l2vc verbose

=== Caso 4 - VSI UP sem aprendizado MAC ===

Sintoma:

* VSI UP.
* MAC Address não aparece.

Possíveis causas:

* Split-horizon.
* VLAN incorreta.
* SAP/AC Down.

Comandos:

display vsi verbose
display mac-address

=== Caso 5 - Problema de MTU ===

Sintoma:

* Ping pequeno funciona.
* Ping grande falha.
* Navegação parcial.

Possíveis causas:

* MTU incompatível.
* MPLS overhead.

Comandos:

ping -f -s 1472 X.X.X.X

== Comandos de Referência Huawei ==

=== OSPF ===

<pre>
display ospf peer
display ospf routing
display ospf interface
display ospf brief
</pre>

=== MPLS ===

<pre>
display mpls interface
display mpls lsr-id
display mpls forwarding-table
display mpls lsp
</pre>

=== LDP ===

<pre>
display mpls ldp peer
display mpls ldp session
display mpls ldp lsp
display mpls ldp statistics
</pre>

=== Targeted LDP ===

<pre>
display mpls ldp remote-peer
display mpls ldp session
</pre>

=== L2VC ===

<pre>
display mpls l2vc
display mpls l2vc verbose
</pre>

=== VSI ===

<pre>
display vsi
display vsi verbose
display mac-address vsi
</pre>

=== Interface ===

<pre>
display interface brief
display interface GigabitEthernet x/x/x
</pre>

== Autor ==

Daniel Melo
Gerente de Redes | G3 Telecom
Especialista em ISP, BGP, MPLS e Engenharia de Backbone

Última atualização: Junho/2026

Guia Operacional MPLS para ISPs

2026-06-08T17:25:33Z

DanielTecnet:

= Guia Operacional MPLS para ISPs =

Este guia tem como objetivo padronizar o troubleshooting MPLS em ambientes de provedores de Internet (ISPs), com foco principal em equipamentos Huawei, mas aplicável a ambientes multivendor.

== Objetivo e Público-Alvo ==

Este documento foi elaborado para auxiliar equipes NOC, N2, N3 e Engenharia na identificação, análise e correção de falhas relacionadas a MPLS.

=== Público-Alvo ===

* Analistas NOC/N1
* Analistas N2/N3
* Engenheiros de Redes
* Operadores de Backbone MPLS

=== Regra Fundamental ===

O troubleshooting MPLS deve seguir uma sequência lógica:

# Camada Física

# Conectividade IP

# OSPF

# MPLS

# LDP

# Serviço (L2VC/VSI)

# MTU

Uma falha em qualquer etapa anterior compromete as etapas seguintes.

== Como o MPLS Funciona na Prática ==

MPLS não deve ser tratado como uma tecnologia isolada. Em uma rede ISP, o MPLS depende inicialmente da conectividade IP e de um protocolo IGP, normalmente OSPF ou IS-IS.

O IGP garante o alcance entre as loopbacks dos roteadores. Em seguida, o LDP utiliza essa conectividade para distribuir labels. Somente após essas etapas os serviços L2VPN, como VPWS (L2VC) e VPLS (VSI), conseguem operar corretamente.

=== Resumo Prático ===

* OSPF encontra o caminho.
* LDP distribui as labels.
* MPLS encaminha usando labels.
* L2VC e VSI utilizam essa infraestrutura para transportar serviços Ethernet.
== Diagramas de Referência ==

[[Arquivo:MPLS Diagramas BPF v1.png|1200px|center|Diagramas MPLS para referência operacional]]

== Função dos Protocolos ==

=== OSPF ===

O OSPF é responsável por garantir a conectividade IP entre os roteadores do backbone. Em ambientes MPLS, normalmente são anunciadas as interfaces de transporte e as loopbacks utilizadas como Router-ID e LSR-ID.

Sem alcance IP entre as loopbacks dos roteadores, o MPLS e o LDP não conseguem estabelecer suas adjacências corretamente.

=== MPLS ===

O MPLS (Multiprotocol Label Switching) adiciona um rótulo (label) aos pacotes para permitir o encaminhamento baseado em labels ao invés de consultas sucessivas à tabela de roteamento IP.

Os principais serviços suportados incluem:

* L2VPN (VPWS/L2VC)
* VPLS (VSI)
* Engenharia de Tráfego
* VPNs de Camada 3

=== LDP ===

O LDP (Label Distribution Protocol) é responsável pela distribuição das labels entre os roteadores MPLS.

Após a conectividade IP ser estabelecida pelo OSPF, os roteadores formam vizinhanças LDP e trocam informações de labels para cada prefixo conhecido.

Caso o LDP apresente falhas, os serviços MPLS dependentes serão impactados.

=== Targeted LDP ===

O Targeted LDP (tLDP) permite estabelecer sessões LDP diretamente entre roteadores não adjacentes.

É amplamente utilizado em serviços VPWS (L2VC), onde os PEs precisam trocar informações de pseudowires através de sessões remotas.

A ausência ou falha do Targeted LDP normalmente resulta em serviços L2VC inoperantes, mesmo que o MPLS e o OSPF estejam funcionando corretamente.
== L2VC versus VSI ==

=== L2VC (VPWS) ===

O L2VC (Layer 2 Virtual Circuit), também conhecido como VPWS (Virtual Private Wire Service), cria uma conexão ponto a ponto entre dois equipamentos PE através da rede MPLS.

Características:

* Serviço ponto a ponto.
* Menor consumo de recursos.
* Simplicidade operacional.
* Amplamente utilizado para transporte de VLANs entre localidades.

Fluxo simplificado:

CE ---- PE ===== MPLS ===== PE ---- CE

=== VSI (VPLS) ===

A VSI (Virtual Switch Instance), utilizada em implementações VPLS, cria um domínio Ethernet multiponto sobre a rede MPLS.

Características:

* Serviço multiponto.
* Comportamento semelhante a um switch Ethernet.
* Permite múltiplos sites na mesma LAN virtual.
* Maior consumo de recursos em comparação ao L2VC.

Fluxo simplificado:

```
CE
|
PE
/ \
/ \
MPLS MPLS
/ \
PE -------- PE
| |
CE CE
```

=== Comparativo ===

{| class="wikitable"
! Característica
! L2VC / VPWS

| ! VSI / VPLS |
| ----------------------------------- |
| Topologia |
| Ponto a Ponto |
| Multiponto |
| - |
| Complexidade |
| Baixa |
| Média |
| - |
| Escalabilidade |
| Alta |
| Muito Alta |
| - |
| Consumo de Recursos |
| Menor |
| Maior |
| - |
| Caso de Uso |
| Transporte de VLAN |
| LAN estendida entre múltiplos sites |
| } |

=== Troubleshooting ===

Quando um L2VC ou VSI apresenta falhas:

# Validar interfaces físicas.

# Confirmar alcance IP entre as loopbacks.

# Verificar OSPF.

# Verificar MPLS.

# Verificar LDP.

# Verificar sessões Targeted LDP.

# Validar MTU ponta a ponta.

# Confirmar estado do serviço (VC ou VSI).

== MTU em Ambientes MPLS ==
[[Arquivo:MTU Explicacao Caixa MPLS.png|1000px|center|Comparação visual de MTU em ambientes MPLS]]
=== Conceitos Fundamentais ===

Em redes MPLS, a MTU deve ser planejada considerando o overhead adicional introduzido pelas labels MPLS.

Cada label MPLS adiciona 4 bytes ao pacote.

Exemplos:

* 1 Label = +4 bytes
* 2 Labels = +8 bytes
* 3 Labels = +12 bytes

Dependendo da tecnologia utilizada (L2VC, VSI, QinQ, PPPoE, VXLAN, etc.), o overhead total pode aumentar significativamente.

=== Exemplo Prático ===

Uma rede Ethernet tradicional normalmente opera com MTU 1500 bytes.

Ao adicionar MPLS:

* Payload IP = 1500 bytes
* 2 Labels MPLS = +8 bytes
* Cabeçalho Ethernet = +18 bytes

O enlace precisa suportar uma MTU superior a 1500 bytes para evitar fragmentação ou descarte de pacotes.

=== Sintomas de Problemas de MTU ===

Problemas de MTU podem gerar sintomas como:

* L2VC sobe, mas não passa tráfego.
* VSI apresenta instabilidade.
* Aplicações específicas não funcionam.
* Sites abrem parcialmente.
* Perda de pacotes para tráfego maior.
* PPPoE conecta, mas navegação apresenta falhas.
* OSPF e BGP estabelecem normalmente, porém o tráfego de usuário apresenta problemas.

=== Validação de MTU ===

Uma das formas mais simples de validação é utilizar ping com DF-bit (Don't Fragment).

Exemplo:

<pre>
ping -f -s 1472 X.X.X.X
</pre>

ou em equipamentos Huawei:

<pre>
ping -a LoopBack0 X.X.X.X -f -s 1472
</pre>

O objetivo é identificar o maior tamanho de pacote que consegue atravessar toda a rede sem fragmentação.

=== Troubleshooting ===

Ao investigar problemas relacionados a MTU:

# Validar MTU física das interfaces.
# Verificar MTU do backbone MPLS.
# Confirmar MTU dos serviços L2VC ou VSI.
# Testar ping com DF-bit.
# Verificar QinQ e encapsulamentos adicionais.
# Confirmar configuração fim a fim.

=== Boas Práticas ===

* Padronizar MTU do backbone.
* Documentar MTU de serviços especiais.
* Validar MTU durante ativações.
* Incluir testes de MTU nos procedimentos operacionais.
* Considerar expansões futuras de encapsulamento.
== Procedimento de Troubleshooting MPLS ==

=== Fluxo de Validação ===

Sempre execute o troubleshooting seguindo a sequência abaixo.

Uma falha identificada em qualquer etapa deve ser corrigida antes de prosseguir.

=== Etapa 1 - Camada Física ===

Validar:

* Interface UP/UP.
* Potência óptica dentro dos limites.
* Ausência de CRC e erros físicos.
* Negociação correta da interface.

Comandos Huawei:

<pre>
display interface brief
display interface GigabitEthernet 0/0/0
</pre>

=== Etapa 2 - Conectividade IP ===

Validar:

* Endereçamento IP.
* Rotas presentes.
* Ping entre vizinhos diretos.

Comandos Huawei:

<pre>
display ip interface brief
display ip routing-table
ping X.X.X.X
</pre>

=== Etapa 3 - OSPF ===

Validar:

* Vizinhanças estabelecidas.
* Loopbacks anunciadas.
* Rotas presentes na tabela.

Comandos Huawei:

<pre>
display ospf peer
display ospf routing
display ip routing-table protocol ospf
</pre>

=== Etapa 4 - MPLS ===

Validar:

* MPLS habilitado nas interfaces.
* LSR-ID configurado.
* Tabela MPLS populada.

Comandos Huawei:

<pre>
display mpls interface
display mpls lsr-id
display mpls forwarding-table
</pre>

=== Etapa 5 - LDP ===

Validar:

* Sessões LDP estabelecidas.
* Troca de labels funcionando.

Comandos Huawei:

<pre>
display mpls ldp session
display mpls ldp peer
display mpls ldp lsp
</pre>

=== Etapa 6 - Targeted LDP ===

Validar:

* Sessões remotas estabelecidas.
* Remote Peer alcançável.

Comandos Huawei:

<pre>
display mpls ldp remote-peer
display mpls ldp session
</pre>

=== Etapa 7 - Serviço ===

Para L2VC:

<pre>
display mpls l2vc
</pre>

Para VSI:

<pre>
display vsi
display vsi verbose
</pre>

Validar:

* Estado UP.
* Labels aprendidas.
* Peer correto.

=== Etapa 8 - MTU ===

Validar:

* MTU física.
* MTU MPLS.
* MTU do serviço.

Executar testes com DF-bit sempre que houver suspeita de fragmentação.

=== Checklist Final ===

{| class="wikitable"
! Item
! Status
|-
| Interface Física
| OK / NOK
|-
| Conectividade IP
| OK / NOK
|-
| OSPF
| OK / NOK
|-
| MPLS
| OK / NOK
|-
| LDP
| OK / NOK
|-
| Targeted LDP
| OK / NOK
|-
| Serviço
| OK / NOK
|-
| MTU
| OK / NOK
|}

== Comandos de Troubleshooting Huawei ==
== Casos Reais de Troubleshooting ==

=== Caso 1 - OSPF UP e LDP DOWN ===

Sintoma:

* OSPF estabelecido.
* Loopbacks alcançáveis.
* LDP não sobe.

Possíveis causas:

* MPLS não habilitado na interface.
* LSR-ID incorreto.
* ACL bloqueando TCP 646.

Comandos:

display mpls interface
display mpls ldp peer

=== Caso 2 - LDP UP e L2VC DOWN ===

Sintoma:

* LDP operacional.
* VC State Down.

Possíveis causas:

* Targeted LDP Down.
* VC-ID divergente.
* Peer incorreto.

Comandos:

display mpls l2vc
display mpls ldp remote-peer

=== Caso 3 - L2VC UP sem tráfego ===

Sintoma:

* VC State UP.
* Cliente sem comunicação.

Possíveis causas:

* MTU.
* VLAN incorreta.
* QinQ inconsistente.

Comandos:

display interface
display mpls l2vc verbose

=== Caso 4 - VSI UP sem aprendizado MAC ===

Sintoma:

* VSI UP.
* MAC Address não aparece.

Possíveis causas:

* Split-horizon.
* VLAN incorreta.
* SAP/AC Down.

Comandos:

display vsi verbose
display mac-address

=== Caso 5 - Problema de MTU ===

Sintoma:

* Ping pequeno funciona.
* Ping grande falha.
* Navegação parcial.

Possíveis causas:

* MTU incompatível.
* MPLS overhead.

Comandos:

ping -f -s 1472 X.X.X.X

=== OSPF ===

{| class="wikitable"
! Verificação
! Comando

| ! Objetivo |
| ---------------------------- |
| Vizinhos OSPF |
| display ospf peer |
| Verificar adjacências |
| - |
| Rotas OSPF |
| display ospf routing |
| Validar aprendizado de rotas |
| - |
| Banco LSDB |
| display ospf lsdb |
| Verificar LSAs |
| } |

=== MPLS ===

{| class="wikitable"
! Verificação
! Comando

| ! Objetivo |
| ----------------------------- |
| MPLS Interfaces |
| display mpls interface |
| Verificar interfaces MPLS |
| - |
| LSR-ID |
| display mpls lsr-id |
| Verificar Router-ID MPLS |
| - |
| Labels |
| display mpls forwarding-table |
| Verificar encaminhamento MPLS |
| } |

=== LDP ===

{| class="wikitable"
! Verificação
! Comando

| ! Objetivo |
| -------------------------------- |
| Sessões LDP |
| display mpls ldp session |
| Verificar sessões |
| - |
| Peers LDP |
| display mpls ldp peer |
| Verificar vizinhos |
| - |
| Labels LDP |
| display mpls ldp lsp |
| Verificar distribuição de labels |
| } |

=== Targeted LDP ===

{| class="wikitable"
! Verificação
! Comando

| ! Objetivo |
| ---------------------------- |
| Remote Peer |
| display mpls ldp remote-peer |
| Verificar sessões remotas |
| - |
| Sessão tLDP |
| display mpls ldp session |
| Confirmar estado UP |
| } |

=== L2VC ===

{| class="wikitable"
! Verificação
! Comando

| ! Objetivo |
| ------------------------- |
| Estado do VC |
| display mpls l2vc |
| Verificar serviço |
| - |
| Estatísticas |
| display mpls l2vc verbose |
| Verificar detalhes |
| } |

=== VSI / VPLS ===

{| class="wikitable"
! Verificação
! Comando

| ! Objetivo |
| -------------------- |
| VSI |
| display vsi |
| Verificar estado |
| - |
| VSI Detalhado |
| display vsi verbose |
| Verificar peers e PW |
| } |

Guia Operacional MPLS para ISPs

2026-06-08T17:17:00Z

DanielTecnet:

= Guia Operacional MPLS para ISPs =

Este guia tem como objetivo padronizar o troubleshooting MPLS em ambientes de provedores de Internet (ISPs), com foco principal em equipamentos Huawei, mas aplicável a ambientes multivendor.

== Objetivo e Público-Alvo ==

Este documento foi elaborado para auxiliar equipes NOC, N2, N3 e Engenharia na identificação, análise e correção de falhas relacionadas a MPLS.

=== Público-Alvo ===

* Analistas NOC/N1
* Analistas N2/N3
* Engenheiros de Redes
* Operadores de Backbone MPLS

=== Regra Fundamental ===

O troubleshooting MPLS deve seguir uma sequência lógica:

# Camada Física

# Conectividade IP

# OSPF

# MPLS

# LDP

# Serviço (L2VC/VSI)

# MTU

Uma falha em qualquer etapa anterior compromete as etapas seguintes.

== Como o MPLS Funciona na Prática ==

MPLS não deve ser tratado como uma tecnologia isolada. Em uma rede ISP, o MPLS depende inicialmente da conectividade IP e de um protocolo IGP, normalmente OSPF ou IS-IS.

O IGP garante o alcance entre as loopbacks dos roteadores. Em seguida, o LDP utiliza essa conectividade para distribuir labels. Somente após essas etapas os serviços L2VPN, como VPWS (L2VC) e VPLS (VSI), conseguem operar corretamente.

=== Resumo Prático ===

* OSPF encontra o caminho.
* LDP distribui as labels.
* MPLS encaminha usando labels.
* L2VC e VSI utilizam essa infraestrutura para transportar serviços Ethernet.
== Diagramas de Referência ==

[[Arquivo:MPLS Diagramas BPF v1.png|1200px|center|Diagramas MPLS para referência operacional]]

== Função dos Protocolos ==

=== OSPF ===

O OSPF é responsável por garantir a conectividade IP entre os roteadores do backbone. Em ambientes MPLS, normalmente são anunciadas as interfaces de transporte e as loopbacks utilizadas como Router-ID e LSR-ID.

Sem alcance IP entre as loopbacks dos roteadores, o MPLS e o LDP não conseguem estabelecer suas adjacências corretamente.

=== MPLS ===

O MPLS (Multiprotocol Label Switching) adiciona um rótulo (label) aos pacotes para permitir o encaminhamento baseado em labels ao invés de consultas sucessivas à tabela de roteamento IP.

Os principais serviços suportados incluem:

* L2VPN (VPWS/L2VC)
* VPLS (VSI)
* Engenharia de Tráfego
* VPNs de Camada 3

=== LDP ===

O LDP (Label Distribution Protocol) é responsável pela distribuição das labels entre os roteadores MPLS.

Após a conectividade IP ser estabelecida pelo OSPF, os roteadores formam vizinhanças LDP e trocam informações de labels para cada prefixo conhecido.

Caso o LDP apresente falhas, os serviços MPLS dependentes serão impactados.

=== Targeted LDP ===

O Targeted LDP (tLDP) permite estabelecer sessões LDP diretamente entre roteadores não adjacentes.

É amplamente utilizado em serviços VPWS (L2VC), onde os PEs precisam trocar informações de pseudowires através de sessões remotas.

A ausência ou falha do Targeted LDP normalmente resulta em serviços L2VC inoperantes, mesmo que o MPLS e o OSPF estejam funcionando corretamente.
== L2VC versus VSI ==

=== L2VC (VPWS) ===

O L2VC (Layer 2 Virtual Circuit), também conhecido como VPWS (Virtual Private Wire Service), cria uma conexão ponto a ponto entre dois equipamentos PE através da rede MPLS.

Características:

* Serviço ponto a ponto.
* Menor consumo de recursos.
* Simplicidade operacional.
* Amplamente utilizado para transporte de VLANs entre localidades.

Fluxo simplificado:

CE ---- PE ===== MPLS ===== PE ---- CE

=== VSI (VPLS) ===

A VSI (Virtual Switch Instance), utilizada em implementações VPLS, cria um domínio Ethernet multiponto sobre a rede MPLS.

Características:

* Serviço multiponto.
* Comportamento semelhante a um switch Ethernet.
* Permite múltiplos sites na mesma LAN virtual.
* Maior consumo de recursos em comparação ao L2VC.

Fluxo simplificado:

```
CE
|
PE
/ \
/ \
MPLS MPLS
/ \
PE -------- PE
| |
CE CE
```

=== Comparativo ===

{| class="wikitable"
! Característica
! L2VC / VPWS

| ! VSI / VPLS |
| ----------------------------------- |
| Topologia |
| Ponto a Ponto |
| Multiponto |
| - |
| Complexidade |
| Baixa |
| Média |
| - |
| Escalabilidade |
| Alta |
| Muito Alta |
| - |
| Consumo de Recursos |
| Menor |
| Maior |
| - |
| Caso de Uso |
| Transporte de VLAN |
| LAN estendida entre múltiplos sites |
| } |

=== Troubleshooting ===

Quando um L2VC ou VSI apresenta falhas:

# Validar interfaces físicas.

# Confirmar alcance IP entre as loopbacks.

# Verificar OSPF.

# Verificar MPLS.

# Verificar LDP.

# Verificar sessões Targeted LDP.

# Validar MTU ponta a ponta.

# Confirmar estado do serviço (VC ou VSI).

== MTU em Ambientes MPLS ==
[[Arquivo:MTU Explicacao Caixa MPLS.png|1000px|center|Comparação visual de MTU em ambientes MPLS]]
=== Conceitos Fundamentais ===

Em redes MPLS, a MTU deve ser planejada considerando o overhead adicional introduzido pelas labels MPLS.

Cada label MPLS adiciona 4 bytes ao pacote.

Exemplos:

* 1 Label = +4 bytes
* 2 Labels = +8 bytes
* 3 Labels = +12 bytes

Dependendo da tecnologia utilizada (L2VC, VSI, QinQ, PPPoE, VXLAN, etc.), o overhead total pode aumentar significativamente.

=== Exemplo Prático ===

Uma rede Ethernet tradicional normalmente opera com MTU 1500 bytes.

Ao adicionar MPLS:

* Payload IP = 1500 bytes
* 2 Labels MPLS = +8 bytes
* Cabeçalho Ethernet = +18 bytes

O enlace precisa suportar uma MTU superior a 1500 bytes para evitar fragmentação ou descarte de pacotes.

=== Sintomas de Problemas de MTU ===

Problemas de MTU podem gerar sintomas como:

* L2VC sobe, mas não passa tráfego.
* VSI apresenta instabilidade.
* Aplicações específicas não funcionam.
* Sites abrem parcialmente.
* Perda de pacotes para tráfego maior.
* PPPoE conecta, mas navegação apresenta falhas.
* OSPF e BGP estabelecem normalmente, porém o tráfego de usuário apresenta problemas.

=== Validação de MTU ===

Uma das formas mais simples de validação é utilizar ping com DF-bit (Don't Fragment).

Exemplo:

<pre>
ping -f -s 1472 X.X.X.X
</pre>

ou em equipamentos Huawei:

<pre>
ping -a LoopBack0 X.X.X.X -f -s 1472
</pre>

O objetivo é identificar o maior tamanho de pacote que consegue atravessar toda a rede sem fragmentação.

=== Troubleshooting ===

Ao investigar problemas relacionados a MTU:

# Validar MTU física das interfaces.
# Verificar MTU do backbone MPLS.
# Confirmar MTU dos serviços L2VC ou VSI.
# Testar ping com DF-bit.
# Verificar QinQ e encapsulamentos adicionais.
# Confirmar configuração fim a fim.

=== Boas Práticas ===

* Padronizar MTU do backbone.
* Documentar MTU de serviços especiais.
* Validar MTU durante ativações.
* Incluir testes de MTU nos procedimentos operacionais.
* Considerar expansões futuras de encapsulamento.
== Procedimento de Troubleshooting MPLS ==

=== Fluxo de Validação ===

Sempre execute o troubleshooting seguindo a sequência abaixo.

Uma falha identificada em qualquer etapa deve ser corrigida antes de prosseguir.

=== Etapa 1 - Camada Física ===

Validar:

* Interface UP/UP.
* Potência óptica dentro dos limites.
* Ausência de CRC e erros físicos.
* Negociação correta da interface.

Comandos Huawei:

<pre>
display interface brief
display interface GigabitEthernet 0/0/0
</pre>

=== Etapa 2 - Conectividade IP ===

Validar:

* Endereçamento IP.
* Rotas presentes.
* Ping entre vizinhos diretos.

Comandos Huawei:

<pre>
display ip interface brief
display ip routing-table
ping X.X.X.X
</pre>

=== Etapa 3 - OSPF ===

Validar:

* Vizinhanças estabelecidas.
* Loopbacks anunciadas.
* Rotas presentes na tabela.

Comandos Huawei:

<pre>
display ospf peer
display ospf routing
display ip routing-table protocol ospf
</pre>

=== Etapa 4 - MPLS ===

Validar:

* MPLS habilitado nas interfaces.
* LSR-ID configurado.
* Tabela MPLS populada.

Comandos Huawei:

<pre>
display mpls interface
display mpls lsr-id
display mpls forwarding-table
</pre>

=== Etapa 5 - LDP ===

Validar:

* Sessões LDP estabelecidas.
* Troca de labels funcionando.

Comandos Huawei:

<pre>
display mpls ldp session
display mpls ldp peer
display mpls ldp lsp
</pre>

=== Etapa 6 - Targeted LDP ===

Validar:

* Sessões remotas estabelecidas.
* Remote Peer alcançável.

Comandos Huawei:

<pre>
display mpls ldp remote-peer
display mpls ldp session
</pre>

=== Etapa 7 - Serviço ===

Para L2VC:

<pre>
display mpls l2vc
</pre>

Para VSI:

<pre>
display vsi
display vsi verbose
</pre>

Validar:

* Estado UP.
* Labels aprendidas.
* Peer correto.

=== Etapa 8 - MTU ===

Validar:

* MTU física.
* MTU MPLS.
* MTU do serviço.

Executar testes com DF-bit sempre que houver suspeita de fragmentação.

=== Checklist Final ===

{| class="wikitable"
! Item
! Status
|-
| Interface Física
| OK / NOK
|-
| Conectividade IP
| OK / NOK
|-
| OSPF
| OK / NOK
|-
| MPLS
| OK / NOK
|-
| LDP
| OK / NOK
|-
| Targeted LDP
| OK / NOK
|-
| Serviço
| OK / NOK
|-
| MTU
| OK / NOK
|}

Arquivo:MTU Explicacao Caixa MPLS.png

2026-06-08T17:11:22Z

DanielTecnet:

Guia Operacional MPLS para ISPs

2026-06-08T17:08:07Z

DanielTecnet:

= Guia Operacional MPLS para ISPs =

Este guia tem como objetivo padronizar o troubleshooting MPLS em ambientes de provedores de Internet (ISPs), com foco principal em equipamentos Huawei, mas aplicável a ambientes multivendor.

== Objetivo e Público-Alvo ==

Este documento foi elaborado para auxiliar equipes NOC, N2, N3 e Engenharia na identificação, análise e correção de falhas relacionadas a MPLS.

=== Público-Alvo ===

* Analistas NOC/N1
* Analistas N2/N3
* Engenheiros de Redes
* Operadores de Backbone MPLS

=== Regra Fundamental ===

O troubleshooting MPLS deve seguir uma sequência lógica:

# Camada Física

# Conectividade IP

# OSPF

# MPLS

# LDP

# Serviço (L2VC/VSI)

# MTU

Uma falha em qualquer etapa anterior compromete as etapas seguintes.

== Como o MPLS Funciona na Prática ==

MPLS não deve ser tratado como uma tecnologia isolada. Em uma rede ISP, o MPLS depende inicialmente da conectividade IP e de um protocolo IGP, normalmente OSPF ou IS-IS.

O IGP garante o alcance entre as loopbacks dos roteadores. Em seguida, o LDP utiliza essa conectividade para distribuir labels. Somente após essas etapas os serviços L2VPN, como VPWS (L2VC) e VPLS (VSI), conseguem operar corretamente.

=== Resumo Prático ===

* OSPF encontra o caminho.
* LDP distribui as labels.
* MPLS encaminha usando labels.
* L2VC e VSI utilizam essa infraestrutura para transportar serviços Ethernet.
== Diagramas de Referência ==

[[Arquivo:MPLS Diagramas BPF v1.png|1200px|center|Diagramas MPLS para referência operacional]]

== Função dos Protocolos ==

=== OSPF ===

O OSPF é responsável por garantir a conectividade IP entre os roteadores do backbone. Em ambientes MPLS, normalmente são anunciadas as interfaces de transporte e as loopbacks utilizadas como Router-ID e LSR-ID.

Sem alcance IP entre as loopbacks dos roteadores, o MPLS e o LDP não conseguem estabelecer suas adjacências corretamente.

=== MPLS ===

O MPLS (Multiprotocol Label Switching) adiciona um rótulo (label) aos pacotes para permitir o encaminhamento baseado em labels ao invés de consultas sucessivas à tabela de roteamento IP.

Os principais serviços suportados incluem:

* L2VPN (VPWS/L2VC)
* VPLS (VSI)
* Engenharia de Tráfego
* VPNs de Camada 3

=== LDP ===

O LDP (Label Distribution Protocol) é responsável pela distribuição das labels entre os roteadores MPLS.

Após a conectividade IP ser estabelecida pelo OSPF, os roteadores formam vizinhanças LDP e trocam informações de labels para cada prefixo conhecido.

Caso o LDP apresente falhas, os serviços MPLS dependentes serão impactados.

=== Targeted LDP ===

O Targeted LDP (tLDP) permite estabelecer sessões LDP diretamente entre roteadores não adjacentes.

É amplamente utilizado em serviços VPWS (L2VC), onde os PEs precisam trocar informações de pseudowires através de sessões remotas.

A ausência ou falha do Targeted LDP normalmente resulta em serviços L2VC inoperantes, mesmo que o MPLS e o OSPF estejam funcionando corretamente.
== L2VC versus VSI ==

=== L2VC (VPWS) ===

O L2VC (Layer 2 Virtual Circuit), também conhecido como VPWS (Virtual Private Wire Service), cria uma conexão ponto a ponto entre dois equipamentos PE através da rede MPLS.

Características:

* Serviço ponto a ponto.
* Menor consumo de recursos.
* Simplicidade operacional.
* Amplamente utilizado para transporte de VLANs entre localidades.

Fluxo simplificado:

CE ---- PE ===== MPLS ===== PE ---- CE

=== VSI (VPLS) ===

A VSI (Virtual Switch Instance), utilizada em implementações VPLS, cria um domínio Ethernet multiponto sobre a rede MPLS.

Características:

* Serviço multiponto.
* Comportamento semelhante a um switch Ethernet.
* Permite múltiplos sites na mesma LAN virtual.
* Maior consumo de recursos em comparação ao L2VC.

Fluxo simplificado:

```
CE
|
PE
/ \
/ \
MPLS MPLS
/ \
PE -------- PE
| |
CE CE
```

=== Comparativo ===

{| class="wikitable"
! Característica
! L2VC / VPWS

| ! VSI / VPLS |
| ----------------------------------- |
| Topologia |
| Ponto a Ponto |
| Multiponto |
| - |
| Complexidade |
| Baixa |
| Média |
| - |
| Escalabilidade |
| Alta |
| Muito Alta |
| - |
| Consumo de Recursos |
| Menor |
| Maior |
| - |
| Caso de Uso |
| Transporte de VLAN |
| LAN estendida entre múltiplos sites |
| } |

=== Troubleshooting ===

Quando um L2VC ou VSI apresenta falhas:

# Validar interfaces físicas.

# Confirmar alcance IP entre as loopbacks.

# Verificar OSPF.

# Verificar MPLS.

# Verificar LDP.

# Verificar sessões Targeted LDP.

# Validar MTU ponta a ponta.

# Confirmar estado do serviço (VC ou VSI).

== MTU em Ambientes MPLS ==

=== Conceitos Fundamentais ===

Em redes MPLS, a MTU deve ser planejada considerando o overhead adicional introduzido pelas labels MPLS.

Cada label MPLS adiciona 4 bytes ao pacote.

Exemplos:

* 1 Label = +4 bytes
* 2 Labels = +8 bytes
* 3 Labels = +12 bytes

Dependendo da tecnologia utilizada (L2VC, VSI, QinQ, PPPoE, VXLAN, etc.), o overhead total pode aumentar significativamente.

=== Exemplo Prático ===

Uma rede Ethernet tradicional normalmente opera com MTU 1500 bytes.

Ao adicionar MPLS:

* Payload IP = 1500 bytes
* 2 Labels MPLS = +8 bytes
* Cabeçalho Ethernet = +18 bytes

O enlace precisa suportar uma MTU superior a 1500 bytes para evitar fragmentação ou descarte de pacotes.

=== Sintomas de Problemas de MTU ===

Problemas de MTU podem gerar sintomas como:

* L2VC sobe, mas não passa tráfego.
* VSI apresenta instabilidade.
* Aplicações específicas não funcionam.
* Sites abrem parcialmente.
* Perda de pacotes para tráfego maior.
* PPPoE conecta, mas navegação apresenta falhas.
* OSPF e BGP estabelecem normalmente, porém o tráfego de usuário apresenta problemas.

=== Validação de MTU ===

Uma das formas mais simples de validação é utilizar ping com DF-bit (Don't Fragment).

Exemplo:

<pre>
ping -f -s 1472 X.X.X.X
</pre>

ou em equipamentos Huawei:

<pre>
ping -a LoopBack0 X.X.X.X -f -s 1472
</pre>

O objetivo é identificar o maior tamanho de pacote que consegue atravessar toda a rede sem fragmentação.

=== Troubleshooting ===

Ao investigar problemas relacionados a MTU:

# Validar MTU física das interfaces.
# Verificar MTU do backbone MPLS.
# Confirmar MTU dos serviços L2VC ou VSI.
# Testar ping com DF-bit.
# Verificar QinQ e encapsulamentos adicionais.
# Confirmar configuração fim a fim.

=== Boas Práticas ===

* Padronizar MTU do backbone.
* Documentar MTU de serviços especiais.
* Validar MTU durante ativações.
* Incluir testes de MTU nos procedimentos operacionais.
* Considerar expansões futuras de encapsulamento.
== Procedimento de Troubleshooting MPLS ==

=== Fluxo de Validação ===

Sempre execute o troubleshooting seguindo a sequência abaixo.

Uma falha identificada em qualquer etapa deve ser corrigida antes de prosseguir.

=== Etapa 1 - Camada Física ===

Validar:

* Interface UP/UP.
* Potência óptica dentro dos limites.
* Ausência de CRC e erros físicos.
* Negociação correta da interface.

Comandos Huawei:

<pre>
display interface brief
display interface GigabitEthernet 0/0/0
</pre>

=== Etapa 2 - Conectividade IP ===

Validar:

* Endereçamento IP.
* Rotas presentes.
* Ping entre vizinhos diretos.

Comandos Huawei:

<pre>
display ip interface brief
display ip routing-table
ping X.X.X.X
</pre>

=== Etapa 3 - OSPF ===

Validar:

* Vizinhanças estabelecidas.
* Loopbacks anunciadas.
* Rotas presentes na tabela.

Comandos Huawei:

<pre>
display ospf peer
display ospf routing
display ip routing-table protocol ospf
</pre>

=== Etapa 4 - MPLS ===

Validar:

* MPLS habilitado nas interfaces.
* LSR-ID configurado.
* Tabela MPLS populada.

Comandos Huawei:

<pre>
display mpls interface
display mpls lsr-id
display mpls forwarding-table
</pre>

=== Etapa 5 - LDP ===

Validar:

* Sessões LDP estabelecidas.
* Troca de labels funcionando.

Comandos Huawei:

<pre>
display mpls ldp session
display mpls ldp peer
display mpls ldp lsp
</pre>

=== Etapa 6 - Targeted LDP ===

Validar:

* Sessões remotas estabelecidas.
* Remote Peer alcançável.

Comandos Huawei:

<pre>
display mpls ldp remote-peer
display mpls ldp session
</pre>

=== Etapa 7 - Serviço ===

Para L2VC:

<pre>
display mpls l2vc
</pre>

Para VSI:

<pre>
display vsi
display vsi verbose
</pre>

Validar:

* Estado UP.
* Labels aprendidas.
* Peer correto.

=== Etapa 8 - MTU ===

Validar:

* MTU física.
* MTU MPLS.
* MTU do serviço.

Executar testes com DF-bit sempre que houver suspeita de fragmentação.

=== Checklist Final ===

{| class="wikitable"
! Item
! Status
|-
| Interface Física
| OK / NOK
|-
| Conectividade IP
| OK / NOK
|-
| OSPF
| OK / NOK
|-
| MPLS
| OK / NOK
|-
| LDP
| OK / NOK
|-
| Targeted LDP
| OK / NOK
|-
| Serviço
| OK / NOK
|-
| MTU
| OK / NOK
|}

Arquivo:MPLS Diagramas BPF v1.png

2026-06-08T16:59:41Z

DanielTecnet:

Guia Operacional MPLS para ISPs

2026-06-08T16:50:59Z

DanielTecnet:

= Guia Operacional MPLS para ISPs =

Este guia tem como objetivo padronizar o troubleshooting MPLS em ambientes de provedores de Internet (ISPs), com foco principal em equipamentos Huawei, mas aplicável a ambientes multivendor.

== Objetivo e Público-Alvo ==

Este documento foi elaborado para auxiliar equipes NOC, N2, N3 e Engenharia na identificação, análise e correção de falhas relacionadas a MPLS.

=== Público-Alvo ===

* Analistas NOC/N1
* Analistas N2/N3
* Engenheiros de Redes
* Operadores de Backbone MPLS

=== Regra Fundamental ===

O troubleshooting MPLS deve seguir uma sequência lógica:

# Camada Física

# Conectividade IP

# OSPF

# MPLS

# LDP

# Serviço (L2VC/VSI)

# MTU

Uma falha em qualquer etapa anterior compromete as etapas seguintes.

== Como o MPLS Funciona na Prática ==

MPLS não deve ser tratado como uma tecnologia isolada. Em uma rede ISP, o MPLS depende inicialmente da conectividade IP e de um protocolo IGP, normalmente OSPF ou IS-IS.

O IGP garante o alcance entre as loopbacks dos roteadores. Em seguida, o LDP utiliza essa conectividade para distribuir labels. Somente após essas etapas os serviços L2VPN, como VPWS (L2VC) e VPLS (VSI), conseguem operar corretamente.

=== Resumo Prático ===

* OSPF encontra o caminho.
* LDP distribui as labels.
* MPLS encaminha usando labels.
* L2VC e VSI utilizam essa infraestrutura para transportar serviços Ethernet.

== Função dos Protocolos ==

=== OSPF ===

O OSPF é responsável por garantir a conectividade IP entre os roteadores do backbone. Em ambientes MPLS, normalmente são anunciadas as interfaces de transporte e as loopbacks utilizadas como Router-ID e LSR-ID.

Sem alcance IP entre as loopbacks dos roteadores, o MPLS e o LDP não conseguem estabelecer suas adjacências corretamente.

=== MPLS ===

O MPLS (Multiprotocol Label Switching) adiciona um rótulo (label) aos pacotes para permitir o encaminhamento baseado em labels ao invés de consultas sucessivas à tabela de roteamento IP.

Os principais serviços suportados incluem:

* L2VPN (VPWS/L2VC)
* VPLS (VSI)
* Engenharia de Tráfego
* VPNs de Camada 3

=== LDP ===

O LDP (Label Distribution Protocol) é responsável pela distribuição das labels entre os roteadores MPLS.

Após a conectividade IP ser estabelecida pelo OSPF, os roteadores formam vizinhanças LDP e trocam informações de labels para cada prefixo conhecido.

Caso o LDP apresente falhas, os serviços MPLS dependentes serão impactados.

=== Targeted LDP ===

O Targeted LDP (tLDP) permite estabelecer sessões LDP diretamente entre roteadores não adjacentes.

É amplamente utilizado em serviços VPWS (L2VC), onde os PEs precisam trocar informações de pseudowires através de sessões remotas.

A ausência ou falha do Targeted LDP normalmente resulta em serviços L2VC inoperantes, mesmo que o MPLS e o OSPF estejam funcionando corretamente.
== L2VC versus VSI ==

=== L2VC (VPWS) ===

O L2VC (Layer 2 Virtual Circuit), também conhecido como VPWS (Virtual Private Wire Service), cria uma conexão ponto a ponto entre dois equipamentos PE através da rede MPLS.

Características:

* Serviço ponto a ponto.
* Menor consumo de recursos.
* Simplicidade operacional.
* Amplamente utilizado para transporte de VLANs entre localidades.

Fluxo simplificado:

CE ---- PE ===== MPLS ===== PE ---- CE

=== VSI (VPLS) ===

A VSI (Virtual Switch Instance), utilizada em implementações VPLS, cria um domínio Ethernet multiponto sobre a rede MPLS.

Características:

* Serviço multiponto.
* Comportamento semelhante a um switch Ethernet.
* Permite múltiplos sites na mesma LAN virtual.
* Maior consumo de recursos em comparação ao L2VC.

Fluxo simplificado:

```
CE
|
PE
/ \
/ \
MPLS MPLS
/ \
PE -------- PE
| |
CE CE
```

=== Comparativo ===

{| class="wikitable"
! Característica
! L2VC / VPWS

| ! VSI / VPLS |
| ----------------------------------- |
| Topologia |
| Ponto a Ponto |
| Multiponto |
| - |
| Complexidade |
| Baixa |
| Média |
| - |
| Escalabilidade |
| Alta |
| Muito Alta |
| - |
| Consumo de Recursos |
| Menor |
| Maior |
| - |
| Caso de Uso |
| Transporte de VLAN |
| LAN estendida entre múltiplos sites |
| } |

=== Troubleshooting ===

Quando um L2VC ou VSI apresenta falhas:

# Validar interfaces físicas.

# Confirmar alcance IP entre as loopbacks.

# Verificar OSPF.

# Verificar MPLS.

# Verificar LDP.

# Verificar sessões Targeted LDP.

# Validar MTU ponta a ponta.

# Confirmar estado do serviço (VC ou VSI).

== MTU em Ambientes MPLS ==

=== Conceitos Fundamentais ===

Em redes MPLS, a MTU deve ser planejada considerando o overhead adicional introduzido pelas labels MPLS.

Cada label MPLS adiciona 4 bytes ao pacote.

Exemplos:

* 1 Label = +4 bytes
* 2 Labels = +8 bytes
* 3 Labels = +12 bytes

Dependendo da tecnologia utilizada (L2VC, VSI, QinQ, PPPoE, VXLAN, etc.), o overhead total pode aumentar significativamente.

=== Exemplo Prático ===

Uma rede Ethernet tradicional normalmente opera com MTU 1500 bytes.

Ao adicionar MPLS:

* Payload IP = 1500 bytes
* 2 Labels MPLS = +8 bytes
* Cabeçalho Ethernet = +18 bytes

O enlace precisa suportar uma MTU superior a 1500 bytes para evitar fragmentação ou descarte de pacotes.

=== Sintomas de Problemas de MTU ===

Problemas de MTU podem gerar sintomas como:

* L2VC sobe, mas não passa tráfego.
* VSI apresenta instabilidade.
* Aplicações específicas não funcionam.
* Sites abrem parcialmente.
* Perda de pacotes para tráfego maior.
* PPPoE conecta, mas navegação apresenta falhas.
* OSPF e BGP estabelecem normalmente, porém o tráfego de usuário apresenta problemas.

=== Validação de MTU ===

Uma das formas mais simples de validação é utilizar ping com DF-bit (Don't Fragment).

Exemplo:

<pre>
ping -f -s 1472 X.X.X.X
</pre>

ou em equipamentos Huawei:

<pre>
ping -a LoopBack0 X.X.X.X -f -s 1472
</pre>

O objetivo é identificar o maior tamanho de pacote que consegue atravessar toda a rede sem fragmentação.

=== Troubleshooting ===

Ao investigar problemas relacionados a MTU:

# Validar MTU física das interfaces.
# Verificar MTU do backbone MPLS.
# Confirmar MTU dos serviços L2VC ou VSI.
# Testar ping com DF-bit.
# Verificar QinQ e encapsulamentos adicionais.
# Confirmar configuração fim a fim.

=== Boas Práticas ===

* Padronizar MTU do backbone.
* Documentar MTU de serviços especiais.
* Validar MTU durante ativações.
* Incluir testes de MTU nos procedimentos operacionais.
* Considerar expansões futuras de encapsulamento.
== Procedimento de Troubleshooting MPLS ==

=== Fluxo de Validação ===

Sempre execute o troubleshooting seguindo a sequência abaixo.

Uma falha identificada em qualquer etapa deve ser corrigida antes de prosseguir.

=== Etapa 1 - Camada Física ===

Validar:

* Interface UP/UP.
* Potência óptica dentro dos limites.
* Ausência de CRC e erros físicos.
* Negociação correta da interface.

Comandos Huawei:

<pre>
display interface brief
display interface GigabitEthernet 0/0/0
</pre>

=== Etapa 2 - Conectividade IP ===

Validar:

* Endereçamento IP.
* Rotas presentes.
* Ping entre vizinhos diretos.

Comandos Huawei:

<pre>
display ip interface brief
display ip routing-table
ping X.X.X.X
</pre>

=== Etapa 3 - OSPF ===

Validar:

* Vizinhanças estabelecidas.
* Loopbacks anunciadas.
* Rotas presentes na tabela.

Comandos Huawei:

<pre>
display ospf peer
display ospf routing
display ip routing-table protocol ospf
</pre>

=== Etapa 4 - MPLS ===

Validar:

* MPLS habilitado nas interfaces.
* LSR-ID configurado.
* Tabela MPLS populada.

Comandos Huawei:

<pre>
display mpls interface
display mpls lsr-id
display mpls forwarding-table
</pre>

=== Etapa 5 - LDP ===

Validar:

* Sessões LDP estabelecidas.
* Troca de labels funcionando.

Comandos Huawei:

<pre>
display mpls ldp session
display mpls ldp peer
display mpls ldp lsp
</pre>

=== Etapa 6 - Targeted LDP ===

Validar:

* Sessões remotas estabelecidas.
* Remote Peer alcançável.

Comandos Huawei:

<pre>
display mpls ldp remote-peer
display mpls ldp session
</pre>

=== Etapa 7 - Serviço ===

Para L2VC:

<pre>
display mpls l2vc
</pre>

Para VSI:

<pre>
display vsi
display vsi verbose
</pre>

Validar:

* Estado UP.
* Labels aprendidas.
* Peer correto.

=== Etapa 8 - MTU ===

Validar:

* MTU física.
* MTU MPLS.
* MTU do serviço.

Executar testes com DF-bit sempre que houver suspeita de fragmentação.

=== Checklist Final ===

{| class="wikitable"
! Item
! Status
|-
| Interface Física
| OK / NOK
|-
| Conectividade IP
| OK / NOK
|-
| OSPF
| OK / NOK
|-
| MPLS
| OK / NOK
|-
| LDP
| OK / NOK
|-
| Targeted LDP
| OK / NOK
|-
| Serviço
| OK / NOK
|-
| MTU
| OK / NOK
|}

Guia Operacional MPLS para ISPs

2026-06-08T16:48:01Z

DanielTecnet:

Guia Operacional MPLS para ISPs

2026-06-08T16:45:58Z

DanielTecnet:

Guia Operacional MPLS para ISPs

2026-06-08T16:42:28Z

DanielTecnet:

Guia Operacional MPLS para ISPs

2026-06-08T16:33:06Z

DanielTecnet:

Guia Operacional MPLS para ISPs

2026-06-08T16:17:30Z

DanielTecnet: Criou página com '= Guia Operacional MPLS para ISPs = Este artigo está em construção. == Objetivo == Padronizar o troubleshooting MPLS em ambientes ISP utilizando equipamentos Huawei e am...'

= Guia Operacional MPLS para ISPs =

Este artigo está em construção.

== Objetivo ==

Padronizar o troubleshooting MPLS em ambientes ISP utilizando equipamentos Huawei e ambientes multivendor.

== Status ==

Artigo em desenvolvimento.

Arquivo:1724268070353.png

2025-04-17T16:57:30Z

DanielTecnet:

1724268070353

Arquivo:Ipoe .png

2025-04-17T16:43:57Z

DanielTecnet:

ipoe

Arquivo:Cabeçalho.png

2025-04-17T16:42:28Z

DanielTecnet:

cabeçalho protocolo