Bond de Linux en actiu-reserva sobre un EVPN tot actiu: què es trenca

Poseu un bond en actiu-reserva al servidor i un segment Ethernet tot actiu a la xarxa, i la meitat del trànsit de tornada pot desaparèixer sense que es mogui ni un sol comptador d’errors. Cap de les dues configuracions no és incorrecta per si sola. El problema és en el traspàs entre elles, on un costat tria un sol port i l’altre assumeix que cada full connectat pot lliurar. Seguiu una trama en cada direcció i el desajust es fa evident.

Què fa l’actiu-reserva a una trama entrant

El mode d’agregació 1 manté exactament un esclau al camí de transmissió i només el canvia quan l’actual falla. Aquesta part és ben coneguda. Aquí, però, importa el costat de recepció: el nucli només lliura una trama a la pila si arriba per l’esclau actiu, i descarta les trames que apareixen per qualsevol altre esclau. Aquest all_slaves_active paràmetre existeix precisament per relaxar aquesta regla, i per defecte està desactivat. ip -d link show bond0 imprimeix el valor actual al costat del mode.

/proc/net/bonding/bond0 anomena l’esclau actiu i informa de l’estat d’enllaç de cada esclau. Aquest fitxer és l’única font honesta de quin port porta trànsit en aquest moment.

Un amfitrió en aquest mode té un sol camí de recepció utilitzable alhora, triat localment sense cap coneixement de la xarxa. Si una trama per a aquest amfitrió arriba pel cable de l’altre costat, el port del commutador la compta com a rebuda, la pila de l’amfitrió no la veu mai, i tots els comptadors llevat del comptador de descarts propi de l’amfitrió semblen perfectament sans.

Què fa el multihoming tot actiu a un salt següent remot

El multihoming EVPN descriu un conjunt de fulls que comparteixen un segment Ethernet, identificat per un ESI, i l’anuncia a la resta de la xarxa. En el model tot actiu, els parells remots instal·len més d’un salt següent per a les adreces del segment. L’unicast cap al servidor pot arribar llavors a qualsevol full, i la xarxa és lliure de triar per flux. Aquest és tot el sentit del disseny, i també és la suposició que el bond del servidor ha de complir.

El trànsit inundat segueix una regla diferent. Els fulls elegeixen un reenviador designat per segment, de manera que broadcast, unicast desconegut i multicast normalment entren per un d’ells. Per tant, unicast i inundació prenen dues decisions separades, i només una apareix a l’estat del bond de l’amfitrió.

On les dues eleccions discrepen

El nucli tria el seu esclau actiu a partir de l’estat d’enllaç i de la seva pròpia política. La xarxa tria els salts següents a partir de les rutes EVPN, i un reenviador designat a partir d’una elecció entre els fulls. Cap dels dos processos consulta l’altre. Quan trien fulls diferents, la fallada és específica de la direcció: el que el servidor envia surt normalment, i les respostes desapareixen.

Hi ha dues sortides suportades, i no són intercanviables. Doneu a l’amfitrió un bond que la xarxa pugui tractar com un sol enllaç lògic, cosa que en la pràctica vol dir un bond LACP negociat amb els fulls, i tots dos enllaços són realment actius alhora. O accepteu també el lliurament single-active des de la xarxa, de manera que el segment segueixi el mateix model d’un port alhora que el bond. El que no funciona és un segment tot actiu davant d’un bond que només escolta en un port, tret que activeu deliberadament la recepció als esclaus inactius i accepteu el lliurament duplicat que se’n segueix.

Per què el cable de reserva continua semblant sa

Un cable que no porta trànsit continua informant d’enllaç aixecat, i un esclau de reserva en un bond està dissenyat per semblar a punt. Els operadors ho llegeixen com a redundància i deixen de fer preguntes.

Pregunteu, en canvi, quin port físic va utilitzar la trama de tornada. A l’amfitrió, compteu els paquets rebuts per esclau i no per bond, perquè el comptador del bond amaga l’asimetria. Al full, mireu les entrades de reenviament del pont per a la MAC del servidor i el conjunt de salts següents que porta la ruta EVPN. Si l’entrada apunta al full l’enllaç del qual cap a l’amfitrió és el de reserva, el disseny està lliurant a un port que l’amfitrió ignora. Això és un desajust de configuració i no una fallada de maquinari, i cap quantitat de monitoratge de l’estat d’enllaç no ho farà aflorar.

Proveu el lliurament en totes dues direccions, no l’estat d’enllaç

Construïu una matriu amb una fila per fallada i una columna per direcció, i ompliu-la amb trànsit lliurat en lloc de l’estat de la interfície. La fila u és el funcionament normal, i és exactament on s’amaga el desajust, perquè el símptoma sembla un problema de l’aplicació.

Després traieu l’enllaç actiu de l’amfitrió, traieu un full, traieu els enllaços ascendents d’aquest full i restaureu-los un per un. Després de cada pas, anoteu l’esclau actiu, l’estat del segment EVPN, l’entrada de reenviament remota i el cabal observat en totes dues direccions. Un full que perd el camí cap a la xarxa mentre el seu enllaç amb l’amfitrió continua aixecat és el cas interessant, perquè l’adjunció continua anunciada i pot esdevenir silenciosament un cul-de-sac. Proveu amb fluxos unicast nous i amb el trànsit inundat del qual depèn l’aplicació, perquè tots dos fan servir decisions de reenviament diferents.

Accepteu el disseny només quan la matriu mostri lliurament bidireccional pel camí que volíeu. Dos cables amb enllaç aixecat no són aquest resultat.