05.10.2010

12498

Was tun wenn ein Subnetz zu klein wird ? Wechsel von Class C auf Class B in laufender Windows AD Umgebung. Geht das so einfach ?

Hallo Fachleute, so nach vier Jahren funktionierdem Netzwerk bin ich auf eine Aufgabenstellung gestoßen die mich ein wenig vewirrt ? Durch die Virtualliesierung und Co. hat sich unser kleines Firmennetzwerk durch ThinClients und unzälige Netzwerkgärte als zu klein vom Subnetz erwiessen...

Als ich vor vier Jahren das Netzwerk mit den anderen konziepierte dache ich mehr als 255 Netzwerkgeräte werden wir niemals haben. Nun ist der Fall passiert das wir in unserem 192.168.0.0/24 alles voll ist, Teile wie PCoIP Hosts schon im 192.168.50.0/24 sind und die SAN's schon in eigene Subnetze untergebracht sind.

So meine Frage nun: Was muss man beachte bzw. befürchten wenn man versucht das Windows AD Netz Class C (192.168.0.0/24) in ein Class B Netz umzuwandeln ?

Oder wäre es besser eine komplett neue Domäne in einem Class B Netz aufzubauen über die nächsten Wochen damit man einen sauberen Schnitt hat ? (Lust und Zeit hab wegen der laufenden Projekte eigentlich nicht)

Also für Ratschläge, Tips und euere Meinung bin ich offen und danke euch schon mal jetzt im vorraus.

Viele Grüße
JBBERLIN

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 152419

Url: https://administrator.de/forum/was-tun-wenn-ein-subnetz-zu-klein-wird-wechsel-von-class-c-auf-class-b-in-laufender-windows-ad-umgebung-geht-152419.html

Ausgedruckt am: 23.12.2024 um 15:12 Uhr

32 Kommentare

Neuester Kommentar

Hi JBBERLIN,
häng doch einfach noch ein /24 Netzwerk dazu. Somit brauchst du an den bestehenden Netzwerk nichts ändern. Vorraussetzung ist ein Layer 3 Switch oder ein Router auf dem ein sekundäre IP-Adresse konfiguieren kannst. Ein großér Nachteil ist, dass sämtlicher Traffic zwischen den beiden Netzwerken über den Switch / Router geht - egal wie nah die beiden GEräte nebeneinander stehen.

Grüße,
Dani

Wechsel von Class C auf Class B

Puh ist das staubig hier.
Und dieser Gestank von seit 1994 ausgestorbener Technologie...

Mal ehrlich: Klassen gibt es seit 94 nicht mehr und was für eine Subnetzstruktur du hast ist AD völlig egal, solange du nicht mit Standorten arbeitest.

Hallo dog,

es gibt sehr wohl noch Klassen, selbst Cisco lehrt dies im CCNA.

@Dani

Layer3 Switche sind als Coreswitch von Nortel vorhanden (4x gestackter 5520-48) was mir mit noch einem /24 Netz Kopfschmerzen bereitet sind die vielen VM's die in den 3 voll ausgebauten Bladecentern laufen wenn deren Traffic dann über den Coreswitch läuft dann guten Nacht.

Momentan benötigen wir als Testumgebungen pro Projekt ca. 20 - 30 VMs, wenn wir nun vorhaben ca. 10 Projekte gleichzeitig zu stemmen und dazu noch die Infrastruktur von unseren 3 Hauptfirmen zu wuchten dann komm ich locker auf den Bedarf von ca. 500-600 IPs.

@dog

Versteh ich dich jetzt recht das ich dem AD und den DC's nicht antue wenn ich jetzt anfangen die IP's von sagen wir mal DC1 von 192.168.0.7/24 auf 172.16.0.7/16 zu ändern ??? Ich hab gelernt (okay ist lang her) ändere niemals die IP des DC's !

Hallo remigius,

dem kann ich nur beistimmen das hab ich auch noch so bei den IBM und Nortel Schulungen 2008 gelernt !

Zitat von @remigius:

Hallo dog,

