DHCPDISCOVER / DHCPOFFER, aber kein DHCPACK

16

Ich habe einen Remote-Client-Computer, der DHCPDISCOVER sendet. Der Server antwortet mit einem DHCPOFFER, es ist jedoch kein DHCPACK vorhanden.

Dies wird ungefähr alle 30 Sekunden vom selben Host wiederholt. Kann ich etwas aus der Ferne tun oder muss ich jemanden dazu bringen, es neu zu starten? Es befindet sich in einem Rechenzentrum, daher muss ich möglicherweise dorthin reisen, um es zu tun!

Danke für die Vorschläge. Ich habe alle Maschinen neu gestartet, aber ich habe immer noch Probleme. Ich denke, dass es ein Problem mit meiner Konfiguration gibt. Sieht das richtig aus?

#
# /etc/dhcpd.conf for primary DHCP server
#

authoritative;
ddns-update-style none;
deny duplicates;
default-lease-time 600;
max-lease-time 3600;

# Our fixed hosts
host host2  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.202; }
host host3  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.203; }
host host4  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.204; }
host host5  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.205; }

subnet x.x.x.128 netmask 255.255.255.128 {
  option subnet-mask 255.255.255.128;
  option broadcast-address x.x.x.255;
  option routers x.x.x.129;
  option domain-name-servers 8.8.8.8, 8.8.4.4;

  # Testing pool.
  pool {
    max-lease-time 300; # 5 minutes
    range x.x.x.250 x.x.x.254;
    deny known-clients;
  }

  # Our hosts - I didn't have this pool declaration before, do I need it if I want
  # the hosts to be running dhcp but always get the same address?
  pool {
    max-lease-time 1800;
    range x.x.x.200 x.x.x.220;
    deny unknown-clients;
  }
}
linux  isc-dhcp  dhcpd 
— Matt
quelle
DHCPRequest sollte vor dem DHCPAck kommen. Siehst du das Versuchen Sie, eine Paketerfassung auf dem Server auszuführen, und suchen Sie nach DHCPDiscover, DHCPOffer, DHCPRequest und DHCPAck zum und vom Server. Befindet sich der Client im selben LAN-Segment wie der Server? Wenn nicht, trennt der Router die beiden als DHCP-Relay?
— Joeqwerty
Es stellte sich heraus, dass das Problem auf eine Fehlkonfiguration zurückzuführen war. Ich hatte einen statischen Bereich, der einen dynamischen Bereich überlappte.
— Matt

Antworten:

13

Es geht:

CLIENT -> DHCPDISCOVER
SERVER -> DHCPOFFER
CLIENT -> DHCPREQUEST
SERVER -> DHCPACK

Sie vermissen die DHCPREQUEST vor dem DHCPACK in Ihrer Beschreibung.

Befindet sich der Client in einem anderen Subnetz als der DHCP-Server, wird DHCPOFFER als Unicast an das DHCP-Relay an Port 67 UDP gesendet. Der DHCP-Relay-Agent sendet das DHCPOFFER über UDP-Port 68 an das Subnetz.

Ich würde Konnektivitätsprobleme im Zusammenhang mit DHCPOFFER untersuchen. Verfolgen Sie es, und überprüfen Sie, ob es den Weg zurück zum Client findet. Wenn dies der Fall ist, gibt der Client die Adresse nicht mit DHCPREQUEST an.

Ein üblicher DHCP-Relay-Agent ist die Option "IP-Helfer-Adresse" in Cisco-Switches unter einer bestimmten Schnittstelle.

— Artifex
quelle
10

Angenommen, Ihr DHCP-Server und Ihr DHCP-Client sind beide mit demselben Ethernet-Segment verbunden, und wenn sich ein solches Ethernet-Segment über mehrere L2-Switches erstreckt, die mit verschiedenen "Trunk" -Links ( 802.1q ) verbunden sind, sind bei mir ähnliche Probleme aufgetreten eine Nichtübereinstimmung zwischen der Konfiguration von mindestens einem Trunk-Link.

Im Detail, der unendliche Zyklus von DHCP-DISCOVER / DHCP-OFFER (von der Seite des DHCP-Servers aus gesehen) lässt mich annehmen, dass der DHCP-Client das DHCP-ANGEBOT NICHT empfängt und daher das DHCP nicht erneut ausgibt -Entdecken Nachricht. Ein solches DHCP-DISCOVER (vom DHCP-Client aus gesehen) wird vom DHCP-SERVER korrekt empfangen.

