Linuxov aktivno-rezervni bond na all-active EVPN segmentu: što se lomi

Postavite aktivno-rezervni bond na server i all-active Ethernet segment na fabric — i pola povratnog prometa može nestati, a da nijedan brojač grešaka ne mrdne. Nijedna konfiguracija sama po sebi nije pogrešna. Problem je u predaji između njih: jedna strana bira jedan port, a druga pretpostavlja da svaki priključeni leaf može dostaviti. Pratite jedan okvir u svakom smjeru i nesklad postaje očigledan.

Što aktivno-rezervni režim radi s dolaznim okvirom

Bonding režim 1 drži točno jedan slave u putu za prijenos i mijenja ga samo kad trenutni otkaže. Taj je dio dobro poznat. Ovdje je važna strana primanja: kernel predaje okvir stacku samo ako je stigao na aktivni slave, a odbacuje okvire koji se pojave na bilo kojem drugom slaveu. Ta all_slaves_active postavka postoji upravo zato da ublaži to pravilo i prema zadanim je vrijednostima isključena. ip -d link show bond0 ispisuje trenutnu vrijednost pokraj režima.

/proc/net/bonding/bond0 imenuje aktivni slave i izvještava o stanju veze za svaki slave. Ta je datoteka jedini iskren izvor podatka o tome koji port trenutno nosi promet.

Host u ovom režimu ima jedan upotrebljiv put primanja u datom trenutku, odabran lokalno bez znanja o fabrici. Ako okvir za taj host stigne drugim kabelom, port preklopnika ga broji kao primljen, stack hosta ga nikad ne vidi, a svi brojači osim vlastitog brojača odbačenih na hostu izgledaju posve zdravo.

Što all-active multihoming radi s udaljenim sljedećim skokom

EVPN multihoming opisuje skup leafova koji dijele jedan Ethernet segment, označen ESI-jem, i oglašava taj segment ostatku fabrike. U all-active modelu udaljeni peerovi instaliraju više od jednog sljedećeg skoka za adrese segmenta. Unicast prema serveru tada može stići na bilo koji leaf, a fabrica slobodno bira po toku. To je cijela svrha dizajna i ujedno pretpostavka koju bond na serveru mora zadovoljiti.

Poplavljeni promet slijedi drugo pravilo. Leafovi biraju određeni forwarder po segmentu, pa broadcast, nepoznati unicast i multicast obično ulaze kroz jedan od njih. Unicast i poplava zato donose dvije odvojene odluke, a samo se jedna vidi u stanju bonda na hostu.

Gdje se dva izbora razilaze

Kernel bira svoj aktivni slave prema stanju veze i vlastitoj politici. Fabrica bira sljedeće skokove prema EVPN rutama, a određeni forwarder prema izboru među leafovima. Nijedan proces ne pita drugi. Kad odaberu različite leafove, kvar ovisi o smjeru: ono što server pošalje izlazi normalno, a odgovori nestaju.

Postoje dva podržana izlaza i nisu zamjenjivi. Dajte hostu bond koji fabrica može tretirati kao jedan logički priključak, što u praksi znači LACP bond dogovoren s leafovima, pa su obje veze doista aktivne zajedno. Ili prihvatite i single-active dostavu iz fabrike, tako da segment slijedi isti model jedan-port-u-jednom-trenutku kao bond. Ono što ne radi jest all-active segment ispred bonda koji sluša samo na jednom portu, osim ako namjerno uključite primanje na neaktivnim slaveovima i prihvatite dvostruku dostavu koja slijedi.

Zašto rezervni kabel stalno izgleda zdrav

Kabel koji ne nosi promet i dalje prijavljuje vezu podignutom, a pričuvni slave u bondu je napravljen da izgleda spremno. Operateri to čitaju kao redundanciju i prestanu postavljati pitanja.

Pitajte umjesto toga koji je fizički port upotrijebio povratni okvir. Na hostu brojite primljene pakete po slaveu, a ne po bondu, jer brojač bonda skriva asimetriju. Na leafu pogledajte forwarding zapise mosta za MAC adresu servera i skup sljedećih skokova koji nosi EVPN ruta. Ako zapis pokazuje na leaf čija je veza prema hostu pričuvna, dizajn dostavlja u port koji host ignorira. To je nesklad u konfiguraciji, a ne kvar hardvera, i nikakvo praćenje stanja veze ga neće otkriti.

Testirajte dostavu u oba smjera, ne stanje veze

Napravite matricu s jednim retkom po kvaru i jednim stupcem po smjeru, pa upisujte dostavljeni promet, a ne stanje sučelja. Redak jedan je normalan rad i upravo se tu nesklad skriva, jer simptom izgleda kao problem aplikacije.

Zatim uklonite aktivnu vezu hosta, uklonite jedan leaf, uklonite uplinkove tog leafa i vratite svaki redom. Nakon svakog koraka zabilježite aktivni slave, stanje EVPN segmenta, udaljeni forwarding zapis i izmjereni protok u oba smjera. Leaf koji izgubi put prema fabrici dok mu veza prema hostu ostaje podignuta zanimljiv je slučaj, jer priključak ostaje oglašen i može tiho postati slijepa ulica. Testirajte svježim unicast tokovima i poplavljenim prometom o kojem aplikacija ovisi, jer njih dvoje koriste različite forwarding odluke.

Prihvatite dizajn samo kad matrica pokaže dvosmjernu dostavu putem puta koji ste namjeravali. Dva kabela s podignutom vezom nisu taj rezultat.