Windows DHCP Server Warteschlange einsehen

[aemonblackfyre]

Hallo,

wir haben das Problem, dass mehr Clients auf eine Lease warten als wir freie DHCP Adressen haben. Gibt es eine Möglichkeit diese "Warteschlange" einzusehen? Am besten direkt per Powershell.

Hoffe ihr könnt mir helfen wo meine Googlekünste scheitern.

 

[wern001]

wieso einsehen?
gibt doch nur zwei Möglichkeiten
1. Leasezeit verkürzen
2. adresspool vergrößern

 

[PHuV]

Wo habt Ihr das Problem genau? Dort dann nachschauen, es wird dort alles anzeigt. Bei meiner Ex-Firma haben wir das DHCP des Windows Server 2016 verwendet, der hat das alles genau angezeigt, wenn die DHCP-Adressen aufgebraucht waren.

 

[Matthias80]

Mir nicht bekannt.
In der Ereignisssnzeige könnte man was rausfinden...
Macht imho auch wenig Sinn.
Wenn er keine hat. Bleibt die Frage unbeantwortet. Da gibt's keine Warteschlange. Der Client probiert es wieder... Bis ein lease abgelaufen ist. Der erste der kommt, kriegt eine. Zack guckt ein anderer in die röhre.

 

[cloudman]

Es gibt keine Warteschlange bei DHCP.
Ein DHCP Client sendet einen DHCPDISCOVER Request als Broadcast und wartet darauf, dass einer der DHCP Server im Netzwerk mit DHCPOFFER antwortet

Im Eventlog gibt es einige Events für Probleme wenn der Scope (fast) voll ist
https://docs.microsoft.com/en-us/pr...ows-server-2012-r2-and-2012/dn800668(v=ws.11)

 

[Raijin]

Es gibt keine Warteschlange bei DHCP.

So sieht's aus.

wir haben das Problem, dass mehr Clients auf eine Lease warten als wir freie DHCP Adressen haben.

Die Lösung wurde bereits genannt: DHCP-Bereich vergrößern und/oder die LeaseTime verringern. Daran führt kein Weg vorbei. Ist das Subnetz bereits ausgeschöpft und der DHCP-Bereich kann nicht mehr vergrößert werden, muss zunächst das Subnetz und anschließend der DHCP-Bereich vergrößert werden.

Wenn du uns die Einstellungen für das Subnetz (IP + Subnetzmaske) und den DHCP-Server (Bereich + LeaseTime) nebst Info über die Anzahl an Clients gibst, können wir zielgerichtetere Vorschläge machen.

 

[aemonblackfyre]

da sind wir schon dabei. haben jetzt ein neues netz mit größerem dhcp bereich das muss aber erstmal an die jeweiligen rechner gepatcht werden damit das alte netz entschlackt werden kann und wir den dhcp bereich vergrößern können.

logt der dhcp nicht die discover anfragen die er nicht beantwortet bzw sendet der dhcp nicht trotzdem eine antwort die eben besagt dass er keine freie adresse hat? oder ist das protokoll wirklich so ausgelegt, dass der dhcp einfach schweigt wenn er nichts verteilen kann?

Zur Begründung:
Wir wissen nicht wie viele Geräte aktuell keine Lease erhalten. Es könnten 10 sein es könnten auch 200 sein. Wir müssten natürlich ungefähr wissen wie viel platz wir schaffen müssen. Das Subnetz ist leider rappelvoll weshalb wir den dhcp bereich nicht vergrößern können und nachdem jetzt für viele die home office zeit endet kommen sie mit ihren laptops ins büro und spätestens morgens um 9 uhr sind alle freien leases aufgebraucht. wenn wir zumindest wüssten auf wen das jeweils zutrifft könnten wir gezielt das neue netz verteilen aktuell fliegen wir aber blind.

 

[Ja_Ge]

Verstehe ich nicht. Auf Clients braucht für DHCP nix gepatcht werden. Und auch abgewiesene Anfragen sollten im Log des DHCP Servers erscheinen. Welchen nutzt ihr überhaupt, Microsoft?

 

[cloudman]

logt der dhcp nicht die discover anfragen die er nicht beantwortet

Puh weiß ich nicht auswendig. Du kannst mal überprüfen ob logging an ist. Den Pfad zum log findest du unter Advanced

Wäre es nicht einfacher die subnetz mask zu verändern und statt /24 ein /22 Netz zu verwenden. Dann siehst du auch wieviele Leases verwendet werden

 

[aemonblackfyre]

Wäre es nicht einfacher die subnetz mask zu verändern und statt /24 ein /22 Netz zu verwenden. Dann siehst du auch wieviele Leases verwendet werden