es gibt sehr wohl noch Klassen, selbst Cisco lehrt dies im CCNA.

Jojo... laut Cisco darf man auch beim Subnetting das erste Subnetz nicht mitrechnen/benutzen.
Sorry, aber das ist schon lange nicht mehr praxisnah... Durch die Erfindung von CIDR ist das Ganze überholt.

Grüße,
Dani

es gibt sehr wohl noch Klassen, selbst Cisco lehrt dies im CCNA.

Und genau da sind wir beim Problem.
Falsch, falscher, Cisco.

Ich weiß durchaus wie Cisco da die Lernenden anlügt, aber Netzklassen sind 1994 schlicht ausgestorben (man muss nur in den Cisco-Büchern sehr genau suchen um den Absatz zu finden).
Kein Router, auch nicht die Cisco-Geräte arbeiten noch mit CBR (ip classless ist eine Default-Einstellung unter IOS).
Es gibt kein Netzwerkgerät, dass noch CBR kann.
Selbst meine Printserver von 1998 mit Token Ring und 10Mbit Ethernet können ausschließlich CIDR.

Es gibt einfach keine Klassen mehr, alles was es noch gibt sind einige Überreste aus der CBR-Zeit, wie eben die Zuweisungen für private Netze und Multicast aber auch die werden komplett durch CIDR dargestellt.

Ich hab gelernt (okay ist lang her) ändere niemals die IP des DC's !

Nein, das stimmt nicht.
Durch DNS ist AD völlig dynamisch.
Spätestens wenn du alle PCs einmal neu gestartet hast haben sie sich an die neue IP akklimatisiert.

Problematisch wird es erst dann, wenn Dienste direkt auf die IP des DCs verweisen, oder wenn er als DNS-Server statisch an den Clients eingetragen ist oder wenn du die automatische DNS-Aktualisierung unterbunden hast (z.B. weil der DC mehrere IPs hat).

Das nicht wirklich. Klar alle unsere Linux Boxen und VM's im produktiven Einsatz haben statische DNS Eintragungen.

Aber nochmal zu meinem Verständnis für ganz Doofe !

- Freitag Mittag alle nach Hause schicken !
- Genug Cola, Red Bull horten und die Nummer vom Pizzadienst auswendig lernen.
- Alle DC's (4 Stück) ins IP/16 bringen.
- Alle Switche ins IP/16 bringen.
- Alle Linuxgateways aufs IP/16 bringen
- DHCP mit ca. 190 Reservierungen neuschreiben
- Alle Linuxboxen und sonstigen festen DNS einträge ändern.
- Alles kräftig neustarten
- Den ganzen Sonntag durchtesten.
- Sonntag Abend mir den ganzen Ärger von meiner Frau abholen wo ich die letzen 3 Tage war ! :-S
- Eine Woche Urlaub beantragen! Aber wissen das man für die nächsten ca. 65000 IP Drucker, IP Cameras und weiss der Teufel was für Appliancen man genug IP's zur Verfügung hat bis in ein paar Jahren IPv6 kommt...

Könnte man so machen

Viele Fehler verstecken sich aber gerne, wie z.B. mal ein Netzlaufwerk über IP verbinden etc.

Juti, dann erst mal vielen Dank an Euch alle !

Betrachten wir diesen Eintrag als Gelöst und ich schreibe dann mal einen Erfahrungsbericht wenn ich das übernächstes Wochenende überstanden habe und alles läuft!

Ich schätze das durch VMware, Hyper-V und Citrix so manch anderer Admin der früher mal mit 20 Servern zutun hatte nun vor dem Problem steht das IP/24 nicht mehr ausreicht !

Schönen Abend/Nacht allen !

Viele Grüße
JBBERLIN

Hi JBBERLIN,
überleg schon mal Plan B falls die 3 Tage nicht reichen sollten und der Montag vor der Türe steht.

Dann deiner Stelle würde ich das sehr sehr gut durchdenken, entsprechende Vorarbeiten leisten und für 99% der möglichen Fehler einen Notfallplan erarbeiten. Erst dann die Umstellung durchziehen.
Denn wenn am Montag keiner mehr arbeiten kann hast du ein richtiges Problem! Da interessiert es keinen wie viele IP-Adressen nun frei sind.

