Linux actief-backup-bond op all-active EVPN: wat er breekt

Zet een actief-backup-bond op de server en een all-active Ethernet-segment op de fabric, en de helft van het retourverkeer kan verdwijnen zonder dat één foutteller beweegt. Geen van beide configuraties is op zichzelf fout. Het probleem zit in de overdracht ertussen, waar de ene kant één poort kiest en de andere aanneemt dat elke aangesloten leaf kan leveren. Volg één frame in elke richting en de mismatch wordt duidelijk.

Wat actief-backup doet met een inkomend frame

Bonding-modus 1 houdt precies één slave in het verzendpad en wisselt die alleen als de huidige uitvalt. Dat deel is bekend. Wat hier telt, is de ontvangstkant: de kernel geeft een frame alleen aan de stack als het op de actieve slave aankomt, en laat frames vallen die op een andere slave verschijnen. Deze all_slaves_active instelling bestaat juist om die regel te versoepelen, en staat standaard uit. ip -d link show bond0 drukt de huidige waarde naast de modus af.

/proc/net/bonding/bond0 noemt de actieve slave en meldt de linkstatus per slave. Dat bestand is de enige eerlijke bron voor welke poort op dit moment verkeer draagt.

Een host in deze modus heeft tegelijk één bruikbaar ontvangstpad, lokaal gekozen zonder kennis van de fabric. Als een frame voor die host op de andere kabel aankomt, telt de switchpoort het als ontvangen, de stack van de host ziet het nooit, en elke teller behalve de eigen dropteller van de host ziet er volkomen gezond uit.

Wat all-active multihoming doet met een volgende hop op afstand

EVPN-multihoming beschrijft een set leaves die één Ethernet-segment delen, geïdentificeerd door een ESI, en adverteert dat segment naar de rest van de fabric. In het all-active-model installeren externe peers meer dan één volgende hop voor de adressen van het segment. Unicast naar de server kan dan op beide leaves aankomen, en de fabric mag per flow kiezen. Dat is het hele punt van het ontwerp, en het is ook de aanname waaraan de bond van de server moet voldoen.

Geflood verkeer volgt een andere regel. De leaves kiezen per segment een aangewezen forwarder, dus broadcast, onbekend unicast en multicast komen normaal via één van hen binnen. Unicast en flooding nemen dus twee afzonderlijke beslissingen, en slechts één daarvan is zichtbaar in de bondstatus van een host.

Waar de twee keuzes uiteenlopen

De kernel kiest zijn actieve slave op basis van linkstatus en zijn eigen beleid. De fabric kiest volgende hops op basis van EVPN-routes, en een aangewezen forwarder op basis van een keuze tussen de leaves. Geen van beide processen raadpleegt het andere. Als ze verschillende leaves kiezen, is de storing richtingspecifiek: wat de server stuurt, gaat normaal naar buiten, en de antwoorden verdwijnen.

Er zijn twee ondersteunde uitwegen, en ze zijn niet uitwisselbaar. Geef de host een bond die de fabric als één logische aansluiting kan behandelen, wat in de praktijk een met de leaves onderhandelde LACP-bond betekent, en beide links zijn echt samen actief. Of accepteer ook single-active levering vanuit de fabric, zodat het segment hetzelfde model van één poort tegelijk volgt als de bond. Wat niet werkt, is een all-active segment voor een bond die maar op één poort luistert, tenzij je bewust ontvangst op de inactieve slaves inschakelt en de dubbele levering die daarop volgt accepteert.

Waarom de reservekabel gezond blijft lijken

Een kabel zonder verkeer meldt nog steeds link omhoog, en een standby-slave in een bond is ontworpen om gereed te lijken. Operators lezen dat als redundantie en stoppen met vragen.

Vraag in plaats daarvan welke fysieke poort het retourframe gebruikte. Op de host, tel ontvangen pakketten per slave in plaats van per bond, want de bondteller verbergt de asymmetrie. Op de leaf, kijk naar de doorstuuraantekeningen van de bridge voor de MAC van de server en naar de set volgende hops die de EVPN-route draagt. Wijst de aantekening naar de leaf waarvan de hostlink de standby is, dan levert het ontwerp in een poort die de host negeert. Dat is een configuratiemismatch en geen hardwarefout, en geen enkele mate van linkstatusmonitoring zal het aan het licht brengen.

Test levering in beide richtingen, niet de linkstatus

Bouw een matrix met één rij per storing en één kolom per richting, en vul geleverd verkeer in in plaats van interfacestatus. Rij één is normale werking, en precies daar verbergt de mismatch zich, omdat het symptoom op een applicatieprobleem lijkt.

Verwijder daarna de actieve hostlink, verwijder één leaf, verwijder de uplinks van die leaf, en herstel elk op zijn beurt. Noteer na elke stap de actieve slave, de toestand van het EVPN-segment, de externe doorstuuraantekening en de waargenomen doorvoer in beide richtingen. Een leaf die zijn fabricpad verliest terwijl de hostlink omhoog blijft, is het interessante geval, omdat de aansluiting aangekondigd blijft en stil een doodlopende weg kan worden. Test met verse unicast-flows en met het gefloode verkeer waarvan de applicatie afhankelijk is, omdat beide verschillende doorstuurbeslissingen gebruiken.

Accepteer het ontwerp alleen wanneer de matrix tweerichtingslevering via het bedoelde pad laat zien. Twee kabels met link omhoog zijn niet dat resultaat.