das mit dem logging schau ich mir gleich mal an
es handelt sich schon um ein /22 und das netz stammt noch aus einer zeit in der zu 99% desktops genutzt wurden weshalb der dhcp bereich mit <50 sehr klein ist. die bereiche vor und nach dem netz sind leider auch schon vergeben weshalb sich das netz nicht vergrößern lässt.

aktuell versuchen wir das alte netz so frei wie möglich zu schaufeln um dann nochmal einen 50er block oder so zum dhcp bereich hinzuzufügen.

es handelt sich um einen Server 2016 Datacenter.

ich hab mir mal das audit log angeschaut das einzige was ich dort finden kann ist aber nur dass der bereich voll ist

14,09/13/22,15:18:18,Bereich ist voll,xyz.xyz.xyz.0,,,,0,6,,,,,,,,,0

Ich kann daraus also immer den Zeitpunkt ablesen, wann dem Server die Adressen ausgehen

man findet es aber in den Serverlogs selbst im eventviewer unter Anwendungs/Dienstprotokolle Microsoft Windows DHCP Server Admin Events mit der ID 20287 finden in denen findet man die MAC und den Zeitstempel

Die DHCP-Clientanforderung von "$MACADRESS" wurde verworfen, da in den entsprechenden IP-Adressbereichen des Geltungsbereichs/der Bereichsgruppierung "$BEREICH" keine IP-Adressen mehr verfügbar sind. Mögliche Ursache: In IP-Adressbereichen einer Richtlinie sind keine IP-Adressen mehr verfügbar.

ich denke von hier aus finde ich einen weg mir die passende abfrage zurecht zu basteln

 

[Raijin]

Wir müssten natürlich ungefähr wissen wie viel platz wir schaffen müssen. Das Subnetz ist leider rappelvoll

Versteh ich nicht. Ihr müsst doch wissen wie viele Hosts ihr im Netzwerk habt und auf Basis dessen einschätzen wie viele davon ihre IP-Adresse via DHCP beziehen und wie viele eine statische Konfiguration haben (zB Infrastruktur, Server, etc).


Es gibt keinen Mechanismus, mit dem der DHCP-Server dem DHCP-Client einen vollen DHCP-Pool mitteilt. Stattdessen schweigt der DHCP-Server, wenn er einem Client keine IP-Adresse anbieten kann. Das ist kein Mangel des Protokolls. Zum einen ist es Sache des Administrators, für einen ausreichend großen Pool zu sorgen, zum anderen gibt es Setups mit mehreren DHCP-Servern (entsprechende Konfiguration vorausgesetzt), die so nicht mehr funktionieren würden, wenn der erste antwortende DHCP-Server dem Client bereits eine Absage erteilt obwohl ein anderer DHCP noch freie IP-Adressen hätte.

Somit obliegt es dem Administrator, das Subnetz und den DHCP-Bereich ausreichend groß zu gestalten. Dabei gilt die Fausregel: So groß wie nötig, aber so klein wie möglich. Aus einem /24er Subnetz mit 254 Host-IPs macht man also nicht einfach so ein /16er Subnetz mit 65534 Host-IPs, sondern zB ein /23 oder /22 Subnetz mit 510 bzw. 1022 IPs.

logt der dhcp nicht die discover anfragen die er nicht beantwortet

Das kommt vermutlich auf die Implementierung des DHCP-Servers an und inwiefern dort Logging vorgesehen bzw. aktiviert ist. Allerdings lassen sich DHCPDISCOVER bzw DHCPOFFER ja auch mit tcpdump respektive WireShark, o.ä. protokollieren.

es handelt sich schon um ein /22 und das netz stammt noch aus einer zeit in der zu 99% desktops genutzt wurden weshalb der dhcp bereich mit <50 sehr klein ist. die bereiche vor und nach dem netz sind leider auch schon vergeben weshalb sich das netz nicht vergrößern lässt.

Hm.. Ein /22 Subnetz hat Platz für 1022 Hosts und der DHCP-Bereich hat davon nur 50 IPs abbekommen?

Meinst du mit davor/danach den IP-Bereich vor/nach dem Subnetz oder innerhalb des Subnetzes vor/nach dem DHCP-Bereich?


Wenn ein /22 Subnetz quasi voll ist (bis zu 1022 Hosts) und davor/danach nichts mehr frei ist, dann wäre es sinnvoll, über ein Redesign der Subnetze nachzudenken, mit ausreichend großen Subnetzen. Nicht zuletzt auf Grund des Broadcastaufkommens sollte man ab einem Punkt jedoch auch überlegen ob eine Segmentierung des Netzwerks in kleinere Subnetze sinnvoll ist.

 

[Skysnake]

Aus einem /24er Subnetz mit 254 Host-IPs macht man also nicht einfach so ein /16er Subnetz mit 65534 Host-IPs, sondern zB ein /23 oder /22 Subnetz mit 510 bzw. 1022 IPs.

