Stille EVPN-værter bliver aldrig opløst: følg ARP'en til bindingen

Endepunktet er tilsluttet, dets port er oppe, og overvågningsværten kan stadig ikke nå det. Nogen kører en ping fra den anden side, og det begynder at virke, hvilket får problemet til at se periodisk ud og fabric til at se uskyldig ud. Det mønster er signaturen på en stille vært: den sender sjældent, så fabric'ens adfærd ved opdagelse og opfriskning betyder mere end dens tilslutningstilstand. Start med én tiltænkt IP, MAC og bridge domain, og følg den næste opløsningsudveksling.

Følg den næste ARP- eller ND-udveksling

For IPv4 skal du holde øje med den anmodende vært ARP-udveksling; for IPv6 skal du følge Neighbor Solicitation og Advertisement. Bekræft, at anmodningen går ind i det tiltænkte lokale segment og det tiltænkte VNI, for en anmodning, der aldrig når det rigtige bridge domain, kan ingen proxy svare på.

Se derefter på, hvad fabric ved om målet. En rute med kun MAC kan identificere en Layer 2-destination, mens proxyen stadig ikke har nogen IP-til-MAC-binding for den. Det er separate poster, og at kontrollere den ene siger intet om den anden.

Hvis der findes en gyldig binding, kan proxyen svare efter sin politik, men MAC'en i den binding har stadig brug for en aktiv videresendelsesvej. Hvis bindingen mangler, skal anmodningen nå endepunktets tilslutning gennem flooding- eller replikeringsvejen, før noget kan lære af svaret.

To poster, der skal stemme overens

MAC-ruten svarer på, hvor Ethernet-adressen bor. Proxy-tabellen svarer på, hvilken IP der mapper til hvilken MAC. En vært, der ikke har talt for nylig, kan have en helt fin MAC-rute og ingen brugbar proxy-post, og det er præcis den tilstand, der giver en opløsningsfejl på en sund tilslutning.

Ved den fjerne tilslutning skal du kontrollere, om endepunktet faktisk modtager og besvarer udvekslingen. Dets svar opfrisker lokal læring og den tilsvarende EVPN-meddelelse, og derfor ser den manuelle ping ud til at rette tingene: du genererede den trafik, fabric ventede på. Det forklarer også, hvorfor rettelsen ikke holder: når den opfriskede post udløber, bliver endepunktet stille igen. En planlagt ping behandler symptomet og skjuler designhullet.

Følg efter svaret den valgte rute og den installerede videresendelsestilstand tilbage mod den anmodende part. At opløsning lykkes, og at videresendelse lykkes, er to separate begivenheder, og en sag, der blander dem sammen, sender dig til det forkerte lag.

Hvad standarden faktisk forudsætter

RFC 9161 beskriver dynamisk proxy-læring og standard-flooding af ukendte ARP- og ND-anmodninger. Fuld undertrykkelse af den flooding er begrænset til installationer, hvis lærings- eller provisioningantagelser gør den sikker, hvilket er en snævrere betingelse, end de fleste konfigurationsvejledninger antyder.

En fabric, der forventer nyligt opdagede endepunkter, har brug for en fungerende vej for de anmodninger. Hvis nogen har deaktiveret flooding af ukendte anmodninger for at reducere BUM-trafik, er stille værter den befolkning, der betaler for det, og symptomet kommer uger senere som en klage over periodisk tilgængelighed.

Læs undertrykkelsesindstillingen som en erklæring om, hvad fabric lover at vide. Hvis intet provisionerer bindingerne, er løftet ikke sandt for sjældne sendere. Sammenlign den konfigurerede undertrykkelse med det provisioning-system, der skal fodre den. Når de to er uenige, opfører fabric sig præcis som konfigureret, og det er forventningen, der skal rettes.

Opfriskning, aldring og det statiske alternativ

Standarden beskriver understøttede opfriskningssonder, før dynamiske poster udløber. Svar opfrisker den relevante bridge- og proxy-tilstand; manglende svar kan med rette føre til fjernelse og tilbagetrækning af rute. Det er ikke en fejl, der skal undertrykkes ved at strække hver timer.

At forlænge aldringstimere på ubestemt tid bytter en synlig fejl for en forældet: fabric bliver ved med at annoncere en placering, som værten har forladt. Brug implementeringens dokumenterede kontroller, og vælg en levetid, der passer til, hvor ofte endepunktet med rimelighed kan forventes at tale.

For kendte, administrerede endepunkter er en statisk eller controller-provisioneret binding en legitim anden model. Den kræver en ejer, der håndterer udskiftning og flytning, fordi en provisioneret post ikke opdaterer sig selv, når værten flytter til en anden port.

Hvad skal registreres før den næste sag

Hold bindingens kilde, sidste opfriskningstid, aktuel placering og enhver tilbagetrækningsbegivenhed ved siden af MAC-ruten. Den post besvarer det spørgsmål, sagen egentlig stiller: venter applikationen på opdagelse, stoler den på en forældet tilstand, eller undlader den at videresende efter vellykket opløsning?

Beslut derefter, hvilken af de tre du er villig til at drive. Opdagelse med flooding, opfriskning med en realistisk levetid eller provisioning med en ejer er alle forsvarlige. En fabric, der er konfigureret til én og forventes at opføre sig som en anden, er der, hvor stille værter forsvinder.