DHCP: IP-Vergabe durcheinander

[daabm 1.184]

...und mir auch nicht. Du schlägst Dich mit Randbedingungen herum, die nicht wirklich nachvollziehbar sind...

[WolverineJR 10]

Du schlägst Dich mit Randbedingungen herum, die nicht wirklich nachvollziehbar sind...

Verstehe zwar nicht was Du meinst, aber dennoch Danke für eure Mühe!

[lefg 276]

Verstehe zwar nicht was Du meinst, aber dennoch Danke für eure Mühe!

 

Nun, der Kollege wirkt in seiner Art recht kurz angebunden.

 

Auffällig für mich ist die geringe Beteiligung am Thread, das Problem scheint nicht bekannt zu sein.

 

Tscha, in Handlungsmöglichkeit erscheinst Du sehr eingeschränkt. Eine Neukonfiguration ist wohl nicht möglich derzeit. Ob sinnvoll, einen weiteren DHCP zu installieren und zu konfigurieren auf einem anderen Server, so rein experimental?

bearbeitet 6. Juni 2014 von lefg

[WolverineJR 10]

Tscha, in Handlungsmöglichkeit erscheinst Du sehr eingeschränkt. Eine Neukonfiguration ist wohl nicht möglich derzeit. Ob sinnvoll, einen weiteren DHCP zu installieren und zu konfigurieren auf einem anderen Server, so rein experimental?

Da gebe ich Dir recht. Von Experimenten an dem produktiven DHCP-Server möchte ich Abstand nehmen. Wenn das Teil nicht läuft, stehen ganz schnell einige Kollegen aus der Entwicklung und Produktion bei mir auf der Matte und fragen, warum ihre Systeme keine IPs beziehen.

Und einen zweiten DHCP-Server ins Netz zu nehmen ist erfahrungsgemäß nicht empfehlenswert.

Ich habe schon mit dem Gedanken gespielt eine virtuelle DHCP-Testumgebung aufzubauen in einem Host-Only-Netz. Um hier ein aussagekräftiges Testfeld zu betreiben, müssen aber mind. ein DHCP-Server und einige Testclients her. Den Aufwand wollte ich mir (bisher) nicht geben. Aber es führt wohl kein Weg daran vorbei.

[Daniel -MSFT- 129]

Richte Dir doch ein virtuelles Testlab ein oder "mißbrauche" einfach ein TechNet Virtual Lab, in dem mindestens ein Server und einige Clients enthalten sind. Dann kannst Du das in Ruhe austesten.

[NilsK 2.781]

Moin,

 

Meinst Du, dass eine Lease von 12h zu lang ist? Wie lang ist denn der Standardwert?

 

um dazu noch kurz was zu sagen: In den meisten Umgebungen ist von derart kurzen Lease-Dauern abzuraten. Insbesondere, wenn ihr sowieso ein Lastproblem habt.

 

Ein DHCP-Client wird im laufenden Betrieb nach 50% der Lease-Dauer seine Lease erneuern. Das ist dann Unicast, aber eben Traffic. Bedeutet bei euch: alle sechs Stunden, also mindestens einmal pro Arbeitstag für die meisten Rechner (in vierstelliger Zahl). Nun hat der Client allerdings auch schon beim Hochfahren seine Lease erneuert ...

 

Sollte der DHCP-Server nicht geantwortet haben, dann versucht der Client nach 87,5% der Lease-Dauer erneut eine Verlängerung per Unicast. Nur wenn das nicht erfolgreich ist, verwirft er seine Lease am Ende von deren Dauer und führt ein neues Broadcast-Discover durch. Wenn ihr ohnehin Last im Netz habt, würde ich nicht ausschließen, dass das bei euch häufiger passiert. Und das alles für vermutlich zum größten Teil stationäre Clients, die ohnehin dauerhaft eine IP-Adresse brauchen und in der Regel auch immer dieselbe vom Server erhalten.

 

Kurze Lease-Dauern haben neben der Netzwerklast noch einen weiteren Nachteil: Die automatische DNS-Registrierung kann dadurch aus dem Tritt geraten, insbesondere wenn auf den (Windows-) DNS-Servern das Scavenging (Entfernen veralteter Einträge) aktiv ist. Hier muss man die Scavenging-Intervalle und die Lease-Dauern aufeinander abstimmen, was mit Lease-Dauern unterhalb von 24 Stunden eigentlich gar nicht geht und mit Dauern unter drei Tagen nicht sinnvoll konfigurierbar ist.

 

Wenn es also nicht wirklich einen zwingenden Grund für kurze Lease-Dauern gibt, solltet ihr die deutlich verlängern.

 

EDIT: Eine mögliche Ursache für euer Phänomen fällt mir noch ein. Könnt ihr sicher ausschließen, dass die Adressen, die der DHCP-Server nicht dynamisch vergibt, in Benutzung sind? Ein Windows-DHCP-Server wird nämlich, bevor er eine Adresse rausgibt, zunächst per Ping prüfen, ob diese schon jemand nutzt ...

 