Grüße,
Dani

Zitat von @dog:

Könnte man so machen

Viele Fehler verstecken sich aber gerne, wie z.B. mal ein Netzlaufwerk über IP verbinden etc.

Das hab ich immer schön vermieden weil ich immer alle gezwungen habe auf je nach Abteilung und Rechte einen Zentralen Ordner der via Folder Aggregation der auf den SAN's verteilt war alles abzulegen.

Und wenn Netzlaufwerke via GPO gemountet wurden dann nur immer schön anhand der DNS Namen.

Aber troztdem werde ich der Geschäftsleitung morgen einen weiteren SAN aus den Rippen leiern und von Donnerstag zu Freitag Nacht vor dem Wochenende ein komplett Backup fahren.

Dank dir nochmal !

Ich hab ja noch eine kleine Testumgebung aus 3 kleinen Servern ! 1x DC, 1x SQL und 1x Hyper-V mit 3 VM's! Klar werde ich das dort mal erst versuchen.

Was mir nur bissel Sorgen macht ist die Gesichte mit den VMware ESX's und den iSCSI und Infiniband SAN's denn dort ist alles natürlich nur über IP Adressen geregelt.

Wir werden sehen... Erfahrungsbericht kommt auf jeden Fall ansonsten wäre mein Plan B einfach nur weil wir genug alte Hardware da haben und ich noch nicht geschafft hab diese
auf eBay reinzustellen das eine komplett neue Domäne über die nächsten Wochen aufgezogen wird, man endlich alte Fehler und (damit finden wir uns ab) ausmerzt und vorallem unseren
Exchange sauber neuaufsetzt. Aber auf jeden Fall muss ich morgen eine Entscheidung treffen da ab November zwei neue Standorte bzw. Zweigstellen via Glasfaser an unser AD angebunden werden und dann
muss das alles sauber laufen.

Danke nochmal für die Warnung bzw. stoppen meines Jubels denn ich gerade durch die Aussage von Dog hatte

Was mir nur bissel Sorgen macht ist die Gesichte mit den VMware ESX's und den iSCSI und Infiniband SAN's denn dort ist alles natürlich nur über IP Adressen geregelt.

Regel Nr.2: Für SAN's immer einen extra IP-Bereich unabhängig vom LAN konfiguieren. Schon alleine wegen Broadcast. Das wäre auch ein Punkt den ich vor der LAN-Umstellung noch beheben würde. Wenn du dem eine 192.168.140.0/24 gibst wirst du die nächsten 5 Jahre im iSCSI-Bereich Ruhe haben.

Grüße,
Dani

Der ist ja vorhanden ! Sogar zwei 192.168.48.0/24 für NFS und 192.168.49.0/24 iSCSI ! Gut Gedankenfehler von meiner Seite aus weil dieser kann ja bleiben !

Hätte ich den nicht gemacht damals wären mir schon vor Monaten die IP's ausgegangen!

Hallo!
Obwohl ich nicht Dog bin, kann ich dir was Deinen letzten Beitrag betrifft, recht geben, und zwar mit beidem.
1.) besser nicht die IP des DC ändern
2.) 192.168.0.7 bleibt 192.168.0.7 - Du änderst ja nicht die IP, sondern die Subnetzmaske...

zu einem Eintrag weiter oben:

DHCP mit ca. 190 Reservierungen neuschreiben

würde ich nicht neu schreiben, sondern am bestehenden dhcp mit netsh wie folgt ausgeben:

netsh dhcp server [IP-Adresse des DHCP Servers] scope [Scope-Adresse] dump>reservierungen.txt

dann öffnest Du die reservierungen.txt mit notepad und löscht alles bis auf die reservierungen
diese dann entpsrechend ändern
abschließend am neuen System

netsh exec reservierungen.txt

