Tihi EVPN host se nikada ne razrješava: pratite ARP do vezivanja

Krajnja točka je priključena, njen port je aktivan, a nadzorni host je još uvijek ne može dosegnuti. Netko pokrene ping s druge strane i to počne raditi, zbog čega problem izgleda povremeno, a fabric izgleda nedužno. Taj obrazac je potpis tihog hosta: rijetko odašilje, pa je ponašanje fabrica pri otkrivanju i osvježavanju važnije od stanja njegovog priključka. Počnite s jednom namjenskom IP adresom, MAC adresom i bridge domainom i pratite sljedeću razmjenu razrješavanja.

Pratite sljedeću ARP ili ND razmjenu

Za IPv4 promatrajte ARP razmjenu hosta koji šalje zahtjev; za IPv6 pratite Neighbor Solicitation i Advertisement. Potvrdite da zahtjev ulazi u namjeravani lokalni segment i namjeravani VNI, jer zahtjev koji nikada ne dosegne pravi bridge domain ne može odgovoriti nijedan proxy.

Zatim pogledajte što fabric zna o cilju. Ruta samo s MAC adresom može identificirati Layer 2 odredište dok proxy još nema vezivanje IP-to-MAC za njega. To su odvojeni zapisi i provjera jednog ne govori ništa o drugom.

Ako valjano vezivanje postoji, proxy može odgovoriti u skladu sa svojom politikom, ali MAC u tom vezivanju još uvijek treba aktivan put prosljeđivanja. Ako vezivanje nedostaje, zahtjev mora doći do priključka krajnje točke kroz put floodinga ili replikacije prije nego što se išta može naučiti iz odgovora.

Dva zapisa koja se moraju slagati

MAC ruta odgovara gdje živi Ethernet adresa. Proxy tablica odgovara koji se IP preslikava na koji MAC. Host koji nedavno nije govorio može imati potpuno dobru MAC rutu i nikakav upotrebljiv proxy zapis, a to je upravo stanje koje proizvodi neuspjeh razrješavanja na zdravom priključku.

Na udaljenom priključku provjerite prima li krajnja točka razmjenu i odgovara li na nju. Njen odgovor osvježava lokalno učenje i odgovarajuću EVPN objavu, zato se čini da ručni ping popravlja stvar: generirali ste promet koji je fabric čekao. To također objašnjava zašto popravak ne traje: nakon što osvježeni zapis istekne, krajnja točka ponovno utihne. Zakazani ping liječi simptom i skriva nedostatak u dizajnu.

Nakon odgovora pratite odabranu rutu i instalirano stanje prosljeđivanja natrag prema pošiljatelju zahtjeva. Uspjeh razrješavanja i uspjeh prosljeđivanja dva su odvojena događaja, a tiket koji ih spaja vodi vas na pogrešan sloj.

Što standard zapravo pretpostavlja

RFC 9161 opisuje dinamičko učenje proxyja i zadano flooding nepoznatih ARP i ND zahtjeva. Potpuno potiskivanje tog floodinga ograničeno je na implementacije čije pretpostavke o učenju ili provisioningu to čine sigurnim, što je uži uvjet nego što implicira većina konfiguracijskih vodiča.

Fabric koji očekuje novo otkrivene krajnje točke treba radni put za te zahtjeve. Ako je netko onemogućio flooding nepoznatih zahtjeva da smanji BUM promet, tihi hostovi su populacija koja to plaća, a simptom dolazi tjednima kasnije kao pritužba na povremenu dostupnost.

Čitajte postavku potiskivanja kao izjavu o tome što fabric obećava znati. Ako ništa ne osigurava vezivanja, obećanje nije istinito za rijetke pošiljatelje. Usporedite konfigurirano potiskivanje sa sustavom za provisioning koji bi ga trebao napajati. Kada se ta dva ne slažu, fabric se ponaša točno onako kako je konfiguriran, a očekivanje je ono što treba popraviti.

Osvježavanje, starenje i statična alternativa

Standard opisuje podržane probe osvježavanja prije nego dinamički zapisi isteknu. Odgovori osvježavaju relevantno stanje bridgea i proxyja; izostanak odgovora može legitimno dovesti do uklanjanja i povlačenja rute. To nije bug koji treba potisnuti rastezanjem svakog tajmera.

Beskonačno produljenje tajmera starenja mijenja vidljiv neuspjeh za zastarjeli: fabric nastavlja oglašavati lokaciju koju je host napustio. Koristite dokumentirane kontrole implementacije i odaberite životni vijek koji odgovara tome kako često se krajnja točka razumno može očekivati da govori.

Za poznate, upravljane krajnje točke statično ili od kontrolera osigurano vezivanje legitiman je drugi model. Treba vlasnika koji se bavi zamjenom i premještanjem, jer se osigurani zapis ne ažurira sam kada se host premjesti na drugi port.

Što zabilježiti prije sljedećeg tiketa

Držite izvor vezivanja, vrijeme zadnjeg osvježavanja, trenutnu lokaciju i svaki događaj povlačenja uz MAC rutu. Taj zapis odgovara na pitanje koje tiket zapravo postavlja: čeka li aplikacija otkrivanje, oslanja li se na zastarjelo stanje ili ne uspijeva proslijediti nakon uspješnog razrješavanja?

Zatim odlučite koji ste od tri spremni upravljati. Otkrivanje s floodingom, osvježavanje s realističnim životnim vijekom ili provisioning s vlasnikom svi su obranjivi. Fabric konfiguriran za jedno, a od kojeg se očekuje da se ponaša kao drugo, mjesto je gdje tihi hostovi nestaju.