Pourquoi un seul tenant EVPN peut afficher plusieurs route distinguishers
Deux RD dans un même tenant ne sont pas un conflit. Remontez de la sortie CLI au MAC-VRF ou à l'IP-VRF qui a créé la route, puis vérifiez l'import RT et le VNI.
Vous filtrez la table EVPN pour un seul tenant, et les routes portent deux route distinguishers différents. Le premier réflexe est un conflit de configuration, et ce réflexe est généralement faux. Le nom d'un tenant est une étiquette métier, pas un objet unique du plan de contrôle, donc le contexte de pontage et le contexte de routage qu'il contient peuvent légitimement s'annoncer sous des identifiants distincts. Remontez une route à la fois de la sortie jusqu'à l'objet de service local qui l'a créée, et le second RD cesse de ressembler à une erreur.
Partez de la sortie qui vous a dérouté
Choisissez une route plutôt que la table entière. Notez son type de route, son RD, ses route targets exportés et le prochain saut. Ces quatre champs suffisent à identifier quel objet local l'a annoncée et quelle politique distante devrait l'importer.
Sur un équipement de style NX-OS, la vue détaillée s'obtient avec show bgp l2vpn evpn route-type 2 detail ou show bgp l2vpn evpn route-type 5 detail. Sur Junos, les mêmes informations se trouvent dans show route table bgp.evpn.0 detail. Syntaxe différente, mêmes champs.
Ne commencez pas par rendre égaux tous les nombres affichés. Égaliser les RD est la modification qui casse la politique d'import sur une fabric qui fonctionne.
Donnez à chaque identifiant son rôle
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
Un MAC-VRF contient les informations de réexpédition MAC d'un service de pontage. Un IP-VRF fournit un contexte de routage IP pour un service routé. Un tenant peut inclure les deux, c'est pourquoi un seul tenant peut produire plus d'un RD sans aucune erreur de configuration.
La RFC 7432 attribue le RD du MAC-VRF annonceur à son EVPN NLRI et exige des RD distincts entre les MAC-VRF d'un même PE. Les procédures route-target sont distinctes : elles autorisent un ou plusieurs attributs RT et s'appuient sur la politique d'import pour l'appartenance. L'égalité des RD n'est pas ce qui crée une appartenance partagée, et la traiter ainsi est à la racine de cette confusion.
Remontez une route de l'annonce à l'import
Suivez la route dans un sens. Confirmez le type de route, le service d'origine, le RD, les RT exportés, puis la politique d'import sur le PE qui la reçoit. Chaque étape répond à une question différente, et une défaillance à n'importe quelle étape ressemble au même préfixe manquant de l'autre côté.
Une fois la route présente, inspectez le contexte de réexpédition installé et le mappage du VNI. Un VNI identique aux deux extrémités démontre que le plan de données est d'accord ; cela ne démontre pas que le plan de contrôle a importé la route via la politique prévue.
Si la route apparaît sur le PE distant mais qu'aucun trafic ne circule, le problème a dépassé EVPN. Vérifiez la liaison VNI-vers-VLAN ou VNI-vers-VRF et le chemin d'underlay avant de modifier à nouveau des route targets. Commencez par le mappage, puis l'underlay, et seulement ensuite le plan de contrôle. Revenir sur un changement de route-target pour poursuivre une panne du plan de données est un moyen fiable de casser un import qui fonctionne.
Les préfixes de couche 3 restent des routes EVPN
Un préfixe IP dans la table EVPN n'est pas du BGP IPv4-unicast ordinaire. La route EVPN IP Prefix est un type de route à part entière, et les annonces MAC/IP et de préfixe IP circulent dans la famille d'adresses EVPN, que la RFC 7432 identifie comme AFI 25 et SAFI 70.
Cette distinction compte lorsque vous comparez une route de la table EVPN avec une de la table unicast. Elles peuvent décrire la même destination et être malgré tout produites, filtrées et importées par des politiques différentes. Lire l'une comme une preuve de l'autre, c'est ainsi qu'une fabric correcte paraît cassée pendant une migration.
Vérifiez la dérivation du constructeur avant de comparer des nombres
La RFC 9136 étend EVPN avec les routes IP Prefix et précise si le RD applicable provient du contexte MAC-VRF ou IP-VRF. C'est pourquoi une étiquette de service L2 et une étiquette de service routé dans la même sortie doivent être lues par rapport aux objets auxquels elles appartiennent, et non réduites à un seul RD par tenant.
La dérivation automatique des RD et RT dépend du constructeur. Lisez la référence du constructeur déployé pour la formule utilisée ; une valeur générée automatiquement vue sur un seul commutateur n'est pas un codage universel, et comparer les nombres de deux constructeurs prouve rarement quoi que ce soit.
Terminez par une trace écrite pour la route avec laquelle vous avez commencé : type, objet d'origine, RD, RT exporté, politique d'import, VNI installé. Six champs expliquent l'annonce à quiconque lira le ticket ensuite, et aucun d'eux n'exige que les nombres du tenant concordent.