Le tunnel RSVP-TE est opérationnel, mais le L3VPN client n’a aucun chemin

Deux équipes peuvent avoir raison en même temps lorsque le client signale que le VPN est hors service et que l’équipe transport signale que le tunnel est en bon état. Un LSP issu de l’ingénierie de trafic et un MPLS L3VPN répondent à des questions différentes : l’un déplace des paquets étiquetés à travers le cœur, l’autre décide à quel contexte de routage un paquet appartient. Quand on les confond, le débat tourne en rond car chaque partie mesure un objet différent et les deux mesures sont valables.

Transport opérationnel et service hors service est un état normal

Un LSP peut être établi, transporter du trafic et être visible dans tous les systèmes de supervision, tandis que le service client reste inutilisable. Rien dans cette combinaison n’est contradictoire, car le tunnel n’a pas d’avis sur l’existence d’un préfixe distant, sur son acceptation par une politique d’importation ou sur le passage des trames par le circuit de rattachement.

Le symptôme qui révèle généralement la confusion est asymétrique : les pings depuis le loopback du PE réussissent alors qu’un hôte du LAN client ne reçoit rien, ou l’inverse. Notez quelles adresses ont fonctionné avant de former une théorie. Dès que vous remarquez que vous testez deux objets différents, l’étape suivante consiste à lire la pile d’étiquettes plutôt qu’à discuter du graphe correct. Deux adresses, deux propriétaires et généralement deux personnes différentes qui chacune croit que l’autre a cassé quelque chose.

Lisez la pile comme deux responsabilités

L’étiquette du bas appartient au service et l’étiquette du haut appartient au chemin. Le RFC 4364 décrit la séquence simplement : l’étiquette de route VPN est d’abord imposée, puis ce paquet étiqueté est tunnélisé vers le prochain saut BGP, où un tunnel d’ingénierie de trafic pousse sa propre étiquette par-dessus.

Au PE distant, l’étiquette de service sélectionne le traitement, qui peut être une recherche VRF ou une décision de rattachement. Cette étiquette ne peut pas être remplacée par une étiquette qui ne fait que traverser le cœur, et les deux ne sont pas interchangeables même lorsqu’elles apparaissent dans la même pile sur la même interface.

Ce que prouve le succès de RSVP et ce qu’il ne prouve pas

RSVP-TE établit des LSP à routage explicite, avec ou sans réservation de ressources, ce qui constitue une garantie précise et utile sur le chemin emprunté par un paquet à travers le cœur. Ce n’est pas une affirmation sur les routes client, et un nom de tunnel configuré n’est pas du tout une route.

La présence de RSVP ne fournit pas non plus de promesse de performance de bout en bout. Une réservation de bande passante sur un LSP ne dit rien du circuit de rattachement, de la ligne d’accès du client ni du comportement de file d’attente à l’extrémité distante. La traiter comme une garantie produit des réponses assurées à des questions que personne n’a posées. Si l’exigence est réellement un engagement de bande passante, elle doit être assemblée à partir des éléments qui en imposent réellement un, et le LSP n’est que le milieu de cette chaîne.

Vérifiez dans l’ordre, puis arrêtez-vous

Travaillez du transport vers l’extérieur et arrêtez-vous à la première étape qui échoue, car chaque étape suivante suppose que les précédentes ont tenu. Confirmez d’abord que le LSP est établi et que l’entrée de transfert du préfixe de service pointe réellement vers lui. Confirmez ensuite que la route VPN existe dans la bonne table, que son binding d’étiquette est présent et que la politique d’importation l’a acceptée. Confirmez ensuite le rattachement : l’interface, l’encapsulation et, le cas échéant, l’identifiant VLAN qui appartient à ce contrat.

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

La syntaxe des commandes varie selon la plateforme, donc traitez ces quatre lignes comme les quatre questions plutôt que comme un script. L’important est que chacune interroge un objet différent, et c’est ce qui fait qu’une panne désigne un propriétaire précis.

Suivez une requête autorisée et conservez les bonnes preuves

Terminez par une seule requête client réelle, autorisée par la politique, et sa réponse. Un flux fonctionnel de bout en bout tranche plus qu’une page de relevés de compteurs, et il exerce la combinaison plutôt que chaque pièce isolément.

Lorsqu’une étape ultérieure échoue, conservez l’observation réussie du LSP au lieu de reconstruire le transport. Reconstruire un tunnel qui fonctionne ne peut pas réparer un préfixe distant absent, un rattachement VRF erroné ou une règle d’accès de destination, et cela détruit la preuve qui vous avait d’abord dit que le transport était sain.