O mesmo /24 para dois clientes? O VPNv4 exige um RD e um rótulo

Dois inquilinos numeram a sua filial com o mesmo 10.50.0.0/24, e após uma alteração a rota de um deles desaparece do limite do fornecedor enquanto a do outro continua a funcionar. A simplificação por trás desse ticket costuma ser eliminar o diferenciador de rota (RD) porque «o rótulo já identifica o cliente». Não identifica. O RD e o rótulo respondem a duas perguntas diferentes, e a diferença só se torna visível quando os endereços sobrepostos a forçam.

Uma rota onde deveriam existir duas

O unicast IPv4 simples compara dois caminhos para o mesmo prefixo e instala o melhor. 10.50.0.0/24 do inquilino A e 10.50.0.0/24 do inquilino B são uma só chave, por isso um ganha e o outro sobrevive apenas como caminho de reserva. O protocolo fez o que lhe foi dito; pediu-se ao plano de controlo que guardasse duas rotas diferentes sob um único identificador.

O resultado parece uma rota em falta e não um erro: o PE que perdeu a competição continua a encaminhar o seu inquilino localmente, por isso um ping dentro do local tem sucesso e o teste entre locais falha. Conte as entradas desse prefixo na tabela VPNv4 antes de tocar em qualquer política.

O RD transforma uma chave em duas

Um diferenciador de rota de oito bytes é colocado à frente do prefixo IPv4, e o objeto que o BGP transporta passa a ser um endereço VPN-IPv4 em vez de um prefixo IPv4. Dois inquilinos podem manter os mesmos 32 bits porque os 64 bits à frente diferem. Existem tipos de formato para um RD baseado em AS e para um baseado em endereço, e a escolha pertence ao PE de origem. Um RD baseado em AS é comum quando os PE partilham um AS, e um baseado em endereço quando não partilham.

Não leia o RD como uma etiqueta de pertença. Os destinos de rota governam a importação e a exportação e decidem quais VRF podem instalar a rota; o RD garante apenas que a rota tem uma identidade própria. Dar a cada VRF o seu próprio RD é a prática comum porque mantém esse mapeamento legível num visualizador de rotas.

O rótulo é uma instrução de encaminhamento local

Cada anúncio também transporta um rótulo MPLS, e o seu significado fica limitado ao router que o atribuiu. Outro PE pode emitir o mesmo número para um destino sem relação. É precisamente por isso que o rótulo não pode substituir a identidade do cliente: o número só está correto ao lado do próximo salto e do estado de encaminhamento que o instalou.

A granularidade da atribuição varia com a implementação e o desenho: algumas plataformas atribuem um rótulo por VRF, outras por prefixo, e o rótulo pode identificar uma ação de encaminhamento em vez de um cliente. Dois rótulos diferentes que chegam ao mesmo destino não são uma contradição, e o mesmo número de rótulo em dois PE também não.

Por que um não pode substituir o outro

Ler um anúncio significa olhar para quatro coisas em conjunto: o prefixo qualificado pelo RD, os destinos de rota, o próximo salto e o rótulo. Ler um pacote de utilizador significa olhar para a pilha instalada a partir dessa informação. Um desenho saudável mostra os dois lados coincidentes, e um avariado tem normalmente um lado correto e o outro desatualizado. Essa comparação separa um problema de identidade de um problema de encaminhamento.

O contraste arrumado entre plano de controlo e plano de dados é um recurso didático, não uma descrição da codificação. RFC 8277 coloca o rótulo dentro do NLRI rotulado, pelo que o próprio anúncio transporta a ligação; usá-lo para encaminhar é o passo posterior e separado.

Quando falta uma rota de inquilino, verifique por esta ordem: duas entradas VPNv4 para o prefixo, o destino de rota correto em cada uma, um próximo salto resolúvel e um rótulo para o qual o PE recetor tenha estado. Corrigir a identidade com um valor de encaminhamento, ou o contrário, passará uma verificação e falhará a seguinte.