Stille EVPN-vert blir aldri oppløst: følg ARP-en til bindingen
En vert som sjelden sender, kan se fraværende ut selv når tilkoblingen er oppe. Følg oppløsningsutvekslingen, MAC-ruten og proxy-bindingen i rekkefølge.
Endepunktet er tilkoblet, porten er oppe, og overvåkningsverten når den fortsatt ikke. Noen kjører en ping fra den andre siden, og det begynner å virke, noe som får problemet til å se periodisk ut og fabric til å se uskyldig ut. Det mønsteret er signaturen til en stille vert: den sender sjelden, så fabricens oppdagelses- og oppfriskningsatferd betyr mer enn tilkoblingstilstanden. Start med én tiltenkt IP, MAC og bridge domain og følg den neste oppløsningsutvekslingen.
Følg den neste ARP- eller ND-utvekslingen
For IPv4, se på ARP-utvekslingen til den forespørrende verten; for IPv6, følg Neighbor Solicitation og Advertisement. Bekreft at forespørselen kommer inn i det tiltenkte lokale segmentet og den tiltenkte VNI-en, fordi en forespørsel som aldri når riktig bridge domain, ikke kan besvares av noen proxy.
Se deretter på hva fabricen vet om målet. En rute med bare MAC kan identifisere en Layer 2-destinasjon mens proxyen fortsatt ikke har noen IP-til-MAC-binding for den. Dette er separate poster, og å sjekke den ene sier ingenting om den andre.
Hvis en gyldig binding finnes, kan proxyen svare etter sin policy, men MAC-en i den bindingen trenger fortsatt en aktiv videresendingsvei. Hvis bindingen mangler, må forespørselen nå endepunktets tilkobling via flooding- eller replikeringsveien før noe kan lære av svaret.
To poster som må stemme overens
MAC-ruten svarer på hvor Ethernet-adressen bor. Proxy-tabellen svarer på hvilken IP som mapper til hvilken MAC. En vert som ikke har snakket nylig, kan ha en helt fin MAC-rute og ingen brukbar proxy-oppføring, og det er nøyaktig tilstanden som gir en oppløsningsfeil på en sunn tilkobling.
Ved den fjerne tilkoblingen, sjekk om endepunktet faktisk mottar og besvarer utvekslingen. Svaret oppfrisker lokal læring og den tilsvarende EVPN-annonsen, og derfor ser den manuelle ping-en ut til å fikse ting: du genererte trafikken fabricen ventet på. Det forklarer også hvorfor rettelsen ikke varer: når den oppfriskede oppføringen blir gammel, blir endepunktet stille igjen. En planlagt ping behandler symptomet og skjuler designhullet.
Etter svaret, følg den valgte ruten og den installerte videresendingstilstanden tilbake mot den forespørrende. At oppløsningen lykkes og at videresendingen lykkes er to separate hendelser, og en sak som blander dem, sender deg til feil lag.
Hva standarden faktisk forutsetter
RFC 9161 beskriver dynamisk proxy-læring og standard-flooding av ukjente ARP- og ND-forespørsler. Fullstendig undertrykkelse av den floodingen er begrenset til distribusjoner der lærings- eller provisjoneringsforutsetningene gjør den trygg, noe som er en snevrere betingelse enn de fleste konfigurasjonsveiledninger antyder.
En fabric som forventer nylig oppdagede endepunkter trenger en fungerende vei for disse forespørslene. Hvis noen har slått av flooding av ukjente forespørsler for å redusere BUM-trafikk, er stille verter den befolkningen som betaler for det, og symptomet kommer uker senere som en klage på periodisk tilgjengelighet.
Les undertrykkelsesinnstillingen som en erklæring om hva fabricen lover å vite. Hvis ingenting provisjonerer bindingene, er løftet ikke sant for sjeldne sendere. Sammenlign den konfigurerte undertrykkelsen med provisjoneringssystemet som skal fôre den. Når de to ikke er enige, oppfører fabricen seg nøyaktig som konfigurert, og det er forventningen som må rettes.
Oppfrisking, aldring og det statiske alternativet
Standarden beskriver støttede oppfriskningssonder før dynamiske oppføringer blir gamle. Svar oppfrisker den relevante bridge- og proxy-tilstanden; manglende svar kan legitimt føre til fjerning og tilbaketrekking av rute. Det er ikke en feil som skal undertrykkes ved å strekke hver timer.
Å forlenge aldringstimere på ubestemt tid bytter en synlig feil mot en utdatert: fabricen fortsetter å annonsere en plassering som verten har forlatt. Bruk implementeringens dokumenterte kontroller og velg en levetid som passer med hvor ofte endepunktet med rimelighet kan forventes å snakke.
For kjente, administrerte endepunkter er en statisk eller kontroller-provisjonert binding en legitim andre modell. Den trenger en eier som håndterer utskifting og flytting, fordi en provisjonert post ikke oppdaterer seg selv når verten flytter til en annen port.
Hva som skal registreres før neste sak
Hold bindingens kilde, siste oppfriskingstid, gjeldende plassering og enhver tilbaketrekkingshendelse ved siden av MAC-ruten. Den posten svarer på spørsmålet saken egentlig stiller: venter applikasjonen på oppdagelse, stoler den på utdatert tilstand, eller mislykkes den med å videresende etter vellykket oppløsning?
Bestem deretter hvilken av de tre du er villig til å drifte. Oppdagelse med flooding, oppfrisking med en realistisk levetid eller provisjonering med en eier er alle forsvarlige. En fabric som er konfigurert for én og forventes å oppføre seg som en annen, er der stille verter forsvinner.