Unter Berücksichtigung des folgenden Szenarios bedeutet Bildbeschreibung hier eingeben die falsche / nicht übereinstimmende Einrichtung der beiden Amtsleitungsports Folgendes :

  • VLAN X-Datenverkehr, der von SW A an SW B über den Trunk (oder vom DHCP-Server an den DHCP-Client) gesendet wird, ist UNTAGGED.
  • VLAN X-Datenverkehr, der von SW B über den Trunk (oder vom DHCP-Client zum DHCP-Server) an SW A gesendet wird, ist TAGGED.
  • Aufgrund der nativen VLAN-Konfiguration des Trunk-Ports von SW B empfängt der DHCP-Client keine Pakete vom DHCP-Server.

Dies ist sehr einfach zu beheben, wenn Sie den DHCP-Client-Host "steuern". In einem solchen Fall wird angenommen, dass eth0 die vom DHCP-Client-Host verwendete Netzwerkschnittstelle ist.

tcpdump -n -i eth0 ether-host <dhcp-server-mac-address>

zeigt an, ob der Client das DHCP-ANGEBOT vom DHCP-SERVER erhält oder nicht.

Es ist schwieriger, Probleme zu beheben, wenn Sie die Clientseite nicht steuern können .

PS: Offensichtlich können die oben genannten Probleme sowie andere damit zusammenhängende Argumente leicht vermieden werden, wenn geeignete Technologien (wie GVRP , VTP oder ein anderer nicht streng manueller Konfigurationsansatz) verwendet werden

— Damiano Verzulli
quelle
Dies kann anscheinend auch auf einen Softwarefehler im DHCP-Server zurückzuführen sein, wenn die serverseitige Schnittstelle über verschiedene VLANs hinweg überbrückt wird.
— DustWolf
6

Hatte das gleiche Problem. Keine DHCPACKs zu sehen. Problem hier war:

Festplatte voll

dhcpd konnte nicht schreiben /var/lib/dhcp/dhcpd.leases.

— 1977er
quelle
Danke vielmals. Ich sah Entdeckung, Angebot, Anfrage, Anfrage, Anfrage und keine Bestätigung und dies war die Ursache. Aus demselben Grund befand sich auch nichts in / var / log / syslog. Es ist an der Zeit, dies zuerst zu überprüfen, wenn ich merkwürdiges Verhalten sehe, das plötzlich einsetzt.
— Rob Fisher
3

Ich habe das ein paar Mal gesehen und bisher habe ich nur zwei Gründe gesehen:

  • Die vom DHCP-Server angegebene IP-Adresse wird bereits von einem anderen Gerät verwendet. Normalerweise wird jedoch ein DHCPNAK angezeigt.
  • Ihre Firewall akzeptiert den Datenverkehr zum DHCP-Server, aber nicht den Datenverkehr zurück

Zum Glück sollten beide leicht zu testen sein. Pingen Sie die IP-Adresse und überprüfen Sie die relevanten Firewalls.

— Dennis Kaarsemaker
quelle
Vielen Dank. Ich habe die angebotene Adresse angerufen, aber keine Antwort erhalten. Ich habe dann einen Host-Eintrag dafür eingerichtet, damit er eine andere Adresse anbietet, aber das schien nicht zu helfen. Überprüft die Firewall.
— Matt
0

Ich habe etwas über Firewalls mit Virtual Box gelernt und hatte ein ähnliches Problem damit, dass DHCPACK nicht auf dem Server installiert wurde. Es stellte sich heraus, dass für das grüne (interne) Testnetzwerk für eine Ubuntu-Firewall vm und die falsche Netzwerkeinstellung für Virtual Box verwendet wurde ein Test Ubuntu Client vm. Wenn Sie das NAT-Netzwerk anstelle des internen Netzwerks von vb verwenden, bezieht der Client vm seine IP-Adresse von vb und nicht vom DHCP-Server vm. In den Protokollen wird angezeigt, dass der Server die Anforderung vom Client erhält, der Client jedoch seine IP-Adresse von vb erhält, sodass Sie niemals eine Bestätigung an den Server zurücksenden.

— Mark Simmons
quelle
0

Für mich war es ein einfacher Fall, zu vergessen, den DHCP-Server (über Internet Sharing) auf dem Client auszuschalten. Sobald ich das ausschaltete, wurde die DHCP-Lease akzeptiert:

Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPREQUEST(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPACK(eth0) 10.0.0.4 40:6c:8f:59:24:8e Heaths-MBP
— Heath Raftery
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.