Un host EVPN silențios nu se rezolvă niciodată: urmați ARP-ul până la legătură

Punctul final este conectat, portul său este activ, iar hostul de monitorizare tot nu îl poate atinge. Cineva rulează un ping din partea cealaltă și începe să funcționeze, ceea ce face problema să pară intermitentă și fabric-ul să pară nevinovat. Acest model este semnătura unui host silențios: transmite rar, așa că comportamentul de descoperire și reîmprospătare al fabric-ului contează mai mult decât starea conexiunii sale. Începeți cu un IP, un MAC și un bridge domain vizate și urmați următorul schimb de rezolvare.

Urmați următorul schimb ARP sau ND

Pentru IPv4, observați schimbul ARP al hostului care solicită; pentru IPv6, urmați Neighbor Solicitation și Advertisement. Confirmați că cererea intră în segmentul local vizat și în VNI-ul vizat, deoarece o cerere care nu ajunge niciodată la bridge domain-ul corect nu poate fi răspunsă de niciun proxy.

Apoi priviți ce știe fabric-ul despre țintă. O rută doar cu MAC poate identifica o destinație Layer 2 în timp ce proxy-ul încă nu are nicio legătură IP-to-MAC pentru ea. Sunt înregistrări separate, iar verificarea uneia nu spune nimic despre cealaltă.

Dacă există o legătură validă, proxy-ul poate răspunde conform politicii sale, dar MAC-ul din acea legătură are în continuare nevoie de o cale de forwarding activă. Dacă legătura lipsește, cererea trebuie să ajungă la conexiunea punctului final prin calea de flooding sau de replicare înainte ca ceva să poată învăța din răspuns.

Două înregistrări care trebuie să coincidă

Ruta MAC răspunde unde locuiește adresa Ethernet. Tabelul proxy răspunde care IP se mapează la care MAC. Un host care nu a vorbit recent poate avea o rută MAC perfect bună și nicio intrare proxy utilizabilă, iar aceasta este exact starea care produce o eroare de rezolvare pe o conexiune sănătoasă.

La conexiunea aflată la distanță, verificați dacă punctul final primește într-adevăr schimbul și răspunde la el. Răspunsul său reîmprospătează învățarea locală și anunțul EVPN corespunzător, motiv pentru care ping-ul manual pare să rezolve lucrurile: ați generat traficul pe care fabric-ul îl aștepta. Aceasta explică și de ce remedierea nu durează: odată ce intrarea reîmprospătată îmbătrânește, punctul final devine din nou silențios. Un ping programat tratează simptomul și ascunde golul de proiectare.

După răspuns, urmați ruta selectată și starea de forwarding instalată înapoi spre solicitant. Reușita rezolvării și reușita forwarding-ului sunt două evenimente separate, iar un tichet care le confundă vă trimite la stratul greșit.

Ce presupune de fapt standardul

RFC 9161 descrie învățarea dinamică a proxy-ului și flooding-ul implicit al cererilor ARP și ND necunoscute. Suprimarea completă a acel flooding este limitată la implementări ale căror ipoteze de învățare sau de provisionare îl fac sigur, ceea ce este o condiție mai îngustă decât sugerează majoritatea ghidurilor de configurare.

Un fabric care așteaptă puncte finale nou descoperite are nevoie de o cale funcțională pentru acele cereri. Dacă cineva a dezactivat flooding-ul cererilor necunoscute pentru a reduce traficul BUM, hosturile silențioase sunt populația care plătește pentru asta, iar simptomul apare săptămâni mai târziu ca o reclamație privind accesibilitatea intermitentă.

Citiți setarea de suprimare ca pe o declarație despre ce promite fabric-ul că știe. Dacă nimic nu furnizează legăturile, promisiunea nu este adevărată pentru expeditorii rari. Comparați suprimarea configurată cu sistemul de provisionare care ar trebui să o alimenteze. Când cele două nu sunt de acord, fabric-ul se comportă exact așa cum a fost configurat, iar așteptarea este cea care trebuie corectată.

Reîmprospătare, îmbătrânire și alternativa statică

Standardul descrie sonde de reîmprospătare acceptate înainte ca intrările dinamice să îmbătrânească. Răspunsurile reîmprospătează starea relevantă a bridge-ului și a proxy-ului; absența răspunsurilor poate duce în mod legitim la eliminare și la retragerea rutei. Acesta nu este un defect care să fie suprimat prin întinderea fiecărui temporizator.

Prelungirea nedeterminată a temporizatoarelor de îmbătrânire schimbă o defecțiune vizibilă cu una învechită: fabric-ul continuă să anunțe o locație pe care hostul a părăsit-o. Folosiți controalele documentate ale implementării și alegeți o durată de viață care se potrivește cu cât de des se poate aștepta în mod rezonabil ca punctul final să vorbească.

Pentru puncte finale cunoscute și gestionate, o legătură statică sau furnizată de controler este un al doilea model legitim. Are nevoie de un proprietar care se ocupă de înlocuire și de mutare, deoarece o înregistrare furnizată nu se actualizează singură când hostul se mută pe alt port.

Ce trebuie înregistrat înainte de următorul tichet

Păstrați sursa legăturii, ora ultimei reîmprospătări, locația curentă și orice eveniment de retragere lângă ruta MAC. Acea înregistrare răspunde la întrebarea pe care tichetul o pune de fapt: aplicația așteaptă descoperirea, se bazează pe o stare învechită sau nu reușește să transmită după o rezolvare reușită?

Apoi decideți pe care dintre cele trei sunteți dispus să îl operați. Descoperirea cu flooding, reîmprospătarea cu o durată de viață realistă sau provisionarea cu un proprietar sunt toate de apărat. Un fabric configurat pentru una și de la care se așteaptă să se comporte ca alta este locul unde hosturile silențioase dispar.