12
DHCP-Server vergibt keine Adressen (IPv4)
Hallo zusammen,
irgendwie ist bei mir hier gerade gehörig der Wurm drin und ich überlege gerade, warum meine bisherigen Servermigrationen fast reibungslos geklappt haben.
Problem ist die Migration eines DHCP-Servers (von Server 2012 R2 nach 2019). Übliche Vorgehensweise:
Problem ist: Der neue Server verteilt keine IP-Adressen. Aktiviere ich parallel wieder den alten DHCP-Server, dann werden IP-Adressen vergeben. Der neue DHCP-Server läuft direkt auf einem DC und auch testweise mit dem Domänen-Admin-Account.
Habt ihr einen Tipp? Eigentlich schon x-mal so vorgegangen, aber aktuell geht es nicht...
Gruß
Michael
irgendwie ist bei mir hier gerade gehörig der Wurm drin und ich überlege gerade, warum meine bisherigen Servermigrationen fast reibungslos geklappt haben.
Problem ist die Migration eines DHCP-Servers (von Server 2012 R2 nach 2019). Übliche Vorgehensweise:
- DHCP-Rolle auf dem neuen Server installieren
- DHCP-Einstellungen auf dem alten Server exportieren (netsh dhcp server export c:\dhcp.dat all)
- DHCP-Einstellungen auf dem neuen Server importieren (netsh dhcp server import c:\dhcp.dat all)
- DHCP-Server auf dem alten Server beenden/deinstallieren
- DHCP-Server auf dem neuen Server neustarten und Autorisierung für neuen Server anpassen bzw. alten löschen.
Problem ist: Der neue Server verteilt keine IP-Adressen. Aktiviere ich parallel wieder den alten DHCP-Server, dann werden IP-Adressen vergeben. Der neue DHCP-Server läuft direkt auf einem DC und auch testweise mit dem Domänen-Admin-Account.
Habt ihr einen Tipp? Eigentlich schon x-mal so vorgegangen, aber aktuell geht es nicht...
Gruß
Michael
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: 2668697446
Url: https://administrator.de/contentid/2668697446
Ausgedruckt am: 22.11.2024 um 06:11 Uhr
12 Kommentare
Neuester Kommentar
Moin Michael,
stehen die Server und Clients im selben Subnetz? Nein, dann muss vermutlich die IP-Adresse auf dem DHCP-Helper noch angepasst werden. Je nachdem auf dem Router oder L3 Switch.
Gruß,
Dani
stehen die Server und Clients im selben Subnetz? Nein, dann muss vermutlich die IP-Adresse auf dem DHCP-Helper noch angepasst werden. Je nachdem auf dem Router oder L3 Switch.
Gruß,
Dani
Hallo,
und hast Du den DHCP-Server im Active Directory authorisiert?
Grüße
lcer
und hast Du den DHCP-Server im Active Directory authorisiert?
Grüße
lcer
Moin!
Ja, beide Server (alt und neu) besitzen eine statische Adresse im Bereich 10.20.0.0/16 und sollen auch dort IP-Adressen vergeben:
Adresse des neuen Servers:
Ja, siehe Schritte oben. Im AD gibt es nun in der Konfiguration unter Services/NetServices zwei Einträge: DhcpRoot und den Eintrag vom neuen Server.
Gruß
Michael
Ja, beide Server (alt und neu) besitzen eine statische Adresse im Bereich 10.20.0.0/16 und sollen auch dort IP-Adressen vergeben:
Adresse des neuen Servers:
Ja, siehe Schritte oben. Im AD gibt es nun in der Konfiguration unter Services/NetServices zwei Einträge: DhcpRoot und den Eintrag vom neuen Server.
Gruß
Michael
Moin,
Hast du die Bindung denn einmal geprüft? Oder gibt es vielleicht mehrere Netzwerkkarten, so dass die Bindung nicht korrekt ist?
Gruß
Doskias
Hast du die Bindung denn einmal geprüft? Oder gibt es vielleicht mehrere Netzwerkkarten, so dass die Bindung nicht korrekt ist?
Gruß
Doskias
Hallo,
bevor es ans eingemachte geht - Schau noch mal nach, ob:
Der Client wird zur Erneuerung eines ablaufenden Leases zunächst den alten DHCP per Unicast! kontaktieren. Nur wenn der nicht antwortet, fällt er dann in das DHCP Broadcast-Veralten zurück.
Wenn das alles stimmt, geht es weiter mit Wireshark auf dem Server.
Grüße
lcer
bevor es ans eingemachte geht - Schau noch mal nach, ob:
- die Firewall UDP Port 67/68 durchläßt
- die Clients überhaupt Leases wollen ....
Der Client wird zur Erneuerung eines ablaufenden Leases zunächst den alten DHCP per Unicast! kontaktieren. Nur wenn der nicht antwortet, fällt er dann in das DHCP Broadcast-Veralten zurück.
Wenn das alles stimmt, geht es weiter mit Wireshark auf dem Server.
Grüße
lcer
16er Prefixes zeugen ja nun auch nicht gerade von gutem IP Adressdesign....
1
Hallo!
Nun ja, was soll ich sagen: Mal wieder "historisch gewachsen". Bin ja schon froh, dass hier tatsächlich private Adressen zum Einsatz kommen. Auch das ist nicht selbstverständlich...aber ich schweife ab...
Ja, die Bindung habe ich auch überprüft; die korrekte Netzwerkschnittstelle ist ausgewählt.
Laut der Firewalleinstellung ist dies der Fall
Jo, das hatte ich auch auf'n Zettel, aber dann müsste ja als Fallback auf jeden Fall der Server irgendwann ne Adresse ausspucken. Und das passiert eben nicht.
Das ist dann das nächste Todo...
Viele Grüße
Michael
Nun ja, was soll ich sagen: Mal wieder "historisch gewachsen". Bin ja schon froh, dass hier tatsächlich private Adressen zum Einsatz kommen. Auch das ist nicht selbstverständlich...aber ich schweife ab...
Zitat von @Doskias:
Hast du die Bindung denn einmal geprüft? Oder gibt es vielleicht mehrere Netzwerkkarten, so dass die Bindung nicht korrekt ist?
Hast du die Bindung denn einmal geprüft? Oder gibt es vielleicht mehrere Netzwerkkarten, so dass die Bindung nicht korrekt ist?
Ja, die Bindung habe ich auch überprüft; die korrekte Netzwerkschnittstelle ist ausgewählt.
Zitat von @lcer00:
bevor es ans eingemachte geht - Schau noch mal nach, ob:
bevor es ans eingemachte geht - Schau noch mal nach, ob:
- die Firewall UDP Port 67/68 durchläßt
Laut der Firewalleinstellung ist dies der Fall
* die Clients überhaupt Leases wollen ....
Der Client wird zur Erneuerung eines ablaufenden Leases zunächst den alten DHCP per Unicast! kontaktieren. Nur wenn der nicht antwortet, fällt er dann in das DHCP Broadcast-Veralten zurück.
Der Client wird zur Erneuerung eines ablaufenden Leases zunächst den alten DHCP per Unicast! kontaktieren. Nur wenn der nicht antwortet, fällt er dann in das DHCP Broadcast-Veralten zurück.
Jo, das hatte ich auch auf'n Zettel, aber dann müsste ja als Fallback auf jeden Fall der Server irgendwann ne Adresse ausspucken. Und das passiert eben nicht.
Wenn das alles stimmt, geht es weiter mit Wireshark auf dem Server.
Das ist dann das nächste Todo...
Viele Grüße
Michael
Hallo,
habe jetzt mal Wireshark bemüht. Offenbar kommen Pakete an, aber es erfolgt keine Antwort vom Server:
Was mir noch aufgefallen ist: Der alte/bisherige Server vergibt IP-Adressen unabhängig davon, ob er im AD autorisiert ist oder auch nicht. Nach meinem Verständnis dürfte er doch eigentlich nur bei einer Autorisierung etwas vergeben, oder?
Habe zwischenzeitlich den DHCP-Server noch einmal komplett deinstalliert und neu installiert - leider weiterhin ohne Erfolg. Hat noch jemand eine Idee? Liegt das ggf. am Zusammenspiel mit dem DNS-Server?
Viele Grüße
Michael
habe jetzt mal Wireshark bemüht. Offenbar kommen Pakete an, aber es erfolgt keine Antwort vom Server:
Frame 801: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits) on interface \Device\NPF_{C9C17521-3397-498F-926B-3F87AE7A2CC9}, id 0
Interface id: 0 (\Device\NPF_{C9C17521-3397-498F-926B-3F87AE7A2CC9})
Encapsulation type: Ethernet (1)
Arrival Time: May 5, 2022 14:41:04.376078000 Mitteleuropäische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1651754464.376078000 seconds
[Time delta from previous captured frame: 0.062236000 seconds]
[Time delta from previous displayed frame: 1.949274000 seconds]
[Time since reference or first frame: 13.560678000 seconds]
Frame Number: 801
Frame Length: 346 bytes (2768 bits)
Capture Length: 346 bytes (2768 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:dhcp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Dummy_xx:9f:a6 (xx:xx:xx:xx:9f:a6), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Dummy_xx3:9f:a6 (xx:xx:xx:xx:9f:a6)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
Total Length: 332
Identification: 0x0000 (0)
Flags: 0x40, Don't fragment
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 64
Protocol: UDP (17)
Header Checksum: 0x3992 [validation disabled]
[Header checksum status: Unverified]
Source Address: 0.0.0.0
Destination Address: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Source Port: 68
Destination Port: 67
Length: 312
Checksum: 0x1c4a [unverified]
[Checksum Status: Unverified]
[Stream index: 6]
[Timestamps]
UDP payload (304 bytes)
Dynamic Host Configuration Protocol (Request)
[Community ID: 1:t9O1j0qj71O4wJM7gnaHtgmfev8=]
Frame 873: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface \Device\NPF_{C9C17521-3397-498F-926B-3F87AE7A2CC9}, id 0
Interface id: 0 (\Device\NPF_{C9C17521-3397-498F-926B-3F87AE7A2CC9})
Encapsulation type: Ethernet (1)
Arrival Time: May 5, 2022 14:41:06.358532000 Mitteleuropäische Sommerzeit
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1651754466.358532000 seconds
[Time delta from previous captured frame: 0.005867000 seconds]
[Time delta from previous displayed frame: 1.982454000 seconds]
[Time since reference or first frame: 15.543132000 seconds]
Frame Number: 873
Frame Length: 342 bytes (2736 bits)
Capture Length: 342 bytes (2736 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:dhcp]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Dummy_xx:9f:a6 (xx:xx:xx:xx:9f:a6), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Source: Dummy_xx:9f:a6 (xx:xx:xx:xx:9f:a6)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
Total Length: 328
Identification: 0x0000 (0)
Flags: 0x40, Don't fragment
...0 0000 0000 0000 = Fragment Offset: 0
Time to Live: 64
Protocol: UDP (17)
Header Checksum: 0x3996 [validation disabled]
[Header checksum status: Unverified]
Source Address: 0.0.0.0
Destination Address: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Source Port: 68
Destination Port: 67
Length: 308
Checksum: 0xad88 [unverified]
[Checksum Status: Unverified]
[Stream index: 6]
[Timestamps]
UDP payload (300 bytes)
Dynamic Host Configuration Protocol (Discover)
[Community ID: 1:t9O1j0qj71O4wJM7gnaHtgmfev8=]Was mir noch aufgefallen ist: Der alte/bisherige Server vergibt IP-Adressen unabhängig davon, ob er im AD autorisiert ist oder auch nicht. Nach meinem Verständnis dürfte er doch eigentlich nur bei einer Autorisierung etwas vergeben, oder?
Habe zwischenzeitlich den DHCP-Server noch einmal komplett deinstalliert und neu installiert - leider weiterhin ohne Erfolg. Hat noch jemand eine Idee? Liegt das ggf. am Zusammenspiel mit dem DNS-Server?
Viele Grüße
Michael
Hallo,
In dem Trace folgt sieht man 1) einen Request und dann 2) ein Discover. Das ist unvollständig. Kannst Du bitte mal alle DHCP-Nachrichten filtern und dann einen Screenshot posten?
Grüße
lcer
In dem Trace folgt sieht man 1) einen Request und dann 2) ein Discover. Das ist unvollständig. Kannst Du bitte mal alle DHCP-Nachrichten filtern und dann einen Screenshot posten?
Grüße
lcer
Hi,
Jupp, das hat mich in der Tat auch gewundert, warum a) die Reihenfolge nicht passt und b) der Request ohne Offer gesendet wird. Mehr Logs (gefiltert auf BOOTP) waren allerdings nicht enthalten.
Ich habe das daher jetzt noch einmal mit einem anderen Client nachvollzogen (sowohl Client- wie auch Serverseite). Dort werden tatsächlich nur mehrere Discover-Pakete an Broadcast gesendet; diese kommen auch laut Wireshark am Server an, werden aber überhaupt nicht weiter beantwortet. Für mich wirkt das, als wäre der DHCP-Server überhaupt nicht autorisiert und verwirft daher die Pakete. Tatsächlich ist er aber ja autorisiert und auch im AD existieren die entsprechenden Einträge.
Gruß
Michael
Zitat von @lcer00:
In dem Trace folgt sieht man 1) einen Request und dann 2) ein Discover. Das ist unvollständig. Kannst Du bitte mal alle DHCP-Nachrichten filtern und dann einen Screenshot posten?
In dem Trace folgt sieht man 1) einen Request und dann 2) ein Discover. Das ist unvollständig. Kannst Du bitte mal alle DHCP-Nachrichten filtern und dann einen Screenshot posten?
Jupp, das hat mich in der Tat auch gewundert, warum a) die Reihenfolge nicht passt und b) der Request ohne Offer gesendet wird. Mehr Logs (gefiltert auf BOOTP) waren allerdings nicht enthalten.
Ich habe das daher jetzt noch einmal mit einem anderen Client nachvollzogen (sowohl Client- wie auch Serverseite). Dort werden tatsächlich nur mehrere Discover-Pakete an Broadcast gesendet; diese kommen auch laut Wireshark am Server an, werden aber überhaupt nicht weiter beantwortet. Für mich wirkt das, als wäre der DHCP-Server überhaupt nicht autorisiert und verwirft daher die Pakete. Tatsächlich ist er aber ja autorisiert und auch im AD existieren die entsprechenden Einträge.
Gruß
Michael
BOOTP ist keine so gute Idee. Besser ist "udp port 68 or port 67" als Capture Filter zu nehmen. Das zeigt die gesamte DHCP Kommunikation.
De facto ist es aber der Server selber oder dessen lokale Firewall.
De facto ist es aber der Server selber oder dessen lokale Firewall.
Juhu, das war's: Ich hatte zwar die eingehenden Firewalleinstellungen auf dem Schirm, nicht aber die ausgehenden, die gesperrt waren... *grhh*
Jetzt geht es! Danke!!