Gruß, Nils

bearbeitet 6. Juni 2014 von NilsK

[lefg 276]

Und einen zweiten DHCP-Server ins Netz zu nehmen ist erfahrungsgemäß nicht empfehlenswert.

 

Nun, falls man damit eine negattive Erfahrung gemacht, .....

 

Ich habe mit mehreren DHCP bisher kein Problem gehabt. Falls beide den selben Adreessbereich bedienen, dann sollte nur einer aktiviert sein. Bei zwei aktivierten DHCP kann man den Adressbereich teilen, z.B. einer poolt 192.168.0.x/23, der andere 192.168.1.x/23.

bearbeitet 6. Juni 2014 von lefg

[WolverineJR 10]

Richte Dir doch ein virtuelles Testlab ein oder "mißbrauche" einfach ein TechNet Virtual Lab, in dem mindestens ein Server und einige Clients enthalten sind. Dann kannst Du das in Ruhe austesten.

Das ist doch mal eine Idee. Wusste noch gar nichts von dieser Möglichkeit. Danke!

 

Gibt es bei den MS-virtuellen Testlabs Einschränken bzgl. Anzahl der virtuellen Maschinen, Konfigurierbarkeit (Änderungen der Netzwekkonfig -> DHCP-Testumgebung) etc.?

 

Und muss ich damit rechnen, wenn ich ein solches Testlab beantragt habe, dass mich danach ein Vertriebler einer MS-Partner-Firma kontaktiert?

 

Moin,

 

 

um dazu noch kurz was zu sagen: In den meisten Umgebungen ist von derart kurzen Lease-Dauern abzuraten. Insbesondere, wenn ihr sowieso ein Lastproblem habt.

 

Ein DHCP-Client wird im laufenden Betrieb nach 50% der Lease-Dauer seine Lease erneuern. Das ist dann Unicast, aber eben Traffic. Bedeutet bei euch: alle sechs Stunden, also mindestens einmal pro Arbeitstag für die meisten Rechner (in vierstelliger Zahl). Nun hat der Client allerdings auch schon beim Hochfahren seine Lease erneuert ...

 

Sollte der DHCP-Server nicht geantwortet haben, dann versucht der Client nach 87,5% der Lease-Dauer erneut eine Verlängerung per Unicast. Nur wenn das nicht erfolgreich ist, verwirft er seine Lease am Ende von deren Dauer und führt ein neues Broadcast-Discover durch. Wenn ihr ohnehin Last im Netz habt, würde ich nicht ausschließen, dass das bei euch häufiger passiert. Und das alles für vermutlich zum größten Teil stationäre Clients, die ohnehin dauerhaft eine IP-Adresse brauchen und in der Regel auch immer dieselbe vom Server erhalten.

 

Kurze Lease-Dauern haben neben der Netzwerklast noch einen weiteren Nachteil: Die automatische DNS-Registrierung kann dadurch aus dem Tritt geraten, insbesondere wenn auf den (Windows-) DNS-Servern das Scavenging (Entfernen veralteter Einträge) aktiv ist. Hier muss man die Scavenging-Intervalle und die Lease-Dauern aufeinander abstimmen, was mit Lease-Dauern unterhalb von 24 Stunden eigentlich gar nicht geht und mit Dauern unter drei Tagen nicht sinnvoll konfigurierbar ist.

 

Wenn es also nicht wirklich einen zwingenden Grund für kurze Lease-Dauern gibt, solltet ihr die deutlich verlängern.

Um ehrlich zu sein, mir fällt spontan auch kein Grund mehr dafür ein, warum wir diese Zeitspanne gewählt haben. Vermutlich wollten wir dadurch "Leichen" im DHCP-Bereich vermeiden o.ä..

Was für einen Zeitraum würdest Du denn empfehlen? Den Standardwert?

Werde deinen Einwand auf jeden Fall mit meinen Kollegen (und vor allem mit meinen Netzwerkkollegen) diskutieren. Danke!

 

 

Könnt ihr sicher ausschließen, dass die Adressen, die der DHCP-Server nicht dynamisch vergibt, in Benutzung sind?

