Server 2008 R2 - DHCP "BAD_ADDRESS" im neuen Subnetz

[zahni 521]

10.16.1.1 bis 10.16.1.150, 22er Subnetzmaske Gateway 10.16.0.254 DNS1+2 10.16.0.206 10.10.1.20 - in dieser Konfiguration habe ich keine Ausschlüsse definiert.

Und für 10.16.0.x hast Du keinen Bereich definiert?

Nochmals: Du darfst für das gleiche Subnet nicht mehr als einen Bereich anlegen.

Dann weis der DHCP nicht, was er verteilen soll.

 

Man kann zwar mit Scope-IDs arbeiten. ist aber  eher unüblich. die Scope-ID muss dann am Client-Gerät definiert werden.

[gardsen 10]

Nein, kein Bereich aktiv. Ich habe jetzt mal folgendes getestet:

 

Erstellung eines Bereiches 10.16.0.1 bis 10.16.1.250, zunächst mit Ausschlüssen von 10.16.0.1 bis 10.16.0.254.

Also IP-Adressverteilung von 10.16.1.1 bis 10.16.1.250 - funktioniert nicht.

Nehme ich die Ausschlüsse weg, wird wieder 10.16.0.1 verteilt und der gleiche Client bekommt sofort eine IP-Adresse.

 

DNS-Log sieht so aus:

 

 

32,05/23/15,17:02:29,DNS-Aktualisierung erfolgreich,10.16.1.31,WIN7-TEST.domain.local,,,0,6,,,
30,05/23/15,17:02:29,DNS-Aktualisierungsanforderung,10.16.1.31,WIN7-TEST.domain.local,,,0,6,,,
13,05/23/15,17:02:29,Konflikt,10.16.1.31,BAD_ADDRESS,,,0,6,,,
32,05/23/15,17:02:29,DNS-Aktualisierung erfolgreich,10.16.1.31,WIN7-TEST.domain.local,,,0,6,,,
30,05/23/15,17:02:43,DNS-Aktualisierungsanforderung,10.16.1.32,WIN7-TEST.domain.local,,,0,6,,,
10,05/23/15,17:02:43,Zuweisen,10.16.1.32,WIN7-TEST.domain.local,005056B33B56,,1823566858,0,,,
32,05/23/15,17:02:43,DNS-Aktualisierung erfolgreich,10.16.1.32,WIN7-TEST.domain.local,,,0,6,,,
30,05/23/15,17:02:43,DNS-Aktualisierungsanforderung,10.16.1.32,WIN7-TEST.domain.local,,,0,6,,,
13,05/23/15,17:02:43,Konflikt,10.16.1.32,BAD_ADDRESS,,,0,6,,,
32,05/23/15,17:02:43,DNS-Aktualisierung erfolgreich,10.16.1.32,WIN7-TEST.domain.local,,,0,6,,,
30,05/23/15,17:02:57,DNS-Aktualisierungsanforderung,10.16.0.1,WIN7-TEST.domain.local,,,0,6,,,
10,05/23/15,17:02:57,Zuweisen,10.16.0.1,WIN7-TEST.domain.local,005056B33B56,,2141615782,0,,,
32,05/23/15,17:02:57,DNS-Aktualisierung erfolgreich,10.16.0.1,WIN7-TEST.domain.local,,,0,6,,,

 

Reverselookup-Zone 10.16.1 ist vorhanden. Was ist hier los? Ich kapier das so langsam echt nicht mehr...

[lefg 276]

Moin, frohe Pfingsten

 

Wurde es einmal mit einem anderen Ausschluss versucht? Beginn nicht gleich am Anfang, also nicht bei 10.16.0.1 und auch nicht bis 10.16.0.254? Meinetwegen 10.16.0.90- 10.16.0.95.

 

Mit dem DNS hat das nichts zu tun.

bearbeitet 25. Mai 2015 von lefg

[gardsen 10]

Ebenfalls frohe Pfingsten :)

 

Das bringt mich ja nicht weiter, ich möchte ja im 0er-Bereich nichts mehr verteilen.

Ich installiere gerade noch mal eine weitere Test-VM mit aktivem neuen Bereich. Ich vermute fast, dass hier irgendwas cached, was nicht cachen soll, auch wenn ich gerade nicht weiß, wo das passieren sollte.

Das ging fix - hat nichts gebracht. Auch die neue VM erzeugt wieder BAD_ADDRESS....

[lefg 276]

Dann mach mal. Ich habe dir einen Rat gegeben zu einem Versuch. Du kannst natürlich auch einen anderen Ausschluss nehmen. Es mach aber keinen Sinn, einem Bereich mit 10.16.0.1 zu beginnen und auch gleich mit einem Auschluss.

 

