Le labo MPLS L3VPN ne répond pas au ping ? Vérifiez ces cinq sauts

Deux routeurs client, une paire de boîtiers provider edge et un ping qui meurt sans message d’erreur. Dans un petit labo MPLS L3VPN, la panne se situe presque toujours à l’un des cinq points de contrôle, et chacun dispose d’une commande qui montre soit que la dépendance fonctionne, soit qu’elle manque. L’erreur consiste à redémarrer BGP à chaque échec du ping au lieu de tester les dépendances dans l’ordre. Si vous foncez directement sur la configuration VRF, vous pouvez passer une heure sur un problème né d’un prochain saut non résolu deux équipements plus loin.

Traitez la liste par le bas. Un point de contrôle qui passe reste validé, et le premier échec est celui qui mérite le débogage.

Point de contrôle un : les PE se joignent entre eux

Chaque PE a besoin d’une route vers le loopback de l’autre PE, et cette route doit se résoudre via quelque chose de réel. Un interior gateway protocol est la voie habituelle, mais une route statique fonctionne aussi tant que la résolution récursive aboutit à une adjacency vivante. Sur les équipements de style IOS, show ip route 10.0.0.2 suivi de show ip cef 10.0.0.2 indique si le préfixe existe et si une adjacency résolue se trouve derrière. Une route présente dans la table sans adjacency derrière n’est pas de la joignabilité.

Vérifiez les deux sens. Des coûts IGP asymétriques, une passive interface du mauvais côté ou une distribute list qui filtre le loopback n’en cassent chacun qu’un seul, et un seul sens suffit à tuer la session. Si les loopbacks répondent au ping mais que la session BGP reste en Active, regardez la update source avant de toucher à autre chose.

Point de contrôle deux : un chemin de labels existe

Une route IP vers le loopback distant ne prouve pas que le transport posera un label. Dans une conception LDP, confirmez que le loopback distant dispose d’une liaison locale et d’une liaison distante, et que le label sortant figure dans la table de forwarding. show mpls ldp bindings 10.0.0.2 32 affiche les paires de labels, et show mpls forwarding-table 10.0.0.2 ce que la line card posera réellement. Quand la seconde commande n’affiche aucun label ou retombe sur IP, le transport ne transporte pas le trafic VPN comme la conception le suppose.

La distinction vient de la façon dont MPLS sépare l’état de forwarding des préfixes de destination, le modèle décrit dans la RFC 3031. Si votre labo utilise RSVP-TE ou des labels adjacents à BGP au lieu de LDP, vérifiez l’état propre à ce mécanisme ; supposer que LDP distribue chaque label de sous-couche est une façon courante de courir après un bug fantôme. Un chemin de labels cassé se manifeste plus tard en général par une route VPN présente mais inutilisable.

Point de contrôle trois : la route VPN est arrivée intacte

Regardez la route VPNv4 ou VPNv6 du préfixe client exact, pas le résumé de session. show bgp vpnv4 unicast all 10.10.1.0/24 doit afficher le route distinguisher, le next hop réglé sur le loopback du PE distant et un label. Si le préfixe manque, la politique d’export sur le PE d’origine ou la politique d’import sur le PE récepteur est le premier suspect, et les route targets sont le coupable habituel.

Lisez le contrôle de route target séparément de la réception BGP. Une route peut arriver avec le bon next hop et ne pas atterrir dans la VRF parce que l’import target ne correspond pas. Sur le PE récepteur, show ip route vrf CUSTOMER 10.10.1.0 est le test qui compte ; la table BGP prouve seulement que la route a traversé le plan de contrôle.

Point de contrôle quatre : l’interface est dans la VRF

Une définition VRF avec un route distinguisher et des route targets ne déplace aucune interface dedans. L’interface côté CE a besoin de l’affectation VRF, et show ip vrf interfaces ou show ip interface brief doit la lister sous la bonne instance. C’est le point de contrôle où une configuration copiée se trompe le plus souvent, parce que le bloc VRF paraît complet alors que l’interface reste dans la table globale.

Confirmez ensuite que le PE a appris le préfixe client local dans cette VRF, et que le CE a une route de retour via le raccordement. Une default statique sur le CE pointant vers le PE suffit pour un labo, à condition que la VRF du PE ait une route vers le LAN du CE. Si l’une des deux moitiés manque, le ping échoue avant qu’un label soit posé.

Point de contrôle cinq : la réponse retrouve son chemin

Tracez le paquet aller puis le paquet retour, car ils utilisent des tables différentes. Sur le PE d’entrée, la source client doit se résoudre dans la VRF vers le préfixe distant avec le label distant. Sur le PE de sortie, la destination doit se résoudre dans la même VRF vers l’interface côté CE. Un ping émis depuis le PE lui-même n’est pas une preuve : il peut sortir par la table globale ou par une autre adresse source, et c’est pourquoi ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 est le test à lancer.

Les pare-feu des hôtes, le reverse-path filtering et les listes d’accès du CE s’appliquent toujours. Si le chemin aller fonctionne et que la réponse meurt, le problème est une route ou un filtre côté retour, pas le transport MPLS.

Tenez une ligne par point de contrôle nommant la première dépendance en échec. Cette ligne transforme la plainte du client qui ne peut pas pinguer en une question précise sur la joignabilité, l’état des labels, l’import de route, l’appartenance de l’interface ou le chemin de retour, et elle évite à la session de débogage suivante de répéter les mêmes cinq commandes dans le même ordre.