Rota em falta na VRF: local, VPNv4 ou tabela de encaminhamento?

Um cliente diz que um prefixo desapareceu após uma alteração do alvo de rota, e a primeira captura de ecrã que envia é habitualmente a tabela errada. Três tabelas diferentes respondem a três perguntas diferentes: se o prefixo existe dentro da VRF, se foi anunciado e importado como rota VPNv4, e se foi realmente instalada uma entrada de encaminhamento. Lê-las fora de ordem produz conclusões seguras e erradas. Este manual leva um prefixo local e um remoto pelas três tabelas, por ordem, e termina com um plano de reversão para a alteração de RT que o começou.

Nomeie o prefixo e a tabela a que pertence

Anote dois prefixos antes de escrever seja o que for. Um é local no site do cliente, aprendido de uma interface ligada ou de um anúncio CE. O outro é remoto e espera-se que chegue pela espinha dorsal do operador. Seguem caminhos diferentes para a mesma VRF, e uma falha num não diz nada sobre o outro.

Mantenha clara a distinção entre os dois identificadores, porque é daí que vem a maior parte da confusão nestes tickets. O distinguidor de rota faz parte do NLRI VPNv4 e existe para tornar únicos na espinha dorsal prefixos de cliente que de outro modo seriam idênticos. O alvo de rota é uma comunidade estendida transportada como atributo, e é com ele que a política de importação e exportação coincide. Não é um segundo nome do distinguidor e não é transportado nos pacotes do cliente.

Passo 1: prove que o prefixo está na VRF

Comece pela vista local e depois pelos RT que governam a importação. Se o prefixo local falta aqui, nada a montante pode ser a causa:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

Um prefixo que aparece como ligado ou estático está aprendido localmente, e a sua presença não diz nada sobre se foi exportado. É a leitura errada mais comum neste fluxo de trabalho: uma tabela de VRF saudável é apenas prova de aprendizagem local. O lado da exportação é uma pergunta separada, respondida pela vista do vizinho e pelo alvo de exportação associado.

Verifique as listas de RT na VRF enquanto está aqui. Se o alvo de importação previsto não estiver na lista, tudo o que está a jusante é irrelevante. Se estiver mas diferir do que o PE remoto exporta, encontrou a falha sem abrir uma única captura de pacotes.

Passo 2: leia a tabela VPNv4 e os seus alvos

A tabela VPNv4 mostra o que o plano de controlo trocou realmente. Procure o prefixo remoto sob o distinguidor correto e depois veja as comunidades que lhe estão associadas:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

Uma entrada com o alvo de rota correto mas sem instalação local aponta para a política de importação ou para a seleção de rota, não para a alcançabilidade. Uma entrada que nunca aparece na tabela VPNv4 aponta para montante: talvez o PE de origem não a tenha exportado, ou a sessão não transporta a família de endereços.

Há um terceiro caso que desorienta as pessoas durante as alterações. Algumas plataformas limitam quais as rotas VPN que pedem ou retêm, usando informação de pertença a alvos de rota, pelo que a ausência de uma NLRI remota numa vista filtrada não é prova de que o anúncio não exista em lado nenhum. Verifique a tabela sem filtro e as rotas anunciadas do vizinho antes de concluir que uma rota foi retirada globalmente.

Passo 3: confirme que algo foi instalado e etiquetado

Uma entrada BGP é uma decisão, não um caminho. As tabelas de encaminhamento dizem se os pacotes têm para onde ir:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

Uma entrada CEF com adjacência resolvida e uma etiqueta de saída significa que o tráfego do plano de dados deve funcionar, e qualquer sintoma restante pertence à aplicação ou à filtragem dentro da VRF. Uma entrada CEF que mostra um próximo salto não resolvido significa que o caminho da etiqueta está incompleto mesmo que o BGP pareça saudável, e é exatamente o caso em que uma captura da tabela BGP induziu em erro uma revisão de alteração.

Compare a etiqueta que o PE local impõe com a que o PE remoto espera receber. Uma divergência entre as duas vistas é um problema de atribuição de etiquetas ou de sessão, e não será corrigida editando alvos de rota, por muitas vezes que o faça.

Reverta a alteração de RT com um âmbito declarado

Se a falha começou com uma edição do alvo de rota, desfaça-a como um único passo deliberado e diga que âmbito está a mudar. Remover um alvo de importação retira a elegibilidade dentro dessa VRF. Não apaga o anúncio VPNv4 da espinha dorsal, e em algumas plataformas a rota fica retida na tabela. São resultados diferentes e o efeito visível para o utilizador depende de qual dos dois quer dizer.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

Uma reconfiguração suave de entrada chega quando a sessão já armazena os prefixos; um reinício forçado de uma sessão virada para o operador em horário laboral é uma decisão que outra pessoa deve tomar. No Junos as verificações equivalentes leem diretamente a tabela por VRF e a tabela VPN, e a reversão é um regresso no commit e não um desfazer por comando, por isso capture a diferença de configuração antes de começar.

Termine com os mesmos três comandos com que começou, na mesma ordem, e registe a saída com um carimbo temporal. Um ticket que diz que a RT estava errada e que agora está certa não é reutilizável; um que mostra o prefixo presente na VRF, presente em VPNv4 e instalado em CEF é prova com que a pessoa seguinte pode comparar. Se só os dois primeiros mudaram, não terminou a alteração.