Das ganze könntest Du natürlich auch im Vorfeld in einer VM testen, in dem Du dort den DCHP konfigurierst, am alten System per netsh die reservierungen ausgibts, diese dann in die VM integrieren, und wenns so aussieht, wie Du es Dir vorstellst, das ganze dann wieder per netsh exportieren.

am Freitag nachmittag (wenn ich mich an Deinen Zeitplan erinnere) einfach den bestehenden Scope am alten System löschen, per netsh die NEUER_SCOPE.txt aus der VM importieren und das wars dann...

Dann sollte sich das ganze auch locker bis Sonntag abend ausgehen...

Du änderst ja "bloß" massig Subnetzmasken...

Ich persönlich sehe da AD-mäßig kein großes Problem (hab letzten Samstag das genau umgekehrte mit 3 DCs, 6 Windowsservern, 1 Ubuntu + 350 Clients durchgezogen, dh, ich hatte ein /16 und hab daraus massig VLANS /24 gemacht.)
Die DCs verkraften das jedenfalls unbeschadet (wenn sie sonst kein Problem haben!)
Das einzige Problem, das sich bei mir zeigte, waren die fehlerhaften Routen im Proxyserver (ISA)...
(source 192.168.0.0 255.255.255.0 ist halt doch was anderes als 192.168.0.0 255.255.0.0)

gutes gelingen

lg
edi

Guten Morgen!

Nur ein kurzer Wink...

wenn du die 192.168.0.x/24 in eine /16 umwandelst, so befindet sich der iSCSI-SAN Bereich mitten im Scope.

Was spricht gegen zusätzliche /24 Scopes?

Der broadcast wird beim /16 gewaltig, iSCSI kommt eventuell noch mit Jumbo-Frames und ich bin mir nicht sicher ob das viel besser ist als den Traffic sauber durch den Core zu routen.

Gruß
Yali0n

Morgen,

na aus unserem 192.168.0.0/24 einfach ein 192.168.0.0/16 zu machen hatte ich auch nicht vor!

Mir gings um das Primäre AD Netz welches sich im 192.168.0.0/24 befindet daraus ein 172.16.0.0/16 zumachen.

Die Netze für:

Infiniband vKernel & vMotion - 192.168.100.0/24
PCoIP - 192.168.50.0/24
iSCSI - 192.168.49.0/24
NFS - 192.168.48.0/24
IPoIB - 192.168.47.0/24

wollte ich unangetastet lassen.

Gruß
JBBERLIN

Hi!

Blöde frage ...

Warum lässt du die Server nicht im 192.168.0.x/24

und nimmst zb. für:

die Clients 192.168.2.x/24 oder /23
die Drucker 192.168.4.x/24
(zukünftige projekte 192.168.6.x /24)

Der riesige Vorteil dadurch ist die Ersparnis die Server mit neuen IP's auszustatten.
Diese Adressen sind bestimmt in so manchen Programmen / Druckern / Scripts hinterlegt - und garantiert findest du an einem Wochenende nicht alle diese Spezialfälle.

Wenn ich die oberen posts richtig verstanden habe wurde immer nur angenommen das die IP's gleich bleiben und sich nur die sub ändert.
Garantieren wird dir bestimmt keiner, dass die dc's das ohne weiteres hinnehmen (IP Change) - zumindest mit dessen Replikationseinstellungen solltest man behutsam umgehen...

Gruß
Yali0n

@Yali0n:

Naja, das mit dem garantieren ist so eine Sache...

dennoch gebe ich zu bedenken, dass es hier um keinen IP Change handelt UND darf JBBerlin zumindest insoweit beruhigen (wenngleich ich persönlich für GAR NICHTS IM LEBEN

garantieren kann), dass ich derartiges bereits 4 mal (halt stets in die andere Richtung, aber das sollte ja soweit egal sein) ohne auch nur das geringste Problem gemacht habe...

die CHANCEN stehen also gut, dass es den DCs komplett wurscht ist, welche Subnetzmaske Du eingetragen hast, sofern natürlich alle die selbe haben...

die paar Minuten während des Umstellens ist halt "nix mit Replizieren", aber die entsprechenden Einträge in der Ereignisanzeige verschwinden schlagartig, wenn wieder alle im selben Netz sind...

