Was ist für einen DHCP-Client die beste Antwort?

Wir haben Schulungsräume, in denen normalerweise Windows XP installiert ist (über PXE). Die "normale" DNS / DHCP-Infrastruktur sind Windows-Server. Der Schulungsraum verfügt über ein eigenes VLAN (anders als die Windows-Server). Daher ist wahrscheinlich ein IP-Helfer für DHCP-Anforderungen auf dem Cisco-Router aktiv, mit dem alle PCs aus diesem Raum verbunden sind.

Jetzt wollten wir stattdessen einige der PCs auf Linux konvertieren. Die Idee war: Setzen Sie unseren eigenen Laptop mit einem DHCP-Server in das VLAN des Raumes und überschreiben Sie die "normale" DHCP-Antwort. Die Idee war, dass dies funktionieren sollte, da ein direkt angeschlossener DHCP-Server in diesem VLAN eine schnellere Antwortzeit haben sollte als der "normale" DHCP-Server, der sich einige Hops von diesem VLAN entfernt befindet.

Es stellte sich heraus, dass dies nicht funktionierte. Wir mussten die Lease manuell auf dem ursprünglichen DHCP-Server freigeben, damit sie funktioniert.

Auf dem Laptop hat der Client die IP angefordert und "unser" DHCP hat NACKs an die Windows-IP-Anforderung gesendet, bevor wir unsere eigene Antwort angeboten haben.

Alte Frage: Warum hat das nicht wie erwartet geklappt? Was bringt den PC dazu, sein altes Leasingverhältnis wiederherzustellen?

Update 08.08.2012:

Das Regain-Problem wurde im DHCP-RFC erläutert. Dies erklärt nun, warum der PC seinen alten Mietvertrag wiedererlangt.

Jetzt geben wir die IP vom Windows-DHCP-Server frei, bevor wir es erneut versuchen.

Nochmal - der Windows-DHCP-Server gewinnt.

Ich vermute, dass es einen Algorithmus für den DHCP-Client gibt, der die "beste" DHCP-Antwort für den Client ermittelt. Die neue Frage lautet:

Wie wählt der Kunde die "beste" Antwort?

Es ist herstellerspezifisch, wie ein Client auf mehrere DHCP-Antworten reagiert.

Varianten, die ich im Laufe der Jahre gesehen habe, sind:

1) Akzeptieren Sie die erste, unabhängig davon, ob es sich um eine ACK oder eine NACK handelt.

2) Nehmen Sie das erste ACK und ignorieren Sie NACKs vollständig.

3) Nehmen Sie die letzte Empfangsbestätigung innerhalb eines festgelegten Zeitintervalls (normalerweise 5-10 Sekunden).

Beispiel: Vor einigen Jahren hatten wir Probleme mit Ricoh-MFPs.
Wir hatten 2 DHCP-Server. Einer lieferte die Adressen, der andere nur zusätzliche DHCP-Optionen. Der 2. Server hat immer zuerst geantwortet.
Die von Ricoh verwendete Variante 1) enthielt auch im 1. Angebot nur DHCP-Optionen. Ricoh änderte es zu Variante 2) mit einem Firmware-Update, nachdem wir ihnen das Problem erklärt hatten.

Angenommen, der Router fungiert immer noch als DHCP-Relay und leitet die Anforderung an Ihren ursprünglichen Server weiter. Der Grund dafür liegt einfach darin, dass der Windows-DHCP-Server ihn angewiesen hat, die IP-Adresse zu verwenden. In diesem Fall ist der DHCPNACK vom neuen Server irrelevant, da ein DHCP-Client alle Antworten berücksichtigt. Da er ein Angebot von der Windows-DHCP-Box erhalten hat, ist er gerne bereit, ihn zu verwenden.

PC: Oh hi world, kann ich 192.168.1.123 verwenden?

New-DHCP: Ich sage nein.

Alt-DHCP: Ich sage ja.

PC: Jemand hat ja gesagt! Süß, ich werde es benutzen!

Wenn nichts anderes hilft - RTFM (lesen Sie das feine Handbuch). In diesem Fall war der erste der Treffer.

RFC 2131 beschreibt DHCP-Operationen.

Abschnitt 1.6 besagt , dass DHCP muss :

Beibehalten der DHCP-Client-Konfiguration über Serverneustarts hinweg. Einem DHCP-Client sollten nach Möglichkeit trotz Neustarts des DHCP-Mechanismus dieselben Konfigurationsparameter zugewiesen werden.

