Linux aktív-tartalék bond all-active EVPN-en: mi törik el

Tegyen aktív-tartalék bondot a szerverre, all-active Ethernet szegmenst a fabricra, és a visszatérő forgalom fele eltűnhet anélkül, hogy egyetlen hibaszámláló is megmozdulna. Egyik konfiguráció sem hibás önmagában. A probléma a kettő közötti átadásban van, ahol az egyik oldal egyetlen portot választ, a másik pedig feltételezi, hogy minden csatlakoztatott levél tud szállítani. Kövessen végig egy keretet mindkét irányban, és az eltérés nyilvánvalóvá válik.

Mit tesz az aktív-tartalék a bejövő kerettel

Az 1-es bonding mód pontosan egy slave-et tart a küldési úton, és csak akkor cseréli le, amikor az aktuális meghibásodik. Ez a rész jól ismert. Itt a fogadási oldal a fontos: a kernel csak akkor adja át a keretet a stacknek, ha az az aktív slave-en érkezik, és eldobja azokat a kereteket, amelyek bármely más slave-en jelennek meg. Ez a all_slaves_active beállítás pontosan e szabály lazítására létezik, és alapértelmezés szerint ki van kapcsolva. ip -d link show bond0 kinyomtatja az aktuális értéket a mód mellett.

/proc/net/bonding/bond0 megnevezi az aktív slave-et, és jelenti minden slave linkállapotát. Az a fájl az egyetlen őszinte forrás arra, melyik port viszi éppen a forgalmat.

Az ebben a módban lévő hosztnak egyszerre egy használható fogadási útja van, helyben választva, a fabric ismerete nélkül. Ha az adott hosztnak szóló keret a másik kábelen érkezik, a kapcsoló portja fogadottként számolja, a hoszt stackje soha nem látja, és a hoszt saját eldobási számlálóján kívül minden számláló teljesen egészségesnek látszik.

Mit tesz az all-active multihoming a távoli következő ugrással

Az EVPN multihoming olyan levelek halmazát írja le, amelyek egy Ethernet szegmenst osztanak meg, amelyet egy ESI azonosít, és ezt a szegmenst meghirdeti a fabric többi része felé. Az all-active modellben a távoli peerek több mint egy következő ugrást telepítenek a szegmens címeihez. A szerver felé menő unicast ekkor bármelyik levélen megérkezhet, és a fabric szabadon választhat folyamonként. Ez a tervezés egész értelme, és egyben az a feltevés is, amelyet a szerver bondjának teljesítenie kell.

Az elöntött forgalom más szabályt követ. A levelek szegmensenként kijelölt forwardert választanak, így a broadcast, az ismeretlen unicast és a multicast általában valamelyikükön keresztül lép be. A unicast és az elöntés tehát két külön döntést hoz, és ezek közül csak az egyik látszik a hoszt bondjának állapotában.

Ahol a két választás eltér

A kernel a linkállapotból és saját szabályából választja ki aktív slave-jét. A fabric az EVPN útvonalakból választja a következő ugrásokat, a kijelölt forwardert pedig a levelek közötti választásból. Egyik folyamat sem kérdezi a másikat. Amikor különböző leveleket választanak, a hiba irányfüggő: amit a szerver küld, az rendesen elindul, a válaszok pedig eltűnnek.

Két támogatott kiút létezik, és ezek nem felcserélhetők. Adjon a hosztnak olyan bondot, amelyet a fabric egy logikai csatlakozásként kezelhet, ami a gyakorlatban a levelekkel egyeztetett LACP bondot jelent, és mindkét link valóban együtt aktív. Vagy fogadja el a fabrictól a single-active szállítást is, hogy a szegmens ugyanazt az egyszerre egy portos modellt kövesse, mint a bond. Ami nem működik, az az all-active szegmens olyan bond előtt, amely csak egy porton figyel, hacsak nem kapcsolja be szándékosan a vételt a nem aktív slave-eken, és nem fogadja el az ezt követő kétszeres szállítást.

Miért tűnik továbbra is egészségesnek a tartalék kábel

A forgalmat nem vivő kábel is link fel állapotot jelent, a bondban lévő készenléti slave pedig arra készült, hogy késznek látszódjon. Az üzemeltetők redundanciaként olvassák ezt, és abbahagyják a kérdezősködést.

Kérdezze inkább azt, melyik fizikai portot használta a visszatérő keret. A hoszton slave-enként számolja a fogadott csomagokat, ne bondonként, mert a bond számlálója elrejti az aszimmetriát. A levélen nézze meg a híd továbbítási bejegyzéseit a szerver MAC-címéhez és a következő ugrások halmazát, amelyet az EVPN útvonal hordoz. Ha a bejegyzés arra a levélre mutat, amelynek hoszt-linkje a tartalék, a tervezés olyan portba szállít, amelyet a hoszt figyelmen kívül hagy. Ez konfigurációs eltérés, nem hardverhiba, és semmilyen linkállapot-figyelés nem hozza felszínre.

A szállítást tesztelje mindkét irányban, ne a linkállapotot

Építsen mátrixot egy sorral minden hibához és egy oszloppal minden irányhoz, majd a szállított forgalommal töltse ki, ne az interfész állapotával. Az egyes sor a normál működés, és pontosan ott rejtőzik az eltérés, mert a tünet alkalmazáshibának látszik.

Ezután távolítsa el az aktív hoszt-linket, távolítson el egy levelet, távolítsa el annak a levélnek az uplinkjeit, és állítsa vissza mindegyiket sorban. Minden lépés után jegyezze fel az aktív slave-et, az EVPN szegmens állapotát, a távoli továbbítási bejegyzést és a megfigyelt átviteli sebességet mindkét irányban. Az a levél az érdekes eset, amely elveszíti a fabric felé vezető útját, miközben a hoszt-linkje fel állapotban marad, mert a csatlakozás meghirdetve marad, és csendben zsákutcává válhat. Teszteljen friss unicast folyamokkal és azzal az elöntött forgalommal, amelytől az alkalmazás függ, mert a kettő eltérő továbbítási döntéseket használ.

Csak akkor fogadja el a tervezést, ha a mátrix kétirányú szállítást mutat a szándékolt úton. Két link fel állapotú kábel nem ez az eredmény.