O VPNv4 precisa de MPLS no núcleo? Não necessariamente

Ativar a família de endereços VPNv4 entre dois routers cria apenas um contexto de distribuição de rotas e nada mais. Não instala um caminho de encaminhamento nem diz qual encapsulação levará um pacote de cliente até o ponto final remoto. Uma vez separados esses dois factos, a pergunta «isto precisa de MPLS no núcleo» torna-se mais estreita e respondível, sobre o plano de dados suportado pela plataforma.

O que a família de endereços realmente negocia

O BGP multiprotocolo transporta as informações de alcançabilidade da camada de rede VPNv4 sob AFI 1 e SAFI 128, e cada entrada emparelha um distinguidor de rota com um prefixo e uma etiqueta. A sessão negocia que ambos os interlocutores conseguem codificar e descodificar essas informações. O que não negocia é um plano de dados. Tudo depois deste parágrafo diz respeito ao encaminhamento, e nada disso fica decidido pelo estabelecimento da sessão.

Assim, uma sessão bem-sucedida é prova da capacidade do plano de controlo, não do encaminhamento. Um router pode manter milhares de entradas VPNv4 e ainda assim descartar cada pacote de cliente, e é por isso que as duas classes de falha se confundem desde o início.

Repare na etiqueta no NLRI. É uma etiqueta de serviço, ligada a um prefixo dentro de uma VRF, e tem um papel de encaminhamento quando o pacote chega ao ponto final de saída. Se algum dispositivo de trânsito a lê é uma decisão de projeto separada.

Receção, importação e encaminhamento são três passos

Receber uma rota, ter permissão para a usar e poder encaminhar com ela são tarefas de partes diferentes do equipamento. O BGP armazena o que ouve; a política de importação e a correspondência do alvo de rota decidem qual VRF a pode considerar; depois o plano de encaminhamento tem de resolver o próximo salto anunciado em algo que consiga realmente colocar num cabo.

É neste passo intermédio que vivem as falhas mais surpreendentes. Uma rota pode estar presente na tabela BGP, ser válida e até a melhor, enquanto a tabela de rotas da VRF fica vazia porque nenhum alvo de rota correspondeu à lista de importação. Nada registra um erro de protocolo, porque não ocorreu nenhum erro de protocolo.

O último passo é onde o suporte da plataforma se manifesta. Um próximo salto alcançável na camada inferior não é automaticamente resolúvel como transporte de serviço VPN, e o equipamento pode exigir um tipo de túnel específico, uma operação de etiqueta específica ou ambas. Ler o estado de resolução é mais informativo do que ler o número de rotas.

Um núcleo IP pode transportar uma pilha que nunca comuta

A distinção que vale a pena conservar é entre «o núcleo não executa MPLS» e «não existe nenhuma etiqueta em qualquer ponto do serviço». São afirmações diferentes, e só a primeira diz respeito a dispositivos de trânsito. O RFC 4023 define o transporte de MPLS por túneis IP ou GRE, e é esse o mecanismo que torna a segunda afirmação possível num núcleo totalmente IP.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

Os routers de trânsito encaminham pelo destino IP exterior e não precisam dos prefixos dos clientes nem da comutação de etiquetas nativa. Na extremidade remota, o túnel exterior é removido e a etiqueta de serviço retoma o seu trabalho. O núcleo moveu uma carga opaca, que é exatamente para o que uma rede IP serve.

O que este projeto não lhe dá é uma garantia universal. Não é prova de que cada router resolve cada próximo salto VPNv4 através de qualquer interface GRE, nem é motivo para apagar uma configuração MPLS nativa que funciona. É um contraexemplo à afirmação universal, e a questão prática permanece local à plataforma. Registe essa questão como uma limitação da plataforma e não como uma regra do protocolo.

Percorra a cadeia no equipamento até ela quebrar

Comece pela rota recebida e pare no primeiro passo que falhar, porque os passos seguintes não podem ser diagnosticados enquanto um anterior está quebrado. Quatro comandos cobrem a maior parte disso numa implementação típica.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

Leia-os como uma sequência e não como quatro verificações independentes. O primeiro confirma que a família está ativa e que o par troca rotas; o segundo mostra se o prefixo chegou com um próximo salto utilizável; o terceiro prova a elegibilidade para importação; o quarto mostra se o plano de encaminhamento lhe ligou uma etiqueta ou um túnel.

Depois teste o caminho da carga de trabalho nos dois sentidos, com uma MTU que sobreviva à encapsulação. O GRE acrescenta bytes de cabeçalho, e um caminho que passa sondas pequenas pode falhar em pacotes de tamanho completo apenas num sentido, o que parece uma falha de aplicação e não de transporte.

Duas notas operacionais fecham o ciclo. O GRE é encapsulação, não confidencialidade, por isso uma rede de trânsito não fidedigna precisa de uma disposição de segurança suportada por cima e não de uma suposição. E registe qual encapsulação a plataforma suporta realmente antes da revisão de projeto, porque essa única resposta decide se um núcleo só IP é uma opção válida ou um plano que não consegue encaminhar.