Route absente dans la VRF : locale, VPNv4 ou table de transfert ?

Un client signale qu’un préfixe a disparu après une modification de cible de route, et la première capture d’écran qu’il envoie est généralement la mauvaise table. Trois tables différentes répondent à trois questions différentes : le préfixe existe-t-il à l’intérieur de la VRF, a-t-il été annoncé et importé comme route VPNv4, et une entrée de transfert a-t-elle réellement été installée. Les lire dans le désordre produit des conclusions assurées et fausses. Ce runbook fait passer un préfixe local et un préfixe distant par les trois tables, dans l’ordre, et se termine par un plan de retour arrière pour la modification de RT qui l’a déclenché.

Nommez le préfixe et la table à laquelle il appartient

Notez deux préfixes avant de taper quoi que ce soit. L’un est local au site du client, appris d’une interface connectée ou d’une annonce CE. L’autre est distant et doit arriver par le backbone de l’opérateur. Ils empruntent des chemins différents vers la même VRF, et une panne sur l’un ne dit rien de l’autre.

Gardez claire la distinction entre les deux identifiants, car l’essentiel de la confusion dans ces tickets en vient. Le distinguateur de route fait partie du NLRI VPNv4 et existe pour rendre uniques dans le backbone des préfixes client qui seraient sinon identiques. La cible de route est une communauté étendue transportée comme attribut, et c’est sur elle que la politique d’import et d’export s’aligne. Ce n’est pas un second nom du distinguateur et elle n’est pas transportée dans les paquets du client.

Étape 1 : prouvez que le préfixe est dans la VRF

Commencez par la vue locale, puis par les RT qui gouvernent l’import. Si le préfixe local manque ici, rien en amont ne peut être en cause :

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

Un préfixe qui apparaît comme connecté ou statique est appris localement, et sa présence ne dit rien sur son exportation. C’est la mauvaise lecture la plus fréquente de ce flux de travail : une table VRF saine n’est qu’une preuve d’apprentissage local. Le côté export est une question distincte, à laquelle répondent la vue du voisin et la cible d’export associée.

Vérifiez les listes de RT sur la VRF pendant que vous y êtes. Si la cible d’import prévue n’est pas dans la liste, tout ce qui est en aval est sans objet. Si elle y est mais diffère de ce qu’exporte le PE distant, vous avez trouvé la panne sans ouvrir une seule capture de paquets.

Étape 2 : lisez la table VPNv4 et ses cibles

La table VPNv4 montre ce que le plan de contrôle a réellement échangé. Cherchez le préfixe distant sous le bon distinguateur, puis regardez les communautés qui lui sont attachées :

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

Une entrée avec la bonne cible de route mais sans installation locale renvoie à la politique d’import ou à la sélection de route, pas à la joignabilité. Une entrée qui n’apparaît jamais dans la table VPNv4 renvoie en amont : le PE d’origine ne l’a peut-être pas exportée, ou la session ne transporte pas la famille d’adresses.

Il existe un troisième cas qui déroute les gens pendant les changements. Certaines plateformes limitent les routes VPN qu’elles demandent ou conservent, à l’aide d’informations d’appartenance aux cibles de route, si bien que l’absence d’un NLRI distant dans une vue filtrée ne prouve pas que l’annonce n’existe nulle part. Vérifiez la table non filtrée et les routes annoncées du voisin avant de conclure qu’une route a été retirée globalement.

Étape 3 : confirmez que quelque chose a été installé et étiqueté

Une entrée BGP est une décision, pas un chemin. Les tables de transfert indiquent si les paquets ont où aller :

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

Une entrée CEF avec une adjacence résolue et une étiquette sortante signifie que le trafic du plan de données devrait fonctionner, et tout symptôme restant relève de l’application ou du filtrage à l’intérieur de la VRF. Une entrée CEF montrant un prochain saut non résolu signifie que le chemin d’étiquettes est incomplet alors que BGP paraît sain, et c’est exactement le cas où une capture de la table BGP a induit en erreur une revue de changement.

Comparez l’étiquette que le PE local impose avec celle que le PE distant s’attend à recevoir. Un écart entre les deux vues est un problème d’allocation d’étiquettes ou de session, et il ne sera pas corrigé en modifiant les cibles de route, quel que soit le nombre de fois où vous le faites.

Annulez la modification de RT avec une portée annoncée

Si la panne a commencé par une modification de cible de route, annulez-la comme une seule étape délibérée et dites quelle portée vous changez. Retirer une cible d’import retire l’éligibilité à l’intérieur de cette VRF. Cela ne supprime pas l’annonce VPNv4 du backbone, et sur certaines plateformes la route reste conservée dans la table. Ce sont des résultats différents et l’effet visible pour l’utilisateur dépend de celui que vous visez.

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

Une reconfiguration douce en entrée suffit lorsque la session stocke déjà les préfixes ; une réinitialisation dure d’une session tournée vers l’opérateur pendant les heures ouvrées est une décision que quelqu’un d’autre doit prendre. Sur Junos, les vérifications équivalentes lisent directement la table par VRF et la table VPN, et le retour arrière est un retour au commit plutôt qu’une annulation par commande, donc capturez le diff de configuration avant de commencer.

Terminez avec les trois mêmes commandes qu’au début, dans le même ordre, et consignez leur sortie avec un horodatage. Un ticket qui dit que le RT était faux et qu’il est maintenant correct n’est pas réutilisable ; celui qui montre le préfixe présent dans la VRF, présent dans VPNv4 et installé dans CEF est une preuve que la personne suivante peut comparer. Si seuls les deux premiers ont changé, vous n’avez pas terminé le changement.