Dhcp vergibt keine Addressen

Hallo zusammen,

Ich teste derzeit den Aufbau einer univention/samba Domäne in einer virtuellen Umgebung.

Die vms laufen zusammen an einer von libvirt verwalteten Bridge ohne Einschränkungen

Die dhcp range ist am pdc konfiguriert, auch wurden unbekannte clients erlaubt

Leider hat weder der memberserver den ich joinen wollte noch die ubuntu testvm antwort vom dhcp erhalten.

Die vms denen ips zugewiesen werden sollen senden ihr dhcp discover wie erwartet, bekommen jedoch keine antwort
Dies habe ich mittels wireshark mehrfach getestet

Bei einem alten setup (einer der ersten ucs 4 versionen) lief das exakt selbe setup ohne probleme, direkt nach der installation mit den exakt gleichen settings

Hat jemand die selbe Problematik schonmal gehabt oder vlt eine idee wie ich dies lösen kann?

habe nun zum testen den Primary controller direkt auf hardware installiert, das problem tritt weiterhin auf
somit konnte ich zumindest eine fehlerhafte konfiguration in meiner virtuellen umgebung ausschließen

Moin,

ich tippe auf falsche DHCP-Konfiguration. Melden Sie sich bitte an der Univention Management Console an und navigieren Sie zu »Domain« → »DHCP«. Klicken Sie im Baum links auf das Service-Objekt. Sind in der Liste rechts dann mindestens ein Subnetz- und ein Server-Objekt zu sehen?

Falls beides vorhanden ist: hat der dort hinterlegte Server eine IP-Adresse im selben Netz, wie es das DHCP-Subnetz-Objekt angibt? Also nicht in der von DHCP-vergebenen Range, sondern im kompletten Netz.

Beispiel:

Subnetz-Objekt ist definiert für 10.1.2.0/24 mit erster Adresse 10.1.2.100 und letzter Adresse 10.1.2.199. Wenn der Server eine Adresse z.B. 10.1.2.5 hat, dann sollte alles klappen.

Letzte Frage: ist auf dem Server das Paket »univention-dhcp« installiert?

Gruß,
mosu

Da der dhcp server infolge dem erstellen einer neuer domäne installiert und konfiguriert wurde waren alle settings bereits richtig festgelegt

Die ip des Univention Primary Domain Controllers 192.168.122.2
Dhcp range 192.168.122.100 - 192.168.122.200
Als broadcast ist 192.168.122.255 angegeben

Das paket univention-dhcp ist installiert, der dienst läuft auch

Ich habe die settings auch mit unserem produktivsetup verglichen, diese unterscheiden sich lediglich durch das netzwerk in dem sie hängen
Auch läuft unser produktivsystem mit der selben virtualisierung an einer von libvirt verwalteten bridge mit den selben settings

Im dhcp log ist auch rein garnichts zu erkennen

Die joinscripte sind alle erfolgreich durchgelaufen

Langsam bin ich mit meinen ideen am ende
Hat vlt noch jemand eine idee?

Moin,

bitte lesen Sie meinen Post noch einmal gründlich durch. Sie müssen unterhalb des DHCP-Service-Objekts zwei Objekte haben: eines vom Typ »DHCP subnet« (dessen Einstellungen haben Sie ja anscheinend geprüft), und eines vom Typ »DHCP server«. Über diese zwei Objekte geschieht die Zuordnung, welcher Server für welche Netzbereiche via DHCP Adressen vergibt.

Gruß,
mosu

Moin,

Auch dies habe ich jetzt nochmal überprüft, die einträge sind alle vorhanden

Moin,

sehr gut. Oder auch nicht, kommt auf die Sichtweise drauf an

Als nächstes prüfen Sie doch bitte mal, ob auf dem Server »pdc« die DHCP-Anfragen überhaupt ankommen. Dafür starten Sie auf dem »pdc« mal den folgenden Befehl als root:

tcpdump -n -i any port 67 or port 68

Anschließend triggern Sie bitte eine DHCP-Anfrage bei einem Client. Ein erfolgreicher Dialog besteht aus vier Zeilen, ein erfolgreiches Renewal eines bereits erhaltenen Releases hingegen nur aus zwei. Taucht aber nicht einmal die erste Zeile auf (eine Anfrage von 0.0.0.0 Port 68, Client hat ja in dem Moment noch keine IP, an die Broadcast-Adresse 255.255.255.255 Port 67), so liegt das Problem in der Netzwerk- oder Firewallkonfiguration.