Der Auschluss könnte wohl beginnen mit 10.16.0.2 und enden mit 10.16.0.4.

 

Und was sollte da wo zwischengespeichert sein?

[gardsen 10]

Funktioniert, Client bekommt eine IP. Das ist jetzt aber der falsche Bereich, ich möchte ja nach 10.16.1.x....

Das ist ja das, was ich vorher auch schon getestet hatte. Im 0er-Bereich ist alles ok, sobald es zu 1.x geht, funktioniert's nicht mehr.

 

Ich weiß auch nicht, was noch wo cachen sollte... War nur so eine Idee. Da aber auch mit einer komplett neuen VM genau das Gleiche passiert ist, kann es ja keine "Karteileiche" sein, die irgendwo drinsteht, da sich diese Maschine komplett neu am System gemeldet hat.

bearbeitet 25. Mai 2015 von gardsen

[zahni 521]

Schalte mal die DNS-Aktualisierung des DHCP-Servers ab. Das ist ein Überbleibsel aus alten Zeiten. Die DNS-Einträge nehmen die Client-PCs per DDNS vor.

Vielleicht entstehen hier ja die Konflikte. Hast Du im DNS mal irgendwann etwas "probiert"?

 

Wenn es nicht klappt: Gib mal auf eine der IP-Adressen in ping P-Adresse ein. Danach sofort arp -a . Steht dort eine MAC-Adresse? Wem gehört die MAC-Adresse?

bearbeitet 25. Mai 2015 von zahni

[lefg 276]

Und wenn Du erst den Ausschluss mal wieder rausnimmst, dann mit dem Beginn von 10.16.0.1 nach oben wanderst, z.B. nach 10.16.0.11?

bearbeitet 25. Mai 2015 von lefg

[gardsen 10]

Da stehen MAC-Adressen, die ARP-Table ist voll mit dem gleichen Eintrag. Ich suche mal gerade in ArpGuard, ob die da irgendwo gelistet ist.

Gehört auf jeden Fall nicht dahin...

Ha! Genau das hab ich mir gedacht. Morgen bekommen die Netzies eins auf die Mütze. Da faselt irgendein Cisco-Router durch die Gegend. Der macht zwar kein DHCP, die Adressen sind aber, aus welchen Gründen auch immer irgendwie ins System geknotet.

 

Ich kläre das morgen mal und werde berichten, was da ein- oder besser nicht ausgeschaltet war....

[NorbertFe 1.805]

Den Hinweis hat dir Daniel aber schon am 18. gegeben, dass du mal nach ip Helfern schauen sollst.

[gardsen 10]

Ich habe unsere Netzwerker ja schon gefragt, jetzt kann ich das eben belegen. Normaler Weise sind diese Dinge auch abgestellt, kann sein, dass er sich da geirrt hat...

[gardsen 10]

So, nachdem ich ja doch intensiv an mir gezweifelt hatte, hier die Auflösung - das wird kein Mensch in seinem Netzwerk nachbauen :)

 

Wir haben zwei NetApp-Systeme, die sich replizieren müssen.

Da wir den Replikationstraffic nicht über die ASA schieben können (nur 100Mbit-Schnittstelle), haben wir auf unserer GigaBit - Strecke über Layer2 VRF geroutet. Klingt etwas wild, ist es auch, funktioniert aber.

Der entsprechende Switch wiederum meinte jetzt, er müsse arp-proxy spielen. Tolle Sache! Mit einer entsprechenden Option konnte dies nun ausgeschaltet werden und die Systeme schmeißen sich die ARP-Table nicht mehr voll....

 

Es ist also hausgemachtes Leid gewesen, ich teste das heute abend noch mal und werde dann hoffentlich einen Erfolg melden ;)

[gardsen 10]

Es hat geklappt. Thread kann m.E. geschlossen werden.

 

Vielen Dank für die Denkanstöße an alle!

[Daniel -MSFT- 129]

BTW: Du hättest in das DHCP-Serverlog schauen sollen, nicht das DNS-Serverlog. Und einen Netzwerktrace anschauen mit Netmon oder Wireshark. Dann wäre das gleich aufgefallen. Hatte ich etwas weiter oben aber schon drauf hingewiesen ;-)

 

Gut, dass der Spuk jetzt behoben ist.

[gardsen 10]

Vertippt.... es war natürlich DHCPServerlog nicht DNS. Ja, Wireshark anzuwerfen klingt immer so einfach - für mich ist dieses Tool nach wie vor ein ziemliches Monster, mit dem ich mich intensiver beschäftigen müsste.

Leider sind solche Probleme in unserem Bereich zu selten, als dass sich das lohnen würde...glücklicher Weise :)

bearbeitet 26. Mai 2015 von gardsen