Aktivně-záložní bond v Linuxu na all-active EVPN: co se rozbije

Nasaďte na server aktivně-záložní bond a na fabric all-active Ethernet segment – a polovina zpětného provozu může zmizet, aniž by se hnul jediný čítač chyb. Ani jedna z těch konfigurací není sama o sobě špatná. Problém je v předání mezi nimi: jedna strana volí jediný port a druhá předpokládá, že každý připojený leaf umí doručit. Sledujte jeden rámec v každém směru a nesoulad je zřejmý.

Co aktivně-záložní režim dělá s příchozím rámcem

Bonding režim 1 drží v přenosové cestě právě jeden slave a vymění ho, jen když ten současný selže. Tahle část je dobře známá. Důležitá je tu strana příjmu: jádro předá rámec zásobníku jen tehdy, když dorazí na aktivní slave, a rámce, které se objeví na jiném slave, zahodí. Toto all_slaves_active nastavení existuje právě proto, aby to pravidlo zmírnilo, a ve výchozím stavu je vypnuté. ip -d link show bond0 vypíše aktuální hodnotu vedle režimu.

/proc/net/bonding/bond0 pojmenuje aktivní slave a hlásí stav spoje pro každý slave. Ten soubor je jediný poctivý zdroj informace o tom, který port právě nese provoz.

Host v tomto režimu má vždy jednu použitelnou příjmovou cestu, zvolenou lokálně bez znalosti fabric. Dorazí-li rámec pro tento host druhým kabelem, port přepínače ho započítá jako přijatý, zásobník hostu ho nikdy neuvidí a všechny čítače kromě vlastního čítače zahazování na hostu vypadají naprosto zdravě.

Co all-active multihoming dělá se vzdáleným dalším skokem

EVPN multihoming popisuje sadu leafů, které sdílejí jeden Ethernet segment označený ESI, a ohlašuje tento segment zbytku fabric. V all-active modelu instalují vzdálení peerové pro adresy segmentu víc než jeden další skok. Unicast k serveru pak může dorazit na kterýkoli leaf a fabric může volit pro každý tok zvlášť. To je celý smysl návrhu a zároveň předpoklad, který musí bond na serveru splnit.

Zaplavený provoz se řídí jiným pravidlem. Leafy volí pro každý segment určený forwarder, takže broadcast, neznámý unicast a multicast obvykle vstupují jedním z nich. Unicast a zaplavení tak činí dvě oddělená rozhodnutí a jen jedno z nich se objeví ve stavu bondu na hostu.

Kde se obě volby rozcházejí

Jádro volí svůj aktivní slave podle stavu spoje a vlastní politiky. Fabric volí další skoky podle EVPN tras a určený forwarder podle volby mezi leafy. Žádný z procesů se s druhým neradí. Když zvolí různé leafy, porucha závisí na směru: co server odešle, odejde normálně, a odpovědi zmizí.

Existují dvě podporované cesty a nejsou zaměnitelné. Dejte hostu bond, který fabric může brát jako jednu logickou přípojku, což v praxi znamená LACP bond vyjednaný s leafy, a oba spoje jsou skutečně aktivní současně. Nebo přijměte i single-active doručování z fabric, aby segment sledoval stejný model jeden port naráz jako bond. Co nefunguje, je all-active segment před bondem, který poslouchá jen na jednom portu, pokud záměrně nezapnete příjem na neaktivních slavech a nepřijmete zdvojené doručení, které z toho plyne.

Proč záložní kabel pořád vypadá zdravě

Kabel, který nenese provoz, stále hlásí spoj nahoru, a pohotovostní slave v bondu je navržen tak, aby vypadal připraveně. Operátoři to čtou jako redundanci a přestanou se ptát.

Ptejte se místo toho, který fyzický port zpětný rámec použil. Na hostu počítejte přijaté pakety po slavech, ne po bondu, protože čítač bondu asymetrii skrývá. Na leafu se podívejte na forwardingové záznamy mostu pro MAC adresu serveru a na sadu dalších skoků, kterou nese EVPN trasa. Pokud záznam ukazuje na leaf, jehož spoj k hostu je záložní, návrh doručuje do portu, který host ignoruje. To je nesoulad konfigurace, ne závada hardwaru, a žádné sledování stavu spojů ho neodhalí.

Testujte doručování v obou směrech, ne stav spoje

Sestavte matici s jedním řádkem na poruchu a jedním sloupcem na směr, pak vyplňujte doručený provoz, ne stav rozhraní. Řádek jedna je normální provoz a právě tam se nesoulad skrývá, protože symptom vypadá jako problém aplikace.

Pak odeberte aktivní spoj hostu, odeberte jeden leaf, odeberte uplinky toho leafu a každý postupně vraťte. Po každém kroku zaznamenejte aktivní slave, stav EVPN segmentu, vzdálený forwardingový záznam a pozorovanou propustnost v obou směrech. Leaf, který ztratí cestu do fabric, zatímco jeho spoj k hostu zůstává nahoře, je zajímavý případ, protože přípojka zůstává ohlašovaná a může se tiše stát slepou uličkou. Testujte s čerstvými unicast toky a se zaplaveným provozem, na kterém aplikace závisí, protože obojí používá jiná forwardingová rozhodnutí.

Návrh přijměte jen tehdy, když matice ukáže obousměrné doručování cestou, kterou jste zamýšleli. Dva kabely se spojem nahoru nejsou ten výsledek.