Stille EVPN-host wordt nooit opgelost: volg de ARP tot de binding

Het eindpunt is aangesloten, de poort is actief en de monitorhost kan het nog steeds niet bereiken. Iemand voert een ping uit vanaf de andere kant en het begint te werken, waardoor het probleem intermitterend lijkt en de fabric onschuldig lijkt. Dat patroon is de signatuur van een stille host: hij zendt zelden, dus het ontdekkings- en verversingsgedrag van de fabric is belangrijker dan de status van zijn aansluiting. Begin met één bedoeld IP, MAC en bridge domain en volg de volgende resolutie-uitwisseling.

Volg de volgende ARP- of ND-uitwisseling

Kijk voor IPv4 naar de ARP-uitwisseling van de vragende host; volg voor IPv6 de Neighbor Solicitation en Advertisement. Bevestig dat het verzoek in het bedoelde lokale segment en de bedoelde VNI terechtkomt, want een verzoek dat nooit het juiste bridge domain bereikt, kan door geen enkele proxy worden beantwoord.

Kijk dan wat de fabric over het doel weet. Een route met alleen MAC kan een Layer 2-bestemming identificeren terwijl de proxy er nog geen IP-naar-MAC-binding voor heeft. Dat zijn afzonderlijke records, en het controleren van het ene zegt niets over het andere.

Als er een geldige binding bestaat, kan de proxy volgens zijn beleid antwoorden, maar de MAC in die binding heeft nog steeds een actief doorstuurpad nodig. Als de binding ontbreekt, moet het verzoek de aansluiting van het eindpunt bereiken via het flooding- of replicatiepad voordat iets van het antwoord kan leren.

Twee records die moeten overeenkomen

De MAC-route antwoordt waar het Ethernet-adres woont. De proxytabel antwoordt welke IP aan welke MAC wordt toegewezen. Een host die recent niet heeft gesproken, kan een volledig goede MAC-route hebben en geen bruikbare proxy-invoer, en dat is precies de toestand die een resolutiefout op een gezonde aansluiting veroorzaakt.

Controleer bij de externe aansluiting of het eindpunt de uitwisseling echt ontvangt en beantwoordt. Het antwoord ververst de lokale learning en de bijbehorende EVPN-aankondiging, en daarom lijkt de handmatige ping dingen te repareren: u genereerde het verkeer waarop de fabric wachtte. Dat verklaart ook waarom de reparatie niet blijft: zodra de ververste invoer veroudert, wordt het eindpunt weer stil. Een geplande ping behandelt het symptoom en verbergt de ontwerpkloof.

Volg na het antwoord de geselecteerde route en de geïnstalleerde doorstuurstaat terug naar de vrager. Dat de resolutie slaagt en dat het doorsturen slaagt, zijn twee afzonderlijke gebeurtenissen, en een ticket dat ze verwart, stuurt u naar de verkeerde laag.

Wat de standaard feitelijk aanneemt

RFC 9161 beschrijft dynamisch proxy-leren en de standaard-flooding van onbekende ARP- en ND-verzoeken. Volledige onderdrukking van die flooding is beperkt tot implementaties waarvan de leer- of provisioning-aannames het veilig maken, wat een engere voorwaarde is dan de meeste configuratiehandleidingen suggereren.

Een fabric die pas ontdekte eindpunten verwacht, heeft een werkend pad nodig voor die verzoeken. Als iemand de flooding van onbekende verzoeken heeft uitgeschakeld om BUM-verkeer te verminderen, zijn stille hosts de populatie die daarvoor betaalt, en het symptoom komt weken later als een klacht over intermitterende bereikbaarheid.

Lees de onderdrukkingsinstelling als een uitspraak over wat de fabric belooft te weten. Als niets de bindingen voorziet, is de belofte niet waar voor weinig zendende hosts. Vergelijk de geconfigureerde onderdrukking met het provisioningsysteem dat het hoort te voeden. Als die twee het niet eens zijn, gedraagt de fabric zich precies zoals geconfigureerd, en de verwachting is wat moet worden gecorrigeerd.

Verversing, veroudering en het statische alternatief

De standaard beschrijft ondersteunde verversingsprobes voordat dynamische invoer veroudert. Antwoorden verversen de relevante bridge- en proxystaat; ontbrekende antwoorden kunnen legitiem leiden tot verwijdering en intrekking van de route. Dat is geen bug die moet worden onderdrukt door elke timer op te rekken.

Verouderingstimers onbeperkt verlengen ruilt een zichtbare fout in voor een verouderde: de fabric blijft een locatie aankondigen die de host heeft verlaten. Gebruik de gedocumenteerde bedieningselementen van de implementatie en kies een levensduur die past bij hoe vaak het eindpunt redelijkerwijs kan worden verwacht te spreken.

Voor bekende, beheerde eindpunten is een statische of door de controller voorziene binding een legitiem tweede model. Het vereist een eigenaar die vervanging en verplaatsing afhandelt, omdat een voorziene registratie zichzelf niet bijwerkt wanneer de host naar een andere poort verhuist.

Wat u vastlegt voor het volgende ticket

Houd de bron van de binding, de laatste verversingstijd, de huidige locatie en elke intrekkingsgebeurtenis naast de MAC-route. Dat record beantwoordt de vraag die het ticket werkelijk stelt: wacht de toepassing op ontdekking, vertrouwt zij op verouderde staat, of slaagt zij er niet in om door te sturen na een geslaagde resolutie?

Bepaal dan welke van de drie u bereid bent te beheren. Ontdekking met flooding, verversing met een realistische levensduur of provisioning met een eigenaar zijn allemaal verdedigbaar. Een fabric die voor het ene is geconfigureerd en waarvan wordt verwacht dat zij zich als het andere gedraagt, is waar stille hosts verdwijnen.