Kann ich zustimmen, wobei für 99% der Leute ein um eins größer gewählte Subnetmask das Leben SEHR vereinfacht und auf Jahre/Jahrzehnte Ruhe bedeutet.

Wir nehmen z.b. auch gerne einen 16er Block bei nur 2000 IPs die wir brauchen weil man dann schön sprechende Namen machen kann und eben auch noch für ne Verdoppelung genug Platz hat.

Ist natürlich immer die Frage wie viel Platzbedarf die Organisation hat. Aber das es jemandem weh tut kommt selten vor.

Wobei eigentlich auch nen 18er Netz schon ausreichend gewesen wäre. Aber dann hat man nicht so schön sprechende IPs...

Gegenbeispiel ist da ein anderes System, bei dem von Start weg die Subnetze minimal gewählt werden mussten und so voll waren das man eben keine sprechenden IPs haben konnte. Das ist ein Grauß und Erweiterungen mit richtig Arbeit verbunden...

 

[aemonblackfyre]

Versteh ich nicht. Ihr müsst doch wissen wie viele Hosts ihr im Netzwerk habt und auf Basis dessen einschätzen wie viele davon ihre IP-Adresse via DHCP beziehen und wie viele eine statische Konfiguration haben (zB Infrastruktur, Server, etc).
[...]
Hm.. Ein /22 Subnetz hat Platz für 1022 Hosts und der DHCP-Bereich hat davon nur 50 IPs abbekommen?

Meinst du mit davor/danach den IP-Bereich vor/nach dem Subnetz oder innerhalb des Subnetzes vor/nach dem DHCP-Bereich?


Wenn ein /22 Subnetz quasi voll ist (bis zu 1022 Hosts) und davor/danach nichts mehr frei ist, dann wäre es sinnvoll, über ein Redesign der Subnetze nachzudenken, mit ausreichend großen Subnetzen. Nicht zuletzt auf Grund des Broadcastaufkommens sollte man ab einem Punkt jedoch auch überlegen ob eine Segmentierung des Netzwerks in kleinere Subnetze sinnvoll ist.

Nein wir wissen nicht wie viele Rechner in dem Netz sind. Es werden immer wieder alte Geräte aus dem Schrank geholt, Geräte mal einige Wochen nicht genutzt und fallen dann aus der Domäne raus. Spätestens seit Corona herrscht die pure Anarchie.

Ja unser netz hat unter 50 DHCP Plätze weil eigentlich das Netz für Desktop Rechner vorgesehen war welche feste IPs bzw. feste Reservierungen bekommen haben. Durch Corona kamen hunderte Laptops hinzu weshalb jetzt das Netz aus allen nähten platzt.

Ich meine die Netze davor. unser netz wäre zb 1.1.14.0/22 und die 1.1.13.0/24 ist belegt sowie die 1.1.17.0/24 das Netz lässt sich also nicht vergrößern. Wir haben wie gesagt auch ein neues Netz in dem wir einen deutlich größeren DHCP Bereich haben, das aktuelle Netz in seiner Form ist so aber schon vor ewigkeiten entstanden weshalb da eben noch nicht an Laptops oder ähnliches gedacht wurde und auch noch mit öffentlichen IPs gearbeitet wurde.
Dieses öffentliche /22 Netz soll jetzt zug um Zug durch zwei private /21 und /22 Netze ersetzt werden für die verschiedenen Locations und in die öffentlichen Netze kommen nurnoch die Clients die auch eine öffentliche Adresse benötigen.

Wir lassen uns jetzt einfach die Zahl der Events pro unique MAC und Tag, Stunde, 10min anzeigen um eine Art Warteschleifenlänge zu kennen.

 

[Skysnake]

Ähm.. öffentliche IPs?

Uhuhuh das ist überhaupt nicht gut

 

[Raijin]

Ich meine die Netze davor. unser netz wäre zb 1.1.14.0/22 und die 1.1.13.0/24 ist belegt sowie die 1.1.17.0/24 das Netz lässt sich also nicht vergrößern.

Hm.. Das geht nicht ganz auf, weil 1.1.14/22 von 1.1.12.1 bis 1.1.15.254 gehen würde, also das 1.1.13.0/24 beinhalten würde. Ich gehe aber mal davon aus, der Fehler ist dem Beispiel geschuldet, weil du das echte Subnetz kaschieren wolltest, was auch immer wir damit schlimmes anstellen sollten

Ich verstehe aber das Problem und ich denke, dass ein komplettes Redesign des Subnetzes unumgänglich ist, ggfs sogar gleich inkl. Segmentierung, um sowas wie "alte Geräte aus dem Schrank" in ein separates Netz zu packen.

