Über DHCP falsche IP

UCS - Univention Corporate Server
#1

Hallo, mir ist aufgefallen, daß zumindest ein Teil Windows-Clients eine falsche IP bekommt:

[quote]05.06.13 18:36:25.178 DEBUG_INIT
05.06.13 18:36:25.180 LDAP ( WARN ) : Not found
05.06.13 18:36:25.191 LDAP ( WARN ) : Not found
05.06.13 19:06:17.966 LDAP ( WARN ) : Not found
05.06.13 19:06:30.941 LDAP ( WARN ) : Not found
05.06.13 19:06:30.977 LDAP ( WARN ) : Not found
05.06.13 19:06:43.974 LDAP ( WARN ) : Not found
05.06.13 19:14:05.473 LDAP ( WARN ) : Not found
05.06.13 19:16:06.480 LDAP ( WARN ) : Not found
[/quote]

Es sieht so aus als gäbs da Probleme mit dem LDAP.

#2

Es tritt offentlich bei allen Windows-Clients auf, ist allerdings nicht unbedingt auf die beschränkt. Während des Upgrades des Opsi-SDC habe ich nämlich auch Probleme beim booten der UCC festgestellt.
Das Problem tritt anscheinend nur auf, wenn dieser läuft.

EDIT: Der SDC läuft übrigens in UVMM auf dem Master.

#3

Ich hab mal ausprobiert ob es an den virtio-Treibern liegt: Fehlanzeige.

Die Meldungen scheint auch nicht direkt was damit zu tun zu haben. Die treten anscheinend bei jedem DHCP-Request auf, egal ob die zugeteilte IP dann richtig ist oder nicht.

#4

Hat vermutlich nichts damit zu, aber ich poste es mal:

