Stille EVPN-vert vert aldri oppløyst: følg ARP-en til bindinga

Endepunktet er tilkopla, porten er oppe, og overvakingsverten når det framleis ikkje. Nokon køyrer ein ping frå den andre sida, og det byrjar å verke, noko som får problemet til å sjå periodisk ut og fabric til å sjå uskuldig ut. Det mønsteret er signaturen til ein stille vert: han sender sjeldan, så åtferda til fabric ved oppdaging og oppfrisking tyder meir enn tilkoplingsstatusen. Start med éin tiltenkt IP, MAC og bridge domain og følg den neste oppløysingsutvekslinga.

Følg den neste ARP- eller ND-utvekslinga

For IPv4, sjå på ARP-utvekslinga til den førespurnande verten; for IPv6, følg Neighbor Solicitation og Advertisement. Stadfest at førespurnaden kjem inn i det tiltenkte lokale segmentet og den tiltenkte VNI-en, fordi ein førespurnad som aldri når rett bridge domain, kan ikkje svarast av nokon proxy.

Sjå deretter på kva fabric veit om målet. Ei rute med berre MAC kan identifisere ein Layer 2-destinasjon medan proxyen framleis ikkje har noka IP-til-MAC-binding for han. Dette er separate postar, og å sjekke den eine seier ingenting om den andre.

Viss ei gyldig binding finst, kan proxyen svare etter policyen sin, men MAC-en i den bindinga treng framleis ein aktiv vidaresendingsveg. Viss bindinga manglar, må førespurnaden nå tilkoplinga til endepunktet via flooding- eller replikeringsvegen før noko kan lære av svaret.

To postar som må stemme overeins

MAC-ruta svarar på kvar Ethernet-adressa bur. Proxy-tabellen svarar på kva IP som blir mappa til kva MAC. Ein vert som ikkje har snakka nyleg, kan ha ei heilt fin MAC-rute og ingen brukbar proxy-oppføring, og det er nøyaktig tilstanden som gir ein oppløysingsfeil på ei sunn tilkopling.

Ved den fjerne tilkoplinga, sjekk om endepunktet faktisk tek imot og svarar på utvekslinga. Svaret oppfriskar lokal læring og den tilsvarande EVPN-annonsen, og difor ser den manuelle ping-en ut til å fikse ting: du genererte trafikken fabric venta på. Det forklarer òg kvifor rettinga ikkje varer: når den oppfriska oppføringa blir gamal, blir endepunktet stille igjen. Ein planlagd ping behandlar symptomet og skjuler designhola.

Etter svaret, følg den valde ruta og den installerte vidaresendingstilstanden tilbake mot den førespurnande. At oppløysinga lykkast og at vidaresendinga lykkast er to separate hendingar, og ei sak som blandar dei, sender deg til feil lag.

Kva standarden faktisk føreset

RFC 9161 skildrar dynamisk proxy-læring og standard-flooding av ukjende ARP- og ND-førespurnader. Fullstendig undertrykking av den floodinga er avgrensa til distribusjonar der lærings- eller provisjoneringsføresetnadene gjer ho trygg, noko som er eit snevrare vilkår enn dei fleste konfigurasjonsrettleidingar antyder.

Ein fabric som ventar nyleg oppdaga endepunkt treng ein fungerande veg for desse førespurnadene. Viss nokon har slått av flooding av ukjende førespurnader for å redusere BUM-trafikk, er stille vertar den befolkninga som betaler for det, og symptomet kjem veker seinare som ei klage på periodisk tilgjenge.

Les undertrykkingsinnstillinga som ei erklæring om kva fabric lovar å vite. Viss ingenting provisjonerer bindingane, er løftet ikkje sant for sjeldne sendarar. Samanlikn den konfigurerte undertrykkinga med provisjoneringssystemet som skal fø han. Når dei to ikkje er samde, oppfører fabric seg nøyaktig som konfigurert, og det er forventninga som må rettast.

Oppfrisking, aldring og det statiske alternativet

Standarden skildrar støtta oppfriskingssondar før dynamiske postar blir gamle. Svar oppfriskar den relevante bridge- og proxy-tilstanden; manglande svar kan legitimt føre til fjerning og tilbaketrekking av rute. Det er ikkje ein feil som skal undertrykkjast ved å strekkje kvar timer.

Å forlenge aldringstimar på ubestemt tid byter ein synleg feil mot ein utdatert: fabric held fram med å annonsere ein plassering som verten har forlate. Bruk dei dokumenterte kontrollane til implementasjonen og vel ei levetid som passar med kor ofte endepunktet med rimelegheit kan venteleg snakke.

For kjende, administrerte endepunkt er ei statisk eller kontroller-provisjonert binding ein legitim andre modell. Ho treng ein eigar som handterer utskifting og flytting, fordi ein provisjonert post ikkje oppdaterer seg sjølv når verten flyttar til ein annan port.

Kva som skal registrerast før neste sak

Hald kjelda til bindinga, siste oppfriskingstid, gjeldande plassering og kvar tilbaketrekkingshending ved sida av MAC-ruta. Den posten svarar på spørsmålet saka eigentleg stiller: ventar applikasjonen på oppdaging, stolar han på utdatert tilstand, eller mislykkast han med å videresende etter vellukka oppløysing?

Avgjer deretter kva av dei tre du er viljug til å drifte. Oppdaging med flooding, oppfrisking med ei realistisk levetid eller provisjonering med ein eigar er alle forsvarlege. Ein fabric som er konfigurert for éin og venta å oppføre seg som ein annan, er der stille vertar forsvinn.