Aktívno-záložný bond Linuxu na all-active EVPN: čo sa pokazí

Dajte na server aktívno-záložný bond a na fabric segment all-active Ethernet, a polovica spätnej prevádzky môže zmiznúť bez toho, aby sa pohol jediný počítač chýb. Ani jedna z tých konfigurácií nie je sama o sebe nesprávna. Problém je v odovzdaní medzi nimi: jedna strana vyberá jediný port, druhá predpokladá, že každý pripojený list dokáže doručiť. Sledujte jeden rámec v každom smere a nesúlad je zrejmý.

Čo aktívno-záložný režim robí s prichádzajúcim rámcom

Bonding režim 1 drží v prenosovej ceste presne jeden slave a vymení ho, až keď ten súčasný zlyhá. Tá časť je dobre známa. Tu je dôležitá strana príjmu: jadro odovzdá rámec zásobníku len vtedy, keď príde na aktívny slave, a rámce, ktoré sa objavia na inom slave, zahodí. Toto all_slaves_active nastavenie existuje práve preto, aby to pravidlo zmiernilo, a predvolene je vypnuté. ip -d link show bond0 vypíše aktuálnu hodnotu vedľa režimu.

/proc/net/bonding/bond0 pomenuje aktívny slave a hlási stav spojenia pre každý slave. Ten súbor je jediný čestný zdroj informácie o tom, ktorý port práve nesie prevádzku.

Host v tomto režime má vždy jednu použiteľnú cestu príjmu, zvolenú lokálne bez znalosti fabric. Ak rámec pre tento host príde druhým káblom, port prepínača ho započíta ako prijatý, zásobník hosta ho nikdy nevidí a všetky počítadlá okrem vlastného počítadla zahadzovania hosta vyzerajú úplne zdravo.

Čo all-active multihoming robí so vzdialeným ďalším skokom

EVPN multihoming opisuje množinu listov, ktoré zdieľajú jeden segment Ethernet označený ESI, a ohlasuje tento segment zvyšku fabric. V modeli all-active vzdialené peery inštalujú viac ako jeden ďalší skok pre adresy segmentu. Unicast k serveru potom môže doraziť na ktorýkoľvek list a fabric môže pre každý tok voľne voliť. To je celý zmysel návrhu a zároveň predpoklad, ktorý musí bond servera splniť.

Zaplavená prevádzka sa riadi iným pravidlom. Listy volia určený forwarder pre každý segment, takže broadcast, neznámy unicast a multicast zvyčajne vstupujú cez jeden z nich. Unicast a zaplavenie teda robia dve oddelené rozhodnutia a len jedno z nich sa objaví v stave bondu hosta.

Kde sa obe voľby rozchádzajú

Jadro volí svoj aktívny slave podľa stavu spojenia a vlastnej politiky. Fabric volí ďalšie skoky podľa trás EVPN a určený forwarder podľa voľby medzi listami. Žiadny proces sa s druhým neradí. Keď zvolia rôzne listy, porucha závisí od smeru: to, čo server odošle, odíde normálne, a odpovede zmiznú.

Existujú dve podporované cesty a nie sú zameniteľné. Dajte hostovi bond, ktorý fabric môže brať ako jedno logické pripojenie, čo v praxi znamená LACP bond vyjednaný s listami, a obe spojenia sú skutočne aktívne súčasne. Alebo prijmite aj doručovanie single-active z fabric, aby segment sledoval rovnaký model jeden port naraz ako bond. Čo nefunguje, je segment all-active pred bondom, ktorý počúva len na jednom porte, ak zámerne nezapnete príjem na neaktívnych slave a neprijmete zdvojené doručenie, ktoré z toho vyplýva.

Prečo záložný kábel stále vyzerá zdravo

Kábel, ktorý nenesie prevádzku, stále hlási spojenie nahor, a pohotovostný slave v bonde je navrhnutý tak, aby vyzeral pripravený. Operátori to čítajú ako redundanciu a prestanú sa pýtať.

Spýtajte sa namiesto toho, ktorý fyzický port použil spätný rámec. Na hoste počítajte prijaté pakety po slave, nie po bonde, pretože počítadlo bondu skrýva asymetriu. Na liste sa pozrite na forwardingové záznamy mosta pre MAC adresu servera a na množinu ďalších skokov, ktorú nesie trasa EVPN. Ak záznam ukazuje na list, ktorého spojenie s hostom je záložné, návrh doručuje do portu, ktorý host ignoruje. To je nesúlad konfigurácie, nie porucha hardvéru, a žiadne sledovanie stavu spojenia ho neodhalí.

Testujte doručovanie v oboch smeroch, nie stav spojenia

Zostavte maticu s jedným riadkom na poruchu a jedným stĺpcom na smer, potom ju vyplňte doručenou prevádzkou, nie stavom rozhrania. Riadok jedna je normálna prevádzka a práve tam sa nesúlad skrýva, pretože symptóm vyzerá ako problém aplikácie.

Potom odoberte aktívne spojenie hosta, odoberte jeden list, odoberte uplinky toho listu a každé postupne vráťte. Po každom kroku zapíšte aktívny slave, stav segmentu EVPN, vzdialený forwardingový záznam a pozorovanú priepustnosť v oboch smeroch. List, ktorý stratí cestu do fabric, kým jeho spojenie s hostom zostáva nahor, je zaujímavý prípad, pretože pripojenie zostáva ohlasované a môže sa ticho stať slepou uličkou. Testujte s čerstvými unicast tokmi a so zaplavenou prevádzkou, na ktorej aplikácia závisí, pretože obe používajú iné forwardingové rozhodnutia.

Návrh prijmite len vtedy, keď matica ukáže obojsmerné doručovanie zamýšľanou cestou. Dva káble so spojením nahor nie sú ten výsledok.