DHCP-Cluster nach Update auf 4.1-4

[roland.gsell]

Liebes Forum,

ein Kunde hat mich gerade angerufen und mir erzählt, dass er seit gestern ein Problem mit seinem DHCP-Cluster hat nachdem er das Update auf 4.1-4 durchgeführt hat.

Das Verhalten ist folgendermassen:
Clients bekommen eine IP vom Master. Wenn dort der DHCP-Dienst beendet wird, übernimmt der Backup und Clients erhalten ihre IPs von ihm. Soweit geht alles wie erwartet.

Wenn jedoch ein Client, welcher bereits eine IP vom Master erhalten hat nach dem Deaktivieren von DHCP am Master ein "ipconfig /renew" macht, bekommt er keine. Man muss ein Release machen und dann ein Renew, dann erst geht es wieder. Mit 4.0-3 gab es dieses Problem nicht.

Leider kann ich mit keinen Log-Einträgen dienen, da es mir nur kurz am Telefon erklärt wurde und ich heute keine Zeit für eine nähere Analyse hatte, aber vielleicht ist das Problem ja bekannt?

Danke fürs Lesen,
Roland.

[roland.gsell]

Update: Gestartet wurde das Update mit Version 4.0-3, nicht mit 4.1-3
Ich habe den Beitrag entsprechend angepasst.

[roland.gsell]

So, ich kann nun mit ein paar Logs und Mitschnitten dienen.

In der Version hat sich ja einiges getan, wie ich aus einem LDAP-Diff herauslesen konnte:
jetzt:
dn: univentionAppID=dhcp-server_10.0.1,cn=dhcp-server,cn=apps,cn=univention,
vorher:
dn: univentionAppID=dhcp-server_8,cn=dhcp-server,cn=apps,cn=univention,dc=

Das Verhalten ist eben wie oben beschrieben:

Der Client holt sich eine IP vom Master (erster tcpdump-Mitschnitt). Dann fällt der Master aus. (zumindest der DHCP-Dienst)
Wenn dann am Client ein renew gemacht wird, sieht man nur am Master Traffic und natürlich dass auf dem entsprechenden Port niemand lauscht. (2. Mitschnitt)
Macht man nun ein Release am Client, teilt er dies ebenfalls dem nicht laufenden Master mit (3.) - der das aber natürlich nicht mitkriegt.
Ein anschließender Renew geht dann auf beide Server und am Backup geht ein erfolgreiches DHCPACK raus. (4.+5.)

1. Master: dhcp läuft, Client bekommt IP, Backup: kein Traffic

09:44:34.944608 IP notebook22.buero.company.com.bootpc > ucs-master.buero.company.com.bootps: BOOTP/DHCP, Request from 74:2b:62:8b:9e:c0 (oui Unknown), length 324
09:44:34.965361 IP ucs-master.buero.company.com.bootps > notebook22.buero.company.com.bootpc: BOOTP/DHCP, Reply, length 300


2. Master: dhcp offline, Am Client: renew, Backup: kein Traffic

09:46:02.302927 IP notebook22.buero.company.com.bootpc > ucs-master.buero.company.com.bootps: BOOTP/DHCP, Request from 74:2b:62:8b:9e:c0 (oui Unknown), length 324
09:46:02.303050 IP ucs-master.buero.company.com > notebook22.buero.company.com: ICMP ucs-master.buero.company.com udp port bootps unreachable, length 360
09:46:05.297356 IP notebook22.buero.company.com.bootpc > ucs-master.buero.company.com.bootps: BOOTP/DHCP, Request from 74:2b:62:8b:9e:c0 (oui Unknown), length 324
09:46:05.297456 IP ucs-master.buero.company.com > notebook22.buero.company.com: ICMP ucs-master.buero.company.com udp port bootps unreachable, length 360
09:46:13.299495 IP notebook22.buero.company.com.bootpc > ucs-master.buero.company.com.bootps: BOOTP/DHCP, Request from 74:2b:62:8b:9e:c0 (oui Unknown), length 324
09:46:13.299586 IP ucs-master.buero.company.com > notebook22.buero.company.com: ICMP ucs-master.buero.company.com udp port bootps unreachable, length 360



3. Master: Am Client: release, Backup: kein Traffic

