Stiller EVPN-Host wird nie aufgelöst: Folgen Sie dem ARP bis zur Bindung

Der Endpunkt ist angeschlossen, sein Port ist aktiv, und der überwachende Host erreicht ihn trotzdem nicht. Jemand führt einen Ping von der Gegenseite aus, und es funktioniert plötzlich, was das Problem intermittierend erscheinen lässt und die Fabric unschuldig aussehen lässt. Dieses Muster ist die Signatur eines stillen Hosts: Er sendet selten, daher ist das Erkennungs- und Auffrischungsverhalten der Fabric wichtiger als sein Anschlusszustand. Beginnen Sie mit einer beabsichtigten IP, MAC und Bridge Domain und verfolgen Sie den nächsten Auflösungsaustausch.

Verfolgen Sie den nächsten ARP- oder ND-Austausch

Beobachten Sie bei IPv4 den ARP-Austausch des anfragenden Hosts; folgen Sie bei IPv6 der Neighbor Solicitation und der Advertisement. Bestätigen Sie, dass die Anfrage in das beabsichtigte lokale Segment und die beabsichtigte VNI gelangt, denn eine Anfrage, die die richtige Bridge Domain nie erreicht, kann von keinem Proxy beantwortet werden.

Schauen Sie dann, was die Fabric über das Ziel weiß. Eine reine MAC-Route kann ein Layer-2-Ziel identifizieren, während der Proxy noch keine IP-zu-MAC-Bindung dafür hat. Das sind getrennte Datensätze, und die Prüfung des einen sagt nichts über den anderen aus.

Wenn eine gültige Bindung existiert, kann der Proxy gemäß seiner Richtlinie antworten, aber die MAC in dieser Bindung braucht weiterhin einen aktiven Weiterleitungspfad. Fehlt die Bindung, muss die Anfrage den Anschluss des Endpunkts über den Flooding- oder Replikationspfad erreichen, bevor irgendetwas aus der Antwort lernen kann.

Zwei Datensätze, die übereinstimmen müssen

Die MAC-Route beantwortet, wo die Ethernet-Adresse lebt. Die Proxy-Tabelle beantwortet, welche IP auf welche MAC abgebildet wird. Ein Host, der in letzter Zeit nicht gesprochen hat, kann eine völlig gute MAC-Route und keinen brauchbaren Proxy-Eintrag haben, und genau dieser Zustand erzeugt einen Auflösungsfehler auf einem gesunden Anschluss.

Prüfen Sie am entfernten Anschluss, ob der Endpunkt den Austausch tatsächlich empfängt und beantwortet. Seine Antwort frischt das lokale Lernen und die zugehörige EVPN-Ankündigung auf, weshalb der manuelle Ping die Dinge zu reparieren scheint: Sie haben den Verkehr erzeugt, auf den die Fabric gewartet hat. Das erklärt auch, warum die Reparatur nicht hält: Sobald der aufgefrischte Eintrag altert, wird der Endpunkt wieder still. Ein geplanter Ping behandelt das Symptom und verdeckt die Designlücke.

Folgen Sie nach der Antwort der ausgewählten Route und dem installierten Weiterleitungszustand zurück zum Anfragenden. Dass die Auflösung gelingt und dass die Weiterleitung gelingt, sind zwei getrennte Ereignisse, und ein Ticket, das sie vermischt, schickt Sie auf die falsche Ebene.

Was der Standard tatsächlich annimmt

RFC 9161 beschreibt dynamisches Proxy-Lernen und das standardmäßige Flooding unbekannter ARP- und ND-Anfragen. Eine vollständige Unterdrückung dieses Floodings ist auf Bereitstellungen beschränkt, deren Lern- oder Bereitstellungsannahmen es sicher machen, was eine engere Bedingung ist, als die meisten Konfigurationshandbücher nahelegen.

Eine Fabric, die neu entdeckte Endpunkte erwartet, braucht einen funktionierenden Pfad für diese Anfragen. Wenn jemand das Flooding unbekannter Anfragen deaktiviert hat, um BUM-Verkehr zu reduzieren, sind stille Hosts die Bevölkerung, die dafür bezahlt, und das Symptom kommt Wochen später als Beschwerde über intermittierende Erreichbarkeit.

Lesen Sie die Unterdrückungseinstellung als Aussage darüber, was die Fabric zu wissen verspricht. Wenn nichts die Bindungen bereitstellt, gilt das Versprechen für seltene Sender nicht. Vergleichen Sie die konfigurierte Unterdrückung mit dem Bereitstellungssystem, das sie speisen soll. Wenn diese beiden nicht übereinstimmen, verhält sich die Fabric genau wie konfiguriert, und die Erwartung ist das, was korrigiert werden muss.

Auffrischung, Alterung und die statische Alternative

Der Standard beschreibt unterstützte Auffrischungsprüfungen, bevor dynamische Einträge altern. Antworten frischen den relevanten Bridge- und Proxy-Zustand auf; ausbleibende Antworten können legitim zum Entfernen und zum Rückzug der Route führen. Das ist kein Fehler, der durch das Strecken jedes Timers unterdrückt werden sollte.

Das unbegrenzte Verlängern von Alterungs-Timern tauscht einen sichtbaren Fehler gegen einen veralteten: Die Fabric kündigt weiterhin einen Standort an, den der Host verlassen hat. Verwenden Sie die dokumentierten Steuerungsmöglichkeiten der Implementierung und wählen Sie eine Lebensdauer, die dazu passt, wie oft der Endpunkt vernünftigerweise sprechen kann.

Für bekannte, verwaltete Endpunkte ist eine statische oder vom Controller bereitgestellte Bindung ein legitimes zweites Modell. Sie braucht einen Eigentümer, der Ersatz und Umzug bearbeitet, denn ein bereitgestellter Datensatz aktualisiert sich nicht selbst, wenn der Host auf einen anderen Port wechselt.

Was vor dem nächsten Ticket erfasst werden sollte

Halten Sie die Quelle der Bindung, die letzte Auffrischungszeit, den aktuellen Standort und jedes Rückzugsereignis neben der MAC-Route fest. Dieser Datensatz beantwortet die Frage, die das Ticket wirklich stellt: Wartet die Anwendung auf die Erkennung, verlässt sie sich auf veralteten Zustand, oder kann sie nach erfolgreicher Auflösung nicht weiterleiten?

Entscheiden Sie dann, welches der drei Sie betreiben wollen. Erkennung mit Flooding, Auffrischung mit realistischer Lebensdauer oder Bereitstellung mit einem Eigentümer sind alle vertretbar. Eine Fabric, die für das eine konfiguriert ist und sich wie das andere verhalten soll, ist der Ort, an dem stille Hosts verschwinden.