weidner/archives/2022/01/

DHCP Relay schiefgelaufen

Das war ein merkwürdiges Problem, das eigentlich nicht hätte auftreten müssen beziehungsweise dürfen.

Ein Drucker an einem externen Standort, der via DHCP konfiguriert wurde, bekam manchmal seine Netzwerkkonfiguration und manchmal nicht. Der Standort ist über zwei Gateways mit der Zentrale verbunden, die sich über CARP die Gateway-Adresse im Failover-Modus teilten. Auf beiden Gateways läuft ein DHCP-Relay.

Die Paketmitschnitte an den Gateways brachten mich schnell auf die Spur. Zunächst schnitt ich am aktiven Gateway auf der Client-Seite mit und sah, dass das Gateway als Antwort auf DHCPDISCOVER des Clients einmal DHCPOFFER als Broadcast mit einer fremden IP-Adresse sendete und einmal als Unicast an das passive Gateway. Bei beiden DHCPOFFER-Datagrammen war die Option Relay-Agent-IP-Address die des passiven Gateways. Das gleiche Spiel wiederholte sich kurz darauf bei DHCPREQUEST, als der Drucker die Adresse für sich einforderte.

Etwa sieben Minuten später, ein Kollege hatte den Drucker über die Admin-Schnittstelle neu gestartet, wiederholte sich das Spiel mit DHCPDISCOVER, DHCPOFFER und DHCPREQUEST. Der Drucker verwendete exakt die gleichen Transaction-IDs und der DHCP-Server lehnte dieses Mal DHCPREQUEST mit NAK ab.

Ich kontrollierte die Konfiguration des Gateways, konnte aber nirgends einen Hinweis auf die fremde IP-Adresse finden, mit der das aktive Gateway die Broadcast-Antworten sendete. Also schaute ich als nächstes auf der Seite zum DHCP-Server nach. Dort sah es so aus:

Zur Kontrolle schnitt ich den DHCP-Verkehr am passiven Gateway mit. Dort sah ich auf der Serverseite nur die DHCP-Anfragen mit der für dieses Gateway korrekten DHCP-Relay-ID.

Ein Kollege sah sich währenddessen die Logs des DHCP-Servers an und bemerkte darin sehr viele NACK für das Client-Netz an diesem Standort.

Was war los?

Sequenzdiagramm

  1. Der Client sendet DHCPDISCOVER als Broadcast.
  2. Das aktive Gateway leitet DHCPDISCOVER als Unicast mit falscher Relay-Adresse an den DHCP-Server.
  3. Das passive Gateway leitet DHCPDISCOVER als Unicast mit korrekter Relay-Adresse an den DHCP-Server.
  4. Der DHCP-Server sendet DHCPOFFER an die Relay-Adresse des passiven Gateways, diese kommt zuerst beim aktiven Gateway an.
  5. Das aktive Gateway erkennt die Transaktions-ID der Antwort vom Server und sendet einen Broadcast für den Client mit falscher Absenderadresse.
  6. Das aktive Gateway leitet die Antwort des DHCP-Servers korrekt an das passive Gateways weiter.

Somit funktionierte DHCPDISCOVER, solange das DHCP-Relay auf dem zweiten Gateway lief.

Direkte DHCPREQUEST per Unicast vom Client zum DHCP-Server funktionierten ebenfalls, da dabei kein DHCP-Relay involviert war.

Ein DHCPREQUEST via Broadcast brachte hingegen wieder beide DHCP-Relays ins Spiel.

Ob der DHCP-Server wegen der falschen Relay-ID oder wegen der wiederverwendeten Transaction-ID ablehnte, ist mir nicht ganz klar geworden.

Als Abhilfe beendete ich das DHCP-Relay auf dem aktiven Gateway und startete es neu. Danach sendete es die korrekte ID zum DHCP-Server. Im Log fanden sich anschließend auch keine NACK mehr für das Client-Netz.

Die Geschichte ist an dieser Stelle aber noch nicht zu Ende. Ich wollte wissen warum das Gateway die falsche DHCP-Relay-ID gesendet hatte. Immerhin enthielt die Konfiguration keinen Hinweis auf den anderen Standort.

Die Gateways waren einige Wochen zuvor ausgeliefert worden. Dabei waren zwei Kollegen von Standort zu Standort gereist und hatten vorkonfigurierte Gateways eingebaut und in Betrieb genommen. Eines der Gateways für diesen Standort ließ sich vor Ort jedoch nicht in Betrieb nehmen. Kurzerhand nahmen die Kollegen ein Gerät für einem anderen Standort in Betrieb und konfigurierten es neu für diesen Standort. Als alles zu funktionieren schien, fuhren sie weiter zum nächsten Standort, ohne die Geräte wenigstens einmal neu zu starten.

So hatte das Gateway die Adressen vom anderen Standort als das DHCP-Relay startete und dieser Prozess lief mehrere Wochen, bis ich mir das oben beschriebene Problem anschaute.

Epilog

Nicht immer kann man ein Gateway nach einer Konfigurationsänderung neu starten, da dabei oft produktive Verbindungen gestört werden. Wenn ein Gerät jedoch neu eingebaut wurde und anschließend die Konfiguration geändert, ist es jedoch auf jeden Fall ratsam, das Gerät neu zu starten bevor man den Ort verlässt. So bekommt man rechtzeitig mit, falls es Probleme nach einem Neustart der Geräte geben sollte. In diesem Fall gab es nicht einmal produktive Verbindungen weil für den Einbau der Geräte eine Ausfallzeit eingeplant war.

Posted 2022-01-11
Tags: