Bond activ-rezervă Linux pe EVPN all-active: ce se rupe

Puneți un bond activ-rezervă pe server și un segment Ethernet all-active pe fabric, și jumătate din traficul de retur poate dispărea fără ca măcar un contor de erori să se miște. Niciuna dintre cele două configurații nu este greșită în sine. Problema stă în predarea dintre ele, unde o parte alege un singur port, iar cealaltă presupune că fiecare frunză conectată poate livra. Urmați un cadru în fiecare direcție și nepotrivirea devine evidentă.

Ce face activ-rezervă cu un cadru primit

Modul de bonding 1 păstrează exact un slave pe calea de transmisie și îl schimbă doar când cel curent cade. Acea parte este bine cunoscută. Aici contează partea de recepție: nucleul predă un cadru stivei doar dacă acesta sosește pe slavele activ și aruncă cadrele care apar pe orice alt slave. Această all_slaves_active setare există exact pentru a relaxa acea regulă și este dezactivată implicit. ip -d link show bond0 afișează valoarea curentă lângă mod.

/proc/net/bonding/bond0 numește slavele activ și raportează starea legăturii pentru fiecare slave. Acel fișier este singura sursă cinstită cu privire la portul care poartă trafic în acel moment.

Un host în acest mod are o singură cale de recepție utilizabilă la un moment dat, aleasă local fără cunoașterea fabricii. Dacă un cadru pentru acel host sosește pe celălalt cablu, portul comutatorului îl numără ca primit, stiva hostului nu îl vede niciodată, iar toate contoarele, în afară de contorul propriu de abandon al hostului, arată perfect sănătoase.

Ce face multihoming all-active cu un următor hop îndepărtat

Multihoming EVPN descrie un set de frunze care împart un segment Ethernet, identificat printr-un ESI, și anunță acel segment restului fabricii. În modelul all-active, perechile îndepărtate instalează mai mult de un următor hop pentru adresele segmentului. Unicastul către server poate ajunge astfel pe oricare frunză, iar fabrica este liberă să aleagă pe flux. Acesta este tot rostul proiectării și totodată presupunerea pe care bondul serverului trebuie să o îndeplinească.

Traficul inundat urmează o altă regulă. Frunzele aleg un forwarder desemnat pe segment, așa că broadcast, unicast necunoscut și multicast intră de obicei prin unul dintre ele. Așadar unicastul și inundarea iau două decizii separate, iar doar una dintre ele apare în starea bondului hostului.

Unde cele două alegeri nu sunt de acord

Nucleul își alege slavele activ după starea legăturii și după propria politică. Fabrica alege următorii hopi după rutele EVPN, iar un forwarder desemnat după o alegere între frunze. Niciunul dintre procese nu îl consultă pe celălalt. Când aleg frunze diferite, defecțiunea depinde de direcție: ce trimite serverul iese normal, iar răspunsurile dispar.

Există două ieșiri acceptate și nu sunt interschimbabile. Oferiți hostului un bond pe care fabrica îl poate trata ca o singură conexiune logică, ceea ce în practică înseamnă un bond LACP negociat cu frunzele, iar ambele legături sunt cu adevărat active împreună. Sau acceptați și livrarea single-active din fabrică, astfel încât segmentul să urmeze același model cu un singur port pe rând ca bondul. Ce nu funcționează este un segment all-active în fața unui bond care ascultă doar pe un port, dacă nu activați intenționat recepția pe slavele inactive și nu acceptați livrarea dublă care urmează.

De ce cablul de rezervă continuă să pară sănătos

Un cablu care nu poartă trafic raportează totuși legătura activă, iar un slave de rezervă într-un bond este proiectat să pară pregătit. Operatorii citesc asta ca redundanță și încetează să mai pună întrebări.

Întrebați în schimb ce port fizic a folosit cadrul de retur. Pe host, numărați pachetele primite pe slave, nu pe bond, pentru că contorul bondului ascunde asimetria. Pe frunză, priviți intrările de forwardare ale punții pentru MAC-ul serverului și setul de următori hopi pe care îl poartă ruta EVPN. Dacă intrarea indică frunza a cărei legătură cu hostul este cea de rezervă, proiectarea livrează într-un port pe care hostul îl ignoră. Este o nepotrivire de configurare, nu o defecțiune hardware, și nicio monitorizare a stării legăturii nu o va scoate la iveală.

Testați livrarea în ambele direcții, nu starea legăturii

Construiți o matrice cu un rând per defecțiune și o coloană per direcție, apoi completați cu trafic livrat, nu cu starea interfeței. Rândul unu este funcționarea normală și exact acolo se ascunde nepotrivirea, pentru că simptomul arată ca o problemă a aplicației.

Apoi scoateți legătura activă a hostului, scoateți o frunză, scoateți uplink-urile acelei frunze și restabiliți fiecare pe rând. După fiecare pas, notați slavele activ, starea segmentului EVPN, intrarea de forwardare îndepărtată și debitul observat în ambele direcții. O frunză care își pierde calea către fabric în timp ce legătura cu hostul rămâne sus este cazul interesant, pentru că atașarea rămâne anunțată și poate deveni în liniște o fundătură. Testați cu fluxuri unicast noi și cu traficul inundat de care depinde aplicația, pentru că ambele folosesc decizii de forwardare diferite.

Acceptați proiectarea doar când matricea arată livrare bidirecțională pe calea dorită. Două cabluri cu legătura sus nu sunt acel rezultat.