Un hôte EVPN silencieux ne se résout jamais : suivez l'ARP jusqu'à la liaison

Le point de terminaison est attaché, son port est actif, et l'hôte de supervision ne peut toujours pas l'atteindre. Quelqu'un lance un ping depuis l'autre côté et cela se met à fonctionner, ce qui fait paraître le problème intermittent et la fabric innocente. Ce schéma est la signature d'un hôte silencieux : il émet rarement, donc le comportement de découverte et de rafraîchissement de la fabric compte plus que l'état de son attachement. Commencez par une IP, une MAC et un bridge domain visés et suivez le prochain échange de résolution.

Suivez le prochain échange ARP ou ND

Pour IPv4, observez l'échange ARP de l'hôte demandeur ; pour IPv6, suivez le Neighbor Solicitation et l'Advertisement. Confirmez que la demande entre dans le segment local visé et dans le VNI visé, car aucun proxy ne peut répondre à une demande qui n'atteint jamais le bon bridge domain.

Regardez ensuite ce que la fabric sait de la cible. Une route MAC seule peut identifier une destination Layer 2 alors que le proxy n'a toujours aucune liaison IP-to-MAC pour elle. Ce sont des enregistrements distincts, et vérifier l'un ne dit rien de l'autre.

Si une liaison valide existe, le proxy peut répondre selon sa politique, mais la MAC de cette liaison a toujours besoin d'un chemin de transfert actif. Si la liaison est absente, la demande doit atteindre l'attachement du point de terminaison par le chemin de flooding ou de réplication avant que quoi que ce soit puisse apprendre de la réponse.

Deux enregistrements qui doivent concorder

La route MAC répond à l'endroit où vit l'adresse Ethernet. La table du proxy répond à quelle IP correspond à quelle MAC. Un hôte qui n'a pas parlé récemment peut avoir une route MAC parfaitement bonne et aucune entrée de proxy utilisable, et c'est exactement l'état qui produit un échec de résolution sur un attachement sain.

À l'attachement distant, vérifiez si le point de terminaison reçoit réellement l'échange et y répond. Sa réponse rafraîchit l'apprentissage local et l'annonce EVPN correspondante, ce qui explique pourquoi le ping manuel semble arranger les choses : vous avez généré le trafic que la fabric attendait. Cela explique aussi pourquoi le correctif ne dure pas : une fois l'entrée rafraîchie vieillie, le point de terminaison redevient silencieux. Un ping planifié traite le symptôme et masque la lacune de conception.

Après la réponse, suivez la route sélectionnée et l'état de transfert installé en revenant vers le demandeur. La réussite de la résolution et celle du transfert sont deux événements distincts, et un ticket qui les confond vous envoie à la mauvaise couche.

Ce que la norme suppose réellement

RFC 9161 décrit l'apprentissage dynamique du proxy et le flooding par défaut des demandes ARP et ND inconnues. La suppression complète de ce flooding est limitée aux déploiements dont les hypothèses d'apprentissage ou de provisionnement la rendent sûre, ce qui est une condition plus étroite que ne le laissent entendre la plupart des guides de configuration.

Une fabric qui attend des points de terminaison récemment découverts a besoin d'un chemin fonctionnel pour ces demandes. Si quelqu'un a désactivé le flooding des demandes inconnues pour réduire le trafic BUM, les hôtes silencieux sont la population qui en paie le prix, et le symptôme arrive des semaines plus tard sous forme de plainte de joignabilité intermittente.

Lisez le réglage de suppression comme une déclaration sur ce que la fabric promet de savoir. Si rien ne provisionne les liaisons, la promesse n'est pas vraie pour les émetteurs peu fréquents. Comparez la suppression configurée au système de provisionnement censé l'alimenter. Quand ces deux-là ne concordent pas, la fabric se comporte exactement comme configuré et c'est l'attente qu'il faut corriger.

Rafraîchissement, vieillissement et l'alternative statique

La norme décrit des sondes de rafraîchissement prises en charge avant que les entrées dynamiques ne vieillissent. Les réponses rafraîchissent l'état pertinent du bridge et du proxy ; l'absence de réponses peut légitimement conduire au retrait et au rappel de la route. Ce n'est pas un défaut à supprimer en étirant chaque minuteur.

Prolonger indéfiniment les minuteurs de vieillissement échange une panne visible contre une panne obsolète : la fabric continue d'annoncer un emplacement que l'hôte a quitté. Utilisez les contrôles documentés de l'implémentation et choisissez une durée de vie qui correspond à la fréquence à laquelle on peut raisonnablement attendre que le point de terminaison parle.

Pour les points de terminaison connus et gérés, une liaison statique ou provisionnée par le contrôleur est un second modèle légitime. Elle a besoin d'un propriétaire qui gère le remplacement et le déplacement, car un enregistrement provisionné ne se met pas à jour tout seul lorsque l'hôte passe à un autre port.

Ce qu'il faut consigner avant le prochain ticket

Gardez la source de la liaison, l'heure du dernier rafraîchissement, l'emplacement actuel et tout événement de rappel à côté de la route MAC. Cet enregistrement répond à la question que le ticket pose vraiment : l'application attend-elle la découverte, s'appuie-t-elle sur un état obsolète, ou échoue-t-elle à transférer après une résolution réussie ?

Décidez ensuite lequel des trois vous êtes prêt à exploiter. La découverte avec flooding, le rafraîchissement avec une durée de vie réaliste ou le provisionnement avec un propriétaire sont tous défendables. Une fabric configurée pour l'un et censée se comporter comme l'autre est l'endroit où les hôtes silencieux disparaissent.