Linux aktīvā-rezerves bond uz all-active EVPN: kas lūzt

Uzlieciet serverim aktīvo-rezerves bond, fabric tīklam all-active Ethernet segmentu, un puse atgriešanās trafika var pazust, nekustoties nevienam kļūdu skaitītājam. Neviena no abām konfigurācijām pati par sevi nav nepareiza. Problēma ir to savstarpējā nodošanā, kur viena puse izvēlas vienu portu, bet otra pieņem, ka katra pievienotā lapa spēj piegādāt. Sekojiet vienam kadram katrā virzienā, un neatbilstība kļūst acīmredzama.

Ko aktīvais-rezerves dara ar ienākošo kadru

Bonding režīms 1 notur tieši vienu slave pārraides ceļā un nomaina to tikai tad, kad esošais sabrūk. Šī daļa ir labi zināma. Šeit svarīga ir uztveršanas puse: kodols nodod kadru stekam tikai tad, ja tas pienāk uz aktīvā slave, un izmet kadrus, kas parādās uz jebkura cita slave. Šis all_slaves_active iestatījums pastāv tieši tāpēc, lai šo noteikumu mīkstinātu, un pēc noklusējuma tas ir izslēgts. ip -d link show bond0 izdrukā pašreizējo vērtību līdzās režīmam.

/proc/net/bonding/bond0 nosauc aktīvo slave un ziņo saites stāvokli katram slave. Šis fails ir vienīgais godīgais avots par to, kurš ports pašlaik nes trafiku.

Hostam šajā režīmā vienlaikus ir viens izmantojams uztveršanas ceļš, kas izvēlēts lokāli, nezinot par fabric tīklu. Ja kadrs šim hostam pienāk pa otru kabeli, komutatora ports to skaita kā saņemtu, hosta steks to nekad neredz, un visi skaitītāji, izņemot paša hosta nomešanas skaitītāju, izskatās pilnīgi veseli.

Ko all-active multihoming dara ar attālu nākamo lēcienu

EVPN multihoming apraksta lapu kopu, kas kopīgo vienu Ethernet segmentu, kas identificēts ar ESI, un izziņo šo segmentu pārējam fabric tīklam. all-active modelī attālie peer uzstāda vairāk nekā vienu nākamo lēcienu segmenta adresēm. Unicast pret serveri tad var nonākt uz jebkuras lapas, un fabric var brīvi izvēlēties katram plūsmam. Tā ir visa dizaina jēga, un tā ir arī pieņēmums, kuru servera bondam jāizpilda.

Pārplūdušais trafiks ievēro citu noteikumu. Lapas ievēlē nozīmētu forwarder katram segmentam, tāpēc broadcast, nezināmais unicast un multicast parasti ienāk pa vienu no tiem. Tādējādi unicast un pārplūde pieņem divus atsevišķus lēmumus, un tikai viens no tiem parādās hosta bonda stāvoklī.

Kur abas izvēles atšķiras

Kodols izvēlas savu aktīvo slave pēc saites stāvokļa un savas politikas. Fabric izvēlas nākamos lēcienus pēc EVPN maršrutiem, bet nozīmēto forwarder — pēc vēlēšanām starp lapām. Neviens process nekonsultējas ar otru. Kad tie izvēlas dažādas lapas, kļūme ir atkarīga no virziena: tas, ko serveris sūta, iziet normāli, un atbildes pazūd.

Pastāv divi atbalstīti izejas ceļi, un tie nav savstarpēji aizstājami. Dodiet hostam bond, ko fabric var uzskatīt par vienu loģisku pieslēgumu, kas praksē nozīmē ar lapām saskaņotu LACP bond, un abas saites tiešām ir aktīvas kopā. Vai arī pieņemiet single-active piegādi no fabric, lai segments ievērotu to pašu viena porta modeli kā bonds. Tas, kas nestrādā, ir all-active segments bonda priekšā, kas klausās tikai vienā portā, ja vien jūs apzināti neieslēdzat uztveršanu uz neaktīvajiem slave un nepieņemat sekojošo dubulto piegādi.

Kāpēc rezerves kabelis joprojām izskatās vesels

Kabelis, kas nenes trafiku, tomēr ziņo saiti augšup, un gaidīšanas slave bondā ir veidots tā, lai izskatītos gatavs. Operatori to uztver kā dublēšanu un pārstāj jautāt.

Tā vietā jautājiet, kuru fizisko portu izmantoja atgriešanās kadrs. Uz hosta skaitiet saņemtos paketes pa slave, nevis pa bond, jo bonda skaitītājs slēpj asimetriju. Uz lapas apskatiet tiltiņa pārsūtīšanas ierakstus servera MAC adresei un nākamo lēcienu kopu, ko nes EVPN maršruts. Ja ieraksts norāda uz lapu, kuras hosta saite ir rezerves, dizains piegādā portā, ko hosts ignorē. Tā ir konfigurācijas neatbilstība, nevis aparatūras kļūme, un nekāda saites stāvokļa uzraudzība to neatklās.

Testējiet piegādi abos virzienos, nevis saites stāvokli

Izveidojiet matricu ar vienu rindu katram bojājumam un vienu kolonnu katram virzienam, pēc tam aizpildiet ar piegādāto trafiku, nevis saskarnes stāvokli. Pirmā rinda ir normāla darbība, un tieši tur slēpjas neatbilstība, jo simptoms izskatās kā lietojumprogrammas problēma.

Pēc tam noņemiet aktīvo hosta saiti, noņemiet vienu lapu, noņemiet tās lapas uplinkus un atjaunojiet katru pēc kārtas. Pēc katra soļa pierakstiet aktīvo slave, EVPN segmenta stāvokli, attālo pārsūtīšanas ierakstu un novēroto caurlaidību abos virzienos. Lapa, kas zaudē savu ceļu uz fabric, kamēr tās hosta saite paliek augšup, ir interesantais gadījums, jo pieslēgums paliek izziņots un var klusi kļūt par strupceļu. Testējiet ar svaigām unicast plūsmām un ar pārplūdušo trafiku, no kura atkarīga lietojumprogramma, jo abi izmanto atšķirīgus pārsūtīšanas lēmumus.

Pieņemiet dizainu tikai tad, kad matrica uzrāda divvirzienu piegādi pa to ceļu, kuru bijāt iecerējis. Divi kabeļi ar saiti augšup nav tas rezultāts.