09:47:54.186992 IP notebook22.buero.company.com.bootpc > ucs-master.buero.company.com.bootps: BOOTP/DHCP, Request from 74:2b:62:8b:9e:c0 (oui Unknown), length 300
09:47:54.187106 IP ucs-master.buero.company.com > notebook22.buero.company.com: ICMP ucs-master.buero.company.com udp port bootps unreachable, length 336



4. Master: Am Client: renew (nach release)

09:48:14.543134 IP notebook22.buero.company.com.bootps > ucs-master.buero.company.com.bootps: BOOTP/DHCP, Request from 74:2b:62:8b:9e:c0 (oui Unknown), length 300
09:48:14.543236 IP ucs-master.buero.company.com > notebook22.buero.company.com: ICMP ucs-master.buero.company.com udp port bootps unreachable, length 336
09:48:14.543263 IP notebook22.buero.company.com.bootps > ucs-master.buero.company.com.bootps: BOOTP/DHCP, Request from 74:2b:62:8b:9e:c0 (oui Unknown), length 300
09:48:14.543278 IP ucs-master.buero.company.com > notebook22.buero.company.com: ICMP ucs-master.buero.company.com udp port bootps unreachable, length 336

5. Backup: Am Client: renew (nach release)

09:48:14.543627 IP notebook22.buero.company.com.bootps > ucs-backup.buero.company.com.bootps: BOOTP/DHCP, Request from 74:2b:62:8b:9e:c0 (oui Unknown), length 300
09:48:14.543717 IP notebook22.buero.company.com.bootps > ucs-backup.buero.company.com.bootps: BOOTP/DHCP, Request from 74:2b:62:8b:9e:c0 (oui Unknown), length 300
09:48:14.544479 IP ucs-backup.buero.company.com.bootps > notebook22.buero.company.com.bootpc: BOOTP/DHCP, Reply, length 300
09:48:14.544824 IP ucs-backup.buero.company.com.bootps > notebook22.buero.company.com.bootpc: BOOTP/DHCP, Reply, length 300
09:48:14.545045 IP dc01.buero.company.com.domain > ucs-backup.buero.company.com.33352: 27200* 2/0/0 PTR notebook22.buero.company.com., PTR notebook03.buero.company.com. (110)


Ausschnitte aus der daemon.log:

Apr 13 09:45:48 ucs-backup dhcpd: peer failover-partner: disconnected
Apr 13 09:45:48 ucs-backup dhcpd: failover peer failover-partner: I move from normal to communications-interrupted


Apr 13 09:48:09 ucs-backup dhcpd: DHCPOFFER on 10.2.1.102 to 74:2b:62:8b:9e:c0 via 10.2.1.253
Apr 13 09:48:09 ucs-backup dhcpd: DHCPDISCOVER from 74:2b:62:8b:9e:c0 via 10.2.1.254
Apr 13 09:48:09 ucs-backup dhcpd: DHCPOFFER on 10.2.1.102 to 74:2b:62:8b:9e:c0 via 10.2.1.254
Apr 13 09:48:10 ucs-backup dhcpd: Dynamic and static leases present for 10.2.1.102.
Apr 13 09:48:10 ucs-backup dhcpd: Remove host declaration NOTEBOOK22 or remove 10.2.1.102
Apr 13 09:48:10 ucs-backup dhcpd: from the dynamic address pool for 10.2.1.0/24
Apr 13 09:48:10 ucs-backup dhcpd: DHCPREQUEST for 10.2.1.102 (10.1.1.205) from 74:2b:62:8b:9e:c0 via 10.2.1.253
Apr 13 09:48:10 ucs-backup dhcpd: DHCPACK on 10.2.1.102 to 74:2b:62:8b:9e:c0 via 10.2.1.253
Apr 13 09:48:10 ucs-backup dhcpd: Dynamic and static leases present for 10.2.1.102.
Apr 13 09:48:10 ucs-backup dhcpd: Remove host declaration NOTEBOOK22 or remove 10.2.1.102
Apr 13 09:48:10 ucs-backup dhcpd: from the dynamic address pool for 10.2.1.0/24
Apr 13 09:48:10 ucs-backup dhcpd: DHCPREQUEST for 10.2.1.102 (10.1.1.205) from 74:2b:62:8b:9e:c0 via 10.2.1.254
Apr 13 09:48:10 ucs-backup dhcpd: DHCPACK on 10.2.1.102 to 74:2b:62:8b:9e:c0 via 10.2.1.254
Apr 13 09:48:14 ucs-backup dhcpd: DHCPINFORM from 10.2.1.102 via 10.2.1.254
Apr 13 09:48:14 ucs-backup dhcpd: DHCPACK to 10.2.1.102 (74:2b:62:8b:9e:c0) via eth0

