Trouver une MAC dans la base EVPN prouve qu'elle a été annoncée ou reçue comme route, et rien de plus. La table de transfert est une autre structure, programmée plus tard, si bien que la même MAC peut apparaître dans l'une et manquer dans l'autre alors que chaque protocole se comporte correctement. Traiter ces deux sorties comme des copies l'une de l'autre envoie les ingénieurs à la poursuite d'une panne BGP alors que l'écart réel est une politique d'importation ou un saut suivant non résolu. La question qui vaut la peine d'être posée n'est pas de savoir si le fabric connaît la MAC, mais à quelle étape elle a cessé d'être transmise.

Deux tables qui répondent à des questions différentes

Sur Junos EVPN, la base liste les adresses MAC par instance ainsi que la façon dont chacune est arrivée : apprise depuis un port d'accès, reçue dans une route Type 2 ou marquée comme faisant partie d'un groupe multihoming. La référence Juniper show evpn database couvre les filtres par MAC et par instance qui rendent la vue lisible. C'est un résumé du plan de contrôle indexé par instance et MAC, pas la table avec laquelle le matériel commute les trames.

La table de commutation est cet état de transfert. Les deux sorties listent des MAC à côté du contexte VLAN ou VNI, ce qui est exactement pourquoi elles sont comparées ligne par ligne, et exactement pourquoi la comparaison induit en erreur. Une entrée dans la base indique que la route existe et a été acceptée dans l'instance ; elle ne dit rien sur le fait que la plateforme l'ait installée pour le transfert.

Une route Type 2 transporte la MAC, une IP optionnelle, un label ou VNI, un distinguateur de route et un saut suivant nommant le VTEP distant. Quatre choses peuvent casser entre le câble et cette route : l'hôte n'est jamais appris, la route n'est jamais annoncée, elle est rejetée à l'importation, ou son saut suivant ne se résout pas. Chaque défaillance laisse un ensemble différent de tables remplies, et c'est pourquoi la séquence peut être diagnostiquée.

L'apprentissage local se produit toujours en premier

L'hypothèse courante est qu'EVPN prend en charge l'apprentissage des MAC, donc une base vide doit signifier un problème d'overlay. L'apprentissage local s'exécute toujours côté accès, exactement comme avant l'existence de VXLAN : le switch apprend la MAC source d'une trame autorisée dans le bon VLAN et le bon service, et ne crée qu'ensuite une Type 2 pour elle. Un hôte qui n'a envoyé aucune trame pertinente n'a rien à annoncer. Un hôte dont les trames sont écartées par l'appartenance au VLAN, un filtre ou un membre inactif d'un agrégat apparaît identique du point de vue de l'overlay.

Commencez au point d'attachement et progressez avec des commandes en lecture seule. L'objectif est de prouver qu'une trame de l'hôte a traversé le service prévu, car rien en aval ne compense une trame qui n'est jamais arrivée.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

Les membres LACP sélectionnés comptent plus que le fait que le bundle soit actif, car un agrégat peut être actif sur un membre alors que le trafic de l'hôte est haché vers un lien inactif ou bloqué. Les compteurs d'interface distinguent un hôte silencieux d'un hôte qui perd des trames, parce qu'un hôte qui n'émet jamais et un hôte dont les trames sont écartées par classification laissent la même table vide.

Où une MAC distante se perd

Une MAC distante échoue dans la direction opposée, et discrètement. La route Type 2 arrive, mais elle n'entre dans une instance que lorsque sa cible de route et son VNI correspondent à la configuration locale, et elle ne devient utilisable que lorsque le saut suivant se résout en un VTEP joignable. Un désaccord de cible de route laisse une route valide dans la table BGP qu'aucune instance ne demande.

Lisez les trois vues dans l'ordre : présence de la route, entrée de base, entrée de transfert. Les commandes ci-dessous interrogent la même MAC à chaque étape, et l'adresse d'exemple garde les sorties comparables.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

Ces sorties répondent à trois questions distinctes. Une route dans bgp.evpn.0 sans entrée de base pointe vers la politique d'importation, la cible de route ou la configuration d'instance. Une entrée de base sans entrée de transfert pointe vers la programmation de la plateforme, qui relève d'un autre chemin d'escalade. Une route active dont le saut suivant ne se résout pas est un problème de transport ou de label, et aucune quantité de débogage MAC ne la répare.

Un redémarrage qui l'a corrigé prouve très peu

Quand un redémarrage fait disparaître le symptôme, la conclusion tentante est que la configuration doit être saine. Un redémarrage reprogramme chaque table de zéro, si bien qu'il masque aussi le cas où une entrée obsolète occultait une erreur de politique ; la panne revient généralement au prochain changement, au flapping d'un lien ou au retrait d'une route.

Avant toute fenêtre de maintenance, capturez ce que le redémarrage effacera. Ces trois commandes suffisent à comparer avant et après, et elles ne changent rien sur l'équipement.

show evpn database instance blue
show route table bgp.evpn.0
show version

Archivez ces sorties avec la date et la version logicielle à côté. Un rapport ultérieur indiquant que le même redémarrage avait déjà fonctionné est une piste plutôt qu'une preuve, et la différence ne devient visible que si quelqu'un a conservé la sortie antérieure.

Quatre observations qui tranchent la plupart des cas

Quatre observations couvrent presque tous les cas : le point d'attachement et son service, la MAC comme valeur d'exemple, l'état de la route et de la base, et la version utilisée. Choisissez une MAC manifestement d'exemple pour que personne ne la confonde avec une adresse de production : un premier octet 02 marque une adresse unicast administrée localement, les octets restants sont libres, et 02:00:00:00:00:5c est donc un espace réservé sûr.

Laissez ensuite les réponses pointer vers l'étape qui a échoué. Aucun apprentissage au point d'attachement signifie le côté accès ; une route sans entrée de base signifie l'importation ; une entrée de base sans état de transfert signifie la programmation. Quoi qu'il en soit, remettez les sorties collectées avec l'hôte, l'interface, le service et la version, afin que l'ingénieur suivant puisse reproduire le chemin au lieu de répéter la requête.

Articles similaires