it-swarm.com.de

DHCPDISCOVER / DHCPOFFER, aber kein DHCPACK

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

Dies wird ungefähr alle 30 Sekunden vom selben Host wiederholt. Gibt es etwas, das ich aus der Ferne tun kann, 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 starten lassen, aber ich habe immer noch Probleme. Ich denke, es gibt ein Problem mit meiner Konfiguration. 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;
  }
}
17
Matt

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 der DHCPOFFER Unicast an das DHCP-Relay an Port 67 UDP gesendet. Der DHCP-Relay-Agent sendet den DHCPOFFER an das Subnetz am UDP-Port 68.

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

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

15
artifex

Angenommen, Ihr DHCP-Server und Ihr DHCP-Client sind beide mit demselben Ethernet-Segment verbunden, und wenn ein solches Ethernet-Segment mehrere L2-Switches umfasst, die mit verschiedenen "Trunk" -Verbindungen ( 802.1q ) verbunden sind, habe ich Es treten ähnliche Probleme auf, wenn die Konfiguration mindestens einer Trunk-Verbindung nicht übereinstimmt.

Im Detail, der unendliche Zyklus von DHCP-DISCOVER/DHCP-OFFER (von der Seite des DHCP-Servers aus gesehen), lassen Sie mich denken, dass der DHCP-Client [ ~ # ~] nicht [~ # ~] Empfängt das DHCP-ANGEBOT und bleibt daher bei der erneuten Ausgabe der DHCP-DISCOVER-Nachricht. Ein solcher DHCP-DISCOVER (von der DHCP-Client-Seite aus gesehen) wird vom DHCP-SERVER korrekt empfangen.

Betrachtet man das folgende Szenario: enter image description here Das falsche/nicht übereinstimmende Setup der beiden Trunk-Ports bedeutet Folgendes:

  • Der von SW A an SW B entlang des Trunks (oder vom DHCP-Server zum DHCP-Client) gesendete VLAN X-Verkehr ist UNTAGGED.
  • Der von SW B an SW A entlang des Trunks (oder vom DHCP-Client zum DHCP-Server) gesendete VLAN X-Verkehr ist TAGGED.
  • aufgrund der nativen VLAN Einrichtung des Trunk-Ports von SW B empfängt der DHCP-Client keine Pakete von 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.

Die Fehlerbehebung ist schwieriger, wenn Sie die Clientseite nicht steuern können.

PS: Offensichtlich können die oben genannten Probleme sowie andere verwandte Argumente leicht vermieden werden, wenn geeignete Technologien verwendet werden (wie GVRP , VTP oder ein anderer nicht streng manueller Konfigurationsansatz), aber ... dies liegt außerhalb des Rahmens dieser Antwort

10

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

festplatte voll

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

6
1977er

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

  • Die vom DHCP-Server angegebene IP-Adresse wird bereits von einem anderen Gerät verwendet. Normalerweise sehen Sie jedoch einen DHCPNAK.
  • Ihre Firewall akzeptiert den Datenverkehr zum DHCP-Server, nicht jedoch 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.

3

Ich habe etwas über Firewalls mit Virtual Box gelernt und hatte ein ähnliches Problem, als ich das DHCPACK nicht auf dem Server bekam. Es stellte sich heraus, dass die falschen Netzwerkeinstellungen für Virtual Box für das grüne Testnetzwerk (intern) für eine Ubuntu-Firewall vm und verwendet wurden ein Test Ubuntu Client vm. Wenn Sie das Netzwerk NAT) anstelle des internen Netzwerks vb verwenden, erhält der Client-VM seine IP-Adresse von vb und nicht vom DHCP-Server vm. Die Protokolle zeigen, dass der Server die Anforderung vom Client erhält, der Client jedoch Die IP-Adresse stammt von vb, sodass Sie nie eine ACK an den Server zurücksenden.

0
Mark Simmons

Für mich war es einfach zu vergessen, den DHCP-Server (über Internet Sharing) auf dem Client auszuschalten. Sobald ich das ausgeschaltet hatte, wurde der DHCP-Mietvertrag 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
0
Heath Raftery