VLSM: Netze passend aufteilen

Ein Adressraum, verschiedene Netzgrößen.

Variable Length Subnet Masking (VLSM) bedeutet, innerhalb eines vorhandenen IPv4-Adressraums Teilnetze mit unterschiedlichen Präfixlängen zu planen. Ein Netz für 100 Geräte braucht mehr Platz als eine Verbindung mit zwei Endpunkten. Würdest du alle Teilnetze gleich groß anlegen, bliebe in kleinen Netzen viel unnötig gebundener Adressraum.

CIDR beschreibt Netze mit Adresse und Präfixlänge unabhängig von historischen Adressklassen. VLSM nutzt unterschiedlich lange Masken für die konkrete Unterteilung. Die gemeinsamen Grundlagen erklärt Subnetzmasken und CIDR; den einzelnen Rechenweg findest du im Subnetting-Spickzettel.

Für die Planung müssen sowohl die benötigten Adressen als auch das verfügbare Ausgangsnetz feststehen. Berücksichtige Gateway, Infrastruktur und gewünschte Reserve in der Anforderung. Unser Beispiel setzt voraus, dass die genannten Bedarfe bereits alle benötigten nutzbaren Adressen umfassen.

Vom Hostbedarf zum ausgerichteten Block.

In einem gewöhnlichen IPv4-Subnetz bis /30 sind Netz- und Broadcastadresse keine Hostadressen. Suche deshalb die kleinste Hostbitzahl h, für die 2h − 2 ≥ Bedarf gilt. Der Block umfasst 2h Adressen; seine Präfixlänge ist 32 − h. Diese Regel verwenden wir hier ausdrücklich für klassische Subnetze. Den /31-Sonderfall behandeln wir separat.

Für 100 Hosts reichen sechs Hostbits mit 62 nutzbaren Adressen nicht. Sieben Hostbits ergeben 128 Adressen insgesamt und 126 nutzbare: Wir brauchen /25. Für 50, 20 und 10 Hosts ergeben sich entsprechend /26, /27 und /28. Zwei nutzbare Adressen verlangen bei klassischer Aufteilung ein /30 mit vier Adressen insgesamt.

Plane üblicherweise vom größten zum kleinsten Block. So belegst du die großen zusammenhängenden Bereiche früh und vermeidest unnötige Lücken. Das ist eine hilfreiche Vorgehensweise, kein Ersatz für die Grenzprüfung: Bei /25 darf das letzte Oktett innerhalb unseres /24 nur bei 0 oder 128 beginnen, bei /26 bei 0, 64, 128 oder 192. Ein /26 ab .160 wäre nicht ausgerichtet und damit keine gültige Netzadresse dieses Präfixes.

1. Bedarfe sammeln, Reserve klären und absteigend sortieren.
2. Je Bedarf kleinste passende Zweierpotenz und Präfix berechnen.
3. Nächsten freien, für die Blockgröße ausgerichteten Anfang wählen.
4. Netz, Maske, Hostbereich und Broadcast vollständig notieren.
5. Teilnetze auf Grenzen, Überlappungen und Zugehörigkeit zum Ausgangsnetz prüfen.
6. Verbleibende Bereiche ausdrücklich als frei dokumentieren.

192.168.20.0/24 vollständig aufteilen.

Das private Beispielnetz reicht von 192.168.20.0 bis 192.168.20.255 und enthält 256 Adressen. Wir planen 100 nutzbare Adressen für die Verwaltung, 50 für die Entwicklung, 20 für den Vertrieb, 10 für Gäste und zwei für eine klassische Punkt-zu-Punkt-Verbindung.

Die Verwaltung belegt zuerst .0 bis .127. Der nächste freie Wert .128 ist gleichzeitig eine gültige /26-Grenze für die Entwicklung. Danach passen der Reihe nach /27 ab .192, /28 ab .224 und /30 ab .240. Alle Grenzen liegen auf einem Vielfachen ihrer jeweiligen Blockgröße.

Die Blöcke verbrauchen zusammen 244 Adressen: 128 + 64 + 32 + 16 + 4. In den fünf Teilnetzen stehen 234 Hostadressen zur Verfügung; davon sind nach Anforderung 182 benötigt. Die 52 zusätzlichen nutzbaren Adressen liegen bereits innerhalb geplanter Teilnetze. Sie sind keine frei verschiebbaren neuen Subnetze.

Zwölf freie Adressen sind kein beliebiges /28.

Frei bleiben 192.168.20.244 bis 192.168.20.255, also zwölf Adressen insgesamt. Als ausgerichtete CIDR-Blöcke lässt sich dieser Bereich exakt durch 192.168.20.244/30 mit Maske 255.255.255.252 und 192.168.20.248/29 mit Maske 255.255.255.248 beschreiben.

Diese Blöcke sind noch nicht als Netze vergeben. Würdest du sie klassisch so verwenden, hätte .244/30 die Hostadressen .245 bis .246 und Broadcast .247; .248/29 hätte Hosts .249 bis .254 und Broadcast .255. Das wären zusammen acht nutzbare Hostadressen. Ein zusammenhängender freier Bereich und die nach seiner Unterteilung nutzbaren Hostadressen sind verschiedene Größen.