ich würde halt vor der Aktion mit replmon explizit überprüfen, ob alle replizieren und wenn dem so ist: just do it

btw: ich musste die DCs noch nicht mal rebooten nach der Änderung.
(Ich würde mit den DCs beginnen und wenns wirklich nicht funktionieren sollte - was ich persönlich für ausgeschlossen halte - dann setzt Du einfach die Subnetzmaske zurück auf 255.255.255.0 und alles läuft wieder wie gehabt.
(Danach kannst Du Dir immer noch einen Plan B ausdenken...
Das hätte im übrigen auch den Vorteil, dass Du zumindest kommendes Wochenende keine Troubles mit Deiner Freundin bekommst

wie gesagt:
gutes gelingen
lg

@ Edi.Pfisterer:
... glaube wir reden aneinander vorbei

Zitat von @Edi.Pfisterer:

(Ich würde mit den DCs beginnen und wenns wirklich nicht funktionieren sollte - was ich persönlich für
ausgeschlossen halte - dann setzt Du einfach die Subnetzmaske zurück auf 255.255.255.0 und alles läuft wieder wie
gehabt.

Wie JBBERLIN schrieb:
na aus unserem 192.168.0.0/24 einfach ein 192.168.0.0/16 zu machen hatte ich auch nicht vor!

Mir gings um das Primäre AD Netz welches sich im 192.168.0.0/24 befindet daraus ein 172.16.0.0/16 zumachen.

... also nicht nur sub zurück und alles läuft wieder

Eigentlich muss man grundsätzlich überlegen ob es sinvoll ist auf Class-B zu gehen.
Aus Performance-Sicht gibts nichts grausameres als sich durch den Broadcast das Netz zuzumüllen - aber das muss jeder für sich entscheiden und abwägen.

Es kann jetzt natürlich auch sein das nur ich das ganze falsch verstanden habe.

lg

Hallo,

anstatt die Maske von /24 auf /16 aufzubohren und damit von 255 auf 65534 möglich Adressen aufzubohren soltest du dir über die folgen klar werden.
Außer den bereits geschilderten Problemen mit Netzlaufwerken und DC's solltest du dir im klaren sein das du dir eine riesige Broadcast Domäne aufbaust
die nur Stress für dich und die Maschinen bedeutet.
Eine anständiges Routing Konzept und die Einführung von VLAN's und schon ist der Netzwerktraffic das geringste deiner Probleme.

Vor allen würde ich den Bereich 192.168.x.x sowieso komplett verlassen und in den Bereich 10.x.x.x umziehen, gibt weniger Stress bei VPN Verbindungen wenn man da eine sauberes Konzept hat.

Wieso sich diese blöden Netzklassen immernoch in der Diskussion halte frage ich mich bis heute. Kein Gerät kann oder macht das noch aber alle Hersteller
und allen voran alle Schulen und Unis beten es jedes Semester wieder vor sich her!

brammer

Moin,

so um klar zu stellen es geht um einen IP und SUBNET wechsel! Von 192.168.0.0/24 auf 172.16.0.0/16 !

Problem ist folgendes:

Unser Aufbau sieht folgendermassen aus: Letztes Jahr sind wir weg von Physischen Clients auf VM's mit ThinClients, immer schön in 3 - 5 Arbeitsplätze, jede dieser Gruppen hat mindestens einen IP Drucker und 1-2 Silex USB 2.0 Server.
Insgesamt komme ich so auf ca. 50 Arbeitsplätze was bedeutet 50 IP für VM's + 50 IP's für die HP ThinClients + 15 IP Drucker + 20 USB Server somit habe ich allein für Verwaltung, Vertrieb, ect. ca 135 - 140 IP's aus dem 192.168.0.0/24 verbraucht.

Dazu kommen die ganzen Server, IP Cameras der Labore, Avocent Appliances... ect. zusätzlich unsere IT-Verwaltung die mindestesn auch noch mal 10-15 IP's mal zum Rollout Test im Produktivnetz sich befindet. Dann hat noch ein Großteil der Angestellten einen Firmen Notebook ect.
so hab ich momentan nur noch sage und schreibe 2 IP's frei.

Dazu kommt das die Firma "sehr schnell und ungesund" von der Netzinfrastruktur gewachsen ist die letzen Jahre sprich, da wurde noch ein Raum angemietet und da mal eine halbe Etage u.s.w... weil schnell gehen sollte wurde dann pro neu angemieten Raum/Fläche mal ein Nortel 5520 Layer3 reingestellt und mit dem Core verbunden und das alles mitlerweile über 3 Etagen, aber nicht hintereinander sonder dazwischen ist mal eine andere Firma und so das vieles in diesem alte Gebäude auch nicht machbar ist. Dank RSTP war auch alles kein Problem. Aber (Teilweise auch meine Schuld da ich eine Dokusau bin) nun alles mit VLAN's für die einzelnen Stationen auszustatten sehe ich einen viel größeren Aufwand da viele Geräte nur von Switchseite aus mit VLAN's sich versehen lassen...

So wie es aussieht wird mein Vorgehen so sein das ich mir heute und morgen über eine VM Struktur aufbaue und dort den IP/SUBNETZ Wechsel ausprobiere... Aber ich neige nachdem ich die Meinungen hier gehört habe eher dazu die nächsten Wochen die Mitarbeiter auf Einschränken einzustimmen und und die Domän neu aufzusetzen so kann man aus den Fehlern der Vergangenheit lernen(Ja auch ich hab den einen oder anderen Fehler im AD gemacht ), einen sauberen Schnitt machen und meine Fachcracks von Entwicklern mal ein wenig SysAdmin Zeug beibringen... Die zaubern jeden Mist mit C++ und lösen jedes Problem in Java oder PHP aber wenn es darum geht mal ein wenig Pflege im Netz zu betreiben oder mal ein SQL Backup manuell zu machen wollen die dann doch lieber was ganz anderes machen...

Die Frage die sich wirklich stellt (und auf die brammer oben ja schon richtig geantwortet hat!) ist warum du dir das alles antust und gleich so einen großen Schritt machst ein komplettes IP Netz zu wechseln. Den ganzen Arbeitsaufwand kannst du dir sparenn wenn du z.B. erstmal nur für die Clients weitere VLANs erzeugst und die in separate VLANs hebst.
Labore in separate VLANs
IT-Verwaltung in ein VLAN
IP-Cameras in ein VLAN
Server belassen im alten VLAN
usw. usw.
Das sind alles Clients die man kinderleicht in eigene VLAN Segmente legen kann um so eine Entspannung der IP Adress Situation im "Altnetz" mit ein paar Mausklicks zu realisieren. Damit reduzierst du den Aufwand auf das Einrichten einer simplen DHCP Range im DHCP Server und das Einrichten dieser VLANs auf den Switches was mit ein paar Mausklicks gemacht ist und kannst so sanft migrieren ohne das es zu Einschränkunden für die Mitarbeiter kommt...im Gegenteil !
Mit einer solchen Segmentierung erhöhst du zudem noch die Performance erheblich indem du die Brodcast Last in den Segmenten reduzierst.
DAS wäre ein erster sinnvoller Schritt wenn man schon den Luxus hat und einen Layer 3 (Routing) Core Switch hat.
Weiter ein dummes flaches Netzwerk nun aber mit einer 16 Bit Maske zu betreiben ist doch vollkommen kontraproduktiv und beschert dir zudem erheblichen Mehraufwand an Arbeit und Problemen !
Über diese intelligentere Segmentierungsstrategie solltest du mal nachdenken !!

Hallo,

@aqui

Eine anständiges Routing Konzept und die Einführung von VLAN's und schon ist der Netzwerktraffic das geringste deiner Probleme.

Wollte ich ja mit dem Satz auch sagen...

@JBBERLIN

nun alles mit VLAN's für die einzelnen Stationen auszustatten sehe ich einen viel größeren Aufwand da viele Geräte nur von Switchseite aus mit VLAN's sich versehen lassen...

Ja Klar!
Du brauchst auf keinem Endgerät so was wie ein VLAN konfigurieren!
VLAN's werden vom Switch gehandelt nicht vom endgerät, das hat keine Ahnung davon.
Das einzige was du machen musst ist dir ein VLAN Konzept ausarbeiten wie aqui es schonmal angerissen hat und dann die entsprechenden Ports an denen die Geräte hängen ins richtige VLAN heben.
Jetzt noch das routing dahinter für die VLAN's anpassen und deine Kollegen freuen sich Montag morgen über eine sauber arbeitendes Netzwerk.

brammer

@ Yali0n:

Sorry,

Mir gings um das Primäre AD Netz welches sich im 192.168.0.0/24 befindet daraus ein 172.16.0.0/16 zumachen.

hab ich tatsächlich überlesen...

DAS ist ja eine ganz andere Baustelle, entschuldige vielmals.
Somit sind beide Postings komplett inhaltlich hinfällig und gehören hier definitiv nicht her!

Sorry nochmals

Na ja Kollege JBBERLIN hat vermutlich eh das Interesse an einer sinnvollen Lösung verloren wie sein mangelndes Feedback hier ja zeigt.

Bleibt eigentlich nur noch
Wie kann ich einen Beitrag als gelöst markieren?

Nö interesse hab ich nicht verloren... nur ein anderes Projekt von einem Kunde was mal wieder SOFORT gemacht werden muss :-P

Ich bin durch das Projekt nicht mal dazu gekommen die Testumgebung aufzubauen...

Entscheidung zusammen mit der Geschäftsleitung ist so gefallen, dass wir nun Anfangen ein Class A zu Segmentieren und dann teilweise via VLAN alles neu Aufsetzen. (Allein schon dadurch das wir nun eine Funktionierende VPN Struktur aufbauen wollen/müssen)

Vorbereitungen bis 5. November und dann bin ich 3 Wochen von allen anderen Projekten freigestellt damit ich zusammen mit zwei Mitarbeitern eine neue Domäne aufziehe.

Dazu nehmen wir 2 alte Bladecenter kurzfristig in Betrieb und die Geschäftsleitung lässt noch ein neues SAN, drei neue Switche, einen x3550 und einen x3650 sowie zwei HS21 Blades springen

Aber ich werde auf jeden Fall dann noch im Anschluss dieser Umstellung troztdem eine Testumgebung aufbauen und mal ausprobieren ob der Wechesel eines IP/SUBNETZES im AD ohne weiteres möglich ist da diese Frage auf jeden Fall bei dem einen oder anderen Kunden von uns kommen wird.

Viele Grüße
JBBERLIN

Hallo,

eine Bitte nochmal, streiche die Klassifizierung der IP Addressen nach A, B und C einfach ersatzlos aus deinem Vokabular, die wurde mitte der 90er aufgehoben und durch Subnetting abgelöst.

Wir arbeiten Firmen intern bei etwa 10,000 MA weltweit mit mehreren Hunderten Subnetzen aus allen möglichen Privaten IP adress bereichen und mit einer Ausnahme nur Netze mit der Maske /24 oder nach Möglichkeit kleiner.
Daher weiß ich nicht wieso ihr euch mit einem /16 selber das leben Schwer machen wollt.

bammer

Tja das mit den Klassen ist durchs Studium so drin... werd aber in Zukunft vlt. dran denken !

Wegen oben hab ich mich vlt. zu kurz ausgedrückt wir gehen auf /24er und wie oben bereits erwähnt mit VLANs aber dadurch das bissel was verwurschtelt wurde was jetzt nichts mit dem Beitrag zu tun hat genau so wenig wie das mit dem Exchange Server... deshalb die Entscheidung von der oberen Etage komplett neu aber in 10.x.x.x/24 Segmente oder auch kleiner was z.B. die SAN und PCoIP Netzwerke betrifft.

Troztdem habe ich Interesse daran was passiert wenn man von 192.168.0.0/24 auf ein 172.16.0.0/16 wechseln würde im AD deshalb werde ich das Testen !

Viele Grüße
JBBERLIN