Tihi gostitelj EVPN se nikoli ne razreši: sledite ARP do vezave

Končna točka je priključena, njena vrata so aktivna, gostitelj za spremljanje pa je še vedno ne doseže. Nekdo zažene ping z druge strani in začne delovati, zato je videti problem občasen, fabric pa nedolžen. Ta vzorec je podpis tihega gostitelja: redko pošilja, zato je vedenje fabric pri odkrivanju in osveževanju pomembnejše od stanja njegove povezave. Začnite z enim predvidenim IP, MAC in bridge domain ter sledite naslednji izmenjavi razreševanja.

Sledite naslednji izmenjavi ARP ali ND

Pri IPv4 opazujte izmenjavo ARP gostitelja, ki pošilja zahtevo; pri IPv6 sledite Neighbor Solicitation in Advertisement. Potrdite, da zahteva vstopi v predvideni lokalni segment in predvideni VNI, ker na zahtevo, ki nikoli ne doseže pravega bridge domain, ne more odgovoriti noben proxy.

Nato poglejte, kaj fabric ve o cilju. Pot samo z MAC lahko prepozna cilj Layer 2, medtem ko proxy zanj še nima vezave IP-to-MAC. To sta ločena zapisa in preverjanje enega ne pove nič o drugem.

Če obstaja veljavna vezava, lahko proxy odgovori v skladu s svojo politiko, vendar MAC v tej vezavi še vedno potrebuje aktivno pot posredovanja. Če vezave ni, mora zahteva doseči povezavo končne točke po poti flooding ali replikacije, preden se lahko karkoli nauči iz odgovora.

Dva zapisa, ki se morata ujemati

Pot MAC odgovarja, kje živi naslov Ethernet. Tabela proxyja odgovarja, kateri IP se preslika v kateri MAC. Gostitelj, ki nedavno ni govoril, ima lahko povsem dobro pot MAC in nobenega uporabnega vnosa proxyja, in to je natanko stanje, ki povzroči neuspeh razreševanja na zdravem priključku.

Na oddaljenem priključku preverite, ali končna točka izmenjavo resnično prejme in nanjo odgovori. Njen odgovor osveži lokalno učenje in ustrezno objavo EVPN, zato se zdi, da ročni ping stvari popravi: ustvarili ste promet, ki ga je fabric čakala. To pojasni tudi, zakaj popravek ne zdrži: ko osveženi vnos postara, končna točka spet utihne. Načrtovani ping zdravi simptom in skriva vrzel v zasnovi.

Po odgovoru sledite izbrani poti in nameščenemu stanju posredovanja nazaj proti prosilcu. Uspeh razreševanja in uspeh posredovanja sta dva ločena dogodka, in zahtevek, ki ju zmeša, vas pošlje na napačno plast.

Kaj standard dejansko predpostavlja

RFC 9161 opisuje dinamično učenje proxyja in privzeto flooding neznanih zahtev ARP in ND. Popolno zatiranje tega floodinga je omejeno na namestitve, katerih predpostavke učenja ali zagotavljanja ga naredijo varnega, kar je ožji pogoj, kot ga nakazuje večina konfiguracijskih vodnikov.

Fabric, ki pričakuje na novo odkrite končne točke, potrebuje delujočo pot za te zahteve. Če je nekdo izklopil flooding neznanih zahtev, da bi zmanjšal promet BUM, so tihi gostitelji populacija, ki to plača, simptom pa pride tedne pozneje kot pritožba zaradi občasne dosegljivosti.

Nastavitev zatiranja berite kot izjavo o tem, kaj fabric obljublja, da ve. Če nič ne zagotavlja vezav, obljuba ne velja za redke pošiljatelje. Primerjajte konfigurirano zatiranje s sistemom zagotavljanja, ki naj bi ga napajal. Ko se ta dva ne ujemata, se fabric obnaša natanko tako, kot je konfigurirana, in popraviti je treba pričakovanje.

Osveževanje, staranje in statična alternativa

Standard opisuje podprte sonde osveževanja, preden dinamični vnosi ostarijo. Odgovori osvežijo ustrezno stanje bridge in proxyja; odsotnost odgovorov lahko zakonito vodi v odstranitev in umik poti. To ni napaka, ki bi jo bilo treba zatreti z raztegovanjem vsakega časovnika.

Neomejeno podaljševanje časovnikov staranja zamenja vidno okvaro za zastarelo: fabric še naprej oglašuje lokacijo, ki jo je gostitelj zapustil. Uporabite dokumentirane kontrolnike implementacije in izberite življenjsko dobo, ki se ujema s tem, kako pogosto je mogoče razumno pričakovati, da bo končna točka spregovorila.

Za znane, upravljane končne točke je statična ali s strani krmilnika zagotovljena vezava zakonit drugi model. Potrebuje lastnika, ki skrbi za zamenjavo in premikanje, ker se zagotovljeni zapis ne posodobi sam, ko se gostitelj premakne na druga vrata.

Kaj zabeležiti pred naslednjim zahtevkom

Ob poti MAC hranite vir vezave, čas zadnjega osveževanja, trenutno lokacijo in vsak dogodek umika. Ta zapis odgovarja na vprašanje, ki ga zahtevek v resnici postavlja: ali aplikacija čaka na odkrivanje, se opira na zastarelo stanje ali po uspešnem razreševanju ne uspe posredovati?

Nato se odločite, katerega od treh ste pripravljeni upravljati. Odkrivanje s floodingom, osveževanje z realistično življenjsko dobo ali zagotavljanje z lastnikom so vsi zagovorljivi. Fabric, konfiguriran za eno in od katerega se pričakuje, da se obnaša kot drugo, je kraj, kjer tihi gostitelji izginejo.