11
DHCP Fehler ID 20322 und 20291
Hallo liebe Mit-Admins.
Durch Wegfall mehrerer MA erhalte ich gerade ungewollt viele neue Tätigkeitsfelder. U.a. muss ich mich plötzlich um unsere Domäne, GPOs, DNS, DHCP mehr oder weniger allein kümmern ... mal schauen wie lange das gut geht, aber das ist ein anderes Thema.
Mein Problem liegt in den Fehler IDs, die der DHCP Dienst auswirft.
Es gibt zwei DHCP Server mit ca. 40 IPv4 Scopes. Für jeden ist die Failoverkonfiguration als Lastverteilung 50/50% aktiv
Im DNS ist für jeden DHCP-Scope auch eine passende Reverse-Lookupzone eingerichtet.
Hab es extra nochmal überprüft.
Auf die Fehler aufmerksam geworden bin ich, weil heute mehrere Dinge passiert sind, die mich in die Logs haben schauen lassen.
Es sollten zwei PC-Systeme ausgetauscht werden. Neu gegen alt. Die Neuen sollen die Aufgaben der Alten übernehmen. Da das Spezial-Kisten sind, haben die DHCP Reservierungen, um immer die gleiche IP zu erhalten.
Entsprechend sollen die IPs beibehalten werden.
DNS-Namen sind allerdings neu und soll auch so.
*Alte System heruntergefahren und abgeklemmt.
*Dann die DHCP Reservierungen gelöscht.
*Neue Reservierungen mit neuer MAC erstellt.
*DNS überprüft, alte Einträge sind auch artig verschwunden. Prima.
Neue Systeme Angeklemmt, hochgefahren, ... nicht erreichbar. Reservierung bleibt (Inaktiv).
Habe festgestellt, dass die neuen Reservierungen nicht auf dem anderen DHCP zu sehen sind.
Wie mir wieder ins Gedächtnis gerufen wurde - Reservierungen replizieren sich _nicht_ von allein. ... kann man ja mal vergessen.
Also kurzerhand die Replizierung von Bereich und Beziehung des entpsrechenden Scopes per Hand angestoßen.
Dabei erschien eine Fehlermeldung, bezüglich der Datenbank. Habe sie leider nicht mehr im Kopf, da mitten in Kundschaft am hantieren etc.
Beim zweiten Versuch klappte es jedenfalls. Konnte den Fehler bisher auch nicht wieder reproduzieren.
Die Reservierungen waren nun auf beiden DHCPs aktiv, die neuen PCs erreichbar. Eigentlich alles tutti.
Was aber exakt Zeitgleich passiert ist:
Ein kürzlich statisch gesetzter DNS Eintrag eines Servers aus einem anderen Scope wurde gelöscht. oO
Habe es per DNS-Server-Logs und Uhrzeit im Eventviewer des DCs nachvollziehen können.
DHCP Bereich repliziert, Zeitgleich DNS Eintrag durch DHCP Aktion gelöscht.
Habe ich ehrlich gesagt nicht nachvollziehen können. Gibt sicher eine vernünftige Erklärung dafür. Ich kenne sie aber nicht.
Habe mich wie erwähnt durch die Logs gewühlt und stoße in dem DHCP-Server Log auf die genannten IDs.
Zu 20322 lese ich, dass der DHCP-Server vermutlich ein Problem mit der Kommunikation mit seinem Failover-Partner haben kann. Genauer gesagt, dass der DHCP-Server nicht in der Lage ist, eine Verbindung zu seinem Failover-Partner herzustellen oder dass die Synchronisation der DHCP-Datenbanken zwischen den beiden Servern nicht erfolgreich war.
Zu 20291 ergibt meine Recherche Ähnliches, dass dies wohl auftritt, wenn es ein Problem mit der DHCP-Failover-Konfiguration oder der Kommunikation zwischen den beiden DHCP-Servern gibt, die für den Failover-Modus eingerichtet sind. Wenn der DHCP-Server Schwierigkeiten hat, mit dem Partner-DHCP-Server zu kommunizieren.
Oder dass es ein Problem mit der Synchronisation der DHCP-Datenbanken gibt.
Wir haben wohl auch, wie ich von unserer Technik erfahren habe, vereinzelt Probleme, dass DHCP-Leases nicht korrekt an die Clients verteilt werden.
Bzw. einige Kisten in einem bestimmten Scope bei jedem Neustart eine neue IP erhalten, bis der Scope voll ist.
Meine Idee: alle Scopes das Failover aufheben und neu einrichten. Wäre das wohl ein Weg?
Was kann man bezüglich der Datenbank unternehmen?
Hat jemand mit ähnlichen Vorfällen und den Fehler IDs bereits Erfahrung und vielleich Tipps für mich?
Ich sage in jedem Fall Danke für mögliche Antworten und wünsche allen Admins ein schönes Wochenende. Ich muss jetzt mal abschalten.
Durch Wegfall mehrerer MA erhalte ich gerade ungewollt viele neue Tätigkeitsfelder. U.a. muss ich mich plötzlich um unsere Domäne, GPOs, DNS, DHCP mehr oder weniger allein kümmern ... mal schauen wie lange das gut geht, aber das ist ein anderes Thema.
Mein Problem liegt in den Fehler IDs, die der DHCP Dienst auswirft.
Es gibt zwei DHCP Server mit ca. 40 IPv4 Scopes. Für jeden ist die Failoverkonfiguration als Lastverteilung 50/50% aktiv
Im DNS ist für jeden DHCP-Scope auch eine passende Reverse-Lookupzone eingerichtet.
Hab es extra nochmal überprüft.
Auf die Fehler aufmerksam geworden bin ich, weil heute mehrere Dinge passiert sind, die mich in die Logs haben schauen lassen.
Es sollten zwei PC-Systeme ausgetauscht werden. Neu gegen alt. Die Neuen sollen die Aufgaben der Alten übernehmen. Da das Spezial-Kisten sind, haben die DHCP Reservierungen, um immer die gleiche IP zu erhalten.
Entsprechend sollen die IPs beibehalten werden.
DNS-Namen sind allerdings neu und soll auch so.
*Alte System heruntergefahren und abgeklemmt.
*Dann die DHCP Reservierungen gelöscht.
*Neue Reservierungen mit neuer MAC erstellt.
*DNS überprüft, alte Einträge sind auch artig verschwunden. Prima.
Neue Systeme Angeklemmt, hochgefahren, ... nicht erreichbar. Reservierung bleibt (Inaktiv).
Habe festgestellt, dass die neuen Reservierungen nicht auf dem anderen DHCP zu sehen sind.
Wie mir wieder ins Gedächtnis gerufen wurde - Reservierungen replizieren sich _nicht_ von allein. ... kann man ja mal vergessen.
Also kurzerhand die Replizierung von Bereich und Beziehung des entpsrechenden Scopes per Hand angestoßen.
Dabei erschien eine Fehlermeldung, bezüglich der Datenbank. Habe sie leider nicht mehr im Kopf, da mitten in Kundschaft am hantieren etc.
Beim zweiten Versuch klappte es jedenfalls. Konnte den Fehler bisher auch nicht wieder reproduzieren.
Die Reservierungen waren nun auf beiden DHCPs aktiv, die neuen PCs erreichbar. Eigentlich alles tutti.
Was aber exakt Zeitgleich passiert ist:
Ein kürzlich statisch gesetzter DNS Eintrag eines Servers aus einem anderen Scope wurde gelöscht. oO
Habe es per DNS-Server-Logs und Uhrzeit im Eventviewer des DCs nachvollziehen können.
DHCP Bereich repliziert, Zeitgleich DNS Eintrag durch DHCP Aktion gelöscht.
Habe ich ehrlich gesagt nicht nachvollziehen können. Gibt sicher eine vernünftige Erklärung dafür. Ich kenne sie aber nicht.
Habe mich wie erwähnt durch die Logs gewühlt und stoße in dem DHCP-Server Log auf die genannten IDs.
Zu 20322 lese ich, dass der DHCP-Server vermutlich ein Problem mit der Kommunikation mit seinem Failover-Partner haben kann. Genauer gesagt, dass der DHCP-Server nicht in der Lage ist, eine Verbindung zu seinem Failover-Partner herzustellen oder dass die Synchronisation der DHCP-Datenbanken zwischen den beiden Servern nicht erfolgreich war.
Zu 20291 ergibt meine Recherche Ähnliches, dass dies wohl auftritt, wenn es ein Problem mit der DHCP-Failover-Konfiguration oder der Kommunikation zwischen den beiden DHCP-Servern gibt, die für den Failover-Modus eingerichtet sind. Wenn der DHCP-Server Schwierigkeiten hat, mit dem Partner-DHCP-Server zu kommunizieren.
Oder dass es ein Problem mit der Synchronisation der DHCP-Datenbanken gibt.
Wir haben wohl auch, wie ich von unserer Technik erfahren habe, vereinzelt Probleme, dass DHCP-Leases nicht korrekt an die Clients verteilt werden.
Bzw. einige Kisten in einem bestimmten Scope bei jedem Neustart eine neue IP erhalten, bis der Scope voll ist.
Meine Idee: alle Scopes das Failover aufheben und neu einrichten. Wäre das wohl ein Weg?
Was kann man bezüglich der Datenbank unternehmen?
Hat jemand mit ähnlichen Vorfällen und den Fehler IDs bereits Erfahrung und vielleich Tipps für mich?
Ich sage in jedem Fall Danke für mögliche Antworten und wünsche allen Admins ein schönes Wochenende. Ich muss jetzt mal abschalten.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-ID: 43657451125
Url: https://administrator.de/contentid/43657451125
Printed on: September 1, 2024 at 08:09 o'clock
11 Comments
Latest comment
Ich ergänze mal noch den Wortlaut der Fehlermeldungen:
ID 20322 : Fehler bei der PTR-Eintragregistrierung für IPv4-Adresse (Adresse) und FQDN (DNSNAME) mit der Meldung 9005 (Der DNS Vorgang wurde abgelehnt.)
Und 20291: Für die IP-Adresse (Adresse) wurde eine Nachricht vom Typ "BINDING-ACK" mit der Transaktions-ID (ID) und dem Ablehnungsgrund "Schwerwiegender Konflik: DIe Adresse wird von einem anderen CLeint verwendet." An den Partnerserver "DHCP2" für die Failoverbeziehung "DHCP1 & DHCP2) gesendet.
Gerade letzteres liest sich ja so, als seien da IPs doppelt vergeben.
ID 20322 : Fehler bei der PTR-Eintragregistrierung für IPv4-Adresse (Adresse) und FQDN (DNSNAME) mit der Meldung 9005 (Der DNS Vorgang wurde abgelehnt.)
Und 20291: Für die IP-Adresse (Adresse) wurde eine Nachricht vom Typ "BINDING-ACK" mit der Transaktions-ID (ID) und dem Ablehnungsgrund "Schwerwiegender Konflik: DIe Adresse wird von einem anderen CLeint verwendet." An den Partnerserver "DHCP2" für die Failoverbeziehung "DHCP1 & DHCP2) gesendet.
Gerade letzteres liest sich ja so, als seien da IPs doppelt vergeben.
Hi,
gibt es einen speziellen Grund, warum Ihr da "Lastverteilung 50/50" gewählt habt und nicht "Active/Standby"?
Wir haben mit A/S keine Probleme und ich hatte für 50/50 genau solche Effekte, wie von Dir beschrieben, befürchtet und deshalb damals mich für A/S entschieden. Ein Server steht am Außenstandort und einer in der Zentrale. Die Helper-Einträge verweisen auf beide Server. Der Server in der Zentrale ist der Standby und in der Helper-Liste an 2. Stelle.
Wir haben bei uns gefühlt 400 Scopes mit ca. 5000 Clients und noch nie Lastprobleme gehabt, die uns an einen möglichen Lastausgleich haben denken lassen.
E.
gibt es einen speziellen Grund, warum Ihr da "Lastverteilung 50/50" gewählt habt und nicht "Active/Standby"?
Wir haben mit A/S keine Probleme und ich hatte für 50/50 genau solche Effekte, wie von Dir beschrieben, befürchtet und deshalb damals mich für A/S entschieden. Ein Server steht am Außenstandort und einer in der Zentrale. Die Helper-Einträge verweisen auf beide Server. Der Server in der Zentrale ist der Standby und in der Helper-Liste an 2. Stelle.
Wir haben bei uns gefühlt 400 Scopes mit ca. 5000 Clients und noch nie Lastprobleme gehabt, die uns an einen möglichen Lastausgleich haben denken lassen.
E.
3Gerade letzteres liest sich ja so, als seien da IPs doppelt vergeben.
Korrekt. Das könnte auch daran liegen, dass die Replikation der Leasen zwichen den Scopes zu langsam oder gestört ist.Wieder ein Grund für mich, mit meiner damaligen Auswahl zufrieden zu sein.
2
Hi und vielen Dank für die Antworten. Warum das die ehemaligen MA so eingerichtet haben ... kann ich nicht beurteilen.
Mit anderen Worten löse ich also alle Failoverbeziehungen auf und setze sie als A/S neu...
Mit anderen Worten löse ich also alle Failoverbeziehungen auf und setze sie als A/S neu...
Zitat von @pcpanik:
Mit anderen Worten löse ich also alle Failoverbeziehungen auf und setze sie als A/S neu...
Das habe ich zwar so explizit nicht geschrieben, aber es könnte die genannten Symptome lindern. Mit anderen Worten löse ich also alle Failoverbeziehungen auf und setze sie als A/S neu...
Ich Denke, viel mehr Optionen bleiben ja nicht?
Ich versichere mich nur zuerst zurück, warum Lastverteilung gewählt wurde... wenns keinen triftigen Grund gibt, kann ich mit A/S gut leben und hoffe, dem Spuk damit ein Ende bereiten zu können.
Ich versichere mich nur zuerst zurück, warum Lastverteilung gewählt wurde... wenns keinen triftigen Grund gibt, kann ich mit A/S gut leben und hoffe, dem Spuk damit ein Ende bereiten zu können.
aber es könnte die genannten Symptome lindern. face-smile
Wenn ich es denn konfiguriert bekäme.
Sind 9 zu wenig ...
Allerdings konnte ich durch meine Aktion auch eine Split-Brain Situation aufdecken, die wohl für die Fehlermeldungen etc Ursächlich war. Ein Scope hatte keinen Failover, war aber auf beiden DHCPs aktiv. Das knallt dann natürlich.
Wenn nur 31 möglich sind, frage ich mich, wie 39 v. 40 Failover-Beziehungen eingerichtet worden sind.
Jetzt wird es für mich sehr rätselhaft.
Wenn nur 31 möglich sind, frage ich mich, wie 39 v. 40 Failover-Beziheungen eingerichtet worden sind.
Jetzt wird es für mich sehr rätselhaft.Ich würde mich nicht wundern, wenn man da über Alias-Namen oder IP-Adressen tricksen kann.
Außerdem braucht man für das Failover mehrerer Scopes zwischen nur 2 Server nicht unbedingt mehrere Failoverbeziehungen, es sei denn,. man fährts für verschiedene Scopes auch verschiedene Einstellungen bei den Beziehungen. Man kann eine Beziehung auch für mehrere Scopes benutzen.
Schau doch mal, ob von den konfigurierten Beziehungen tatsächlich alle noch in Verwendung sind. Wenn nicht, die obsoleten löschen.
Man kann eine Beziehung auch für mehrere Scopes benutzen.
Ahso. Okay. Ich sehe meinen Fehler. Habe jeden Scope einzeln bearbeitet. Auf die Idee, im rechten Konsolenfenster mehrere zu markieren bin ich nicht gekommen.
Habe im linken Teil auf jeden Scope das Kontextmenü geöffnet.
Werde es so probieren. Nochmal alle löschen, warten bis das durchgereicht wurde, dann alle Markieren und den Failover einrichten.
Danke!
Also, alle entfernen war nun einfach, nichtsdestotrotz bleibt die Fehlermeldung bestehen.
Als wenn die alten Failover-Beziehungen noch irgendwo stecken würden.
Habe den 2. DHCP Dienst De-Autorisiert und neu Autrorisiert, sowie bei beiden den DHCP-Dienst neu gestartet.
Es ändert nichts an der Fehlermeldung, obwohl es derzeit keine aktiven Failover-Beziehungen gibt.
Da scheint etwas gecachet zu sein. Denn ich kann nun keine Einzige mehr neu anlegen.
Hat dazu noch jemand eine Idee?
Als wenn die alten Failover-Beziehungen noch irgendwo stecken würden.
Habe den 2. DHCP Dienst De-Autorisiert und neu Autrorisiert, sowie bei beiden den DHCP-Dienst neu gestartet.
Es ändert nichts an der Fehlermeldung, obwohl es derzeit keine aktiven Failover-Beziehungen gibt.
Da scheint etwas gecachet zu sein. Denn ich kann nun keine Einzige mehr neu anlegen.
Hat dazu noch jemand eine Idee?
Ich ergänze mal:
zeigt mir tatsächlich 31 vorhandene Beziehungen an, die in der Konsole nicht vorhanden sind. Selbst ein Neustart der Kisten ändert das nicht.
Edit:
Naheligend hat nun
Geholfen. 31 mal ausgeführt... alles Sauber.
Alle Bereiche in der Konsole markiert und eingerichtet. Fertig.
Ich Danke für die Tipps
Get-DhcpServerv4Failover -ComputerName "DHCP-Server-Name" Edit:
Naheligend hat nun
Remove-DhcpServerv4Failover -ComputerName "DHCP-Server-Name" -Name "Failover-Name" -Force Geholfen. 31 mal ausgeführt... alles Sauber.
Alle Bereiche in der Konsole markiert und eingerichtet. Fertig.
Ich Danke für die Tipps
