Tyst EVPN-värd löses aldrig upp: följ ARP:en till bindningen

Ändpunkten är ansluten, porten är uppe och övervakningsvärden når den fortfarande inte. Någon kör en ping från andra sidan och det börjar fungera, vilket får problemet att verka intermittent och fabric att verka oskyldig. Det mönstret är signaturen för en tyst värd: den sänder sällan, så fabricens upptäckts- och uppdateringsbeteende betyder mer än dess anslutningsstatus. Börja med en avsedd IP, MAC och bridge domain och följ nästa upplösningsutbyte.

Följ nästa ARP- eller ND-utbyte

För IPv4, titta på den frågande värdens ARP-utbyte; för IPv6, följ Neighbor Solicitation och Advertisement. Bekräfta att begäran kommer in i det avsedda lokala segmentet och det avsedda VNI:t, eftersom en begäran som aldrig når rätt bridge domain inte kan besvaras av någon proxy.

Titta sedan på vad fabric vet om målet. En rutt med bara MAC kan identifiera en Layer 2-destination medan proxyn ännu inte har någon IP-till-MAC-bindning för den. Det är separata poster, och att kontrollera den ena säger ingenting om den andra.

Om en giltig bindning finns kan proxyn svara enligt sin policy, men MAC:en i den bindningen behöver fortfarande en aktiv vidarebefordringsväg. Om bindningen saknas måste begäran nå ändpunktens anslutning via flooding- eller replikeringsvägen innan något kan lära sig av svaret.

Två poster som måste stämma överens

MAC-rutten svarar på var Ethernet-adressen bor. Proxytabellen svarar på vilken IP som mappar till vilken MAC. En värd som inte har talat nyligen kan ha en helt bra MAC-rutt och ingen användbar proxy-post, och det är precis det tillstånd som ger ett upplösningsfel på en frisk anslutning.

Vid den avlägsna anslutningen, kontrollera om ändpunkten faktiskt tar emot och besvarar utbytet. Dess svar uppdaterar den lokala inlärningen och motsvarande EVPN-annons, vilket är varför den manuella pingen verkar lösa saken: du genererade trafiken som fabric väntade på. Det förklarar också varför åtgärden inte håller: när den uppdaterade posten åldras blir ändpunkten tyst igen. En schemalagd ping behandlar symptomet och döljer designluckan.

Efter svaret, följ den valda rutten och det installerade vidarebefordringstillståndet tillbaka mot den frågande. Att upplösningen lyckas och att vidarebefordringen lyckas är två separata händelser, och ett ärende som blandar dem skickar dig till fel lager.

Vad standarden faktiskt förutsätter

RFC 9161 beskriver dynamisk proxyinlärning och standardflooding av okända ARP- och ND-begäranden. Fullständig undertryckning av den floodingen är begränsad till driftsättningar vars inlärnings- eller provisioneringsantaganden gör den säker, vilket är ett snävare villkor än de flesta konfigurationsguider antyder.

En fabric som förväntar sig nyligen upptäckta ändpunkter behöver en fungerande väg för dessa begäranden. Om någon har stängt av flooding av okända begäranden för att minska BUM-trafik är tysta värdar den befolkning som betalar för det, och symptomet kommer veckor senare som ett klagomål på intermittent nåbarhet.

Läs undertryckningsinställningen som ett uttalande om vad fabric lovar att veta. Om ingenting provisionerar bindningarna är löftet inte sant för sällsynta avsändare. Jämför den konfigurerade undertryckningen med provisioneringssystemet som ska mata den. När de två inte stämmer överens beter sig fabric exakt som konfigurerat, och det är förväntan som behöver rättas.

Uppdatering, åldring och det statiska alternativet

Standarden beskriver stödda uppdateringsprober innan dynamiska poster åldras. Svar uppdaterar relevant bridge- och proxytillstånd; uteblivna svar kan legitimt leda till borttagning och återkallande av rutt. Det är inte en bugg som ska undertryckas genom att sträcka ut varje timer.

Att förlänga åldringstimrar obegränsat byter ett synligt fel mot ett inaktuellt: fabric fortsätter annonsera en plats som värden har lämnat. Använd implementeringens dokumenterade kontroller och välj en livstid som matchar hur ofta ändpunkten rimligen kan förväntas tala.

För kända, hanterade ändpunkter är en statisk eller controller-provisionerad bindning en legitim andra modell. Den behöver en ägare som hanterar utbyte och flytt, eftersom en provisionerad post inte uppdaterar sig själv när värden flyttar till en annan port.

Vad som ska registreras före nästa ärende

Håll bindningens källa, senaste uppdateringstid, nuvarande plats och varje återkallandehändelse bredvid MAC-rutten. Den posten svarar på frågan ärendet egentligen ställer: väntar applikationen på upptäckt, förlitar den sig på inaktuellt tillstånd, eller misslyckas den att vidarebefordra efter lyckad upplösning?

Bestäm sedan vilken av de tre du är beredd att driva. Upptäckt med flooding, uppdatering med realistisk livstid eller provisionering med en ägare är alla försvarbara. En fabric som är konfigurerad för en och förväntas bete sig som en annan är där tysta värdar försvinner.