Linux aktyvusis-rezervinis bond all-active EVPN tinkle: kas lūžta

Įdėkite aktyvųjį-rezervinį bond į serverį, all-active Ethernet segmentą į fabric tinklą, ir pusė grįžtančio srauto gali dingti nejudant nė vienam klaidų skaitikliui. Nė viena konfigūracija savaime nėra neteisinga. Problema yra jų perdavime, kai viena pusė pasirenka vieną prievadą, o kita daro prielaidą, kad kiekvienas prijungtas lapas gali pristatyti. Sekite vieną kadrą kiekviena kryptimi ir neatitikimas tampa akivaizdus.

Ką aktyvusis-rezervinis daro su gaunamu kadru

Bonding 1 režimas išlaiko tiksliai vieną slave perdavimo kelyje ir pakeičia jį tik tada, kai dabartinis sugenda. Ši dalis gerai žinoma. Čia svarbi priėmimo pusė: branduolys perduoda kadrą į steką tik tada, kai jis ateina aktyviuoju slave, o kadrus, pasirodančius bet kuriame kitame slave, numeta. Šis all_slaves_active nustatymas egzistuoja būtent tam, kad sušvelnintų tą taisyklę, ir pagal numatytuosius nustatymus jis išjungtas. ip -d link show bond0 išspausdina dabartinę reikšmę šalia režimo.

/proc/net/bonding/bond0 įvardija aktyvųjį slave ir praneša kiekvieno slave ryšio būseną. Tas failas yra vienintelis sąžiningas šaltinis, kuris prievadas šiuo metu neša srautą.

Šiame režime esantis hostas vienu metu turi vieną tinkamą priėmimo kelią, parinktą vietoje, nežinant apie fabric tinklą. Jei kadras tam hostui ateina kitu kabeliu, komutatoriaus prievadas jį skaičiuoja kaip gautą, hosto stekas jo niekada nemato, o visi skaitikliai, išskyrus paties hosto metimo skaitiklį, atrodo visiškai sveiki.

Ką all-active multihoming daro tolimam kitam šuoliui

EVPN multihoming apibūdina lapų rinkinį, kurie dalijasi vienu Ethernet segmentu, žymimu ESI, ir skelbia tą segmentą likusiam fabric tinklui. all-active modelyje tolimi peer įrengia daugiau nei vieną kitą šuolį segmento adresams. Unicast link serverio tuomet gali atvykti į bet kurį lapą, o fabric gali laisvai rinktis pagal srautą. Tai yra visa dizaino esmė, ir tai taip pat prielaida, kurią serverio bond turi atitikti.

Užtvindytas srautas laikosi kitos taisyklės. Lapai renka paskirtą forwarder kiekvienam segmentui, todėl broadcast, nežinomas unicast ir multicast paprastai įeina per vieną iš jų. Taigi unicast ir užtvindymas priima du atskirus sprendimus, ir tik vienas iš jų matomas hosto bond būsenoje.

Kur du rinkimai nesutaria

Branduolys renkasi aktyvųjį slave pagal ryšio būseną ir savo politiką. Fabric renkasi kitus šuolius pagal EVPN maršrutus, o paskirtą forwarder – pagal rinkimus tarp lapų. Nė vienas procesas nesitaria su kitu. Kai jie pasirenka skirtingus lapus, gedimas priklauso nuo krypties: tai, ką serveris siunčia, išeina normaliai, o atsakymai dingsta.

Yra du palaikomi keliai, ir jie nėra keičiami. Duokite hostui bond, kurį fabric gali traktuoti kaip vieną loginį prijungimą, o tai praktiškai reiškia su lapais suderėtą LACP bond, ir abi jungtys tikrai aktyvios kartu. Arba priimkite ir single-active pristatymą iš fabric, kad segmentas laikytųsi to paties vieno prievado modelio kaip bond. Tai, kas neveikia, yra all-active segmentas prieš bond, kuris klausosi tik viename prievade, nebent sąmoningai įjungtumėte priėmimą neaktyviuose slave ir priimtumėte dvigubą pristatymą, kuris po to seka.

Kodėl atsarginis kabelis vis dar atrodo sveikas

Kabelis, kuris neneša srauto, vis tiek praneša ryšį aukštyn, o budėjimo slave bond’e yra sukurtas atrodyti pasiruošęs. Operatoriai tai skaito kaip dubliavimą ir nustoja klausti.

Paklauskite vietoj to, kurį fizinį prievadą naudojo grįžtantis kadras. Hosto pusėje skaičiuokite gautus paketus pagal slave, o ne pagal bond, nes bond skaitiklis slepia asimetriją. Lape pažiūrėkite tiltų perdavimo įrašus serverio MAC adresui ir kitų šuolių rinkinį, kurį neša EVPN maršrutas. Jei įrašas rodo į lapą, kurio hosto jungtis yra atsarginė, dizainas pristato į prievadą, kurio hostas nepaiso. Tai konfigūracijos neatitikimas, o ne aparatūros gedimas, ir joks ryšio būsenos stebėjimas to neparodys.

Testuokite pristatymą abiem kryptimis, o ne ryšio būseną

Sukurkite matricą su viena eilute kiekvienam gedimui ir vienu stulpeliu kiekvienai krypčiai, tada užpildykite pristatytu srautu, o ne sąsajos būsena. Pirma eilutė yra normalus veikimas, ir būtent ten slepiasi neatitikimas, nes simptomas atrodo kaip programos problema.

Tada pašalinkite aktyviąją hosto jungtį, pašalinkite vieną lapą, pašalinkite to lapo uplinkus ir atstatykite kiekvieną iš eilės. Po kiekvieno žingsnio užsirašykite aktyvųjį slave, EVPN segmento būseną, tolimą perdavimo įrašą ir stebėtą pralaidumą abiem kryptimis. Lapas, kuris praranda kelią į fabric, kol jo hosto jungtis lieka aukštyn, yra įdomus atvejis, nes prijungimas lieka skelbiamas ir gali tyliai tapti aklaviete. Testuokite su naujais unicast srautais ir su užtvindytu srautu, nuo kurio priklauso programa, nes abu naudoja skirtingus perdavimo sprendimus.

Priimkite dizainą tik tada, kai matrica rodo dvikryptį pristatymą per tą kelią, kurį numatėte. Du kabeliai su ryšiu aukštyn nėra tas rezultatas.