DHCP-IP-Adressenbereich verkleinert - Hat der Server aber nicht übernommen

[CroDiver 10]

Hallo Kollegen,

 

bin hier am verzweifeln! Vorgeschichte:

Wir haben in unserer Domäne einen IP-Adressbereich ,der vom DHCP verwaltet wurde, von X.X.0.1 bis X.X.0.200 gehabt, wobei die 1 für den Router steht.

Jetzt habe ich diesen bereich auf X.X.0.100 bis X.X.0.200 für den DHCP-Adress-Pool verkleinert, und ungefähr 60 statische IPs auf den Rechnern vergeben(Grund: SIF-Firewall). Die Lease-Time ist schon längst 2 mal abgelaufen; trotzdem zeigt er mir folgenden Fehler an:Der Bereich "192.168.0.0" ist zu 87 Prozent ausgelastet. Es stehen nur noch 13 IP-Adressen zur Verfügung.

Warum macht er das??? Ich habe nur 20 Clients die ihre IP über DHCP beziehen. Eigentlich müssten doch genügend IP vorhanden sein. Die Clients, die mit stat. IPs arbeiten, laufen alle ganz normal; also keine Netzwerkprobleme oder so.

Wisst ihr eine Antwort???

Vielen dank im Voraus schon mal,

 

CroDiver

[djmaker 95]

Hallo,

 

verwendest Du Reservierungen im DHCP-Bereich?

[weg5st0 10]

Wie lange ist die Leasetime?

 

Inaktive Einträge fliegen trotz abgelaufener Leasetime erst nach 8 Stunden (oder so - genau weiß ich das nicht mehr) raus.

[grizzly999 11]

Hast du denn die einfachste Sache überhupt gemacht, nämlich einfach mal die geleasten Adressen im DHCP angeschaut, wer die hat :suspect:

 

Kann es sein, dass du einen RAS/VPN-Server hast, und auch Einwhlclients und sich der RAS die Adressen holt?

 

 

grizzly999

[CroDiver 10]

Hallo djmaker, servus grizzly999, salve weg5st0,

 

danke erstmal für die Antworten.

Ich verwende keine Reservierungen in DHCP, und die Clients die eine statische IP aus dem Bereich 192.168.0.1 bis 100 haben sollten, haben auch eine.

Die anderen 20 Rechner die über DHCP lafen, haben auch wirklich IPs aus dem Bereich 192.168.0. 100 bis 200. Es passt ja alles, aber trotzdem gibt es eben diese doofe Fehlermeldung, und das nervt und macht mein System unnötig instabiel!

[blub 115]

a) hast du win2003 mit SP1. Ist stark zu empfehlen für DHCP.

b) Hast du deine DHCP-Datenbank mal aufgeräumt mit

 

netsh dhcp server reconcile /fix

und

jetpack (s. kb 145881)

 

c) was verstehst du unter instabil? Hast du sonst noch Ausfälle

 

 

cu

blub

[CroDiver 10]

a) yap, hab ich. :)

b) kann ich das auch sicher machen, wenn die DCs auch gleichzeitig Terminalserver sind???

[blub 115]

Die DHCP-Datenbank ist unabhängig von DC und Terminalserver. Sichern solltest du die DHCP-Datenbank natürlich vorher schon...und am besten einen Restore auf einem Testsystem auch schonmal gemacht haben

[CroDiver 10]

Nochmal kurz zu b)

 

Der Befehl: netsh dhcp server reconcile /fix

funzt bei mir irgendwie nicht. *Achsel zuck* Hab mir die Hilfe angeschaut und find den Fehler nicht. Vielleicht stell ich mich wohl grad a weng dumm an.

 

zu c)

Ja, hab ich. Seit dem das Problem auftritt, vergibt der Server wohl nicht mehr sauber IPs an Clients die sich per Remote einwählen wollen. Mal klappt es, und mal einfach nicht.

[blub 115]

mach mal

netsh dhcp server dump >filename.txt

 

Da sind alle dhcp-Daten drinnen, ausser den dynamischen Adressen. Siehst du hier Fehler?

 

Als letztes Mittel kannst du die DHCP-datenbank neu aufbauen, wenn du in eine neue DHCP-Datenbank diese Daten wieder einspielst

netsh exec filename.txt

 

Das kann manchmal schiefgehen, wenn die Datenbank mal von w2k auf w2k3 upgedatet wurde. Also auf jedenfall immer gut testen und sichern!

cu

blub

[CroDiver 10]

Also:

mach mal

netsh dhcp server dump >filename.txt ...

... hab ich gemacht, aber nix falsches gefunden.

 

An die Reparatur wag ich mich ehrlich gesagt nicht ran, weil ich mich dann doch nicht sooo gut auskenne.:rolleyes:

Kann es denn nicht auch an was anderem liegen???

Apropos:

Kennst Du ne gute Seite oder ein gutes Buch zum Thema DHCP/DNS mit Windows???

Die "grünen" Bücher bringen mich nicht wirklich weiter.

[blub 115]

die Jetpackreparatur machst du mit einer Kopie der dhcp.mdb, da kann produktiv nichts kaputtgehen. Interessant ist, ob du Fehlermeldungen bekommst.

 

Kann's an was anderem liegen? Layer 8 Fehler können natürlich immer sein. Hast du evtl. noch andere DHCPs im Netz?

 

Literatur: ResourceKit, Technet, Netzwerkmonitor

 

cu

blub