Aktivno-rezervni bond Linuxa na all-active EVPN: kaj se zlomi

Na strežnik postavite aktivno-rezervni bond, na fabric pa segment all-active Ethernet, in polovica povratnega prometa lahko izgine, ne da bi se premaknil en sam števec napak. Nobena od obeh konfiguracij ni sama po sebi napačna. Težava je v predaji med njima: ena stran izbere ena vrata, druga pa predpostavlja, da lahko vsak priključen list dostavi. Sledite enemu okvirju v vsako smer in neskladje postane očitno.

Kaj aktivno-rezervni način naredi s prihajajočim okvirjem

Način povezovanja 1 drži natanko en slave na poti pošiljanja in ga zamenja le, ko trenutni odpove. Ta del je dobro znan. Tu je pomembna stran sprejemanja: jedro preda okvir skladu le, če prispe na aktivni slave, okvire, ki se pojavijo na drugem slave, pa zavrže. Ta all_slaves_active nastavitev obstaja prav zato, da omili to pravilo, in je privzeto izklopljena. ip -d link show bond0 izpiše trenutno vrednost ob načinu.

/proc/net/bonding/bond0 poimenuje aktivni slave in poroča stanje povezave za vsak slave. Ta datoteka je edini pošten vir o tem, katera vrata trenutno nosijo promet.

Gostitelj v tem načinu ima hkrati eno uporabno pot sprejemanja, izbrano lokalno brez vedenja o fabricu. Če okvir za tega gostitelja prispe po drugem kablu, vrata stikala ga štejejo kot prejetega, sklad gostitelja ga nikoli ne vidi, vsi števci razen lastnega števca zavrženih na gostitelju pa so videti povsem zdravi.

Kaj all-active multihoming naredi z oddaljenim naslednjim skokom

EVPN multihoming opisuje množico listov, ki si delijo en segment Ethernet, označen z ESI, in ta segment oglašuje preostanku fabrica. V modelu all-active oddaljeni peerji namestijo več kot en naslednji skok za naslove segmenta. Unicast proti strežniku lahko zato prispe na katerikoli list, fabric pa lahko prosto izbira po toku. To je ves smisel zasnove in hkrati predpostavka, ki jo mora bond strežnika izpolniti.

Poplavljeni promet sledi drugemu pravilu. Listi izberejo določen forwarder na segment, zato broadcast, neznani unicast in multicast običajno vstopajo skozi enega od njih. Unicast in poplavljanje torej sprejmeta dve ločeni odločitvi, v stanju bonda gostitelja pa se pokaže le ena.

Kje se izbiri razhajata

Jedro izbere svoj aktivni slave glede na stanje povezave in lastno politiko. Fabric izbere naslednje skoke glede na poti EVPN, določen forwarder pa glede na izbiro med listi. Noben proces se ne posvetuje z drugim. Ko izbereta različne liste, je napaka odvisna od smeri: kar strežnik pošlje, odide normalno, odgovori pa izginejo.

Obstajata dva podprta izhoda in nista zamenljiva. Gostitelju dajte bond, ki ga fabric lahko obravnava kot eno logično priključitev, kar v praksi pomeni bond LACP, dogovorjen z listi, in obe povezavi sta resnično aktivni skupaj. Ali pa sprejmite tudi dostavo single-active iz fabrica, da segment sledi istemu modelu enih vrat naenkrat kot bond. Kar ne deluje, je segment all-active pred bondom, ki posluša le na enih vratih, razen če namerno vklopite sprejemanje na neaktivnih slave in sprejmete dvojno dostavo, ki temu sledi.

Zakaj rezervni kabel še vedno izgleda zdrav

Kabel, ki ne nosi prometa, še vedno poroča o povezavi navzgor, pripravljeni slave v bondu pa je zasnovan tako, da je videti pripravljen. Operaterji to berejo kot redundanco in nehajo spraševati.

Vprašajte raje, katera fizična vrata je uporabil povratni okvir. Na gostitelju štejte prejete pakete po slave, ne po bondu, ker števec bonda skriva asimetrijo. Na listu poglejte preusmeritvene zapise mostu za MAC naslov strežnika in množico naslednjih skokov, ki jo nosi pot EVPN. Če zapis kaže na list, katerega povezava z gostiteljem je rezervna, zasnova dostavlja v vrata, ki jih gostitelj ignorira. To je neskladje konfiguracije, ne okvara strojne opreme, in nobeno spremljanje stanja povezave ga ne bo razkrilo.

Testirajte dostavo v obe smeri, ne stanja povezave

Zgradite matriko z eno vrstico na okvaro in enim stolpcem na smer, nato jo napolnite z dostavljenim prometom, ne s stanjem vmesnika. Prva vrstica je običajno delovanje in prav tam se neskladje skriva, ker je simptom videti kot težava aplikacije.

Nato odstranite aktivno povezavo gostitelja, odstranite en list, odstranite uplinke tega lista in vsakega po vrsti obnovite. Po vsakem koraku zapišite aktivni slave, stanje segmenta EVPN, oddaljeni preusmeritveni zapis in izmerjeno prepustnost v obe smeri. List, ki izgubi pot do fabrica, medtem ko njegova povezava z gostiteljem ostane navzgor, je zanimiv primer, ker priključitev ostane oglaševana in lahko tiho postane slepa ulica. Testirajte s svežimi tokovi unicast in s poplavljenim prometom, od katerega je odvisna aplikacija, ker oba uporabljata različne preusmeritvene odločitve.

Zasnovo sprejmite le, ko matrika pokaže dvosmerno dostavo po načrtovani poti. Dva kabla s povezavo navzgor nista ta rezultat.