Linux aktiv-backup-bond på all-active EVPN: hva som ryker

Sett en aktiv-backup-bond på serveren, sett et all-active Ethernet-segment på fabric, og halvparten av returtrafikken kan forsvinne uten at en eneste feilteller rører seg. Ingen av de to konfigurasjonene er feil i seg selv. Problemet ligger i overleveringen mellom dem, der den ene siden velger én port og den andre antar at hver tilkoblet leaf kan levere. Følg én ramme i hver retning, og misforholdet blir tydelig.

Hva aktiv-backup gjør med en innkommende ramme

Bonding-modus 1 holder nøyaktig én slave i sendebanen og bytter den bare når den nåværende feiler. Den delen er godt kjent. Det som betyr noe her, er mottakssiden: kjernen gir bare en ramme til stakken hvis den ankommer på den aktive slaven, og forkaster rammer som dukker opp på en annen slave. Denne all_slaves_active innstillingen finnes nettopp for å lempe på den regelen, og den er av som standard. ip -d link show bond0 skriver ut gjeldende verdi ved siden av modusen.

/proc/net/bonding/bond0 navngir den aktive slaven og rapporterer lenkestatus for hver slave. Den filen er den eneste ærlige kilden til hvilken port som faktisk bærer trafikk.

En vert i denne modusen har én brukbar mottaksbane om gangen, valgt lokalt uten kjennskap til fabric. Hvis en ramme for den verten ankommer på den andre kabelen, teller svitsjporten den som mottatt, vertens stakk ser den aldri, og hver teller bortsett fra vertens egen droppteller ser helt sunn ut.

Hva all-active multihoming gjør med et fjernt neste hopp

EVPN-multihoming beskriver et sett med leaf-er som deler ett Ethernet-segment, identifisert av en ESI, og annonserer segmentet til resten av fabric. I all-active-modellen installerer fjerne peers mer enn ett neste hopp for segmentets adresser. Unicast mot serveren kan da ankomme begge leaf-ene, og fabric kan fritt velge per flyt. Det er hele poenget med designet, og det er også den forutsetningen serverbondet må oppfylle.

Oversvømt trafikk følger en annen regel. Leaf-ene velger en utpekt forwarder per segment, så broadcast, ukjent unicast og multicast kommer normalt inn gjennom en av dem. Unicast og oversvømmelse tar derfor to separate beslutninger, og bare én av dem vises i vertens bondstatus.

Der de to valgene er uenige

Kjernen velger sin aktive slave ut fra lenkestatus og sin egen policy. Fabric velger neste hopp ut fra EVPN-ruter, og en utpekt forwarder ut fra et valg blant leaf-ene. Ingen av prosessene spør den andre. Når de velger ulike leaf-er, er feilen retningsavhengig: det serveren sender går ut normalt, og svarene forsvinner.

Det finnes to støttede veier ut, og de er ikke utskiftbare. Gi verten et bond som fabric kan behandle som én logisk tilkobling, som i praksis betyr et LACP-bond forhandlet med leaf-ene, og begge lenkene er virkelig aktive sammen. Eller godta også single-active levering fra fabric, slik at segmentet følger samme modell med én port om gangen som bondet. Det som ikke fungerer, er et all-active segment foran et bond som bare lytter på én port, med mindre du bevisst slår på mottak på de inaktive slavene og godtar den doble leveringen som følger.

Hvorfor reserverkabelen fortsatt ser sunn ut

En kabel som ikke bærer trafikk rapporterer likevel lenke opp, og en standby-slave i et bond er laget for å se klar ut. Operatører leser det som redundans og slutter å stille spørsmål.

Spør i stedet hvilken fysisk port returrammen brukte. På verten, tell mottatte pakker per slave i stedet for per bond, fordi bondtelleren skjuler asymmetrien. På leaf-en, se på videreformidlingsoppføringene i broen for serverens MAC og neste-hopp-settet som EVPN-ruten bærer. Hvis oppføringen peker på leaf-en der vertslenken er standby, leverer designet inn i en port verten ignorerer. Det er et konfigurasjonsmisforhold og ikke en maskinvarefeil, og ingen mengde lenkestatusovervåking vil avdekke det.

Test levering i begge retninger, ikke lenkestatus

Bygg en matrise med én rad per feil og én kolonne per retning, og fyll inn levert trafikk i stedet for grensesnittstatus. Rad én er normal drift, og det er nettopp der misforholdet gjemmer seg, fordi symptomet ser ut som et applikasjonsproblem.

Fjern deretter den aktive vertslenken, fjern én leaf, fjern uplink-ene til den leaf-en, og gjenopprett hver av dem etter tur. Etter hvert trinn, noter den aktive slaven, tilstanden til EVPN-segmentet, den fjerne videreformidlingsoppføringen og målt gjennomstrømning i begge retninger. En leaf som mister fabric-banen sin mens vertslenken blir stående oppe, er det interessante tilfellet, fordi tilkoblingen forblir annonsert og kan stille bli en blindvei. Test med ferske unicast-flyter og med den oversvømte trafikken applikasjonen er avhengig av, fordi de to bruker ulike videreformidlingsbeslutninger.

Godta designet bare når matrisen viser toveis levering gjennom banen du hadde tenkt. To kabler med lenke opp er ikke det resultatet.