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

Set ein aktiv-backup-bond på serveren, set eit all-active Ethernet-segment på fabric, og halvparten av returtrafikken kan forsvinne utan at ein einaste feilteljar rører seg. Ingen av dei to konfigurasjonane er feil i seg sjølv. Problemet ligg i overleveringa mellom dei, der den eine sida vel éin port og den andre føreset at kvar tilkopla leaf kan levere. Følg éi ramme i kvar retning, og misforholdet vert tydeleg.

Kva aktiv-backup gjer med ei innkomande ramme

Bonding-modus 1 held nøyaktig éin slave i sendebana og byter han berre når den noverande sviktar. Den delen er godt kjend. Det som tel her, er mottakssida: kjernen gjev berre ei ramme til stakken om ho kjem inn på den aktive slaven, og kastar rammer som dukkar opp på ein annan slave. Denne all_slaves_active innstillinga finst nettopp for å mjuke opp den regelen, og ho er av som standard. ip -d link show bond0 skriv ut gjeldande verdi ved sida av modusen.

/proc/net/bonding/bond0 namngjev den aktive slaven og rapporterer lenkjestatus for kvar slave. Den fila er den einaste ærlege kjelda til kva port som faktisk ber trafikken.

Ein vert i denne modusen har éi brukbar mottaksbane om gongen, vald lokalt utan kjennskap til fabric. Kjem ei ramme for den verten inn på den andre kabelen, tel svitsjporten ho som motteken, stakken til verten ser ho aldri, og kvar teljar bortsett frå verten sin eigen dropteljar ser heilt sunn ut.

Kva all-active multihoming gjer med eit fjernt neste hopp

EVPN-multihoming skildrar eit sett leaf-ar som deler eitt Ethernet-segment, identifisert av ein ESI, og annonserer segmentet til resten av fabric. I all-active-modellen installerer fjerne peer-ar meir enn eitt neste hopp for adressene til segmentet. Unicast mot serveren kan då kome inn på begge leaf-ane, og fabric kan fritt velje per flyt. Det er heile poenget med designet, og det er òg føresetnaden serverbondet må oppfylle.

Oversvøymt trafikk følgjer ein annan regel. Leaf-ane vel ein utpeika forwarder per segment, så broadcast, ukjend unicast og multicast kjem normalt inn gjennom ein av dei. Unicast og oversvøyming tek derfor to separate avgjerder, og berre éi av dei syner i bondstatusen til ein vert.

Der dei to vala er usamde

Kjernen vel den aktive slaven sin ut frå lenkjestatus og sin eigen politikk. Fabric vel neste hopp ut frå EVPN-ruter, og ein utpeika forwarder ut frå eit val blant leaf-ane. Ingen av prosessane spør den andre. Når dei vel ulike leaf-ar, er feilen retningsavhengig: det serveren sender går ut normalt, og svara forsvinn.

Det finst to støtta vegar ut, og dei er ikkje utskiftbare. Gje verten eit bond som fabric kan handsame som éin logisk tilkopling, som i praksis tyder eit LACP-bond forhandla med leaf-ane, og begge lenkjene er verkeleg aktive saman. Eller godta òg single-active levering frå fabric, slik at segmentet følgjer same modell med éin port om gongen som bondet. Det som ikkje fungerer, er eit all-active segment framfor eit bond som berre lyttar på éin port, med mindre du med vilje slår på mottak på dei inaktive slavane og godtek den doble leveringa som følgjer.

Kvifor reservekabelen framleis ser sunn ut

Ein kabel som ikkje ber trafikk rapporterer likevel lenkje opp, og ein standby-slave i eit bond er laga for å sjå klar ut. Operatørar les det som redundans og sluttar å stille spørsmål.

Spør i staden kva fysisk port returramma brukte. På verten, tel mottekne pakkar per slave i staden for per bond, fordi bondteljaren skjuler asymmetrien. På leaf-en, sjå på vidareformidlingsoppføringane i brua for MAC-en til serveren og neste-hopp-settet som EVPN-ruta ber. Peikar oppføringa på leaf-en der vertslenkja er standby, leverer designet inn i ein port verten ignorerer. Det er eit konfigurasjonsmisforhold og ikkje ein maskinvarefeil, og inga mengd lenkjestatusovervaking vil avdekkje det.

Test levering i begge retningar, ikkje lenkjestatus

Bygg ein matrise med éi rad per feil og éin kolonne per retning, og fyll inn levert trafikk i staden for grensesnittstatus. Rad éin er normal drift, og det er nettopp der misforholdet gøymer seg, fordi symptomet ser ut som eit applikasjonsproblem.

Fjern deretter den aktive vertslenkja, fjern éin leaf, fjern uplink-ane til den leaf-en, og gjenopprett kvar av dei etter tur. Etter kvart trinn, noter den aktive slaven, tilstanden til EVPN-segmentet, den fjerne vidareformidlingsoppføringa og målt gjennomstrøyming i begge retningar. Ein leaf som mistar fabric-bana si medan vertslenkja blir ståande oppe, er det interessante tilfellet, fordi tilkoplinga blir verande annonsert og kan stille bli ein blindveg. Test med ferske unicast-flytar og med den oversvøymde trafikken applikasjonen er avhengig av, fordi dei to brukar ulike vidareformidlingsavgjerder.

Godta designet berre når matrisen syner toveg-levering gjennom bana du hadde tenkt. To kablar med lenkje opp er ikkje det resultatet.