Jun 6 19:06:56 udsmaster dhcpd: DHCPINFORM from 192.168.10.4 via eth0: not authoritative for subnet 192.168.10.0 Jun 6 19:06:56 udsmaster dhcpd: If this DHCP server is authoritative for that subnet, Jun 6 19:06:56 udsmaster dhcpd: please write an `authoritative;' directive either in the Jun 6 19:06:56 udsmaster dhcpd: subnet declaration or in some scope that encloses the Jun 6 19:06:56 udsmaster dhcpd: subnet declaration - for example, write it at the top Jun 6 19:06:56 udsmaster dhcpd: of the dhcpd.conf file. Jun 6 19:06:59 udsmaster dhcpd: DHCPINFORM from 192.168.10.4 via eth0: not authoritative for subnet 192.168.10.0

Wenn ein Client eine falsche IP bekommt wird dazu leider nichts verdächtiges ins syslog geschrieben.

#5

Hallo,

Vielleicht können Sie ja nichts sehen, weil es im syslog auf einem anderen DHCP-Server steht?

Nicht nur die NSA kann lauschen, ich würde mal schauen, was so an DHCP-Nachrichten durchläuft.

tcpdump  '(port 67 or port 68)'
#6

Hm an der Opsi-VM scheint es dann noch zu liegen. Der Client kriegt eine falsche IP bzw. keine nachdem der DCHP-Pool mit gelöscht wurde.

Meldungen:

mac-adresse IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from mac-adresse (oui Unknown), length 548
#7

Die Meldung taucht noch im syslog auf:

dhcpd: 5 bad udp checksums in 5 packets

Laut dem hier hat das anscheinend mit KVM und virtio zu tun. Allerdings läuft da der dhcpd wohl in der VM und nicht auf dem Host. Und ich hab jetzt noch mal neugestartet und vorher alle VMs ausgeschaltet: Läuft trotzdem nicht.

Als Verdächtige fallen mir nur noch die Bridge Netzwerkkarte oder Switche ein.

#8

Allerdings macht das auch keinen Sinn. Denn der Client kriegt ja eine IP aus dem Pool. Nur nicht die zugeteilte feste. Klingt also eigentlich eher nach einem Problem mit dem LDAP-Backend. Z.B. ist mir aufgefallen, daß der Client keine IP kriegt, wenn der Pool im selben “LDAP-Netzwerk” wie der Client ist. Allerdings kriegt er auch nicht die richtige, wenn ich ihn ins default-Netz nehme.

Noch zur Erläuterung: Der Client von dem hier rede sind eigentlich zwei WIndows-Clients, bei denen das Phänomen auftritt. Bei einem dritten ist auch mal aufgetren, als gerade die Opsi-VM lief. Nachm ihrem Shutdown trat es bei diesem nicht mehr auf. So kam es zu der entsprechenden Theorie.

Die UCCs bleiben beim booten manchmal in einer Warteschlange hängen. Aber ich weiß nicht ob das die selbe Ursache hat. Wenn sie mal laufen haben sie jedenfalls immer die richtige IP.

#9

Also bisherige Tests scheinen wohl fehlerhaft durchgeführt worden zu sein. Jedenfalls erscheint es mir jetzt ziemlich eindeutig, daß Rechner, die nicht unterm dem default-DHCP-Objekt liegen, eine IP aus dem dynamischen Pool kriegen, weil ihr Eintrag dann wohl nicht ausgewertet wird. Bei einem neu angelegten DHCP-Objekt tritt das leider auch auf, dieser Weg taugt also leider nicht als Workaround

#10

Hallo,

ob und wie das zusätzliche DHCP-Objekt funktioniert, hängt von der Definition Ihrer Netzwerke (Netz-Objekte im LDAP) ab.
Im Moment sieht es für mich so aus, als wenn eine zumindest teilweise überlappende Konfiguration entweder bei den Netzwerken oder den DHCP-Objekten dazu führt, dass die Adressen aus dem Pool, welche unbekannte Clients zulässt, kommen.

In der Standard-Doku stehen noch ein paar Hinweise die sich - mir zumindest - erst beim mehrmaligen Lesen und Testen erschließen. Für Sie könnte der Punkt interessant werden, dass sich die Pools sowohl im “DHCP: Subnet” als auch unterhalb von “DHCP: Subnet” als “DHCP: Pool” definieren lassen.
IP assignment via DHCP

#11

Hm danke für den Hinweis, auf die Idee mal ins Handbuch zu gucken hätte ich auch mal selbst gucken können. Allerdings tas ja mit UCS 2.4 so funktioniert.

Also die Problemstellung ist ja eigentlich, daß Windows- und Linux-Clients unterschiedliche Bootserver haben. Daher hatte ich damals ein zweites Netzwerk angelegt, daß nur ein anderes DHCP:Service-Objekt hatte. Und das bekam dann eine andere Richtlinie bzgl. PXE.

Nach der Lektüre des Handbuchs verstehe ich es nun so, daß dem zweiten DHCP:Service “opsi” ein DHCP:Server-Eintrag fehlt. Der DHCP-Server fühlt sich deshalb dafür nicht zuständig? Wenn ich darin nun eins anlege beschwert er sich, daß es schon vorhanden ist.

#12

Es ist wahrscheinlich sinnvoller, anstelle eines separaten DHCP-Services ein weiteres DHCP-Subnet unter dem vorhandenen Service zu erstellen. Dort können Sie dann die abweichenden Richtlinien zuweisen.

Wenn es nur bei einzelnen DHCP-Hosts nicht funktioniert, wäre zu prüfen, ob diese nicht versehentlich eine eigene abweichende Richtlinie bekommen haben.

#13

Das Subnetz-Objekt hab ich ja eigentlich schon. Wie kriegt man nun die UMC dazu die Windows-DHCP-Objekte darunter anzulegen?

#14

Das geht wohl so nicht.
Vorausgesetzt, am DHCP-Host oder an einem anderen darüberliegenden Objekt ist keine DHCP-Richtlinie gesetzt, wird die Richtlinie des passenden DHCP-Subnetzes gezogen.
Welche Richtlinie greift, können Sie mit “univention-policy-result” prüfen.

Es gibt dazu übrigens auch den Doc-[bug]31650[/bug].

In [url]Keine Antwort von UCS an DHCP-Relay] finden Sie einen Hinweis, wie Sie die aus dem LDAP ermittelte DHCP-Konfiguration sehen können.

Viele Grüße,
Dirk Ahrnke

#15

Danke. Ich hab jetzt die Richtlinie an das Rechner-Objekt gesetzt denke ich werde das vorerst so lassen.

Mastodon