Linux aktiv-backup-bond på all-active EVPN: vad som går sönder

Sätt ett aktiv-backup-bond på servern och ett all-active Ethernet-segment på fabric, och hälften av returtrafiken kan försvinna utan att en enda felräknare rör sig. Ingen av de två konfigurationerna är fel i sig. Problemet ligger i överlämningen mellan dem, där den ena sidan väljer en enda port och den andra antar att varje ansluten löv kan leverera. Följ en ram i varje riktning och missförhållandet blir tydligt.

Vad aktiv-backup gör med en inkommande ram

Bonding-läge 1 håller exakt en slave i sändningsvägen och byter den bara när den nuvarande fallerar. Den delen är välkänd. Det som spelar roll här är mottagarsidan: kärnan lämnar bara en ram till stacken om den anländer på den aktiva slaven, och släpper ramar som dyker upp på någon annan slave. Denna all_slaves_active inställning finns just för att luckra upp den regeln, och den är av som standard. ip -d link show bond0 skriver ut det aktuella värdet bredvid läget.

/proc/net/bonding/bond0 namnger den aktiva slaven och rapporterar länkstatus för varje slave. Den filen är den enda ärliga källan till vilken port som just nu bär trafik.

En värd i detta läge har en användbar mottagningsväg i taget, vald lokalt utan kunskap om fabric. Om en ram för den värden anländer på den andra kabeln räknar switchporten den som mottagen, värdens stack ser den aldrig, och varje räknare utom värdens egen droppräknare ser helt frisk ut.

Vad all-active multihoming gör med ett avlägset nästa hopp

EVPN-multihoming beskriver en uppsättning löv som delar ett Ethernet-segment, identifierat av en ESI, och annonserar segmentet till resten av fabric. I all-active-modellen installerar avlägsna peers mer än ett nästa hopp för segmentets adresser. Unicast mot servern kan då anlända till endera leafen, och fabric får fritt välja per flöde. Det är hela poängen med designen, och det är också det antagande som serverns bond måste uppfylla.

Översvämmad trafik följer en annan regel. Löven väljer en utsedd forwarder per segment, så broadcast, okänd unicast och multicast kommer normalt in genom en av dem. Unicast och översvämning fattar därför två separata beslut, och bara ett av dem syns i en värds bondstatus.

Där de två valen går isär

Kärnan väljer sin aktiva slave utifrån länkstatus och sin egen policy. Fabric väljer nästa hopp utifrån EVPN-rutter, och en utsedd forwarder utifrån ett val bland löven. Ingen av processerna rådfrågar den andra. När de väljer olika löv är felet riktningsberoende: det servern skickar går ut normalt, och svaren försvinner.

Det finns två stödda vägar ut, och de är inte utbytbara. Ge värden ett bond som fabric kan behandla som en enda logisk anslutning, vilket i praktiken betyder ett LACP-bond förhandlat med löven, och båda länkarna är verkligen aktiva tillsammans. Eller acceptera även single-active leverans från fabric, så att segmentet följer samma modell med en port i taget som bondet. Det som inte fungerar är ett all-active segment framför ett bond som bara lyssnar på en port, om du inte medvetet slår på mottagning på de inaktiva slavarna och accepterar den dubbla leverans som följer.

Varför reservkabeln fortsätter att se frisk ut

En kabel utan trafik rapporterar ändå länk uppe, och en standby-slave i ett bond är utformad för att se redo ut. Operatörer läser det som redundans och slutar ställa frågor.

Fråga i stället vilken fysisk port returramen använde. På värden, räkna mottagna paket per slave i stället för per bond, eftersom bondräknaren döljer asymmetrin. På leafen, titta på bryggans vidarebefordringsposter för serverns MAC och på nästa-hopp-uppsättningen som EVPN-rutten bär. Om posten pekar på leafen vars värdlänk är standby, levererar designen in i en port som värden ignorerar. Det är en konfigurationsavvikelse och inte ett hårdvarufel, och ingen mängd länkstatusövervakning kommer att avslöja det.

Testa leverans i båda riktningarna, inte länkstatus

Bygg en matris med en rad per fel och en kolumn per riktning, och fyll sedan i levererad trafik i stället för gränssnittsstatus. Rad ett är normal drift, och det är just där avvikelsen gömmer sig, eftersom symptomet ser ut som ett applikationsproblem.

Ta sedan bort den aktiva värdlänken, ta bort en leaf, ta bort den leafens uplinks och återställ var och en i tur och ordning. Efter varje steg, notera den aktiva slaven, EVPN-segmentets tillstånd, den avlägsna vidarebefordringsposten och den uppmätta genomströmningen i båda riktningarna. En leaf som tappar sin fabric-väg medan dess värdlänk står kvar uppe är det intressanta fallet, eftersom anslutningen förblir annonserad och tyst kan bli en återvändsgränd. Testa med färska unicast-flöden och med den översvämmade trafik som applikationen är beroende av, eftersom de två använder olika vidarebefordringsbeslut.

Acceptera designen först när matrisen visar tvåvägsleverans genom den väg du avsåg. Två kablar med länk uppe är inte det resultatet.