Bond actif-secours Linux sur EVPN all-active : ce qui casse

Mettez un bond actif-secours sur le serveur et un segment Ethernet all-active sur le fabric, et la moitié du trafic de retour peut disparaître sans qu’un seul compteur d’erreurs ne bouge. Aucune des deux configurations n’est fausse en soi. Le problème se situe dans la remise entre les deux, où un côté choisit un seul port et l’autre suppose que chaque feuille reliée peut livrer. Suivez une trame dans chaque direction et le décalage devient évident.

Ce que fait l’actif-secours à une trame entrante

Le mode de bonding 1 ne garde qu’un seul esclave dans le chemin d’émission et ne le remplace que lorsque l’actuel tombe. Cette partie est bien connue. Ce qui compte ici, c’est le côté réception : le noyau ne remet une trame à la pile que si elle arrive sur l’esclave actif, et il jette les trames qui apparaissent sur tout autre esclave. Ce all_slaves_active réglage existe précisément pour assouplir cette règle, et il est désactivé par défaut. ip -d link show bond0 affiche la valeur courante à côté du mode.

/proc/net/bonding/bond0 nomme l’esclave actif et rapporte l’état du lien de chaque esclave. Ce fichier est la seule source honnête du port qui porte réellement le trafic à un instant donné.

Un hôte dans ce mode dispose d’un seul chemin de réception utilisable à la fois, choisi localement sans connaissance du fabric. Si une trame destinée à cet hôte arrive par l’autre câble, le port du commutateur la compte comme reçue, la pile de l’hôte ne la voit jamais, et tous les compteurs sauf le compteur de rejets propre à l’hôte semblent parfaitement sains.

Ce que fait le multihoming all-active à un prochain saut distant

Le multihoming EVPN décrit un ensemble de feuilles qui partagent un segment Ethernet, identifié par un ESI, et annonce ce segment au reste du fabric. Dans le modèle all-active, les pairs distants installent plus d’un prochain saut pour les adresses du segment. L’unicast vers le serveur peut alors arriver sur l’une ou l’autre feuille, et le fabric est libre de choisir par flux. C’est tout l’intérêt de la conception, et c’est aussi l’hypothèse que le bond du serveur doit satisfaire.

Le trafic inondé suit une autre règle. Les feuilles élisent un forwarder désigné par segment, si bien que le broadcast, l’unicast inconnu et le multicast entrent normalement par l’une d’elles. Unicast et inondation prennent donc deux décisions distinctes, et une seule apparaît dans l’état du bond de l’hôte.

Là où les deux élections divergent

Le noyau choisit son esclave actif d’après l’état du lien et sa propre politique. Le fabric choisit les prochains sauts d’après les routes EVPN, et un forwarder désigné d’après une élection entre les feuilles. Aucun des deux processus ne consulte l’autre. Quand ils choisissent des feuilles différentes, la panne dépend du sens : ce que le serveur émet sort normalement, et les réponses disparaissent.

Il existe deux issues prises en charge, et elles ne sont pas interchangeables. Donnez à l’hôte un bond que le fabric peut traiter comme un seul raccordement logique, ce qui en pratique signifie un bond LACP négocié avec les feuilles, et les deux liens sont réellement actifs ensemble. Ou acceptez aussi une livraison single-active depuis le fabric, afin que le segment suive le même modèle d’un port à la fois que le bond. Ce qui ne fonctionne pas, c’est un segment all-active devant un bond qui n’écoute que sur un port, à moins d’activer délibérément la réception sur les esclaves inactifs et d’accepter la livraison en double qui s’ensuit.

Pourquoi le câble de secours continue de paraître sain

Un câble qui ne porte aucun trafic signale toujours un lien actif, et un esclave de secours dans un bond est conçu pour paraître prêt. Les opérateurs y lisent de la redondance et cessent de poser des questions.

Demandez plutôt quel port physique la trame de retour a utilisé. Sur l’hôte, comptez les paquets reçus par esclave plutôt que par bond, car le compteur du bond masque l’asymétrie. Sur la feuille, regardez les entrées de commutation du pont pour la MAC du serveur et l’ensemble de prochains sauts que porte la route EVPN. Si l’entrée pointe vers la feuille dont le lien hôte est le secours, la conception livre dans un port que l’hôte ignore. Il s’agit d’un décalage de configuration et non d’une panne matérielle, et aucun monitoring de l’état du lien ne le fera apparaître.

Testez la livraison dans les deux sens, pas l’état du lien

Construisez une matrice avec une ligne par panne et une colonne par sens, puis remplissez-la avec le trafic livré plutôt qu’avec l’état de l’interface. La ligne une est le fonctionnement normal, et c’est précisément là que le décalage se cache, car le symptôme ressemble à un problème applicatif.

Retirez ensuite le lien hôte actif, retirez une feuille, retirez les uplinks de cette feuille, puis rétablissez chacun à tour de rôle. Après chaque étape, notez l’esclave actif, l’état du segment EVPN, l’entrée de commutation distante et le débit observé dans les deux sens. Une feuille qui perd son chemin vers le fabric alors que son lien hôte reste actif est le cas intéressant, car le raccordement reste annoncé et peut devenir silencieusement un cul-de-sac. Testez avec des flux unicast neufs et avec le trafic inondé dont dépend l’application, car les deux utilisent des décisions de commutation différentes.

N’acceptez la conception que lorsque la matrice montre une livraison bidirectionnelle par le chemin voulu. Deux câbles avec lien actif ne sont pas ce résultat.