In der Zwischenzeit wäre es einen Versuch wert, im DHCP die LeaseTime zu kürzen. Das könnte zumindest bei rein temporären Geräten die Situation etwas verbessern, weil deren IP-Adresse so spätestens 1h nach Ausschalten wieder für andere Geräte verfügbar wäre.

 

[M-X]

Uhuhuh das ist überhaupt nicht gut

Warum ? Wenn der rest wie Firewall etc. stimmt kann man auch öffentliche IPs nutzen. Ist in großen Firmen die damals riesige Subnetze abgegriffen haben auch nicht unüblich.

Hier liegt aber das Problem schon ganz woanders. Wenn ich in Meiner Domäne / Netzwerk nicht mal weiß wie viele Clients ich ca. habe, ist das schon problematisch.

Lass mich raten IPv6 ist natürlich auch aus ?

Ich würde auch mal über ein komplettes Redesign nachdenken bevor ich da weiter rumpfusche, ist aber natülrich Aufwand.

 

[Skysnake]

Ganz einfach. So was macht man einfach nicht. Denn im Fallen von Problemen suchst du dich dumm und dämlich.

Den Fall das einem das Subnetz gehört mal ausgeschlossen.

 

[M-X]

Den Fall das einem das Subnetz gehört mal ausgeschlossen.

Das ist doch wohl die Voraussetzung ? Sonst hast du Adresskonflikte ohne Ende aber davon würde ich hier jetzt mal ausgehen.

 

[aemonblackfyre]

Ganz einfach. So was macht man einfach nicht. Denn im Fallen von Problemen suchst du dich dumm und dämlich.

Den Fall das einem das Subnetz gehört mal ausgeschlossen.

uns gehört ein class b netz

Warum ? Wenn der rest wie Firewall etc. stimmt kann man auch öffentliche IPs nutzen. Ist in großen Firmen die damals riesige Subnetze abgegriffen haben auch nicht unüblich.

Hier liegt aber das Problem schon ganz woanders. Wenn ich in Meiner Domäne / Netzwerk nicht mal weiß wie viele Clients ich ca. habe, ist das schon problematisch.

Lass mich raten IPv6 ist natürlich auch aus ?

Ich würde auch mal über ein komplettes Redesign nachdenken bevor ich da weiter rumpfusche, ist aber natülrich Aufwand.

ja ist natürlich alles hinter einer sehr restriktiven firewall

wir wissen wie viele rechner es maximal sind aber wie viele tatsächlich in nutzung sind ist nicht wirklich herauszufinden und ist auch ständig im wandel. den einzelnen abteilungen gehört die hardware weshalb sie am ende auch die finale entscheidung darüber haben was sie mit dem kram machen und wie sie ihn nutzen solange es eben unseren sicherheitsrichtlinien entspricht.

ein komplettes redesign wäre natürlich schön aber dann steht plötzlich alles still und selbst das häppchenweise umziehen in ein neues netz wirft jeden tag neue probleme auf. wenn man das an einem stück machen würde wäre wohl erstmal alles für eine woche offline. ich glaube das würde wohl nicht akzeptiert werden

und ja ipv6 ist natürlich aus

Hm.. Das geht nicht ganz auf, weil 1.1.14/22 von 1.1.12.1 bis 1.1.15.254 gehen würde, also das 1.1.13.0/24 beinhalten würde. Ich gehe aber mal davon aus, der Fehler ist dem Beispiel geschuldet, weil du das echte Subnetz kaschieren wolltest, was auch immer wir damit schlimmes anstellen sollten

In der Zwischenzeit wäre es einen Versuch wert, im DHCP die LeaseTime zu kürzen. Das könnte zumindest bei rein temporären Geräten die Situation etwas verbessern, weil deren IP-Adresse so spätestens 1h nach Ausschalten wieder für andere Geräte verfügbar wäre.

geht 1.1.14.0/22 nicht von 1.1.14.0 bis 1.1.17.254? ich dachte man zählt hoch ist aber auch schon etwas her dass ich die basics gelernt hab
aber naja man hat ja verstanden worum es geht. die IP hab ich einfach nur der anonymität wegen weg gelassen

die leasetime ist schon auf 15 minuten eingestellt da würde eine weitere kürzung leider auch nichts mehr bringen. das war eine der ersten heftpflaster die wir angebrachten hatten als sich das problem gezeigt hatte.

 

[M-X]

wir wissen wie viele rechner es maximal sind

Na dann hast du doch deine Lösung ? Die Zahl nehmen nochmal +20% und ihr habt erstmal kein Problem. Wenn euch natürlich die IPs ausgehen weil ihr mittlerweile Sau wertvolle Public IPs für Clients nutzt kommt ihr um einen redesing nicht herum.

Und es kann schonmal einer anfangen sich mit IPv6 auseinander zu setzen. Ignorieren geht hier nämlich auch bald nicht mehr.