29
Netzwerksegmentierung eines 16bit Kundennetzes
Hallo lieber IT Mitstreiter,
ich habe folgendes Problem bei einem Kunden, der ein grosses /16 Netz hat und bei dem wir endlich eine Segmentierung einführen dürfen. Die neuen Netzsegmente werden wir auf einer zusätzlichen Firewall im Backend (jetzt 2 stufiges FW Konzept) einrichten und die Netzte dann pro Netz umstellen.
Zum Glück sind die Bereich der Clients und Server etc. zumindest IP technisch schon sauber in /24 er Netze getrennt, aber natürlich mit einer /16 Maske versehen. Wir haben bei der Umstellung, die möglichst smart für den Kunden laufen soll, folgendes Problem. Die Umstellung des default GW zusammen mit der Netzmaske. Bei Geräten wie Clients, die über DHCP Ihre IP erhalten, können wir für alle das Def. GW und Netzmaske via DHCP Scope auf einen Schlag ändern und gut ist. Das Problem liegt aber mehr bei den statischen Adressen wie z.B. der Server.
Die Server alle auf einen Schlag (am WE) mit den Clients, Drucker etc. umzuheben ist nicht machbar, da der Kunde zu wenig Ressourcen hat und dies sehr waghalsig wäre. Der Laden muss Montags wieder gehen.
Problem: Stellen wir einige Server auf die neue Netzmaske /24 um und geben das Interface der neuen Backend FW als Gateway an, dann haben die restlichen Server, die noch im grossen /16 er Netz sind, noch das Problem, daß sie wenn Sie z.B. aus dem Netz 10.4.5.0/16 (altes Netz) in ein anderes /24 Netz z.B. 10.4.2.0/24 kommunizieren wollen, nicht Ihr Gateway ansprechen, weil die Adresse ja in deren lokalen Netz (/16) ist. Dies bedeutet, diese Server sprechen, bis zur Umstellung ins neue kleinere Segment aufgrund der grossen Netzmaske, nicht die Firewall als GW an. Bisher hatten die Geräte als GW nur die FW im Frontend, wenn Sie ins Internet oder in ein VPN wollten.
Ich hoffe ich konnte das Problem einigermaßen schildern. Ansonsten fragt ruhig nach.
Hat jemand dafür eine Idee/Lösung, ohne dass ich jedem Server bis zur Umstellung ins neue Netz eine explizite kleinere Route in seiner lokalen Routing Table verpassen muss?
Vielen Dank vorab.
Grüße Locke
ich habe folgendes Problem bei einem Kunden, der ein grosses /16 Netz hat und bei dem wir endlich eine Segmentierung einführen dürfen. Die neuen Netzsegmente werden wir auf einer zusätzlichen Firewall im Backend (jetzt 2 stufiges FW Konzept) einrichten und die Netzte dann pro Netz umstellen.
Zum Glück sind die Bereich der Clients und Server etc. zumindest IP technisch schon sauber in /24 er Netze getrennt, aber natürlich mit einer /16 Maske versehen. Wir haben bei der Umstellung, die möglichst smart für den Kunden laufen soll, folgendes Problem. Die Umstellung des default GW zusammen mit der Netzmaske. Bei Geräten wie Clients, die über DHCP Ihre IP erhalten, können wir für alle das Def. GW und Netzmaske via DHCP Scope auf einen Schlag ändern und gut ist. Das Problem liegt aber mehr bei den statischen Adressen wie z.B. der Server.
Die Server alle auf einen Schlag (am WE) mit den Clients, Drucker etc. umzuheben ist nicht machbar, da der Kunde zu wenig Ressourcen hat und dies sehr waghalsig wäre. Der Laden muss Montags wieder gehen.
Problem: Stellen wir einige Server auf die neue Netzmaske /24 um und geben das Interface der neuen Backend FW als Gateway an, dann haben die restlichen Server, die noch im grossen /16 er Netz sind, noch das Problem, daß sie wenn Sie z.B. aus dem Netz 10.4.5.0/16 (altes Netz) in ein anderes /24 Netz z.B. 10.4.2.0/24 kommunizieren wollen, nicht Ihr Gateway ansprechen, weil die Adresse ja in deren lokalen Netz (/16) ist. Dies bedeutet, diese Server sprechen, bis zur Umstellung ins neue kleinere Segment aufgrund der grossen Netzmaske, nicht die Firewall als GW an. Bisher hatten die Geräte als GW nur die FW im Frontend, wenn Sie ins Internet oder in ein VPN wollten.
Ich hoffe ich konnte das Problem einigermaßen schildern. Ansonsten fragt ruhig nach.
Hat jemand dafür eine Idee/Lösung, ohne dass ich jedem Server bis zur Umstellung ins neue Netz eine explizite kleinere Route in seiner lokalen Routing Table verpassen muss?
Vielen Dank vorab.
Grüße Locke
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 516491
Url: https://administrator.de/contentid/516491
Printed on: June 3, 2024 at 00:06 o'clock
29 Comments
Latest comment
Hallo Locke,
ich glaube, du brauchst entweder mehr Manpower oder ein entsprechend solides Skripting/Vorbereitung.
Daneben ist natürlich auch die Frage: Reden wir bei der Umstellung von 10 Server oder von 1000? Sind es 240 Clients oder 5000? Kann es nach und nach passieren, oder muss alles auf einen Rutsch?
Das alles führt zu Bewertungsanpassungen.
Viele Grüße,
Christian
certifiedit.net
ich glaube, du brauchst entweder mehr Manpower oder ein entsprechend solides Skripting/Vorbereitung.
Daneben ist natürlich auch die Frage: Reden wir bei der Umstellung von 10 Server oder von 1000? Sind es 240 Clients oder 5000? Kann es nach und nach passieren, oder muss alles auf einen Rutsch?
Das alles führt zu Bewertungsanpassungen.
Viele Grüße,
Christian
certifiedit.net
Moin,
es ist doch dein Kunde, es ist DEINE Dienstleistung die du verkaufst - dann solltest du auch die Lösung kennen, oder? Ich würde das ganze mit nem simplen routing lösen. Je nachdem wieviele Server das sind sollte das wohl kaum 48h dauern...
es ist doch dein Kunde, es ist DEINE Dienstleistung die du verkaufst - dann solltest du auch die Lösung kennen, oder? Ich würde das ganze mit nem simplen routing lösen. Je nachdem wieviele Server das sind sollte das wohl kaum 48h dauern...
1
So ist das nicht lösbar, denn du willst ja die /16er Maske so nicht verändern bei den statischen Maschinen die du nicht anfassen willst.
Das geht dann nur wenn der Bereich der /24er Subnetze extern ist und sich nicht überschneidet mit dem /16er Netz. Dann könnte man zwischen diesem neuen /24 Kontingent und dem /16er Altnetz routen. Will man aber das /16er Subnetz so beibehalten geht das nicht oder nur bedingt.
Ein "Trick" wäre diese statischen Adressen zu belassen und die mit einer /17er Maske zu betreiben. Das geht aber nur wenn diese ALLE im /17er Netz liegen und du den 2ten Teil des /17ers dann in die /24er aufteilst.
Klingt etwas verwirrend aber dieser Thread erklärt dir wie es geht:
Aufsplittung Subnetz in VLANs
So oder so musst du da aber auch die Subnetzmaske anfassen auch wenn die IPs bestehen bleiben können. Um das kommst du nicht herum.
Das geht dann nur wenn der Bereich der /24er Subnetze extern ist und sich nicht überschneidet mit dem /16er Netz. Dann könnte man zwischen diesem neuen /24 Kontingent und dem /16er Altnetz routen. Will man aber das /16er Subnetz so beibehalten geht das nicht oder nur bedingt.
Ein "Trick" wäre diese statischen Adressen zu belassen und die mit einer /17er Maske zu betreiben. Das geht aber nur wenn diese ALLE im /17er Netz liegen und du den 2ten Teil des /17ers dann in die /24er aufteilst.
Klingt etwas verwirrend aber dieser Thread erklärt dir wie es geht:
Aufsplittung Subnetz in VLANs
So oder so musst du da aber auch die Subnetzmaske anfassen auch wenn die IPs bestehen bleiben können. Um das kommst du nicht herum.
Hi Christian,
wir reden über maximal 100 Server und 400 Clients. Ich würde auch mit den Clients beginnen, da ja in der Regel die Clients die Server ansprechen und die ja nach der Umstellung über die FW als Gateway laufen. Das blöde ist, der Kunde kennt seine Infrastruktur schlecht. Mir persönliche wäre es ja auch lieber, wenn die Server die neuen /24 Segmente auch in der lokalen Routingtabelle hätten. Man darf ja auch nicht vergessen, dass evtl. Group Policies etc. laufen und so seitens Server Kommunikation in Richtung Client läuft. Dafür muss der Server aber dann über die Firewall (neues GE), die ja dann das Netz "directly connected" kennt und das Regelwerk abarbeitet. Bei der grossen Netzmaske sehe ich das aber nur via loakelem Routingeintrag mit Angabe des neuen GW oder sehe ich das falsch?
Alles auf einen Schlag an einem Wochenende umzustellen ist mir zu gewagt. Besonders ein Grossrechner darf wärend der Business Zeit nicht den Dienst verweigern, sonst gibt es mächtig Probleme mit den Abläufen und wiederum deren Kunden.
Also nach und nach wäre uns recht und im Sinne des Kunden. Allerdings muss sichergestellt sein, dass die Kommunikation sauber läuft.
Wie gesagt ist das Problem nur die grosse Netzmaske mit/16 und somit das Ansprechen des def. GW bis alles umgestellt ist.
VG Locke
wir reden über maximal 100 Server und 400 Clients. Ich würde auch mit den Clients beginnen, da ja in der Regel die Clients die Server ansprechen und die ja nach der Umstellung über die FW als Gateway laufen. Das blöde ist, der Kunde kennt seine Infrastruktur schlecht. Mir persönliche wäre es ja auch lieber, wenn die Server die neuen /24 Segmente auch in der lokalen Routingtabelle hätten. Man darf ja auch nicht vergessen, dass evtl. Group Policies etc. laufen und so seitens Server Kommunikation in Richtung Client läuft. Dafür muss der Server aber dann über die Firewall (neues GE), die ja dann das Netz "directly connected" kennt und das Regelwerk abarbeitet. Bei der grossen Netzmaske sehe ich das aber nur via loakelem Routingeintrag mit Angabe des neuen GW oder sehe ich das falsch?
Alles auf einen Schlag an einem Wochenende umzustellen ist mir zu gewagt. Besonders ein Grossrechner darf wärend der Business Zeit nicht den Dienst verweigern, sonst gibt es mächtig Probleme mit den Abläufen und wiederum deren Kunden.
Also nach und nach wäre uns recht und im Sinne des Kunden. Allerdings muss sichergestellt sein, dass die Kommunikation sauber läuft.
Wie gesagt ist das Problem nur die grosse Netzmaske mit/16 und somit das Ansprechen des def. GW bis alles umgestellt ist.
VG Locke
Hallo Locke,
ich stelle fest, dass du für den Job nicht geeignet bist. Schon alleine die Aussage " der Kunde kennt seine Infrastruktur schlecht" sagt, dass du keine Vorbereitung in der Hinsicht getroffen hast - du musst die kennen, denn du willst die Infra umstellen. Es hilft nichts, wenn der Kunde die Infra kennt, du aber nicht.
100 Server ist nun, je nach System, überschaubar. Kommt natürlich auch darauf an, was darauf läuft.
VG
ich stelle fest, dass du für den Job nicht geeignet bist. Schon alleine die Aussage " der Kunde kennt seine Infrastruktur schlecht" sagt, dass du keine Vorbereitung in der Hinsicht getroffen hast - du musst die kennen, denn du willst die Infra umstellen. Es hilft nichts, wenn der Kunde die Infra kennt, du aber nicht.
100 Server ist nun, je nach System, überschaubar. Kommt natürlich auch darauf an, was darauf läuft.
VG
Hallo Aqui,
nein die IP Adressen überschneiden sich nicht. Und das Routen ist ja über die FW gewünscht. Bitte nicht falsch verstehen, die /16 soll ganz weg und auch die Maschinen sollen ALLE angefasst und die Masken geändert werden. Mein Problem ist, ich versuche es verständlicher zu erklären:
Clients aus dem Bereich zum Beispiel 10.1.3.X /16 (leider so aus der Histoire konfiguriert, auch wenn man die Hände überm Kopf zusammenschlagen möche), wandern ins neue Segment 10.1.3.x/24 mit 10.1.3.1 als GW (Firewall Interface). Die Server sind jetzt aber NOCH so konfiguriert 10.1.1.X/16 und möchetn z.B. die Clients 10.1.3.x/24 ansprechen. Der Server verlässt doch aufgrund seiner grossen /16 nicht sein Netz und spricht somit doch auch nicht das GW an. Das würde doch erst passieren, wenn die auch ins neue Segment wandern mit z.B. 10.1.1.X/24 und dem GW 10.1.1.1 also die FW. Dann würde die FW ja zwischen den beiden Netzen routen, wie es üblich ist.
Ich suche nur nach einer kleinen Übergangslösung.
Klar könnte ich den Servern per Script mit "Route ADD" einen loaklen Routingeintrag auf das Client Netz geben und als GW die neue FW. Frage ist, ob dies auch geschickter bzw. einfacher geht.
Am Ende sol
Vielen Dank und Grüße
Locke
nein die IP Adressen überschneiden sich nicht. Und das Routen ist ja über die FW gewünscht. Bitte nicht falsch verstehen, die /16 soll ganz weg und auch die Maschinen sollen ALLE angefasst und die Masken geändert werden. Mein Problem ist, ich versuche es verständlicher zu erklären:
Clients aus dem Bereich zum Beispiel 10.1.3.X /16 (leider so aus der Histoire konfiguriert, auch wenn man die Hände überm Kopf zusammenschlagen möche), wandern ins neue Segment 10.1.3.x/24 mit 10.1.3.1 als GW (Firewall Interface). Die Server sind jetzt aber NOCH so konfiguriert 10.1.1.X/16 und möchetn z.B. die Clients 10.1.3.x/24 ansprechen. Der Server verlässt doch aufgrund seiner grossen /16 nicht sein Netz und spricht somit doch auch nicht das GW an. Das würde doch erst passieren, wenn die auch ins neue Segment wandern mit z.B. 10.1.1.X/24 und dem GW 10.1.1.1 also die FW. Dann würde die FW ja zwischen den beiden Netzen routen, wie es üblich ist.
Ich suche nur nach einer kleinen Übergangslösung.
Klar könnte ich den Servern per Script mit "Route ADD" einen loaklen Routingeintrag auf das Client Netz geben und als GW die neue FW. Frage ist, ob dies auch geschickter bzw. einfacher geht.
Am Ende sol
Vielen Dank und Grüße
Locke
Habe ich noch vergessen, aber Aqui versteht es auch ohne den Beitrag.
Der loakle Eintrage auf das neue Client Netz mit /24 würde ja ziehen, da die kleinere Maske ja genauer ist als die /16er Route.
Der loakle Eintrage auf das neue Client Netz mit /24 würde ja ziehen, da die kleinere Maske ja genauer ist als die /16er Route.
Eins geht aber de facto nicht:
Du kannst natürlich niemals an einem Router oder Firewall an einem Interface das 10.1.0.0 /16 Netz haben (wozu natürlich auch 10.1.3.X /16 gehört) und dann gleichzeitig dort ein Interface mit 10.1.3.X /24 definieren.
Dann hast du nämlich genau die oben angesprochenen sich überschneidenen Adressräume !! Ein Routing ist damit völlig unmöglich, logisch !
Mal ganz davon abgesehen das sich sowas an einem Router/Firewall auch gar nicht konfigurieren lässt weil es sofort einen Fehler im Setup GUI provoziert durch die falsche IP Adressierung.
Was geht, ist das alte 10.1.0.0 /16 zu belassen und dann die neue Segmentierung auf 10.2.x.0 /24 mit den 24er Subnetzen zu legen. Das willst du aber ja genau nicht wenn du die 10.1.0.0 behalten willst.
Du hast dann nur die Option das alte Netz zu halbieren in ein /17 und eine der Hälften in die /24er zu teilen und hoffen das du die restlichen statischen Adressen dann alle in der einen oder anderen Hälfte hast.
So oder so musst du da aber auch die Subnetzmaske anfassen.
Eine Aufteilung des Netzes unter Beibehaltung der /16er Maske für das alte Netz ist technisch unmöglich.
Du kannst natürlich niemals an einem Router oder Firewall an einem Interface das 10.1.0.0 /16 Netz haben (wozu natürlich auch 10.1.3.X /16 gehört) und dann gleichzeitig dort ein Interface mit 10.1.3.X /24 definieren.
Dann hast du nämlich genau die oben angesprochenen sich überschneidenen Adressräume !! Ein Routing ist damit völlig unmöglich, logisch !
Mal ganz davon abgesehen das sich sowas an einem Router/Firewall auch gar nicht konfigurieren lässt weil es sofort einen Fehler im Setup GUI provoziert durch die falsche IP Adressierung.
Was geht, ist das alte 10.1.0.0 /16 zu belassen und dann die neue Segmentierung auf 10.2.x.0 /24 mit den 24er Subnetzen zu legen. Das willst du aber ja genau nicht wenn du die 10.1.0.0 behalten willst.
Du hast dann nur die Option das alte Netz zu halbieren in ein /17 und eine der Hälften in die /24er zu teilen und hoffen das du die restlichen statischen Adressen dann alle in der einen oder anderen Hälfte hast.
So oder so musst du da aber auch die Subnetzmaske anfassen.
Eine Aufteilung des Netzes unter Beibehaltung der /16er Maske für das alte Netz ist technisch unmöglich.
Ich mach gerade etwas Brainstorming:
Ein wird ein zweiter Router benötigt, temporär, bis alles umgestellt ist.
Der alte Router mit /16er Maske bleibt und spielt auch DHCP. Er ist mit dem Hauptswich verbunden.
Der Router erhält ein zweites Netz mit neuer IP außerhalb des Firmennetzes z.B. 172.0.0.0/24 und versorgt es mit dem Internet.
Das neue Gateway wird mit dem WAN Anschluss an das neue Netz des alten Routers gesteckt, daher holt es sich die Internet Daten.
Das neue Gateway bekommt 24er Netze auf mehrere Schnittstellen:
Schnittstelle 1: 10.10.1.1/24 sind für Server
Schnittstelle 2: 10.10.2.1/24 sind für Clients
Usw...
Alle Schnittstellen des Gateway (ausser WAN) sind ebenfalls mit dem Hauptswitch verbunden.
Das Gateway darf kein DHCP machen, das macht immer noch der alte Router.
Noch funktioniert die Kommunikation unverändert. Das neue Gateway kennt noch niemand, alles läuft über den alten Router.
Nun wird DHCP umgestellt. Alle DHCP Clients bekommen die /24 Maske und das neue Gateway, also die IP der Schnittstelle 2 zugewiesen. Der Client fragt nach einem Server, das sich nicht in seinem /24 Netz befindet. Das neue Gateway hört es auf der Schnittstelle 2 und routet es zu Schnittstelle 1 und es geht zum Switch zurück. Der Server hört es, hat noch seine /16 Maske und antwortet direkt über den Swich zum Client. Der Switch bekommt doppelten Traffic ab, aber STP dürfte nicht greifen, da im ersten Paket das Gateway als Ziel drinnen steht.
Sobald alle Server auf /24 umgestellt sind, funktioniert die gesamte Kommunikation nur noch über das neue Gateway und der alte Router hat keine Arbeit mehr Im /16er Netz. Dann kann aufgeräumt werden.
Ein wird ein zweiter Router benötigt, temporär, bis alles umgestellt ist.
Der alte Router mit /16er Maske bleibt und spielt auch DHCP. Er ist mit dem Hauptswich verbunden.
Der Router erhält ein zweites Netz mit neuer IP außerhalb des Firmennetzes z.B. 172.0.0.0/24 und versorgt es mit dem Internet.
Das neue Gateway wird mit dem WAN Anschluss an das neue Netz des alten Routers gesteckt, daher holt es sich die Internet Daten.
Das neue Gateway bekommt 24er Netze auf mehrere Schnittstellen:
Schnittstelle 1: 10.10.1.1/24 sind für Server
Schnittstelle 2: 10.10.2.1/24 sind für Clients
Usw...
Alle Schnittstellen des Gateway (ausser WAN) sind ebenfalls mit dem Hauptswitch verbunden.
Das Gateway darf kein DHCP machen, das macht immer noch der alte Router.
Noch funktioniert die Kommunikation unverändert. Das neue Gateway kennt noch niemand, alles läuft über den alten Router.
Nun wird DHCP umgestellt. Alle DHCP Clients bekommen die /24 Maske und das neue Gateway, also die IP der Schnittstelle 2 zugewiesen. Der Client fragt nach einem Server, das sich nicht in seinem /24 Netz befindet. Das neue Gateway hört es auf der Schnittstelle 2 und routet es zu Schnittstelle 1 und es geht zum Switch zurück. Der Server hört es, hat noch seine /16 Maske und antwortet direkt über den Swich zum Client. Der Switch bekommt doppelten Traffic ab, aber STP dürfte nicht greifen, da im ersten Paket das Gateway als Ziel drinnen steht.
Sobald alle Server auf /24 umgestellt sind, funktioniert die gesamte Kommunikation nur noch über das neue Gateway und der alte Router hat keine Arbeit mehr Im /16er Netz. Dann kann aufgeräumt werden.
Das habe sogar ich verstanden! 
Na ja, du nimmst dann aber auch für die neue /24er Struktur ein komplett neues IP Netz. Das das dann ganz einfach funktioniert ist klar, dafür bräuchte es dann diesen Thread hier auch gar nicht, denn dieses IP Netz kann man ja parallel auf Router oder Firewall einrichten und dann sanft Schritt für Schritt im laufenden Betrieb migrieren.
Diese Klimmzüge mit extra Router wären dann völlig überflüssig und müsste man nicht machen. Das ginge dann auch so direkt wenn man dem Router oder FW der jetzt das /16er Altnetz routet diese neuen IPs einfach anhängt.
Das wäre der klassische Weg wie es jeder machen würde bei einer solchen Migration, genau nämlich deswegen weil man eben sowas langsam Stück für Stück im laufenden Betrieb machen kann.
Diese kleinen Migrationsschritte minimieren so dann auch das Ausfallrisiko weill man dann einfach zurückstekcne kann sollte dennoch mal was nicht klappen. Wie bereits gesagt, der ideale Weg aber eben mit einer ganz neuen IP Range.
Versteht man den TO aber im Ursprungsthread oben richtig, sollte es ja eben nicht mit einer neuen IP Netz Adresse gemacht werden sondern die alte 10.4.0.0 /16 er Adresse beibehalten werden und diese nur in /24er Segmente aufgeteilt werden. Und eben DAS geht so dann parallel eben wegen der Überschneidung nicht ohne das Altnetz zu unterteilen.
Wenn man parallel die neue /24er Struktur in einem neuen 10.5.0.0 /16er Subnetz Segment aufbaut ist das dann natürlich problemlos parallel möglich, keine Frage.
Aber für solche Binsenweisheit bräuchte man diesen Thread und auch einen Zusatzrouter gar nicht !!
Diese Klimmzüge mit extra Router wären dann völlig überflüssig und müsste man nicht machen. Das ginge dann auch so direkt wenn man dem Router oder FW der jetzt das /16er Altnetz routet diese neuen IPs einfach anhängt.
Das wäre der klassische Weg wie es jeder machen würde bei einer solchen Migration, genau nämlich deswegen weil man eben sowas langsam Stück für Stück im laufenden Betrieb machen kann.
Diese kleinen Migrationsschritte minimieren so dann auch das Ausfallrisiko weill man dann einfach zurückstekcne kann sollte dennoch mal was nicht klappen. Wie bereits gesagt, der ideale Weg aber eben mit einer ganz neuen IP Range.
Versteht man den TO aber im Ursprungsthread oben richtig, sollte es ja eben nicht mit einer neuen IP Netz Adresse gemacht werden sondern die alte 10.4.0.0 /16 er Adresse beibehalten werden und diese nur in /24er Segmente aufgeteilt werden. Und eben DAS geht so dann parallel eben wegen der Überschneidung nicht ohne das Altnetz zu unterteilen.
Wenn man parallel die neue /24er Struktur in einem neuen 10.5.0.0 /16er Subnetz Segment aufbaut ist das dann natürlich problemlos parallel möglich, keine Frage.
Aber für solche Binsenweisheit bräuchte man diesen Thread und auch einen Zusatzrouter gar nicht !!
Zitat von @aqui:
Na ja, du nimmst dann aber auch für die neue /24er Struktur ein komplett neues IP Netz.
Na ja, du nimmst dann aber auch für die neue /24er Struktur ein komplett neues IP Netz.
Versteht man den TO aber im Ursprungsthread oben richtig, sollte es ja eben nicht mit einer neuen IP Netz Adresse gemacht werden sondern die alte 10.4.0.0 /16 er Adresse beibehalten werden
Ach, doch, ich meinte schon das gleiche Netz. Ich bin nur nicht seinem alten Netz gefolgt (hab auf die schnelle seine IPs nicht gesehen) und habe mir Beispiel IPs ausgedacht.
Der alte Router bleibt also auf 10.4.0.0/16
Der neue Router bekommt
10.4.1.0 auf /24 und
10.4.2.0 auf /24
Der neue Router ist dafür da damit der alte Router keine Überschneidung seines 16er Netzes bekommt und die 172er Verbindung ist dafür da, dass der neue Router nicht meckert, dass seine LAN und WAN Seite die gleichen IPs verwenden, damit der neue Router ins Internet kommt.
Wird in der Firma das Netz am WE der Umstellung benötigt ?
Die Clients via DHCP alle umzustellen sollte wohl kein Problem darstellen.
Die Drucker werden hoffentlich auch über DHCP versorgt.
Bleiben 100 Server die umgestellt werden müssen. Wie viele Standorte und wie viel Manpower? Da es sicherlich um keine Server handelt die nach Änderung der IP neu booten müssen, sollte das doch sicherlich zu stemmen sein.
Die Clients via DHCP alle umzustellen sollte wohl kein Problem darstellen.
Die Drucker werden hoffentlich auch über DHCP versorgt.
Bleiben 100 Server die umgestellt werden müssen. Wie viele Standorte und wie viel Manpower? Da es sicherlich um keine Server handelt die nach Änderung der IP neu booten müssen, sollte das doch sicherlich zu stemmen sein.
Das ist doch Unsinn, das kann doch niemals funktionieren. Denk doch mal selber etwas nach !
Endgeräte im Altnetz die dann dann ein neues Endgerät im 10.4.2.x /24er Netz erreichen wollen, wie sollte das denn gehen ?? Das musst du der Community hier dann mal erklären.
So ein Endgerät im Altnetz "denkt" doch die 10.4.2.x ist in seinem lokalen Netz und ARPt noch nicht einmal nach dem Router sondern das Endgerät direkt. Klar es ja ein Endgerät im lokalen Netz aus seiner netzsicht mit 16 Bit.
Der Router wird also noch nicht einmal erkannt. Wie auch mit einer inkonsistenten Subnetz Maske. Sowas ist noch nicht einmal erlaubt.
Sorry, aber der Vorschlag ist doch kompletter Blödsinn und kann niemals klappen !
Geräte im Altnetz mit /16er Maske haben doch gar keine Ahnung das irgendwo was steht was das gleiche IP Netz weiter subnettet.
Mal ganz abgesehen von der Überschneidung der IP Adressen die dann sofort einen Konfig Fehler in einem Gerät (Router, Firewall) erzeugen würde, würde man versuchen den Unsinn zu konfigurieren.
Wenns so einfach wäre....
Das Netzwerk ist falsch designed und soll richtigerweise in VLANs geteilt werden um die L2 Broadcast Domains entsprechend klein zu halten und das Netzwerk damit an sich performant. Technisch ja auch ein absolut richtiger und sehr vernünftiger Weg. Nur geht es eben nicht so einfach wenn man das alte /16er IP Netz behalten will in einer neuen /24er Aufteilung.
Endgeräte im Altnetz die dann dann ein neues Endgerät im 10.4.2.x /24er Netz erreichen wollen, wie sollte das denn gehen ?? Das musst du der Community hier dann mal erklären.
So ein Endgerät im Altnetz "denkt" doch die 10.4.2.x ist in seinem lokalen Netz und ARPt noch nicht einmal nach dem Router sondern das Endgerät direkt. Klar es ja ein Endgerät im lokalen Netz aus seiner netzsicht mit 16 Bit.
Der Router wird also noch nicht einmal erkannt. Wie auch mit einer inkonsistenten Subnetz Maske. Sowas ist noch nicht einmal erlaubt.
Sorry, aber der Vorschlag ist doch kompletter Blödsinn und kann niemals klappen !
Geräte im Altnetz mit /16er Maske haben doch gar keine Ahnung das irgendwo was steht was das gleiche IP Netz weiter subnettet.
Mal ganz abgesehen von der Überschneidung der IP Adressen die dann sofort einen Konfig Fehler in einem Gerät (Router, Firewall) erzeugen würde, würde man versuchen den Unsinn zu konfigurieren.
Wenns so einfach wäre....
Wie viele Standorte und wie viel Manpower?
Die Frage ist ja auch sinnfrei wenn es nur ein einziges /16er Netz ist in dem die Server und der gesamte Rest stehen. Sowas wie "Standorte" kanns ja dann wohl kaum geben. Der TO redet davon ja logischerweise auch nicht.Das Netzwerk ist falsch designed und soll richtigerweise in VLANs geteilt werden um die L2 Broadcast Domains entsprechend klein zu halten und das Netzwerk damit an sich performant. Technisch ja auch ein absolut richtiger und sehr vernünftiger Weg. Nur geht es eben nicht so einfach wenn man das alte /16er IP Netz behalten will in einer neuen /24er Aufteilung.
Die müssen doch gar nicht unterscheiden.
Ein Client im Altnetz hat z.B. die 10.4.7.45 und will auf den 10.4.1.4 zugreifen. Durch seine 16er Maske im Altnetz schickt er das Paket einfach über seine Schnittstelle raus. Der Server hängt ja auch am Switch, also hört er es.
Ein Client im Neunetz hat z.B. die 10.4.2.45 und will auf den 10.4.1.4 zugreifen. Im Neunetz hat er die 24er Maske und schickt das Paket zum neuen Gateway. Das Gateway hört es und schickt es weiter auf Schnittstelle 1. Dann hört es der Server wieder.
Bedenke, es läuft ja sowieso alles wieder auf den Hauptswitch. Es kann sich also kein Paket verirren.
Ein Client im Altnetz hat z.B. die 10.4.7.45 und will auf den 10.4.1.4 zugreifen. Durch seine 16er Maske im Altnetz schickt er das Paket einfach über seine Schnittstelle raus. Der Server hängt ja auch am Switch, also hört er es.
Ein Client im Neunetz hat z.B. die 10.4.2.45 und will auf den 10.4.1.4 zugreifen. Im Neunetz hat er die 24er Maske und schickt das Paket zum neuen Gateway. Das Gateway hört es und schickt es weiter auf Schnittstelle 1. Dann hört es der Server wieder.
Bedenke, es läuft ja sowieso alles wieder auf den Hauptswitch. Es kann sich also kein Paket verirren.
Ein Client im Altnetz hat z.B. die 10.4.7.45 ....
OK das ist der Verlauf einer klassischen IP Kommunikation. Das ist zweifelsohne richtig.Ein Client im Neunetz hat z.B. die 10.4.2.45....
Und hier ist dein fataler Denkfehler !Im Neunetz hat er die 24er Maske und schickt das Paket zum neuen Gateway.
Das ist noch richtig und korrekt.Das Gateway hört es und schickt es weiter auf Schnittstelle 1.
Und hier geht es jetzt los !- Schnittstelle 1 ist gar nicht so konfigurierbar mit einer /16er Adresse, denn das Gateway würde sofort einen Konfig Fehler detektieren, denn dein 10.4.2.45 /24 Host Segment liegt im gleichen Netzwerk wie Schnittstelle 1, überschneidet sich also und ergibt einen Syntax bzw. Adress Konfig Error.
- Gesetzt den Fall du findest ein dummes Gateway das solche falsche Konfig zulässt oder konfigurierst die Altnetz Schnittstelle bewusst falsch mit einer /24er Maske und hängst sie ins /16er Netz. Was passiert dann:
- 1.) Schnittstelle 1 hat dann z.B. die Adresse 10.4.200.1 /24. Die könnte dann aber niemals auf den Server 10.4.1.4 zugreifen da keine Route dafür vorhanden. Das Packet wird sofort verworfen. Scheitert also sofort.
- 2.) Schnittstelle 1 hat z.B. die Adresse 10.4.1.1 mit falscher Maske /24. Dann ARPt das Gateway nach dem Server und würde den auch erreichen. Eine Verbindung kommt dann auch nicht zustande.
Im Paket das der Router dann an den Server schickt steht ja als Absender die IP 10.4.2.45 an die der Server das Antwort IP Paket senden muss. Der Server hat die Mac Adresse dafür aber nicht und muss danach ARPen. Er denkt das es im lokalen Netz ist und ARPt also danach. Aber niemand antwortet auf den ARP....
Folglich wird auch das Paket verworfen bzw. timed aus.
Auch wenn aus dem Server z.B. durch eine längere Pause der ARP Cache gelöscht ist müsste er neu nach dem Host 10.4.2.45 ARPen, was er dann auch tut. Das dann aber mit einer /16er Maske und der Router würde logischerweise niemals antworten darauf. Dann stirbt die Kommunikation.
Abgesehen das so eine Konfig mit nicht konsistenten Masken nicht Standard konform ist und natürlich auch aus den o.g. Gründen nicht supportet scheitert auch so eine Kommunikation.
Eine klare Sackgasse also und auch erwartbar bei solch falscher IP Adressierung.
Lass dir doch einfach mal den IP Paket Flow durch den Kopf gehen dann ist es doch klar das sowas scheitern muss.
Wenn du es dennoch nicht glaunst stell das mit einem kleinen Router mal nach. Ist ja schnell gemacht und Wireshark wird dir dann die Augen öffnen...
Ja, das mit dem Arp muss ich nochmal genauer durchdenken. Bei der Überlegung bin ich rein von IP Adressen ausgegangen. Die Layer arbeiten aber über MAC.
So ist es und das sollte man nie vergessen...!
Hallo Aqui,
vielen Dank für Deine Hilfe. Ja ich muss Dir hier Recht geben. Geplant war es mal im 2. Octet zu springen, um dem aus dem Weg zu gehen, allerdings gab es hier seitens Kunde viel Angst mit einer Kernanwendung die auch noch statisch auf Drucker zugreift. Und nein die Drucker sind auch statisch konfiguriert. Hier könnte man aber ja mit Reservierungen auf dem DHCP vorbereitend arbeiten (im neuen Segment).
Aber wie Du schon gesagt hast ist das Routing zwischen dem alten grossen Segment und den neuen Segmenten so nicht machbar. Ich muss ja den neuen Segmenten den Zugriff auf alte /16 IP bereich geben, sonst können diese ja nichts mehr im alten Netz erreichen.
Ich werde hier nochmals das Whiteboard befüllen und aufmahlen. Dann ist weiteres Brainstorming angesagt.
Ich danke schon mal für die konstruktive Unterstützung hier.
Ich berichte natürlich später über den weiteren Verlauf.
Danke und viele Grüße
Locke
vielen Dank für Deine Hilfe. Ja ich muss Dir hier Recht geben. Geplant war es mal im 2. Octet zu springen, um dem aus dem Weg zu gehen, allerdings gab es hier seitens Kunde viel Angst mit einer Kernanwendung die auch noch statisch auf Drucker zugreift. Und nein die Drucker sind auch statisch konfiguriert. Hier könnte man aber ja mit Reservierungen auf dem DHCP vorbereitend arbeiten (im neuen Segment).
Aber wie Du schon gesagt hast ist das Routing zwischen dem alten grossen Segment und den neuen Segmenten so nicht machbar. Ich muss ja den neuen Segmenten den Zugriff auf alte /16 IP bereich geben, sonst können diese ja nichts mehr im alten Netz erreichen.
Ich werde hier nochmals das Whiteboard befüllen und aufmahlen. Dann ist weiteres Brainstorming angesagt.
Ich danke schon mal für die konstruktive Unterstützung hier.
Ich berichte natürlich später über den weiteren Verlauf.
Danke und viele Grüße
Locke
Hi,
ich habe mir jetzt zwar nicht alles durchgelesen, aber ich würde dies anders lösen, um nach und nach die Endgeräte in das richtige VLAN zu setzen.
Das bisherige Netz lautet 10.4.0.0/16 GW sagen wir mal 10.4.0.1
Dann würde ich VLANs anlegen und mit 10.5.0.0/24, 10.5.1.0/24, 10.5.2.0/24 usw. anfangen
Routing zwischen den Netzen 10.4.0.0/16 und den 24er Subnetzen anlegen.
Notfalls ein Transfernetz anlegen...
DHCP Bereiche auf dem DHCP Server anlegen
Und nun nach und nach die Server Drucker usw in die jeweiligen VLANs nehmen.
Dies kann der Kunde dann auch immer mal machen, wenn er Zeit findet.
LG
Patrick
ich habe mir jetzt zwar nicht alles durchgelesen, aber ich würde dies anders lösen, um nach und nach die Endgeräte in das richtige VLAN zu setzen.
Das bisherige Netz lautet 10.4.0.0/16 GW sagen wir mal 10.4.0.1
Dann würde ich VLANs anlegen und mit 10.5.0.0/24, 10.5.1.0/24, 10.5.2.0/24 usw. anfangen
Routing zwischen den Netzen 10.4.0.0/16 und den 24er Subnetzen anlegen.
Notfalls ein Transfernetz anlegen...
DHCP Bereiche auf dem DHCP Server anlegen
Und nun nach und nach die Server Drucker usw in die jeweiligen VLANs nehmen.
Dies kann der Kunde dann auch immer mal machen, wenn er Zeit findet.
LG
Patrick
Ich denke auch, dass Locke das Pferd falsch herum aufzäumt.
Die Stolpersteine werden offensichtlich ja nicht besser.
Die Stolpersteine werden offensichtlich ja nicht besser.
Aber wie Du schon gesagt hast ist das Routing zwischen dem alten grossen Segment und den neuen Segmenten so nicht machbar.
Das stimmt ja so nicht oder du hast die obige Diskussion nicht gelesen oder verstanden. So ist es ja nicht gesagt....Machbar ist es schon, es bedeutet aber einen höheren Aufwand und Nachteile als wenn du in einen /24er Bereich mit einem neuen 2ten Oktet migrierst.
Du hast dann eine längere Downtime, weil du mehr zu tun hast und du hast das Damoklesschwert das du es in der Downtime zwingend umsetzen musst.
Du bringst dich mit der Beibehaltung der IP Adressierung also um die Option langsam und sukzessive zu migrieren.
Gerade im Hinblick auf diese statische Drucker Applikation wäre das einer der Hauptpunkte diesen Weg eben nicht zu gehen und eine sanfte Migration zu machen.
Das würde ja auch explizit den Kundenwünschen entsprechen, denn so kannst du das Altnetz so belassen wie es ist und nimmst dann erstmal sukzessive alle einfach zu migrierenden Clients, Server und Hardware raus in die neuen /24er Segmente. Das kannst du dann in mehreren Sessions Schritt für Schritt machen ohne das du das Altnetz anfassen musst. Alles rennt weiter wie gehabt nur das aus dem Altnetz nach und nach die Geräte rausgehen in die neue Infrastruktur. Das geht alles parallel und sogar im laufenden Betrieb wenn erforderlich.
Mehr Freiheiten kann man doch bei einer Migration gar nicht haben.... Sollte etwas bei der schrittweisen Migration mal nicht klappen (was sehr unwahrscheinlich ist) hast du immer die Option alles schnell wieder ins Altnetz zurückzustecken.
Das machst du dann soweit bis nur noch die wenigen harten Restkandidaten im Altnetz vorhanden sind. Für die gibt es dann eine letzte Downtime wo du ihnen entweder im Altnetz nur eine neue /24er Maske setzt unter Beibehaltung der IP Adresse oder indem du sie dann auch auf die neue /24er IP Adressierung bzw. in ihre dortigen Segmente migrierst.
Da diese neue Infrastruktur ja schon parallel koexistiert hast du sogar alle Optionen diese statische Druckeranwendung auch schon im neuen Bereich mal vorab wasserdicht zu testen um ggf. Probleme bei der Migration vorab zu eliminieren !
Fazit:
Es spricht also alles dafür parallel zum Altnetz deine neue Struktur mit z.B. 10.5.x.y /24 anzulegen und loszulegen !! Es ist ja alles bei dir vorhanden um das schnell und einfach umzusetzen.
Hallo Certified.
Sag doch nicht immer, cih würde das nicht verstehen oder das Pferd falsch ehrum aufzäumen, Du kennst doch die Verhältnisse gar nicht.
Es war anfangs geplant im zweiten Octet zu springen von 10.1.0.0/16 auf 10.2.0.x/24, dann hätten wir alle Probleme nicht.
Die Stolpesteine kamen vom Kunden und man versucht ja immer möglichst kundenfreundlich und smart zu agieren. In dem Fall gibt es wohl keine andere Lösung. Und noch mal extra für Dich, der Kunde hat kaum ManPower, und mega Angst vor der Segmentierung.
Das iwderspricht sich mit dem Auftrag ganz klar, hatte ich denne auch gesagt, ist aber erst nunmal so.
Nächste Woche gibt es klärende Gespräche dazu, kurz gesagt "take it or leave it".
WICHTIG: Ich danke allen für die nette Hilfe und das Brainstorming.
@cerrtified, warum bist Du hier im Portal? Nimm es nicht persönlich, aber ich habe den Eindruck, dass Du gar nicht helfen möchtest. Du wirfst mir vor ich sei nicht geeignet, hast aber bisher noch nicht ein schlaues Wörtchen abgegeben. Ich finde das in bisschen schwach, aber auch Dir trotzdem Danke für Dein Feedback.
@ Aqui: Kompliment. Immer gestochen scharf und auf den Punkt. Eine grosse Bereicherung hier.
Ich berichte gerne wie wir mit dem Kunde verblieben sind.
Viele Grüße
Locke
Sag doch nicht immer, cih würde das nicht verstehen oder das Pferd falsch ehrum aufzäumen, Du kennst doch die Verhältnisse gar nicht.
Es war anfangs geplant im zweiten Octet zu springen von 10.1.0.0/16 auf 10.2.0.x/24, dann hätten wir alle Probleme nicht.
Die Stolpesteine kamen vom Kunden und man versucht ja immer möglichst kundenfreundlich und smart zu agieren. In dem Fall gibt es wohl keine andere Lösung. Und noch mal extra für Dich, der Kunde hat kaum ManPower, und mega Angst vor der Segmentierung.
Das iwderspricht sich mit dem Auftrag ganz klar, hatte ich denne auch gesagt, ist aber erst nunmal so.
Nächste Woche gibt es klärende Gespräche dazu, kurz gesagt "take it or leave it".
WICHTIG: Ich danke allen für die nette Hilfe und das Brainstorming.
@cerrtified, warum bist Du hier im Portal? Nimm es nicht persönlich, aber ich habe den Eindruck, dass Du gar nicht helfen möchtest. Du wirfst mir vor ich sei nicht geeignet, hast aber bisher noch nicht ein schlaues Wörtchen abgegeben. Ich finde das in bisschen schwach, aber auch Dir trotzdem Danke für Dein Feedback.
@ Aqui: Kompliment. Immer gestochen scharf und auf den Punkt. Eine grosse Bereicherung hier.
Ich berichte gerne wie wir mit dem Kunde verblieben sind.
Viele Grüße
Locke
Sorry für die Tippfehler
Ich berichte gerne wie wir mit dem Kunde verblieben sind.
Wir sind sehr gespannt ! Und...du musst keinerlei Angst vor dieser Segmentierung haben. Es ist in jedem Falle der richtige und vernünftige Weg und wenn der Kunde einem neuen Segment zustimmt ist das eine sehr einfache Nummer und kann eben wie bereits oben mehrfach gesagt sanft und parallel um Tagebetrieb erfolgen !
Hallo Aqui, nein habe keine Angst davor. Bin jetzt auch nicht ganz neu im Geschäft. Manchmal steht man auch etwas auf der Leitung.
Wenn der Kunde mitspielt, ist das nichts wildes. Hier haben wir den Fehler gemacht und nicht direkt gesagt, geht nicht, sondern nach ner Lösung gesucht und hier etwas in die Sackgasse gelaufen. Aber man lernt ja immer dazu.
Blöd sind dann nur Dinge wie über 100 Drucker statisch konfiguriert, als hätten die keinen DHCP der ja auch IP's reservieren kann, aber egal.
Machs gut und bis nächste Woche.
Wenn der Kunde mitspielt, ist das nichts wildes. Hier haben wir den Fehler gemacht und nicht direkt gesagt, geht nicht, sondern nach ner Lösung gesucht und hier etwas in die Sackgasse gelaufen. Aber man lernt ja immer dazu.
Blöd sind dann nur Dinge wie über 100 Drucker statisch konfiguriert, als hätten die keinen DHCP der ja auch IP's reservieren kann, aber egal.
Machs gut und bis nächste Woche.
Man könnte die Drucker ja im Vorfeld auf DHCP umstellen und die IP alten Adressen reservieren. Erst, wenn alle Geräte auf DHCP stehen, kann man dann die Umstellung starten.
..oder die 3 Azubis einspannen die das als dedizierte Einzelaufgabe bekommen die zu migrieren
Alles eine Frage der Manpower
Alles eine Frage der Manpower
Zitat von @Locke2016:
Hallo Certified.
Sag doch nicht immer, cih würde das nicht verstehen oder das Pferd falsch ehrum aufzäumen, Du kennst doch die Verhältnisse gar nicht.
Hallo Certified.
Sag doch nicht immer, cih würde das nicht verstehen oder das Pferd falsch ehrum aufzäumen, Du kennst doch die Verhältnisse gar nicht.
Das ist witzig, das zu sagen, nachdem du uns ja quasi als Planende Institution eingebunden hast, sagst du uns, dass wir die Verhältnisse nicht kennen? Das mag ich.
Es war anfangs geplant im zweiten Octet zu springen von 10.1.0.0/16 auf 10.2.0.x/24, dann hätten wir alle Probleme nicht.
Warum hast du es nicht getan?
Die Stolpesteine kamen vom Kunden und man versucht ja immer möglichst kundenfreundlich und smart zu agieren. In dem Fall gibt es wohl keine andere Lösung. Und noch mal extra für Dich, der Kunde hat kaum ManPower, und mega Angst vor der Segmentierung.
Kundenfreundliches unmögliches möglich zu machen sollte man in dem Job als erstes sein lassen, außer, man nennt sich Marketing. Fällt aber dann wieder uns (also dem Administrator.de Forum) auf die Füße...
Das iwderspricht sich mit dem Auftrag ganz klar, hatte ich denne auch gesagt, ist aber erst nunmal so.
Nun, dann musst du das durchbringen oder eben weiteres externes Personal hin zu ziehen.
Nächste Woche gibt es klärende Gespräche dazu, kurz gesagt "take it or leave it".
WICHTIG: Ich danke allen für die nette Hilfe und das Brainstorming.
@certifiedit.net, warum bist Du hier im Portal? Nimm es nicht persönlich, aber ich habe den Eindruck, dass Du gar nicht helfen möchtest. Du wirfst mir vor ich sei nicht geeignet, hast aber bisher noch nicht ein schlaues Wörtchen abgegeben. Ich finde das in bisschen schwach, aber auch Dir trotzdem Danke für Dein Feedback.
WICHTIG: Ich danke allen für die nette Hilfe und das Brainstorming.
@certifiedit.net, warum bist Du hier im Portal? Nimm es nicht persönlich, aber ich habe den Eindruck, dass Du gar nicht helfen möchtest. Du wirfst mir vor ich sei nicht geeignet, hast aber bisher noch nicht ein schlaues Wörtchen abgegeben. Ich finde das in bisschen schwach, aber auch Dir trotzdem Danke für Dein Feedback.
Ich hab mal den Namen korrigiert, ist nicht so schwer.
Zum Warum, ich bin hier tatsächlich um zu helfen, aber bei dir schreit in vielen Punkten das "eigentlich bin ich nicht fit genug in der Materie" heraus. Ob du dir also alleine (insbesondere anscheinend in planender und umsetzender Funktion) zutrauen solltest, stelle ich daher zur Disposition, vielleicht hat der Kunde auch genau deswegen Angst. - Weil er deine bemerkt, ist ein wenig wie mit Tieren (nicht negativ gemeint). Und aus deinen Nachrichten ergibt sich (fast) jedes mal ein neues Problem und die Aussage, dass du damit (noch) nicht klar kommst.(-> erstmal "trocken üben" musst...). Wenn du das nicht als Hilfe ansiehst, sei es so, ich hab schon oft genug hingefrickelte Netze flicken müssen und mich gewundert...
@ Aqui: Kompliment. Immer gestochen scharf und auf den Punkt. Eine grosse Bereicherung hier.
Ich berichte gerne wie wir mit dem Kunde verblieben sind.
Viele Grüße
Locke