Da hab ich jetzt ein Verständnisproblem mit deiner Formulierung. Meinst Du damit die Adressen aus den Bereichen außerhalb der dynamischen Vergabe (also in unserem Fall alles außer dem 99'er-Bereich)?

Oder willst Du damit sagen, dass alle IPs aus dem dynamischen Bereich (bei uns 99'er) ausschließlich nur über den DHCP vergeben werden?

[Daniel -MSFT- 129]

Generell stelle ich auch die kurze Lease-Dauer in Frage: Welchen Vorteil verspricht man sich davon? Schon der Ausfall des DHCP-Servers für einen Tag verursacht Chaos im Netz, wenn man keine permanentes Monitoring sowie Hochverfügbarkeit für DHCP realisiert. Vor allem, wenn man die Neuerungen von Windows Server nicht benutzt. Früher musste man einen DHCP-Server clustern, um Ausfallsicherheit zu erreichen. Heute gibt es dafür DHCP-Failover und -Replikation: http://blogs.technet.com/b/teamdhcp/archive/2012/06/28/ensuring-high-availability-of-dhcp-using-windows-server-2012-dhcp-failover.aspx

 

Die Labs kannst Du frei nutzen. Du bekommst maximal E-Mails von uns, falls Du der Nutzung der Daten von Microsoft nicht widersprichst. Steht alles im Klartext beim Einrichten der Labs. Step-by-Step-Guides für DHCP findest Du hier: http://technet.microsoft.com/library/hh831825

bearbeitet 6. Juni 2014 von Daniel -MSFT-

[NilsK 2.781]

Moin,

 

Da hab ich jetzt ein Verständnisproblem mit deiner Formulierung. Meinst Du damit die Adressen aus den Bereichen außerhalb der dynamischen Vergabe (also in unserem Fall alles außer dem 99'er-Bereich)?

Oder willst Du damit sagen, dass alle IPs aus dem dynamischen Bereich (bei uns 99'er) ausschließlich nur über den DHCP vergeben werden?

 

ich meine damit die Adressen aus dem DHCP-Scope, die der DHCP-Server aus irgendeinem Grund überspringt, statt sie zu vergeben. Vielleicht werden die ja in Wirklichkeit benutzt und sind nicht frei.

 

Gruß, Nils

[WolverineJR 10]

Moin,

 

 

ich meine damit die Adressen aus dem DHCP-Scope, die der DHCP-Server aus irgendeinem Grund überspringt, statt sie zu vergeben. Vielleicht werden die ja in Wirklichkeit benutzt und sind nicht frei.

 

Gruß, Nils

 

Ok. So habe ich es auch verstanden. Also ein simpler Check ("ping") auf die ersten vier IP-Adressen aus dem Bereich (99.1, 99.2, 99.3, 99.4) ergaben, dass diese nicht erreichbar sind. Dann gehe ich mal davon aus, dass diese Vermutung nicht zutrifft.

[h-d.neuenfeldt 21]

Nun haben wir das Problem, dass die dynamisch vergebenen IPs immer am Ende des Ranges anfangen. Es wird also NIE die IPs aus dem Bereich xxx.xxx.99.1 bis xxx.xxx.99.230 vergeben. Die ersten IPs werden im Bereich von xxx.xxx.99.240 vergeben. Da der DHCP-Server anscheinend nur so "intelligent" ist immer nur höhere IPs als die zuletzt vergebene zu vergeben, sind wir ständig der Gefahr ausgesetzt, dass der dynamische IP-Bereich "vollläuft" (obwohl noch über 230 IPs eigentlich frei sind!).

 

Diese Beschreibung halte ich für ein Missverständnis deinerseits.

Wenn der DHCP Server an welcher Stelle auch immer anfängt IPs zu erteilen und am oberen Ende des zu verteilenden Bereichs ankommt, fängt er von alleine vorne wieder an.

 

Deine Beschreibung :

 Es wird also NIE die IPs aus dem Bereich xxx.xxx.99.1 bis xxx.xxx.99.230 vergeben

ist daher grundfalsch.

Der DHCP Server liefert erst dann keine IPs mehr aus, wenn auch wirklich keine mehr frei ist.

 

Leider kenne ich kein Verfahren, mit dem du das Testen kannst ...

 

Beschreibung von DHCP :

http://www.planet-rcs.de/article/dhcp_howto/

bearbeitet 6. Juni 2014 von h-d.neuenfeldt

[Doso 77]

ich meine damit die Adressen aus dem DHCP-Scope, die der DHCP-Server aus irgendeinem Grund überspringt, statt sie zu vergeben. Vielleicht werden die ja in Wirklichkeit benutzt und sind nicht frei.

 

Das sieht man dann aber im DHCP Server, das die entsprechenden dann entsprechend markiert.

[testperson 1.527]

Hi,

 

habe das "Phänomen" letzte Woche ebenfalls beobachten können, dass der Windows DHCP in einem Netz 192.168.0.0/16 (vermutlich auch in anderen /16 Netzen) mit der IP-Adress-Vergabe bei 192.168.255.x startete. Aber mal ganz ehrlich wo ist denn da das Problem? Nachdem er die letzte IP vergeben hatte, fing er einfach wo anders wieder an.

 

Lancom Router mit aktivem DHCP vergeben die IPs scheinbar komplett per Zufall aus dem Pool.

 

Gruß

Jan

[lefg 276]

......... Aber mal ganz ehrlich wo ist denn da das Problem? ........

 

Der TO schilderte, es seien keine Adressen mehr vergeben worden. (oder es sei befürchtet worden)