RD contra RT numa VPN MPLS: unicidade contra política de importação

Dois sites de cliente podem anunciar 10.20.0.0/24 e ambos continuam válidos dentro de uma única rede do provedor. O route distinguisher mantém esses anúncios separados; o route target decide qual VRF do cliente pode pegar uma cópia. Eles aparecem lado a lado na configuração e fazem trabalhos completamente diferentes. Confundi-los leva a mudanças que parecem razoáveis e não corrigem nada.

Siga uma rota da borda do cliente até uma VRF remota e a divisão fica concreta: a identidade é anexada antes de a rota entrar no BGP, e a política de distribuição é avaliada quando a rota chega à borda do provedor que a recebe.

Uma rota VPN-IPv4 é um RD mais um prefixo IPv4

A RFC 4364 define a família de endereços VPN-IPv4 como um route distinguisher de oito bytes seguido de um endereço IPv4 de quatro bytes. O RD é colocado à frente do prefixo do cliente, de modo que dois prefixos idênticos de sites diferentes se tornam duas rotas BGP diferentes.

Essa construção é todo o mecanismo de unicidade. O provedor não precisa que os clientes concordem com um espaço de endereços sem sobreposição, e uma rota de um site não pode substituir silenciosamente um prefixo idêntico de outro site.

O próprio formato do RD é um valor escolhido pelo administrador, normalmente um número de sistema autónomo e um número local. A sua forma numérica é uma convenção, não um sinal de que os dois campos partilham significado com um route target que por acaso usa os mesmos dígitos.

O RD torna distinguíveis os prefixos sobrepostos

Considere dois anúncios para o mesmo prefixo. O site A carrega o RD 65000:101 e o site B carrega o RD 65000:202, ambos para 10.20.0.0/24. O BGP passa a ter duas rotas VPN-IPv4 que podem ser comparadas, filtradas e selecionadas de forma independente.

O RD não diz qual VRF deve receber qualquer uma das rotas, nem identifica um cliente ou um serviço. É um campo de identidade da rota, não uma lista de associação. O RD de uma VRF não precisa de coincidir com o RD de uma rota que ela importa.

Por isso mudar um RD para coincidir com o número de outro site não corrige nada. Se falta uma rota do outro lado, fazer coincidir os dígitos cria um problema de identidade diferente em vez de reparar a decisão de importação.

O RT é um atributo BGP, não uma etiqueta do pacote

Uma política de exportação anexa um ou mais route targets à rota como atributos de comunidade estendida do BGP. A borda do provedor que recebe compara esses atributos com a política de importação de cada VRF. O RT viaja com a rota pelo plano de controlo. A comparação acontece inteiramente na política de encaminhamento, antes de qualquer pacote do cliente ser reencaminhado.

Os pacotes de dados do cliente não transportam o RT. Uma vez instalada a rota numa VRF, o reencaminhamento usa a tabela dessa VRF e a pilha de etiquetas MPLS que a arquitetura atribui. A borda do provedor não lê um route target de cada pacote do cliente.

Uma rota pode transportar vários RT, e uma VRF pode importar vários. A configuração costuma parecer um bloco curto:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

Leia esse bloco como duas instruções separadas. A linha de exportação controla o que é anexado às rotas que saem desta VRF; a linha de importação controla o que esta VRF está disposta a considerar. Números coincidentes são cómodos, não obrigatórios.

A elegibilidade de importação não é instalação

Uma rota pode ser elegível para uma VRF e ainda assim não aparecer na sua tabela de reencaminhamento. A elegibilidade é um filtro; depois o processo normal de decisão do BGP compara as rotas elegíveis e seleciona uma. Uma rota mais antiga ou menos preferida pode perder para outro caminho elegível.

Verifique a rota selecionada, não apenas a política de importação. Uma VRF que importa o RT 65000:500 e não mostra qualquer rota para 10.20.0.0/24 pode ter recebido a rota e rejeitado na seleção, ou pode nunca a ter recebido.

Esta distinção também importa quando aparece um prefixo inesperado. Uma política de importação demasiado ampla pode atrair rotas que o site não pretendia usar, e a unicidade do RD não o impede de forma alguma. O alcance da distribuição é uma questão de política de RT.

Depure uma rota em falta pela ordem do plano de controlo

Comece pelo anúncio: a VRF de origem exporta o RT pretendido e a rota existe como rota VPN-IPv4 no refletor de rotas ou no PE que recebe? Depois verifique o atributo tal como foi recebido, não como está configurado no emissor.

A seguir compare a lista de importação da VRF recetora com os valores reais de RT da rota. Por fim inspecione a rota selecionada nessa VRF e a ligação da etiqueta. Cada passo responde a uma pergunta diferente, e saltar para o RD normalmente omite o passo que está errado.

Registe o RD, o RT exportado, o RT importado e o próximo salto selecionado para o site que funciona e o que falha. Quatro valores lado a lado transformam um vago «a VPN não passa rotas» no passo exato do plano de controlo que difere.