Ein weiteres /28 für zehn Hosts passt nicht mehr: Es benötigt 16 zusammenhängende, korrekt ausgerichtete Adressen. Die vorhandenen zwölf reichen nicht. Die freien Hostplätze in Verwaltung oder Entwicklung lassen sich ohne Änderung der Netzplanung nicht zu diesem neuen Teilnetz zusammensetzen.

Routen zusammenfassen braucht passende Grenzen.

Route Summarization bündelt mehrere Präfixe zu einer weniger spezifischen Route. Zum Beispiel lassen sich 192.168.20.192/27 und 192.168.20.224/27 exakt zu 192.168.20.192/26 zusammenfassen: Zwei benachbarte gleich große Blöcke teilen sich ein gemeinsames kürzeres Präfix. In unserer tatsächlichen Planung ist der zweite /27-Bereich allerdings weiter unterteilt und teilweise frei.

Eine aggregierte Route 192.168.20.0/24 umfasst alle geplanten Teilnetze und den freien Rest. Sie kann an einer geeigneten Netzgrenze sinnvoll sein, wenn der zuständige Router die enthaltenen Netze tatsächlich erreicht und für ungenutzte Ziele eine passende Verwerfungsstrategie existiert. Eine Zusammenfassung erzeugt weder neue Erreichbarkeit noch verbindet sie VLANs. Ungenaue Aggregate können Verkehr ins Leere lenken oder Schleifen begünstigen. Bei der Auswahl passender Routen gewinnt zunächst das längste passende Präfix; mehr dazu im Routing-Artikel.

/31 ist eine eigene Betriebsregel.

RFC 3021 erlaubt auf geeigneten IPv4-Punkt-zu-Punkt-Verbindungen ein /31. Dort werden beide Adressen als Endpunkte verwendet; ein gerichteter Subnetz-Broadcast ist auf diesem Link nicht erforderlich. 192.168.20.240/31 könnte dann die Endpunkte .240 und .241 enthalten. Beide Seiten und ihre Konfiguration müssen dieses Modell unterstützen.

Das ist eine alternative Planung, kein nachträglicher Austausch einzelner Tabellenwerte. Unser Hauptbeispiel bleibt ausdrücklich beim verlangten klassischen /30: Netz .240, Hosts .241 und .242, Broadcast .243. Für ein gewöhnliches LAN mit mehreren Geräten ist /31 nicht das passende Modell.

Die Prüfung beginnt bei der kleinsten Annahme.

In IHK-nahen Aufgaben zählt eine nachvollziehbare Planung. Schreibe zuerst auf, ob „100 Hosts“ bereits das Gateway einschließt. Sortiere dann die Bedarfe und notiere pro Teilnetz die vollständige Rechnung. Prüfe zuletzt jedes Intervall einschließlich seiner Netz- und Broadcastadresse gegen alle anderen Intervalle.

Typische Fehler sind das Aufrunden auf irgendeine gerade Zahl statt auf eine Zweierpotenz, ein nicht ausgerichteter Anfang, das Zählen des nächsten Netzes als Broadcast und das Verwechseln von freien Hostplätzen mit frei planbarem Adressraum. Auch genügend Adressen in der Summe garantieren bei einer bereits fragmentierten Planung keinen ausreichend großen zusammenhängenden Block.

Die IPv4-Grundlagen erklären die Adressrollen. Anschließend kannst du im Subnetting-Trainer einzelne Teilnetze prüfen. Der Trainer rechnet Netz und Hostbereich; er plant nicht automatisch die gesamte VLSM-Belegung. Bei dynamischer Vergabe müssen die DHCP-Scopes mit diesen Teilnetzen übereinstimmen.

Bedarf und Ausrichtung selbst kontrollieren.

Aufgabe 1: Nach der Verwaltung .0/25 soll die Entwicklung mit 50 Hosts bei .160/26 beginnen. Warum ist diese Angabe falsch, und welcher nächste Block passt?

Aufgabe 2: Ein zusätzliches klassisches Teilnetz braucht sechs nutzbare Adressen. Passt es in den freien Rest? Nenne Netz, Maske, Hostbereich und Broadcast. Was wäre bei zehn Hosts?

Quellen und Rechenstand.

Geprüft am 22. Oktober 2026. Der Adressplan, die Zahlenstrahlpositionen und die Übungen sind eigene Beispiele und wurden unabhängig mit Python ipaddress sowie dem bestehenden Subnetting-Modell geprüft.

• RFC 4632 / BCP 122: klassenlose Präfixe, Adresszuteilung und Aggregation; ersetzt RFC 1519.
• RFC 3021: /31 ausschließlich als erklärter Sonderfall für geeignete Punkt-zu-Punkt-Verbindungen.
• RFC 1918: privater IPv4-Adressraum, zu dem das gewählte 192.168.20.0/24 gehört.

Passend dazu ansehen.

Veröffentlichte BitSicht-Videos mit Zusammenfassung, Kapiteln und einem Player, den du selbst aktivierst.

• IPv4-Subnetting Schritt für Schritt: Netzadresse, Broadcast & Hosts berechnen
• IPv4-Subnetting kompakt erklärt – Netzadresse, Broadcast & /26