Die interessante Frage ist nun, wie dieses Designziel bei einem Kunden erreicht wird, der keine Kenntnis von seiner Vergangenheit hat. Abschnitt 3.2 skizziert:

3.2 Client-Server-Interaktion - Wiederverwenden einer zuvor zugewiesenen Netzwerkadresse

Wenn sich ein Client an eine zuvor zugewiesene
Netzwerkadresse erinnert und diese wiederverwenden möchte, kann er einige der
im vorherigen Abschnitt beschriebenen Schritte weglassen . Das Timeline-Diagramm in Abbildung 4
zeigt die Timing-Beziehungen in einer typischen Client-Server-Interaktion für einen Client, der eine zuvor zugewiesene Netzwerkadresse wiederverwendet.

1. Der Client sendet eine DHCPREQUEST-Nachricht in seinem lokalen Subnetz. Die Nachricht enthält die Netzwerkadresse des Clients in der Option 'Angeforderte IP-Adresse'. Da der Client seine Netzwerkadresse nicht erhalten hat, DARF er das Feld 'ciaddr' NICHT ausfüllen. BOOTP-Relay-Agenten leiten die Nachricht an DHCP-Server weiter, die sich nicht im selben Subnetz befinden. Wenn der Client eine 'Client-ID' zum Abrufen seiner Adresse verwendet hat, MUSS der Client dieselbe 'Client-ID' in der DHCPREQUEST-Nachricht verwenden.

2. Server, die die Konfigurationsparameter des Clients kennen, antworten mit einer DHCPACK-Nachricht an den Client. Server DÜRFEN NICHT überprüfen, ob die Netzwerkadresse des Clients bereits verwendet wird. Der Client kann zu diesem Zeitpunkt auf ICMP-Echoanforderungsnachrichten antworten.

Ein DHCP-Server mit einer aktiven Lease hat also Vorrang, indem er eine Verknüpfung im Protokoll verwendet.

1. Client: DHCREQUEST (MAC-Adresse, Broadcast, wird im lokalen Broadcastbereich übertragen - hier das lokale VLAN und via IP-Helfer zum Windows-DHCP-Server)
2. Laptop-DHCP-Server: DHCPOFFER
3. Windows-DHCP-Server: Hey - ich kenne dich schon - DHCPACK
4. Kunde: Oh, ich habe zwei Antworten erhalten. Einer, der mich schon kennt. Cool, ich werde das nehmen

Ab diesem Zeitpunkt wird der Laptop-DHCP-Server vom Client ignoriert.

Die Lösung in unserem Fall wird also wahrscheinlich sein (ich werde dies aktualisieren, wenn wir es tatsächlich testen):

1. Stellen Sie sicher, dass der Client ausgeschaltet ist
2. DHCP-Server auf Laptop ausschalten, Client-MAC auf Laptop fälschen, DHCP-Request
3. IP freigeben
4. Stellen Sie die ursprüngliche IP- und MAC-Adresse wieder her und schalten Sie den DHCP-Server ein
5. Client einschalten und PXE-Boot durchführen ...

Die neue Frage sollte sich wahrscheinlich in einer anderen Frage befinden - der Titel der Frage passt überhaupt nicht zum Hauptteil der Frage.

In jedem Fall ist es in Bezug auf die Auswahl des passenden Angebots für einen Client, sofern er keine aktuelle Lease hat, Sache des Clients, aber in jeder mir bekannten DHCP-Client-Implementierung ein einfaches Rennen .

RFC 2131 behandelt dies:

DHCP-Clients können bei der Auswahl eines DHCP-Servers eine beliebige Strategie anwenden, von der der Client eine DHCPOFFER-Nachricht empfängt.

Es gibt da draußen einen IETF-Entwurf , der tot zu sein scheint, der den Auswahlprozess konfigurierbarer gemacht hätte, und der auch die glanzlosen Client-Implementierungen erwähnt (vor über einem Jahrzehnt, aber nicht viel hat sich geändert):

In der Praxis ist die Umsetzung der Richtlinien durch die meisten Anbieter sehr einfach (z. B. das erste Angebot oder das erste akzeptable Angebot) und "fest codiert" (dh nicht konfigurierbar).

Wenn zwei DHCP-Server das gleiche Netzwerk mit unterschiedlicher Konfiguration bedienen, führt dies nur zu Rennen, was aus Gründen der Zuverlässigkeit oder der Vorhersagbarkeit nicht wünschenswert ist. Es gibt wirklich keinen Grund, warum Sie Ihren einzelnen DHCP-Server nicht dazu bringen können, das zu liefern, was Sie benötigen.