Gibt es Ideen dazu? Etwas das ich prüfen noch kann?

LG,
Roland.

[Moritz_Bunkus]

Moin,

Ihre Dumps sind leider etwas abgeschnitten. Vermutlich haben Sie Filter auf die Hosts gesetzt. Dadurch fehlen entscheidende Anfragen, nämlich die Broadcasts, die bei der Suche nach verfügbaren DHCP-Servern eingesetzt werden.

Ein Dialog beim Dynamic Host Configuration Protocol besteht für ein »kaltes« Gerät (das also noch keine IP hatte) aus folgenden Schritten:

1. Client sendet ein »DHCP discover« an die Broadcast-Adresse des lokalen Netzwerks.
2. Alle verfügbaren DHCP-Server, die dieses Broadcast sehen (und für die entsprechenden Parameter konfiguriert sind), antworten mit einer »DHCP offer«, in der eine IP-Adresse angeboten wird.
3. Der Client sucht sich daraus einen passenden aus; meist ist es schlicht die erste Antwort, die er erhält.
4. Nun sendet der Client an den Server (und nicht mehr an die Broadcast-Adresse), von dem das Angebot kam, eine Bitte um Reservierung, »DHCP request«.
5. Der Server prüft, ob die Adresse noch frei ist. Bei Erfolg bestätigt der Server das nun mit einer Nachricht »DHCP acknowledge«.
6. Der Client kann nun die in Schritt 3 angefragte Adresse konfigurieren.

Hat ein Client aber bereits ein gültiges Lease von einem Server, und nähert sich das Lease der Verfallszeit (oder aber macht man ein manuelles Update wie z.B. unter Windows mit ipconfig /renew), so weiß der Client ja bereits, von welchem Server er die Anfrage bekommen hat. Er spart sich somit Schritte 1 und 3 (damit entfällt auch Schritt 2) und macht gleich mit Schritt 4 weiter: er bittet den Server, von dem aus er die Adresse bekommen hat, um ein erneutes Lease für dieselbe Adresse, auch hier wieder mit »DHCP request«.

Das ist das, was bei Ihnen passiert. Nun ist aber der Server, von dem aus der Client das Lease ursprünglich erhalten hat, nicht mehr verfügbar, weshalb keine Antwort vom Server kommt. Anscheinend wertet der Client das nicht als grundlegendes Problem, weil das Lease per se ja noch gültig ist, der Client es also problemlos weiter verwenden darf.

Sobald das Lease ausläuft, sollte der Client wieder in den »kalten« Modus zurückfallen und den Dialog wieder ganz von vorne beginnen. Ab dem Zeitpunkt sollte dann auch der Backup-Server ins Spiel kommen und bei Schritt 2 antworten, bei Schritt 3 ausgewählt und ab Schritt 4 für Leases befragt werden. All das sollte vollautomatisch passieren.

Kurz: die Situation sollte eigentlich kein Problem darstellen; die Testmdethodik ist hier schlicht nur nicht dafür geeignet, was Ihr Kunde testen wollte.

Wenn man ein ipconfig /release macht, so geht der Netzwerkstack sofort für das Interface in den unkonfigurierten, kalten Modus. Daher klappt dann auch der Dialog mit dem Backup sofort, weil der DHCP-Dialog sofort wieder von ganz vorne beginnt.

Gruß,
mosu

[roland.gsell]

Das hört man natürlich gerne, dass man eigentlich gar kein Problem hat.
(ja, die Dump waren auf den Client gefiltert)

Danke für die ausführliche Antwort,

[Moritz_Bunkus]

Gern. Sie sollten das schon beobachten und einfach mal ausprobieren — einfach den DHCP-Server auf dem Master ein paar Stunden aus lassen und schauen, ob Clients von sich aus den Dialog mit dem Backup beginnen, wenn ihr Lease normal ausläuft.