Beispiel für ein erfolgreiches, erstmaliges Beziehen einer Adresse:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 10:16:52.914969 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:50:56:23:41:98, length 300 10:16:53.916962 IP 10.191.1.1.67 > 10.191.1.103.68: BOOTP/DHCP, Reply, length 300 10:16:53.917214 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:50:56:23:41:98, length 300 10:16:53.918075 IP 10.191.1.1.67 > 10.191.1.103.68: BOOTP/DHCP, Reply, length 300

Gruß,
mosu

Der Request kommt am pdc an, dennoch geht keine antwort raus

root@pdc:~# tcpdump -n -i any port 67 or port 68 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 10:25:01.911814 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:25:04.706224 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:25:11.191067 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:25:19.951828 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:25:30.603749 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:25:44.437095 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:25:47.383973 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:25:47.914960 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:af:d6:3c, length 300 10:25:49.580713 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:25:51.652829 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:af:d6:3c, length 300 10:25:52.678828 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:25:56.309354 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:af:d6:3c, length 300 10:26:01.415724 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 10:26:05.059224 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:af:d6:3c, length 300

Hmmm…

OK, nächster Schritt. Bitte editieren Sie mal die Datei »/etc/dhcp/dhcpd.conf«. Dort gibt es eine auskommentierte Zeile »ldap-debug-file…«. Diese bitte einkommentieren.

Anschließend starten Sie den DHCP-Dienst mit »service univention-dhcp restart« neu. Nun sollten Sie eine neue Logdatei vorfinden: »/var/log/dhcp-ldap-startup.log«. Bitte pasten Sie den Inhalt hier.

Gruß,
mosu

Anbei dhcp-ldap-startup.log

root@pdc:~# cat /var/log/dhcp-ldap-startup.log #DHCP Service option routers 192.168.122.1; option domain-name "huf.intranet"; option domain-name-servers 192.168.122.2; allow unknown-clients; ignore bootp; ignore booting; allow duplicates; ignore declines;subnet 192.168.122.0 netmask 255.255.255.0 { range 192.168.122.100 192.168.122.200; option broadcast-address 255.255.255.255; option routers 192.168.122.1; option domain-name "huf.intranet"; option domain-name-servers 192.168.122.2; allow unknown-clients; ignore bootp; ignore booting; allow duplicates; ignore declines; }

Hey,

aaaaaaaaaaha! Das »ignore bootp« sorgt dafür, dass bootp-Anfragen (das sind diejenigen, die man landläufig als »DHCP-Anfragen« bezeichnet) ignoriert werden. Diese Option wird in der UMC über Policies eingestellt.

Schauen Sie bitte mal, woher die Policy kommt, die das festlegt. Dazu gibt’s mehrere Möglichkeiten.

Eine davon: Kommandozeile. Sie können den folgenden Befehl ausführen:

univention-policy-result -D $(ucr get ldap/hostdn) -y /etc/machine.secret cn=192.168.122.0,cn=huf.intranet,cn=dhcp,$(ucr get ldap/base)

Relevant ist der Block für das Attribut »univentionDhcpBootp«, bei einem meiner Testserver beispielsweise:

… Policy: cn=TestMe,cn=scope,cn=dhcp,cn=policies,dc=mbu-test,dc=intranet Attribute: univentionDhcpBootp Value: ignore

Nun wissen Sie, welches Policy-Objekt dafür verantwortlich ist. Editieren Sie sie und ändern Sie den Eintrag für bootp auf »allow« (oder auf leer, denn leer = Standard wird genommen, und Standard ist »allow«).

Etwas einfacher: editieren Sie das DHCP-Subnetz-Objekt in der UMC, gehen Sie auf den Reiter »Policies«, erweitern Sie den Bereich »Policy: DHCP Allow/Deny« und clicken Sie auf das kleine Icon zum Bearbeiten (das mit dem Stift).

Wenn das alles wieder funktioniert, dann können Sie auch die Änderung an der dhcpd.conf wieder rückgängig machen. Sie schadet aber auch nicht wirklich.

Gruß,
mosu

Wieder mal was dazugelernt, ich dachte das würde mit dem netzwerk boot zusammenhängen

Tausend dank für die Hilfe!

root@pdc:~# tcpdump -n -i any port 67 or port 68 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 12:29:18.078727 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 12:29:18.082229 IP 192.168.122.2.67 > 192.168.122.100.68: BOOTP/DHCP, Reply, length 300 12:29:18.082418 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:23:0a:d4, length 300 12:29:18.085392 IP 192.168.122.2.67 > 192.168.122.100.68: BOOTP/DHCP, Reply, length 300

Gern geschehen