Netzwerk von C auf B umstellen

Hallo zusammen,

hab hier ein C-Netzwerk (192.168.1.X), welches etwas an seine Grenzen kommt. Außerdem bin ich Fan davon anhand der IP zu erkennen, welches Gerät da dran hängt (.1.X = fixe IPs - also Server, Router, Switche, Drucker, .2.X = PCs, .3.X = Laptops .... so in der Art).

Sollte doch jetzt einfach möglich sein, die fix vergebenen Subnetzmasken bei Servern, Routern ... auf /16 umzustellen und im DHCP entsprechend verteilen zu lassen.

Oder gibts da einen Haken?

Gibt keine nennenswerten Besonderheiten. Zwei DCs, ein Fileserver, ein Exchange. Das VPN für die Homeoffice-User sollte auch ohne Probleme funktionieren.

Wenn sich jemand fragt, wie der DHCP zwischen PC und Laptop unterscheidet - ich arbeite gerne mit Reservierungen. Der PC30 hat dann die IP 192.168.2.30. Hört sich im ersten Moment umständlich an (ist es auch, wenn man es nacharbeiten wollte), aber wenn ein neuer PC reinkommt, muss der sowieso eingerichtet und in der Domäne entsprechend verortet werden. Da kommts da auch nicht mehr drauf an. Er hat ja ne IP bekommen, da kann man die Mac-Adresse kopieren und in den DHCP-Reservierungen einfügen - nur die IP muss eintragen werden. Der zusätzliche Aufwand hält sich echt in Grenzen, aber wenn eine IP-Adresse irgendwie auffällt, weiß ich sofort was/wer das ist und wo das Gerät steht. Ich würde das hier nicht nachträglich abarbeiten, sondern einfach ab jetzt so machen, dann ist das Thema in zwei, drei Jahren von alleine durch.

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

Content-ID: 7674926189

Url: https://administrator.de/forum/netzwerk-von-c-auf-b-umstellen-7674926189.html

Ausgedruckt am: 22.12.2024 um 08:12 Uhr

14 Kommentare

Neuester Kommentar

Moin,

ein /16'er Netz würde ich dir nicht empfehlen. Mach lieber mehrere /24'er, dann hast du alles sauber getrennt und kannst die Segmente ggfs auch noch mit ACLs abschotten.

lg,
Slainte

hab hier ein C-Netzwerk

Klassen sind tiefstes Netzwerk Neandertal und gibt es im Zeitalter von modernen CIDR Netzen schon seit mehr als 30 Jahren! nicht mehr!
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing

Bleibt nur noch die goldene Netzwerker Regel fürs Adress Design zu zitieren das eine L2 Broadcast Domain niemals mehr als 150 Clients (plus/minus) enthalten sollte. Andernfalls ist es immer besser zu segmentieren! (VLANs etc.)
Kollege @SlainteMhath ja schon alles gesagt zu dieser Thematik.

An IPv6 denkt niemand?
Naja, sind ja noch ein paar Jahrzente, bis dahin

eine Grandiose Idee. Offensichtlich kommst du aber nicht aus der Industrie (gut, ich weiss auch nicht, ob der TO aus der Industrie kommt...), aber wenn du einen Maschinenfuhrpark hast, ist die Chance, dass die mit IPv6 umgehen können, verschwindend gering.

Wie schon gesagt:
Alles auf VLANs umstellen und brav segmentieren:

Infrastruktur
Drucker
Server
Clients
Gäste
...

Wenn sich jemand fragt, wie der DHCP zwischen PC und Laptop unterscheidet - ich arbeite gerne mit Reservierungen.

Wer keine ARbeit hat, macht sich welche.
Für die Clients sollten IPs Schall und Rauch sein. FQDN ist wichtig und wenn DNS und DHCP sauber eingerichtet sind... Obendrein noch an die Lease-Dauer denken. 12-24h reichen dicke.
Dann hast du auch wieder freie IPs, wenn Mitarbeiter im Urlaub sind oder die Laptops außer Haus verweilen... Du blockierst dir doch unnötig IPs.

