Linux-bond in aktiewe rugsteunmodus op 'n alles-aktiewe EVPN: wat breek

Plaas 'n bond in aktiewe rugsteunmodus op die bediener en 'n alles-aktiewe Ethernet-segment op die netwerk, en die helfte van die terugverkeer kan verdwyn sonder dat 'n enkele foutteller beweeg. Nie een van die twee konfigurasies is op sigself verkeerd nie. Die probleem lê in die oorhandiging tussen hulle, waar die een kant 'n enkele poort kies en die ander aanneem elke aangehegte leaf kan aflewer. Volg een raam in elke rigting en die wanpassing word duidelik.

Wat aktiewe rugsteun aan 'n inkomende raam doen

Bondmodus 1 hou presies een slave in die stuurpad en ruil dit net om wanneer die huidige een faal. Daardie deel is algemeen bekend. Wat hier saak maak, is die ontvangkant: die kernel gee 'n raam slegs aan die stapel as dit op die aktiewe slave aankom, en laat val rame wat op enige ander slave verskyn. Die all_slaves_active instelling bestaan juis om daardie reël te verslap, en dit is by verstek af. ip -d link show bond0 druk die huidige waarde langs die modus.

/proc/net/bonding/bond0 noem die aktiewe slave en rapporteer skakeltoestand vir elke slave. Daardie lêer is die enigste eerlike bron vir watter poort tans verkeer dra.

'n Gasheer in hierdie modus het op 'n slag een bruikbare ontvangspad, plaaslik gekies sonder kennis van die netwerk. As 'n raam vir daardie gasheer op die ander kabel aankom, tel die skakelpoort dit as ontvang, die gasheer se stapel sien dit nooit, en elke teller behalwe die gasheer se eie wegvalteller lyk heeltemal gesond.

Wat alles-aktiewe multihoming aan 'n volgende hop op afstand doen

EVPN-multihoming beskryf 'n stel leaf-punte wat een Ethernet-segment deel, deur 'n ESI geïdentifiseer, en adverteer daardie segment aan die res van die netwerk. In die alles-aktiewe model installeer afstandporture meer as een volgende hop vir die segment se adresse. Unicast na die bediener kan dan by enige blaar aankom, en die netwerk is vry om per vloei te kies. Dit is die hele punt van die ontwerp, en dit is ook die aanname waaraan die bediener se bond moet voldoen.

Oorstroomde verkeer volg 'n ander reël. Die leaf-punte kies 'n aangewese forwarder per segment, so broadcast, onbekende unicast en multicast kom gewoonlik deur een van hulle binne. Unicast en oorstroming neem dus twee afsonderlike besluite, en net een daarvan wys in 'n gasheer se bondtoestand.

Waar die twee verkiesings verskil

Die kernel kies sy aktiewe slave uit skakeltoestand en sy eie beleid. Die netwerk kies volgende hops uit EVPN-roetes, en 'n aangewese forwarder uit 'n verkiesing onder die leaf-punte. Nie een proses raadpleeg die ander nie. Wanneer hulle verskillende leaf-punte kies, is die fout rigting-spesifiek: wat die bediener stuur, vertrek normaal, en die antwoorde verdwyn.

Daar bestaan twee ondersteunde uitweë, en hulle is nie uitruilbaar nie. Gee die gasheer 'n bond wat die netwerk as een logiese aansluiting kan behandel, wat in die praktyk 'n LACP-bond beteken wat met die leaf-punte onderhandel word, en albei skakels is werklik saam aktief. Of aanvaar ook enkel-aktiewe aflewering van die netwerk, sodat die segment dieselfde een-poort-op-'n-tyd-model as die bond volg. Wat nie werk nie, is 'n alles-aktiewe segment voor 'n bond wat net op een poort luister, tensy jy doelbewus ontvangs op die onaktiewe slaves aanskakel en die duplikaat-aflewering wat daarop volg aanvaar.

Waarom die rugsteunkabel gesond bly lyk

'n Kabel wat geen verkeer dra nie, rapporteer steeds skakel op, en 'n bystand-slave in 'n bond is ontwerp om gereed te lyk. Operateurs lees dit as oortolligheid en hou op vrae vra.

Vra eerder watter fisiese poort die terugraam gebruik het. Op die gasheer, tel ontvangde pakkette per slave eerder as per bond, want die bond-teller verberg die asimmetrie. Op die leaf, kyk na die brug se forward-inskrywings vir die bediener se MAC en na die volgende-hop-versameling wat die EVPN-roete dra. As die inskrywing na die leaf wys wie se gasheer-skakel die bystand is, lewer die ontwerp in 'n poort wat die gasheer ignoreer. Dit is 'n konfigurasie-wanpassing eerder as 'n hardewarefout, en geen mate van skakeltoestand-monitering sal dit oppervlak nie.

Toets aflewering in albei rigtings, nie skakeltoestand nie

Bou 'n matriks met een ry per fout en een kolom per rigting, en vul dan afgelewerde verkeer in eerder as koppelvlaktoestand. Ry een is normale werking, en dit is juis waar die wanpassing wegkruip, want die simptoom lyk soos 'n toepassingsprobleem.

Verwyder dan die aktiewe gasheer-skakel, verwyder een leaf, verwyder daardie leaf se uplinks, en herstel elkeen op sy beurt. Teken na elke stap die aktiewe slave, die EVPN-segmenttoestand, die afstand-forward-inskrywing en die waargenome deurvloei in albei rigtings aan. 'n Leaf wat sy netwerkpad verloor terwyl sy gasheer-skakel op bly, is die interessante geval, want die aansluiting bly geadverteer en kan stilweg 'n doodloop word. Toets met vars unicast-vloei en met die oorstroomde verkeer waarvan die toepassing afhanklik is, want die twee gebruik verskillende forward-besluite.

Aanvaar die ontwerp net wanneer die matriks tweerigting-aflewering deur die pad wys wat jy bedoel het. Twee kabels met skakel op is nie daardie resultaat nie.