Site icon bintorosoft.com

IPv4-Subnetze erweitern: Ohne Chaos von /24 auf /23

Red Snapper

Audio snake and stage box with xlr cables and jacks at a live show.

IPv4-Subnetze erweitern klingt zunächst simpel: Statt einem /24 soll ein /23 her, damit mehr Geräte Platz haben. In der Praxis kann genau dieser Schritt jedoch „Chaos“ verursachen – plötzlich funktionieren einige Clients nicht mehr, Drucker sind verschwunden, DHCP vergibt merkwürdige Adressen, Broadcast-Verkehr steigt spürbar an oder Firewalls blockieren unerwartet. Der Grund ist selten ein einzelner Konfigurationsfehler, sondern das Zusammenspiel aus Subnetzmaske, Routing, DHCP, statischen IPs, Access-Listen, VLANs und gelegentlich auch Altlasten wie Proxy- oder NAC-Regeln. Wer von /24 auf /23 umstellt, verändert nicht nur die Anzahl möglicher Hosts, sondern auch die Grenzen der Layer-2-Domain und die Art, wie Geräte entscheiden, ob ein Ziel „lokal“ ist oder über das Gateway geroutet werden muss. Dieser Artikel zeigt dir Schritt für Schritt, wie du ein IPv4-Subnetz sauber von /24 auf /23 erweiterst – ohne Ausfälle, ohne schwer nachvollziehbare Nebeneffekte und ohne späteren Wartungsfrust. Du bekommst konkrete Planungsregeln, eine praxistaugliche Migrations-Checkliste und typische Fallstricke, damit die Erweiterung kontrolliert abläuft und dein Netz danach stabiler statt komplizierter ist.

Was sich bei /24 auf /23 technisch wirklich ändert

Ein /24 hat 256 IPv4-Adressen (254 nutzbare Hosts), ein /23 hat 512 Adressen (510 nutzbare Hosts). Wichtiger als die reine Zahl: Die Netzgrenze verschiebt sich. Ein /23 umfasst zwei zusammenhängende /24-Netze. Beispiel:

Damit wird ein Gerät mit 192.168.10.x plötzlich „Nachbar“ eines Geräts mit 192.168.11.x – und versucht, es direkt per ARP zu erreichen, statt über das Default Gateway zu gehen. Genau diese Änderung ist der Ursprung vieler Nebenwirkungen.

Rechenbasis: Hostanzahl und Präfixlänge

Die Anzahl nutzbarer Hostadressen ergibt sich aus der Präfixlänge:

Hosts = 2 32 − Präfix − 2

Für /24: 2^(8) − 2 = 254. Für /23: 2^(9) − 2 = 510. Das „−2“ steht für Netzwerkadresse und Broadcast-Adresse.

Wann eine Erweiterung auf /23 sinnvoll ist – und wann nicht

Bevor du umstellst, solltest du prüfen, ob „größer machen“ wirklich die beste Lösung ist. Ein /23 ist oft sinnvoll, wenn:

Es ist dagegen häufig nicht die beste Wahl, wenn:

Der häufigste Denkfehler: „Wir ändern nur die Maske“

In einem perfekt dokumentierten Netz wäre das fast so. In echten Umgebungen sind aber viele Komponenten indirekt an das Subnetz gekoppelt:

Eine saubere /23-Migration ist deshalb immer auch eine Dokumentations- und Konsistenzaufgabe.

Vorbereitung: Das musst du vor der Umstellung zwingend klären

Die wichtigste Phase ist die Planung. Wenn du hier sauber bist, wird die Umstellung später deutlich ruhiger.

1) Prüfen, ob das benachbarte /24 wirklich frei ist

Ein /23 „schluckt“ das nächste /24. Wenn du z. B. 10.10.20.0/23 nutzen willst, gehören 10.10.20.0/24 und 10.10.21.0/24 dazu. Du musst sicherstellen, dass:

2) Gateway-Strategie festlegen

In einem /24 ist das Gateway oft .1 oder .254. Beim /23 bleibt das grundsätzlich so, aber du solltest entscheiden:

Wichtig ist Konsistenz, weil sie spätere Fehlersuche drastisch vereinfacht.

3) DHCP-Design anpassen

Wenn DHCP im Spiel ist, muss der Scope erweitert werden. Typische Aufgaben:

Wichtig: Wenn du zwei DHCP-Server oder DHCP-Relay-Setups hast, muss die Scope-Definition überall übereinstimmen.

