Klusais EVPN resursdators nekad netiek atrisināts: sekojiet ARP līdz saistījumam

Galapunkts ir pievienots, tā ports ir aktīvs, un uzraudzības resursdators joprojām nevar to sasniegt. Kāds palaiž ping no pretējās puses, un tas sāk darboties, kas liek problēmai izskatīties periodiskai un fabric izskatīties nevainīgam. Šis modelis ir klusa resursdatora paraksts: tas reti pārraida, tāpēc fabric atklāšanas un atjaunināšanas uzvedība ir svarīgāka par tā pievienojuma stāvokli. Sāciet ar vienu paredzētu IP, MAC un bridge domain un sekojiet nākamajai atrisināšanas apmaiņai.

Sekojiet nākamajai ARP vai ND apmaiņai

IPv4 gadījumā vērojiet pieprasītāja ARP apmaiņu; IPv6 gadījumā sekojiet Neighbor Solicitation un Advertisement. Apstipriniet, ka pieprasījums nonāk paredzētajā lokālajā segmentā un paredzētajā VNI, jo pieprasījumu, kas nekad nesasniedz pareizo bridge domain, nevar atbildēt neviens starpniekserveris.

Pēc tam apskatiet, ko fabric zina par mērķi. Maršruts tikai ar MAC var identificēt Layer 2 galamērķi, kamēr starpniekserverim vēl nav IP-to-MAC saistījuma tam. Tie ir atsevišķi ieraksti, un viena pārbaude neko nepasaka par otru.

Ja pastāv derīgs saistījums, starpniekserveris var atbildēt saskaņā ar savu politiku, bet MAC šajā saistījumā joprojām ir vajadzīgs aktīvs pārsūtīšanas ceļš. Ja saistījums nav, pieprasījumam jāsasniedz galapunkta pievienojums pa flooding vai replicēšanas ceļu, pirms kaut kas var mācīties no atbildes.

Divi ieraksti, kuriem jāsakrīt

MAC maršruts atbild, kur dzīvo Ethernet adrese. Starpniekservera tabula atbild, kura IP atbilst kurai MAC. Resursdators, kas nesen nav runājis, var būt ar pilnīgi labu MAC maršrutu un bez jebkura izmantojama starpniekservera ieraksta, un tieši šis stāvoklis rada atrisināšanas kļūmi veselā pievienojumā.

Attālajā pievienojumā pārbaudiet, vai galapunkts tiešām saņem apmaiņu un atbild uz to. Tā atbilde atjaunina lokālo mācīšanos un atbilstošo EVPN paziņojumu, tāpēc manuālais ping izskatās, ka labo lietas: jūs radījāt trafiku, uz kuru fabric gaidīja. Tas arī izskaidro, kāpēc labojums nepaliek: kad atjauninātais ieraksts noveco, galapunkts atkal kļūst kluss. Plānotais ping ārstē simptomu un slēpj dizaina plaisu.

Pēc atbildes sekojiet izvēlētajam maršrutam un instalētajam pārsūtīšanas stāvoklim atpakaļ pie pieprasītāja. Atrisināšanas panākumi un pārsūtīšanas panākumi ir divi atsevišķi notikumi, un biļete, kas tos sajauc, sūta jūs uz nepareizo slāni.

Ko standarts patiesībā pieņem

RFC 9161 apraksta dinamisko starpniekservera mācīšanos un nezināmu ARP un ND pieprasījumu noklusējuma flooding. Pilnīga šī flooding nomākšana ir ierobežota ar izvietojumiem, kuru mācīšanās vai nodrošināšanas pieņēmumi to padara drošu, kas ir šaurāks nosacījums nekā vairums konfigurācijas rokasgrāmatu norāda.

Fabric, kas sagaida nesen atklātus galapunktus, šiem pieprasījumiem vajag strādājošu ceļu. Ja kāds ir izslēdzis nezināmu pieprasījumu flooding, lai samazinātu BUM trafiku, klusie resursdatori ir tā populācija, kas par to maksā, un simptoms ierodas nedēļas vēlāk kā sūdzība par periodisku sasniedzamību.

Lasiet nomākšanas iestatījumu kā apgalvojumu par to, ko fabric sola zināt. Ja nekas nenodrošina saistījumus, solījums nav patiess retajiem sūtītājiem. Salīdziniet konfigurēto nomākšanu ar nodrošināšanas sistēmu, kurai tā būtu jābaro. Kad abas nesakrīt, fabric uzvedas tieši tā, kā konfigurēts, un labot vajag tieši gaidas.

Atjaunināšana, novecošana un statiskā alternatīva

Standarts apraksta atbalstītās atjaunināšanas zondes, pirms dinamiskie ieraksti noveco. Atbildes atjaunina attiecīgo bridge un starpniekservera stāvokli; atbilžu trūkums var likumīgi novest pie dzēšanas un maršruta atsaukšanas. Tas nav defekts, kas jānomāc, izstiepjot katru taimeri.

Novecošanas taimeru neierobežota pagarināšana apmaina redzamu kļūmi pret novecojušu: fabric turpina reklamēt vietu, kuru resursdators ir atstājis. Izmantojiet implementācijas dokumentētos vadīklas un izvēlieties mūža ilgumu, kas atbilst tam, cik bieži galapunkts saprātīgi var tikt gaidīts runājam.

Zināmiem, pārvaldītiem galapunktiem statisks vai kontrollera nodrošināts saistījums ir likumīgs otrais modelis. Tam vajag īpašnieku, kas rīkojas ar nomaiņu un pārvietošanu, jo nodrošināts ieraksts pats neatjauninās, kad resursdators pāriet uz citu portu.

Ko pierakstīt pirms nākamās biļetes

Turiet saistījuma avotu, pēdējo atjaunināšanas laiku, pašreizējo atrašanās vietu un jebkuru atsaukšanas notikumu blakus MAC maršrutam. Šis ieraksts atbild uz jautājumu, ko biļete patiešām uzdod: vai lietojumprogramma gaida atklāšanu, paļaujas uz novecojušu stāvokli vai nespēj pārsūtīt pēc veiksmīgas atrisināšanas?

Pēc tam izlemiet, kuru no trim esat gatavs darbināt. Atklāšana ar flooding, atjaunināšana ar reālistisku mūža ilgumu vai nodrošināšana ar īpašnieku — visi ir aizstāvami. Fabric, kas konfigurēts vienam un no kura tiek gaidīts uzvedība kā no cita, ir vieta, kur klusie resursdatori pazūd.