Linuxi aktiiv-varu bond all-active EVPN-il: mis katki läheb

Pange serverile aktiiv-varu bond ja fabricile all-active Etherneti segment, ning pool tagasitulevast liiklusest võib kaduda, ilma et ükski vealoendur liiguks. Kumbki konfiguratsioon ei ole iseenesest vale. Probleem on nendevahelises üleandmises, kus üks pool valib ühe pordi ja teine eeldab, et iga külge ühendatud leaf suudab kohale toimetada. Jälgige üht kaadrit kummaski suunas ja ebakõla muutub ilmsiks.

Mida aktiiv-varu sissetuleva kaadriga teeb

Bondimisrežiim 1 hoiab saate teel täpselt üht slave'i ja vahetab selle ainult siis, kui praegune üles ütleb. See osa on hästi teada. Siin on oluline vastuvõtupool: kernel annab kaadri virnale ainult siis, kui see saabub aktiivsele slave'ile, ja viskab kõrvale kaadrid, mis ilmuvad mõnele teisele slave'ile. See all_slaves_active säte on olemas just selle reegli leevendamiseks ja on vaikimisi väljas. ip -d link show bond0 prindib praeguse väärtuse režiimi kõrvale.

/proc/net/bonding/bond0 nimetab aktiivse slave'i ja teatab iga slave'i lingi oleku. See fail on ainus aus allikas selle kohta, milline port praegu liiklust kannab.

Selles režiimis hostil on korraga üks kasutatav vastuvõtutee, mis on valitud lokaalselt ilma fabrici teadmiseta. Kui selle hosti jaoks mõeldud kaader saabub teise kaabli kaudu, loeb kommutaatori port selle vastuvõetuks, hosti virn ei näe seda kunagi ja kõik loendurid peale hosti enda kaotuste loenduri näivad täiesti terved.

Mida all-active multihoming teeb kaugema järgmise hüppega

EVPN multihoming kirjeldab leafide kogumit, mis jagavad üht Etherneti segmenti, mille tähistab ESI, ja teavitab seda segmenti ülejäänud fabricile. All-active mudelis paigaldavad kauged peer'id segmendi aadressidele rohkem kui ühe järgmise hüppe. Unicast serveri poole võib siis saabuda kummale tahes leafile ja fabric võib iga voolu kohta vabalt valida. See ongi kogu disaini mõte ja see on ka eeldus, millele serveri bond peab vastama.

Üleujutatud liiklus järgib teist reeglit. Leafid valivad iga segmendi jaoks määratud forwarderi, nii et broadcast, tundmatu unicast ja multicast sisenevad tavaliselt ühe kaudu neist. Seega teevad unicast ja üleujutus kaks eraldi otsust ning ainult üks neist näitub hosti bondi olekus.

Kus kaks valikut lahknevad

Kernel valib oma aktiivse slave'i lingi oleku ja oma poliitika järgi. Fabric valib järgmised hüpped EVPN marsruutide järgi ja määratud forwarderi leafide vahelise valiku järgi. Kumbki protsess ei konsulteeri teisega. Kui nad valivad erinevad leafid, on rike suunapõhine: see, mida server saadab, väljub normaalselt, ja vastused kaovad.

On kaks toetatud väljapääsu ja need ei ole vahetatavad. Andke hostile bond, mida fabric saab kohelda ühe loogilise ühendusena, mis praktikas tähendab leafidega läbi räägitud LACP bondi, ja mõlemad lingid on tõeliselt koos aktiivsed. Või nõustuge ka single-active tarnega fabricist, nii et segment järgib sama üks-port-korraga mudelit nagu bond. See, mis ei tööta, on all-active segment sellise bondi ees, mis kuulab ainult ühel pordil, kui te ei lülita teadlikult sisse vastuvõttu mitteaktiivsetel slave'idel ja ei nõustu sellele järgneva topelt tarnega.

Miks varukaabel jääb terve välja nägema

Kaabel, mis liiklust ei kanna, teatab ikkagi lingist üleval, ja bondi ootel slave on loodud valmis välja nägema. Operaatorid loevad seda liiasusena ja lõpetavad küsimast.

Küsige hoopis, millist füüsilist porti tagasitulev kaader kasutas. Hostis loendage vastuvõetud pakette slave'i, mitte bondi kohta, sest bondi loendur peidab asümmeetria. Leafil vaadake silla edastuskirjeid serveri MAC-i jaoks ja järgmiste hüpete kogumit, mida EVPN marsruut kannab. Kui kirje osutab leafile, mille hosti link on ootel, tarnib disain porti, mida host eirab. See on konfiguratsiooni ebakõla, mitte riistvara viga, ja ükski lingi oleku jälgimine ei too seda pinnale.

Testige tarnet mõlemas suunas, mitte lingi olekut

Ehitage maatriks, kus iga rikke kohta on üks rida ja iga suuna kohta üks veerg, ning täitke siis tarnitud liiklusega, mitte liidese olekuga. Rida üks on normaalne töö ja just seal ebakõla peitub, sest sümptom näeb välja nagu rakenduse probleem.

Seejärel eemaldage aktiivne hosti link, eemaldage üks leaf, eemaldage selle leafi uplinkid ja taastage igaüks kordamööda. Pärast igat sammu kirjutage üles aktiivne slave, EVPN segmendi olek, kaugem edastuskirje ja vaadeldud läbilaskevõime mõlemas suunas. Leaf, mis kaotab oma fabrici tee, samal ajal kui selle hosti link jääb üles, on huvitav juhtum, sest ühendus jääb teavitatud ja võib vaikselt muutuda tupikteeks. Testige värskete unicast vooludega ja üleujutatud liiklusega, millest rakendus sõltub, sest need kaks kasutavad erinevaid edastusotsuseid.

Nõustuge disainiga alles siis, kui maatriks näitab kahesuunalist tarnet teel, mida kavatsesite. Kaks üleval lingiga kaablit ei ole see tulemus.