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;
}
}
Antworten:
Es geht:
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.
quelle
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
die falsche / nicht übereinstimmende Einrichtung der beiden Amtsleitungsports Folgendes
:
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.
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
quelle
Hatte das gleiche Problem. Keine DHCPACKs zu sehen. Problem hier war:
dhcpd konnte nicht schreiben
/var/lib/dhcp/dhcpd.leases.quelle
Ich habe das ein paar Mal gesehen und bisher habe ich nur zwei Gründe gesehen:
Zum Glück sollten beide leicht zu testen sein. Pingen Sie die IP-Adresse und überprüfen Sie die relevanten Firewalls.
quelle
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.
quelle
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:
quelle