Subnetz einer Active Directory Umgebung ändern
Hallo zusammen,
wir überlegen, unsere Domäne von mehreren Klasse-C-Netzen auf ein Klasse-B-Netz (beides IPv4) umzustellen.
Die Domain-Stufe ist Server 2012 und es gibt 3 DCs mit Server 2012 R2. Alle sind DNS-Server, einer davon ist DHCP-Server.
Mir geht es hier in erster Linie darum, ob bei den DCs etwas Besonderes zu beachten ist, damit man sich nicht das Active Directory lahm legt.
Wir würden wie folgt vorgehen:
- die statischen IP-Adressen der Domain-Controller über deren Netzwerk- und Freigabecenter umstellen
- prüfen, ob die NS und Host A-Einträge im DNS sich aktualisieren und wenn nicht, dies manuell tun
- im DNS die Forwarders aktualisieren
- die IP-Adresse der DNS Delegation aktualisieren
- im Zonentransfer die IP-Adressen der primären und sekundären DNS Zonentransfers aktualisieren
Das Vorgehen entspricht dem Technet-Artikel https://technet.microsoft.com/de-de/library/cc794931(v=ws.10).aspx.
Anschließend würden wir dann im DHCP alles für den neuen Adressbereich einrichten.
Meine Fragen:
Hat das schonmal jemand gemacht?
Muss ich noch etwas dazu beachten?
Beste Grüße
O. Marc
wir überlegen, unsere Domäne von mehreren Klasse-C-Netzen auf ein Klasse-B-Netz (beides IPv4) umzustellen.
Die Domain-Stufe ist Server 2012 und es gibt 3 DCs mit Server 2012 R2. Alle sind DNS-Server, einer davon ist DHCP-Server.
Mir geht es hier in erster Linie darum, ob bei den DCs etwas Besonderes zu beachten ist, damit man sich nicht das Active Directory lahm legt.
Wir würden wie folgt vorgehen:
- die statischen IP-Adressen der Domain-Controller über deren Netzwerk- und Freigabecenter umstellen
- prüfen, ob die NS und Host A-Einträge im DNS sich aktualisieren und wenn nicht, dies manuell tun
- im DNS die Forwarders aktualisieren
- die IP-Adresse der DNS Delegation aktualisieren
- im Zonentransfer die IP-Adressen der primären und sekundären DNS Zonentransfers aktualisieren
Das Vorgehen entspricht dem Technet-Artikel https://technet.microsoft.com/de-de/library/cc794931(v=ws.10).aspx.
Anschließend würden wir dann im DHCP alles für den neuen Adressbereich einrichten.
Meine Fragen:
Hat das schonmal jemand gemacht?
Muss ich noch etwas dazu beachten?
Beste Grüße
O. Marc
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 309828
Url: https://administrator.de/contentid/309828
Ausgedruckt am: 22.11.2024 um 14:11 Uhr
7 Kommentare
Neuester Kommentar
Zitat von @O-Marc:
wir überlegen, unsere Domäne von mehreren Klasse-C-Netzen auf ein Klasse-B-Netz (beides IPv4) umzustellen.
wir überlegen, unsere Domäne von mehreren Klasse-C-Netzen auf ein Klasse-B-Netz (beides IPv4) umzustellen.
Die frage ist, ob Ihr aus mehreren /24 ein /16 mahen wollt udn damit mehrere hundert rechner in ein IP-v4-Netz packen oder ob Ihr einfach nur die netze aus dem RFC1918 Bereich 192.168.0.0/16 in den RFC1918-Bereich 172.16.0.0/12 packen wollt unter Beibehaltung der der Masken.
Wenn Ihr ein riesiges /16-Netz macht, werdet Ihr garantiert Probleme bekommen.
lks
Zitat von @O-Marc:
Hallo,
erstmal danke für Eure Antworten.
Es soll aus mehreren /24-Klasse-C-Netzen ein /16-Klasse-B-Netz gemacht werden.
An Netzwerkgeräten sind ca. 500 vorhanden. Luft nach oben für zusätzliche 500 Geräte wäre gut.
Hallo,
erstmal danke für Eure Antworten.
Es soll aus mehreren /24-Klasse-C-Netzen ein /16-Klasse-B-Netz gemacht werden.
An Netzwerkgeräten sind ca. 500 vorhanden. Luft nach oben für zusätzliche 500 Geräte wäre gut.
500 gerät in eine gemeinsame broadcast-Domain zu packen wird Dein Netz sehr stark belasten, ggf., je nach Auslastung "auspusten".
Mir ist klar, dass man bei 172.16.0.0 /16 sehr viel mehr Adressen hat. Den Vorschlag dazu hat ein Dienstleister gemacht und bisher bin ich unvoreingenommen davon ausgegangen, dass die sich dabei schon was gedacht haben.
Vermutlich nicht viel.
Mein Gegenvorschlag war, beim vorhandenen Netz die Subnetzmaske zu ändern auf 255.255.252.0.
Damit hätte man das Netz 192.168.0.0 /22 mit 1022 nutzbaren IP-Adressen.
Der Dienstleister meinte, das könne zu Problemen führen.
Damit hätte man das Netz 192.168.0.0 /22 mit 1022 nutzbaren IP-Adressen.
Der Dienstleister meinte, das könne zu Problemen führen.
Eben,. das führt zu denselben Problemen, die man in einem "flachen" Netz hat, in der alle Nodes in derselben Broadcast-Domain sind.
Die micration des 192.168-er Netze in den 172.16.0.0/12-er Bereich ist an und für sich schon sinnvoll, um Konflikte mit "Heimnetzen" zu vermeiden.
Aber Ihr solltet die Systeme in einzelne Subnetze segmentieren, um die Belastungen, z.B. durch Broadcast & co. mildern.
Du kannst das Dir wie mit 500 Mitarbeitern und vielen Büros vorstellen.
Wenn Du die 500 Mitarbeiter in einen einzigen großen raumsteckst, wird vermutlich die Arbeitseffektivität sehr leiden, wenn die Leute sich gegenseitig die Informationen zurufen.
wenn Du hingegen durch "kleinere Büroräume" segmentierst und da die arbeitsgruppen reinsteckst, die hauptsächlich miteinander reden, wird der Arbeitsfluß deutlich gesteigert werden.
Wie bei den Büros ist die Kunst, die richtige "Bürogröße" und die richtigen "Arbeitsgruppen zu finden.
Solltest Du Unterstützung brauchen. Man kann mich auch "kaufen".
lks
PS. Siehe dazu auch z.B. in einem ähnlichen Thread
Tach,
Ich habe vor ca 4 Jahren ähnliches gemacht, wie du:
Das 192.168.0.0/24er Netz wurde voll, hatte nur noch rund 15 freie IPs.
Bin dann (in Ermangelung an geigneter Hardware) im gleichen VLAN auf ein 172.16.0.0/22er Netz gewechselt um seit ca. 4 Monaten aktiv dabei zu sein, aus dem 172er mehrere kleinere 192er Netze zu bauen. ( einige sehr alte Devices kommen mit Subnetzen nicht klar, daher klassische Class C Verwendung)
Denn durch neu angeschaffte Switche und einer vernünftigen UTM kann ich nun VLANs fahren und dadurch auch Zugriffe (via CoreSwitch) auch "spezielle" VLANs regeln.
Es muss z.B. kein Netzfremder in das Netz, in dem div. Maschinensteuerungen sitzen. Auch müssen die Clients keinen Zugriff auf die VMWare Kernels haben.
Zudem ist es insbesondere bei Maschinensteuerungen oder der Einsatz von vMotion sinnvoll, die Daten in eigenen BroadcastDomains laufen zu lassen, da dadurch die Last nicht andere Segmente beeinträchtigt.
In summe optimierst du zu den bereits angesprochen Performance-Aspekten auch dein Sicherheitslevel....
Wenn du also umstellst, dann verschiebe die Clients in ein eigenes VLAN, div. Managementzugänge zu Switchen, etc. in ein weiteres. Server kannst du dort ja belassen (spart einem Arbeit mit Drittanbietern etc.) und setzt das Netz halt nicht als Default VLAN, sondern verpasst denen einen eigens VLAN...
Gruß
em-Pie
Ich habe vor ca 4 Jahren ähnliches gemacht, wie du:
Das 192.168.0.0/24er Netz wurde voll, hatte nur noch rund 15 freie IPs.
Bin dann (in Ermangelung an geigneter Hardware) im gleichen VLAN auf ein 172.16.0.0/22er Netz gewechselt um seit ca. 4 Monaten aktiv dabei zu sein, aus dem 172er mehrere kleinere 192er Netze zu bauen. ( einige sehr alte Devices kommen mit Subnetzen nicht klar, daher klassische Class C Verwendung)
Denn durch neu angeschaffte Switche und einer vernünftigen UTM kann ich nun VLANs fahren und dadurch auch Zugriffe (via CoreSwitch) auch "spezielle" VLANs regeln.
Es muss z.B. kein Netzfremder in das Netz, in dem div. Maschinensteuerungen sitzen. Auch müssen die Clients keinen Zugriff auf die VMWare Kernels haben.
Zudem ist es insbesondere bei Maschinensteuerungen oder der Einsatz von vMotion sinnvoll, die Daten in eigenen BroadcastDomains laufen zu lassen, da dadurch die Last nicht andere Segmente beeinträchtigt.
In summe optimierst du zu den bereits angesprochen Performance-Aspekten auch dein Sicherheitslevel....
Wenn du also umstellst, dann verschiebe die Clients in ein eigenes VLAN, div. Managementzugänge zu Switchen, etc. in ein weiteres. Server kannst du dort ja belassen (spart einem Arbeit mit Drittanbietern etc.) und setzt das Netz halt nicht als Default VLAN, sondern verpasst denen einen eigens VLAN...
Gruß
em-Pie