Certaines routes L2VPN disparaissent après l’ajout de réflecteurs de routes

Les sessions restent actives, l’IGP est stable et pourtant une poignée de routes L2VPN n’apparaissent jamais sur deux des quatre extrémités du fournisseur. Ce schéma relève d’un problème de réflexion et non de transport, car une session cassée échoue entièrement tandis qu’une frontière de réflexion réutilisée échoue sélectivement. L’anneau physique n’y est pour rien ; le graphe logique de distribution est l’endroit où ces routes se sont arrêtées. Trouver ce point ne demande pas de reconstruire le plan de contrôle.

La perte est sélective, ce qui resserre la recherche

Quatre extrémités de fournisseur sur un anneau physique nécessitent six sessions logiques pour un maillage complet, puisque chaque routeur s’apparie aux trois autres. Ces sessions circulent sur le transport routé, donc le câblage ne dit rien du nombre d’adjacences ni de celles qui réfléchissent. Quand deux extrémités manquent un ensemble précis de préfixes alors que tout le reste converge, le câble n’est pas le suspect.

La perte sélective pointe vers la prévention des boucles, la politique ou le sens de la relation, où certaines routes franchissent une frontière et d’autres sont écartées en chemin. La perte totale pointe vers la session ou la famille d’adresses. Décider laquelle des deux vous regardez est la première étape utile, et elle ne demande qu’une commande.

Ce que la réflexion change réellement

La réflexion de routes assouplit la règle selon laquelle un locuteur iBGP ne peut pas réannoncer une route apprise d’un autre locuteur iBGP. RFC 4456 exprime l’exception par la relation entre le locuteur et la source de la route, et le sens de cette relation compte plus que ne le suggèrent la plupart des résumés. Une route apprise d’un client peut être réfléchie vers d’autres clients et vers des non-clients, tandis qu’une route apprise d’un non-client ne peut être réfléchie que vers des clients. Lisez l’asymétrie deux fois, car elle explique comment l’ajout d’une relation client peut masquer une erreur de conception : elle ouvre un chemin que la topologie n’avait jamais prévu.

L’attribut CLUSTER_LIST enregistre l’historique de réflexion, et un réflecteur qui trouve son propre identifiant de cluster dans cette liste doit ignorer l’annonce. C’est la prévention des boucles, et c’est aussi le mécanisme qui supprime des routes quand des identifiants sont réutilisés par accident. ORIGINATOR_ID joue un rôle apparenté en nommant le routeur qui a annoncé la route en premier.

Les identifiants de cluster réutilisés sont la façon dont les routes disparaissent

Un petit réseau invite à un raccourci : donnez à chaque routeur un identifiant de cluster égal à son loopback, ajoutez plus tard un autre réflecteur et réutilisez un loopback existant parce qu’il est commodément à portée de main. Si cet identifiant apparaît désormais à deux étages de réflexion indépendants, le second étage voit son propre identifiant dans CLUSTER_LIST et écarte la route. Rien ne journalise d’erreur, car écarter est la réponse correcte à une boucle.

Les réflecteurs redondants desservant un même cluster sont l’exception légitime : ils partagent un identifiant à dessein pour que l’un ou l’autre puisse desservir les mêmes clients. L’identifiant doit correspondre à la conception de la réflexion et non distinguer des noms de châssis.

Dessinez le graphe prévu avant de toucher à la moindre configuration : qui originine le préfixe, quelle relation client autorise la première réflexion, quel réflecteur le porte à l’étage suivant et où se trouve le dernier client. Chaque saut de ce graphe est un endroit où un identifiant réutilisé, une relation client manquante ou un filtre de politique peut arrêter la route. Une fois le graphe dessiné, une route manquante a un emplacement au lieu d’un mystère.

Résistez à la tentation de faire de chaque voisin un client

La réparation rapide d’une route manquante consiste à faire de chaque voisin un client de chaque réflecteur. La propagation revient et la conception cesse de vous dire quoi que ce soit : elle multiplie les routes que chaque locuteur porte tout en masquant quelle relation était censée faire le travail.

Un petit réseau a généralement besoin de l’une de deux formes. Un maillage iBGP complet représente six sessions pour quatre routeurs sans aucune réflexion, et une paire désignée de réflecteurs desservant les extrémités restantes est l’autre. Les deux se raisonnent plus facilement qu’un maillage partiel où chaque routeur réfléchit un peu. Choisissez la forme selon l’échelle et le comportement en cas de panne, pas selon le schéma de câblage.

Vérifiez la famille d’adresses avant d’accuser la réflexion

Une session TCP sur le port 179 prouve que les deux locuteurs peuvent se parler, et rien sur le fait que la famille d’adresses VPN ait échangé une seule route. Établissez l’état de la session, puis la famille, puis le préfixe individuel.

vtysh -c "show bgp summary"
vtysh -c "show bgp l2vpn evpn summary"
vtysh -c "show bgp l2vpn evpn"

Ces trois sorties séparent un problème d’adjacence d’un problème d’échange et d’un problème de préfixe manquant. Si la famille n’affiche aucun préfixe, inspectez l’état d’activation et la politique d’exportation du voisin avant de regarder la réflexion. Si des préfixes apparaissent sur une extrémité mais pas sur une autre, comparez la liste de clusters et l’originator côté réception, puis parcourez le graphe de la section précédente.

Gardez l’accessibilité du saut suivant et l’état de transfert hors de ce contrôle. Une route réfléchie avec un saut suivant inaccessible est présente et inutilisable, ce qui ressemble à une défaillance de réflexion tant que vous ne regardez pas la colonne du saut suivant. Résolvez le saut suivant, confirmez l’entrée de transfert, et seulement alors décidez si le graphe de distribution a besoin d’un autre réflecteur.