Aktiva-rezerva bond de Linux sur all-active EVPN: kio rompiĝas
All-active EVPN-segmento sendas unicast al ambaŭ folioj, dum aktiva-rezerva bond de Linux aŭskultas sur unu haveno. Agordu la du modelojn antaŭ ol testi.
Metu aktivan-rezervan bond sur la servilon, metu all-active Ethernet-segmenton sur la fabrikon, kaj duono de la revena trafiko povas malaperi sen ke eĉ unu erarkalkulilo moviĝu. Neniu el la du agordoj estas malĝusta per si mem. La problemo kuŝas en la transdono inter ili, kie unu flanko elektas unu havenon kaj la alia supozas, ke ĉiu alkroĉita folio povas liveri. Sekvu unu kadron en ĉiu direkto kaj la misakordo fariĝas evidenta.
Kion aktiva-rezerva faras al alvenanta kadro
Bonda reĝimo 1 tenas ĝuste unu sklavon en la senda vojo kaj ŝanĝas ĝin nur kiam la nuna malsukcesas. Tiu parto estas bone konata. Gravas ĉi tie la riceva flanko: la kerno transdonas kadron al la stako nur se ĝi alvenas sur la aktiva sklavo, kaj forĵetas kadrojn kiuj aperas sur iu alia sklavo. Ĉi tiu all_slaves_active agordo ekzistas ĝuste por malstreĉi tiun regulon, kaj ĝi estas defaŭlte malŝaltita. ip -d link show bond0 presas la nunan valoron apud la reĝimo.
/proc/net/bonding/bond0 donas la nomon de la aktiva sklavo kaj raportas la ligan staton por ĉiu sklavo. Tiu dosiero estas la sola honesta fonto pri tio, kiu haveno nun portas trafikon.
Gastiganto en ĉi tiu reĝimo havas unu uzeblan ricevan vojon samtempe, elektitan loke sen scio pri la fabriko. Se kadro por tiu gastiganto alvenas sur la alia kablo, la ŝaltila haveno kalkulas ĝin kiel ricevitan, la gastiganta stako neniam vidas ĝin, kaj ĉiu kalkulilo krom la propra forĵeta kalkulilo de la gastiganto aspektas perfekte sana.
Kion all-active multihoming faras al fora sekva salto
EVPN-multihoming priskribas aron da folioj, kiuj dividas unu Ethernet-segmenton, identigitan per ESI, kaj anoncas tiun segmenton al la resto de la fabriko. En la all-active modelo, foraj egaluloj instalas pli ol unu sekvan salton por la adresoj de la segmento. Unicast al la servilo povas tiam alveni ĉe iu ajn folio, kaj la fabriko libere elektas laŭ fluo. Tio estas la tuta senco de la dezajno, kaj ĝi ankaŭ estas la supozo, kiun la servila bond devas plenumi.
Inundita trafiko sekvas alian regulon. La folioj elektas difinitan forwarder-on por ĉiu segmento, do broadcast, nekonata unicast kaj multicast normale eniras tra unu el ili. Unicast kaj inundado do faras du apartajn decidojn, kaj nur unu el ili aperas en la bonda stato de gastiganto.
Kie la du elektoj malkonsentas
La kerno elektas sian aktivan sklavon el la liga stato kaj sia propra politiko. La fabriko elektas sekvajn saltojn el EVPN-vojoj, kaj difinitan forwarder-on el elekto inter la folioj. Neniu procezo konsultas la alian. Kiam ili elektas malsamajn foliojn, la fiasko dependas de la direkto: kion la servilo sendas eliras normale, kaj la respondoj malaperas.
Ekzistas du subtenataj eliroj, kaj ili ne estas interŝanĝeblaj. Donu al la gastiganto bond, kiun la fabriko povas trakti kiel unu logikan alkroĉon, kio praktike signifas LACP-bond intertraktitan kun la folioj, kaj ambaŭ ligiloj estas vere aktivaj kune. Aŭ akceptu ankaŭ single-active liveradon el la fabriko, por ke la segmento sekvu la saman modelon de unu haveno samtempe kiel la bond. Kio ne funkcias estas all-active segmento antaŭ bond, kiu aŭskultas nur sur unu haveno, krom se vi intence ŝaltas ricevon sur la neaktivaj sklavoj kaj akceptas la duoblan liveradon, kiu sekvas.
Kial la rezerva kablo daŭre aspektas sana
Kablo, kiu portas neniun trafikon, tamen raportas ligon supren, kaj rezerva sklavo en bond estas desegnita por aspekti preta. Operatoroj legas tion kiel redundon kaj ĉesas demandi.
Demandu anstataŭe, kiun fizikan havenon la revena kadro uzis. Sur la gastiganto, kalkulu ricevitajn pakaĵojn por sklavo anstataŭ por bond, ĉar la bonda kalkulilo kaŝas la nesimetrion. Sur la folio, rigardu la plusendajn registrojn de la ponto por la MAC de la servilo kaj la aron da sekvaj saltoj, kiun portas la EVPN-vojo. Se la registro montras al la folio, kies gastiganta ligilo estas la rezerva, la dezajno liveras en havenon, kiun la gastiganto ignoras. Tio estas misakordo de agordo, ne aparata paneo, kaj neniu kvanto de observado de liga stato malkaŝos ĝin.
Testu liveradon en ambaŭ direktoj, ne la ligan staton
Konstruu matricon kun unu vico por fiasko kaj unu kolumno por direkto, poste plenigu liveritan trafikon anstataŭ interfacan staton. Vico unu estas normala funkciado, kaj ĝuste tie kaŝiĝas la misakordo, ĉar la simptomo aspektas kiel aplika problemo.
Poste forigu la aktivan gastigantan ligilon, forigu unu folion, forigu la suprenligojn de tiu folio, kaj restarigu ĉiun laŭvice. Post ĉiu paŝo, notu la aktivan sklavon, la staton de la EVPN-segmento, la foran plusendan registron kaj la observitan trafikon en ambaŭ direktoj. Folio, kiu perdas sian fabrikan vojon dum ĝia gastiganta ligilo restas supren, estas la interesa kazo, ĉar la alkroĉo restas anoncita kaj povas silente fariĝi sakstrato. Testu per novaj unicast-fluoj kaj per la inundita trafiko, de kiu dependas la aplikaĵo, ĉar la du uzas malsamajn plusendajn decidojn.
Akceptu la dezajnon nur kiam la matrico montras ambaŭdirektan liveradon tra la vojo, kiun vi intencis. Du kabloj kun ligo supren ne estas tiu rezulto.