5
DHCP Server vergibt keine IP an ein Debian System
Folgende Umgebung:
1x Host mit Server 2008 R2, darauf 1x Windows Server 2008 als DC, DHCP, DNS, VPN, Exchange, 1x Windows Server 2003, 1x Debian Linux
1x Server, um den es hier geht, mit Debian
Mehrere Clients
Hallo zusammen,
obige Konstellation, der virtuelle DHCP Server vergibt einwandfrei IPv4-Adressen, sowohl an die virtuellen Maschinen, als auch an die physikalischen Clients. Jetzt kommt ein weiterer physikalischer Server unter Debian Linux ins Netz. Die Netzwerkkarte ist mit DHCP konfiguriert, bekommt aber keine IP-Adresse vom DHCP-Server. Habe daraufhin mit Network Monitor auf dem Server geschaut:
- DHCP DISCOVER-Paket kommt einwandfrei an, aber der Server reagiert nicht darauf
- Tests mit den anderen Systemen liefen einwandfrei und der DHCP antwortete auch gleich darauf.
Einziger Unterschied, den ich so direkt in NM erkennen kann ist, dass die Spalte Process Name bei den Paketen des neuen Systems leer ist, bei den anderen steht "svchost.exe". Daher denke ich, dass das Paket nicht bis zum DHCP Server selbst durchdringt.
Weiß jemand, woran das liegen könnte?
Grüße und Danke
1x Host mit Server 2008 R2, darauf 1x Windows Server 2008 als DC, DHCP, DNS, VPN, Exchange, 1x Windows Server 2003, 1x Debian Linux
1x Server, um den es hier geht, mit Debian
Mehrere Clients
Hallo zusammen,
obige Konstellation, der virtuelle DHCP Server vergibt einwandfrei IPv4-Adressen, sowohl an die virtuellen Maschinen, als auch an die physikalischen Clients. Jetzt kommt ein weiterer physikalischer Server unter Debian Linux ins Netz. Die Netzwerkkarte ist mit DHCP konfiguriert, bekommt aber keine IP-Adresse vom DHCP-Server. Habe daraufhin mit Network Monitor auf dem Server geschaut:
- DHCP DISCOVER-Paket kommt einwandfrei an, aber der Server reagiert nicht darauf
- Tests mit den anderen Systemen liefen einwandfrei und der DHCP antwortete auch gleich darauf.
Einziger Unterschied, den ich so direkt in NM erkennen kann ist, dass die Spalte Process Name bei den Paketen des neuen Systems leer ist, bei den anderen steht "svchost.exe". Daher denke ich, dass das Paket nicht bis zum DHCP Server selbst durchdringt.
Weiß jemand, woran das liegen könnte?
Grüße und Danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 122436
Url: https://administrator.de/contentid/122436
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
wie sieht denn die /etc/networks/interfaces aus vom deb server?
wie sieht denn die /etc/networks/interfaces aus vom deb server?
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
dns-nameservers 192.168.0.4 192.168.0.1
dns-search domain.local
was passiert wenn du ein ifdown eth0 und ifup eth0 machst?
Wenn ich das richtig sehe dann fehlt irgendwie ein auto eth0 in der config.
Aber bin mir da bei Suse net so sicher...
Wenn ich das richtig sehe dann fehlt irgendwie ein auto eth0 in der config.
Aber bin mir da bei Suse net so sicher...
Danach versucht er ein DHCP-Discover, die kommen auch auf Serverseite an. Allerdings schickt der Windows-DHCP keine Antwort raus.
Ist übrigens kein SuSE, sondern Debian.
Ist übrigens kein SuSE, sondern Debian.
Oh Mann, gerade hatte ich mal in die Logs meines VM-Hosts geschaut und den Fehler gefunden. Normalerweise gibt man in Hyper-V den Netzwerkkarten der VMs dynamische MAC-Adressen in einem vordefinierten Bereiche, damit sie nicht mit realen System kollidieren. Mein Debian-System ist allerdings mein alter Server auf dem eine der jetzt virtualisierten Server 2008 läuft, auf dem auch der DHCP läuft.
Virtualisiert wurde das ganze mittels SCVMM 2008 und der nimmt die MAC-Adresse mit. Damit war die MAC bereits im Netzwerk und mein VM-Host hat sie korrekterweise abgelehnt, was auch in den Eventlogs des Systems verzeichnet wird.
Ganz zufällig habe ich das eben gesehen. Also muss ich nur bei Gelegenheit die VM runterfahren und ihr eine neue MAC verpassen, dann sollte es wieder gehen. Und da macht man stundenlang an der Fehlersuche rum ...
Virtualisiert wurde das ganze mittels SCVMM 2008 und der nimmt die MAC-Adresse mit. Damit war die MAC bereits im Netzwerk und mein VM-Host hat sie korrekterweise abgelehnt, was auch in den Eventlogs des Systems verzeichnet wird.
Ganz zufällig habe ich das eben gesehen. Also muss ich nur bei Gelegenheit die VM runterfahren und ihr eine neue MAC verpassen, dann sollte es wieder gehen. Und da macht man stundenlang an der Fehlersuche rum ...
