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

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:

• 192.168.10.0/24 deckt 192.168.10.0 bis 192.168.10.255 ab.
• 192.168.10.0/23 deckt 192.168.10.0 bis 192.168.11.255 ab.

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:

$\mathrm{Hosts}=2^{32-\mathrm{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:

• du kurzfristig deutlich mehr Hosts in einem Segment benötigst (z. B. WLAN, Schulnetz, Großraumbüro),
• du den Aufwand einer Segmentierung in mehrere VLANs aktuell nicht leisten kannst,
• die Geräte innerhalb des Segments tatsächlich viel direkt miteinander sprechen sollen.

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

• du ohnehin Sicherheitszonen brauchst (Gäste, IoT, Mitarbeiter) – dann ist Segmentierung meist besser als ein großes Layer-2-Netz.
• du Broadcast- und Multicast-Verkehr reduzieren willst – ein /23 kann die Broadcast-Domain vergrößern.
• du Probleme mit ARP-Last, mDNS/Discovery oder WLAN-Airtime hast – größere Netze können das verschärfen.

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:

• DHCP-Scopes (Range, Exclusions, Option 3 Gateway, Option 6 DNS)
• Statische IPs (Server, Drucker, Access Points, Kameras)
• Firewall- und ACL-Regeln (Source-/Destination-Subnets)
• Routing (statische Routen, Zusammenfassungen, VRFs)
• NAC/802.1X, Netzwerk-Zonen, Proxy-Policies (häufig Subnetz-basiert)
• Monitoring (Subnets in Tools, Alarme, IPAM)

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:

• 10.10.21.0/24 nicht bereits als eigenes VLAN/Subnetz existiert,
• 10.10.21.0/24 nicht über VPN/Standortanbindungen genutzt wird,
• keine statischen Routen oder Firewall-Objekte das /24 separat behandeln.

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:

• Bleibt das Gateway im ersten /24 (z. B. 10.10.20.1)?
• Oder nutzt du ein „zentraleres“ Schema (z. B. 10.10.20.254) und reservierst definierte Blöcke?

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:

• Adresspool erweitern (z. B. .50–.250 plus .50–.250 im zweiten /24-Teil)
• Exclusions für statische IPs setzen (Server, Drucker, Infrastruktur)
• Lease-Time prüfen (kurz vor Migration kann eine kürzere Lease-Time helfen)

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

• Liste aller statischen IPs im bisherigen /24 erstellen (inkl. Infrastruktur: APs, Switch-Management, Drucker, Kameras).
• Adressbereiche definieren: z. B. .1–.49 Infrastruktur, .50–.399 DHCP, .400–.510 reserviert.
• Konfliktprüfung im zweiten /24-Teil: existieren dort bereits Geräte oder Routen?

Schritt 2: Routing- und Firewall-Objekte vorbereiten

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

• Firewall-Address-Objects
• ACLs auf Routern/Switches (SVI)
• VPN-Policies (Local/Remote Networks)
• Routenfilter in OSPF/BGP (falls vorhanden)

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:

• Optionen (Gateway, DNS, Domain-Suffix) unverändert korrekt bleiben,
• der Scope nicht versehentlich überlappende Pools mit anderen Segmenten erzeugt,
• Reservierungen (MAC → IP) weiterhin in der neuen Logik liegen.

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:

• Lease-Time vorab reduzieren (z. B. auf 30–60 Minuten), um Umstellung zu beschleunigen.
• Nach Umstellung: Clients DHCP erneuern lassen (Reconnect, Neustart oder DHCP-Release/Renew).
• Statische Hosts manuell auf /23 anpassen (Maske!), falls sie mit festen IPs arbeiten.

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:

• ein zweites /24 in einem neuen VLAN für eine Gerätekategorie,
• Routing zwischen VLANs über Firewall oder L3-Switch,
• gezielte Policies pro Segment (Sicherheit, QoS, Zugriff).

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

• Ausgang: 10.10.20.0/24, Gateway 10.10.20.1, DHCP 10.10.20.50–10.10.20.250
• Prüfung: 10.10.21.0/24 ist frei (kein VLAN, keine VPN-Policy, keine Route)
• Neu: Gateway bleibt 10.10.20.1, Maske 255.255.254.0
• DHCP neu: 10.10.20.50–10.10.21.250 (mit Exclusions für Infrastruktur und statische Hosts)
• Firewall: Regeln von 10.10.20.0/24 auf 10.10.20.0/23 erweitern
• Statische Hosts: Maske auf /23 anpassen (nicht nur IP/Gateway)

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

• Benachbartes /24 auf Konflikte prüfen (lokal, VPN, Cloud, Partner)
• Adressplan und Reservierungsbereiche festlegen
• Firewall/ACL/VPN-Objekte vorbereiten und erweitern
• Gateway/SVI-Maske auf /23 ändern
• DHCP-Scope erweitern, Lease-Time-Strategie anwenden
• Statische Geräte auf neue Maske umstellen
• Clients zu DHCP-Renew bewegen (kontrolliert)
• Monitoring/IPAM/Dokumentation aktualisieren
• Nachkontrolle: Erreichbarkeit zwischen .20.x und .21.x testen

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

• RFC 4632: CIDR und Classless Inter-Domain Routing
• RFC 1918: Private IPv4-Adressbereiche
• RFC 950: Subnetting (historische Grundlage, hilfreich für Begriffe)
• RFC Editor: Offizielle RFC-Sammlung
• CIDR im Überblick (konzeptionell, mit Beispielen)

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.