Linux aktiv-backup-bond på all-active EVPN: hvad der brækker

Sæt et aktiv-backup-bond på serveren, sæt et all-active Ethernet-segment på fabric, og halvdelen af returtrafikken kan forsvinde, uden at en enkelt fejltæller flytter sig. Ingen af de to konfigurationer er forkert i sig selv. Problemet ligger i overdragelsen mellem dem, hvor den ene side vælger én port, og den anden antager, at hver tilknyttet leaf kan levere. Følg én ramme i hver retning, og misforholdet bliver tydeligt.

Hvad aktiv-backup gør ved en indgående ramme

Bondingtilstand 1 holder præcis én slave på sendestien og skifter den kun, når den nuværende fejler. Den del er velkendt. Det, der betyder noget her, er modtagesiden: kernen giver kun en ramme til stakken, hvis den ankommer på den aktive slave, og dropper rammer, der dukker op på en anden slave. Denne all_slaves_active indstilling findes netop for at lempe den regel, og den er som standard slået fra. ip -d link show bond0 udskriver den aktuelle værdi ved siden af tilstanden.

/proc/net/bonding/bond0 navngiver den aktive slave og rapporterer linktilstand for hver slave. Den fil er den eneste ærlige kilde til, hvilken port der aktuelt bærer trafik.

En vært i denne tilstand har én brugbar modtagest i gangen, valgt lokalt uden kendskab til fabric. Hvis en ramme til den vært ankommer på det andet kabel, tæller switchporten den som modtaget, værtens stak ser den aldrig, og hver tæller bortset fra værtens egen drop-tæller ser helt sund ud.

Hvad all-active multihoming gør ved et fjernt næste hop

EVPN-multihoming beskriver et sæt leafs, der deler et Ethernet-segment, identificeret af en ESI, og annoncerer det segment til resten af fabric. I all-active-modellen installerer fjerne peers mere end ét næste hop for segmentets adresser. Unicast mod serveren kan derefter ankomme til begge leafs, og fabric kan frit vælge per flow. Det er hele pointen med designet, og det er også den antagelse, serverbondet skal opfylde.

Oversvømmet trafik følger en anden regel. Leafsene vælger en udpeget forwarder per segment, så broadcast, ukendt unicast og multicast kommer normalt ind gennem en af dem. Unicast og oversvømmelse træffer derfor to separate beslutninger, og kun én af dem ses i værtens bondtilstand.

Hvor de to valg er uenige

Kernen vælger sin aktive slave ud fra linktilstand og sin egen politik. Fabric vælger næste hop ud fra EVPN-ruter og en udpeget forwarder ud fra et valg blandt leafsene. Ingen af processerne spørger den anden. Når de vælger forskellige leafs, er fejlen retningsbestemt: det, serveren sender, kommer normalt ud, og svarene forsvinder.

Der findes to understøttede udveje, og de kan ikke udskiftes. Giv værten et bond, som fabric kan behandle som én logisk tilknytning, hvilket i praksis betyder et LACP-bond forhandlet med leafsene, og begge links er reelt aktive sammen. Eller accepter også single-active levering fra fabric, så segmentet følger samme model med én port ad gangen som bondet. Det, der ikke virker, er et all-active segment foran et bond, der kun lytter på én port, medmindre du bevidst aktiverer modtagelse på de inaktive slaves og accepterer den dobbelte levering, der følger.

Hvorfor reservekablet bliver ved med at se sundt ud

Et kabel uden trafik rapporterer stadig link op, og en standby-slave i et bond er designet til at se klar ud. Operatører læser det som redundans og holder op med at stille spørgsmål.

Spørg i stedet, hvilken fysisk port returrammen brugte. På værten, tæl modtagne pakker per slave i stedet for per bond, fordi bondtælleren skjuler asymmetrien. På leafen, se på broens forwarding-poster for serverens MAC og på det næste-hop-sæt, som EVPN-ruten bærer. Hvis posten peger på den leaf, hvis vært-link er standby, leverer designet ind i en port, som værten ignorerer. Det er et konfigurationsmisforhold og ikke en hardwarefejl, og ingen mængde linktilstandsovervågning vil afsløre det.

Test levering i begge retninger, ikke linktilstand

Byg en matrix med én række per fejl og én kolonne per retning, og udfyld derefter leveret trafik i stedet for interfacetilstand. Række et er normal drift, og det er netop der, misforholdet gemmer sig, fordi symptomet ligner et applikationsproblem.

Fjern derefter det aktive vært-link, fjern en leaf, fjern den leafs uplinks, og genskab hver af dem efter tur. Noter efter hvert skridt den aktive slave, EVPN-segmentets tilstand, den fjerne forwarding-post og den målte gennemstrømning i begge retninger. En leaf, der mister sin fabric-sti, mens dens vært-link forbliver oppe, er det interessante tilfælde, fordi tilknytningen forbliver annonceret og stille kan blive en blindgyde. Test med friske unicast-flows og med den oversvømmede trafik, som applikationen afhænger af, fordi de to bruger forskellige forwarding-beslutninger.

Accepter først designet, når matrixen viser tovejslevering gennem den sti, du havde tænkt. To kabler med link op er ikke det resultat.