Abgeschottet/getrennt werden muss nichts. Das hört sich nach viel mehr an, als es ist. Es gibt viele Arbeitsplatzdrucker und noch mehr Labeldrucker, einige netzwerkfähige Sensoren (alleine 20 Temperatursensoren bei Kühlschränken, einige Rauchmelder, Drucküberwachung für CO2 und O2 und sowas). Jetzt sollen noch Sensoren für Wasser (bei auslaufendem Wasser) dazu kommen. Da werden die IP-Adressen eben knapp.

Laptops und PCs sind gar nicht soooo viele.

Trotzdem würde ich kleinere Netze wählen und sie dann per inter vlan routing verbinden.

Das kannst du dann auch für 192.168.x.x und 10.x.x.x gemischt machen, die alten IP Adressen müssen deswegen nicht geändert werden.

Bei Wassermeldern, Rauchmeldern, Drucksensoren usw stelle ich mir die Frage, wo die Anforderung dafür herkommt. Aus Spaß macht man das ja nicht. Entweder ist das eine Anforderung für eine Zertifizierung oder die GF hat einen Hang zu business continuity - beides natürlich gut. Aber aus beiden Richtungen sehe ich auch entsprechende Netzwerksegmentierung um die Ecke taumeln.

Teils, Teils. Rauchmelder sind vorgeschrieben, die Drucksensoren sind notwendig (sind ein paar Labore dabei), weil CO2 und O2 benötigt wird. Ist schon passiert, dass am Wochenende der Druck abgefallen ist und es keiner gemerkt hat. Daher jetzt mit Alarm. Wasser gab es vor Kurzem ein größeres Problem. Im Stockwerk drüber ist ein Wasserrohr geplatzt - natürlich auch am Wochenende. Ist nur aufgefallen, weil das Wasser in den Büros oben drüber einen Kurzsschluss ausgelöst hat und die Sicherung der Alarmanlage und/oder der Zugangskontrolle rausgeflogen ist.

Erst als der Sicherheitsdienst hinkam um nach dem Strom zu schauen und ihm das Wasser über die Treppe entgegenlief "wie ein Wasserfall" (Zitat), wurde unser Chef alarmiert. Bei uns ist nix passiert - Boden nass, aber nix kaputt gegangen.

Trotzdem soll sowas jetzt komplett mit abgesichert werden. Und da wir ca. 800qm Fläche haben, braucht es schon einige Sensoren.

Aber die Idee, die ganzen Sensoren einfach über ein zweites LAN abzubilden ist gar nicht schlecht - da greift sowieso keiner drauf zu.

Ähhh, also hier bei uns|mir sind IPv6 schon Realität. Wer heutzutage noch auf Klassen bei IPv4 setzt, ist vermutlich schon länger in einer Zeitschleife gefangen.

Wer heutzutage noch auf Klassen bei IPv4 setzt, ist vermutlich schon länger in einer Zeitschleife gefangen.

Die Klassen selbst dienen nur der Bezeichnung / Beschreibung. Es reicht wenn man weiss welche IP Bereiche für die interne Kommunikation vorgesehen sind, die man verwenden kann. IPv4 ist immer noch bei einiger Hardware die einzig mögliche Kommunikation, sodaß "intern" keine IPv6 Kommunikation nötig ist. Das macht nur zusätzlich Arbeit in der Netzwerkverwaltung und bei den Firewall Regeln und bringt keine Vorteile.

Das macht nur zusätzlich Arbeit in der Netzwerkverwaltung und bei den Firewall Regeln

Das klingt mittlerweile aber auch sehr nach einem Gefangenen in der Zeitschleife...

Die Verwaltung von Firewall-Regel wird mit Hilfe von Ansible basierend auf den Informationen der CMDB|Inventory orchestriert. Wo ist da bitte Mehraufwand?