Die Umstellung Schritt für Schritt: Von /24 auf /23 ohne Nebenwirkungen

Ein kontrollierter Ablauf minimiert Ausfälle und verhindert, dass einzelne Geräte „auf dem alten Stand“ bleiben.

Schritt 1: Inventarisieren und reservieren

Schritt 2: Routing- und Firewall-Objekte vorbereiten

Alle Regeln, die das alte /24 referenzieren, müssen das neue /23 abdecken. Typische Stellen:

Wenn du Routen zusammenfasst (Summarization), überprüfe, ob das /23 in bestehende Summaries passt oder sie verändert. CIDR als Konzept ist in RFC 4632 beschrieben.

Schritt 3: Subnetzmaske am Gateway/SVI ändern

Das Default Gateway (Router-Interface oder Layer-3-Switch SVI) ist der zentrale Punkt. Hier stellst du die Maske von 255.255.255.0 auf 255.255.254.0 um. Dadurch weiß das Gateway, dass es nun beide /24-Bereiche lokal bedient.

Wichtig: Wenn in deinem Netz mehrere Gateways/VRRP/HSRP existieren, müssen alle beteiligten Geräte konsistent umgestellt werden.

Schritt 4: DHCP-Scope erweitern und aktivieren

Nun passt du DHCP an, damit Clients Adressen aus dem erweiterten Bereich bekommen. Achte darauf, dass:

Schritt 5: Clients kontrolliert erneuern lassen

Viele Probleme entstehen, wenn Clients noch die alte Subnetzmaske behalten. Dann glauben sie weiterhin, dass der zweite /24-Teil „fremd“ ist, und routen falsch. Vorgehen:

Typische Stolperfallen und wie du sie vermeidest

Statische Geräte: „Die IP stimmt, aber es geht trotzdem nicht“

Sehr häufig haben Drucker, Scanner, Kameras oder Access Points eine statische IP, aber die alte /24-Maske. Wenn ein Client schon /23 nutzt, sieht er das Gerät als „lokal“. Das Gerät selbst denkt jedoch, ein Teil des Netzes sei „remote“ und sendet Antworten über das Gateway oder versucht zu routen, was zu asymmetrischem Verkehr führt. Lösung: Statische Geräte konsequent auf die neue Maske umstellen.

ACLs und Firewall-Regeln: Nur das alte /24 ist erlaubt

Wenn du Regeln hast wie „Source 10.10.20.0/24 darf auf Servernetz zugreifen“, dann sind Clients aus 10.10.21.0/24 plötzlich ausgesperrt. Bei /23-Erweiterungen ist das einer der häufigsten produktiven Ausfälle. Lösung: Regeln auf 10.10.20.0/23 erweitern und dabei prüfen, ob du damit unbeabsichtigt zu viel öffnest.

IPAM/Monitoring: Subnetze bleiben „falsch“ hinterlegt

Viele Tools (IPAM, Asset-Management, Monitoring) führen Subnetze als Objekte. Wenn dort weiterhin /24 steht, bekommst du falsche Warnungen, unvollständige Discovery oder doppelte Alarme. Lösung: Dokumentation und Tools parallel zur technischen Umstellung aktualisieren.

Broadcast und ARP: Größer heißt mehr Nebenverkehr

Ein /23 verdoppelt die Hostanzahl in der Broadcast-Domain. Das kann ARP-Tabellen, Broadcast-Last und WLAN-Airtime beeinflussen. In „stillen“ Netzen ist das unkritisch; in WLANs oder IoT-lastigen Umgebungen kann es relevant werden. Wenn du bereits am Limit bist, ist Segmentierung oft die bessere Lösung.

Alternative zur /23-Erweiterung: Mehr Netze statt ein größeres

Manchmal ist der Wunsch nach /23 eigentlich ein Wunsch nach „mehr Adressen“. Die sauberere, skalierbarere Lösung ist oft:

Damit reduzierst du Broadcast-Domains und bekommst gleichzeitig mehr Struktur. Für viele Organisationen ist das langfristig wartbarer als ein großes /23, besonders wenn Gäste, IoT und Mitarbeiter gleichzeitig im Spiel sind.

Praxisbeispiel: Saubere Erweiterung 10.10.20.0/24 → 10.10.20.0/23

Dieses Muster ist robust, solange das benachbarte /24 wirklich frei ist und keine Policies das alte /24 hart kodieren.

Migrations-Checkliste: In der richtigen Reihenfolge arbeiten

Outbound-Links für vertiefende, verlässliche Informationen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version