IPv4-Subnetting mit VLSM (Variable Length Subnet Mask) ist eine der wirkungsvollsten Methoden, um knappe IPv4-Adressräume effizient zu nutzen. Während klassisches Subnetting oft nach dem Motto „ein Netz pro Bereich, alle gleich groß“ umgesetzt wird, führt das in der Praxis schnell zu Verschwendung: Ein kleines VLAN mit 20 Geräten bekommt unnötig ein /24, während ein wachsendes Servernetz plötzlich zu klein wird. VLSM löst dieses Problem, indem du Subnetze mit unterschiedlichen Präfixlängen innerhalb eines übergeordneten Adressblocks kombinierst – genau passend zum Bedarf. Das Ergebnis ist mehr Flexibilität, weniger ungenutzte IPs und eine bessere Grundlage für sauberes Routing-Design, insbesondere in Unternehmen mit vielen Segmenten, Standorten oder Cloud-Umgebungen. Gleichzeitig ist VLSM kein „Trick“, sondern sauberes CIDR-basiertes Planen: Du vergibst die größten Netze zuerst, hältst Grenzen (Subnetzgrenzen) ein, dokumentierst sauber und reservierst Wachstum. Dieser Artikel erklärt verständlich, wie IPv4-Subnetting mit VLSM funktioniert, wie du Subnetze korrekt berechnest, typische Fehler vermeidest und mit praxistauglichen Beispielen tatsächlich IPv4-Adressen sparst – ohne dass dein Netzwerk dadurch unübersichtlich wird.
Was ist VLSM und warum spart es IPv4-Adressen?
VLSM bedeutet, dass du innerhalb eines größeren IPv4-Adressbereichs (z. B. 10.10.0.0/16) Subnetze unterschiedlicher Größe anlegst: ein /24 für ein größeres Clientnetz, ein /26 für ein kleineres VLAN, ein /30 oder /31 für Punkt-zu-Punkt-Verbindungen. So erhält jeder Bereich genau so viele IP-Adressen, wie er realistisch benötigt – plus Reserve – statt pauschal zu große Netze zu bekommen.
- Weniger Verschwendung: Kleine Segmente bekommen kleine Präfixe (z. B. /27 statt /24).
- Bessere Skalierung: Große Segmente erhalten ausreichend Platz, ohne dass du alles neu nummerieren musst.
- Saubere Hierarchie: VLSM lässt sich mit Summarization kombinieren, wenn du strukturiert planst.
Die Grundlage hierfür ist CIDR (Classless Inter-Domain Routing), beschrieben in RFC 4632. Private IPv4-Adressbereiche sind in RFC 1918 definiert.
VLSM vs. klassisches Subnetting: Der Unterschied in der Praxis
Klassisches Subnetting (historisch aus der Zeit fester Klassen und starrer Masken) führt oft dazu, dass du einen großen Block in gleich große Subnetze teilst. Das ist leicht zu merken, aber selten optimal. VLSM ist hingegen bedarfsorientiert.
- Klassisch: 10.10.0.0/16 wird in viele /24 zerlegt – einfach, aber oft zu grob.
- VLSM: 10.10.0.0/16 enthält ein /22, zwei /24, mehrere /26 und /28 – passend für reale Segmente.
In modernen Netzwerken ist VLSM praktisch der Standard, weil VLANs, DMZs, Management-Netze, Voice-Netze und Punkt-zu-Punkt-Links sehr unterschiedliche Größenanforderungen haben.
Grundlagen: Wie viele Hosts passen in ein IPv4-Subnetz?
Für VLSM ist die Kapazitätsberechnung entscheidend. Ein IPv4-Subnetz mit Präfixlänge
Beispiele (klassisch gerechnet):
- /24 → 256 Adressen, ca. 254 Hosts
- /26 → 64 Adressen, ca. 62 Hosts
- /27 → 32 Adressen, ca. 30 Hosts
- /28 → 16 Adressen, ca. 14 Hosts
- /30 → 4 Adressen, ca. 2 Hosts (typisch für Punkt-zu-Punkt)
VLSM-Planung: Der bewährte Ablauf in 6 Schritten
VLSM ist leicht, wenn du eine klare Reihenfolge einhältst. Der größte Fehler ist „einfach irgendwo anfangen“ und später feststellen, dass ein großes Netz keinen zusammenhängenden Platz mehr hat.
- Schritt 1: Anforderungen sammeln (Hosts pro Segment, Wachstum, Sonderfälle).
- Schritt 2: Segmente nach Größe sortieren (größte Netze zuerst).
- Schritt 3: Für jedes Segment das kleinste passende Präfix bestimmen (inkl. Reserve).
- Schritt 4: Subnetze nacheinander im Adressblock platzieren – immer auf korrekten Grenzen.
- Schritt 5: Reserven einplanen (freie Blöcke für Wachstum, neue VLANs, neue Standorte).
- Schritt 6: Dokumentieren und in IPAM/CMDB pflegen (inkl. Zweck, Gateway, DHCP-Bereich).
Subnetzgrenzen: Warum „korrekte Grenzen“ so wichtig sind
Ein Subnetz muss auf einer Grenze beginnen, die zur Präfixlänge passt. Ein /26 hat eine Blockgröße von 64 Adressen. Das bedeutet: Ein /26 kann bei .0, .64, .128 oder .192 beginnen (im letzten Oktett), nicht bei .32 oder .96. Genau diese Grenzlogik verhindert Überlappungen und sorgt für saubere Routingtabellen.
VLSM-Beispiel: Ein /24 effizient in mehrere Netze aufteilen
Angenommen, du hast 192.168.10.0/24 (nur als Beispiel) und benötigst folgende Segmente:
- Netz A: 50 Hosts (z. B. Büro-VLAN)
- Netz B: 20 Hosts (z. B. Drucker/IoT)
- Netz C: 10 Hosts (z. B. Management)
- Netz D: 2 Hosts (Punkt-zu-Punkt-Link)
Du wählst die kleinsten passenden Präfixe (mit etwas Reserve):
- 50 Hosts → /26 (62 Hosts möglich)
- 20 Hosts → /27 (30 Hosts möglich)
- 10 Hosts → /28 (14 Hosts möglich)
- 2 Hosts → /30 (2 Hosts möglich)
Platzierung (größte zuerst) innerhalb von 192.168.10.0/24:
- Netz A: 192.168.10.0/26 (Bereich .0–.63)
- Netz B: 192.168.10.64/27 (Bereich .64–.95)
- Netz C: 192.168.10.96/28 (Bereich .96–.111)
- Netz D: 192.168.10.112/30 (Bereich .112–.115)
Der Rest (.116–.255) bleibt als Reserve für neue VLANs oder Wachstum. Genau hier zeigt sich der Spareffekt: Statt viermal /24 zu vergeben, nutzt du einen /24-Block hoch effizient aus.
VLSM in der Unternehmenspraxis: Typische Einsatzfälle
VLSM entfaltet den größten Nutzen, wenn du viele unterschiedliche Netzwerktypen betreibst. Häufige Fälle:
- Client-Netze: größere Subnetze (z. B. /23 oder /22) für viele Endgeräte
- Server- und Applikationsnetze: oft /24 oder /25, je nach Dichte und Skalierung
- DMZ: bewusst klein und restriktiv (z. B. /27 oder /28), um Angriffsfläche zu begrenzen
- Management/Out-of-Band: klein, kontrolliert (z. B. /28)
- Punkt-zu-Punkt-Verbindungen: /30 oder /31 (je nach Design und Geräteunterstützung)
/31 für Punkt-zu-Punkt: Noch effizienter als /30
Für echte Punkt-zu-Punkt-Links kann ein /31 sinnvoll sein, weil es genau zwei Adressen enthält und keine klassische Broadcast-Adresse benötigt. Dieses Verfahren ist in RFC 3021 beschrieben. Dadurch sparst du im Vergleich zu /30 zusätzliche IPv4-Adressen – besonders relevant, wenn du sehr viele Links hast.
Adresssparende Planung: Reserve richtig kalkulieren
VLSM spart Adressen nur dann nachhaltig, wenn du nicht zu knapp planst. Zu kleine Subnetze sind eine häufige Ursache für spätere Renummerierungen. Eine einfache Methode ist, pro Segment eine Wachstumsreserve zu definieren, etwa 20–50% je nach Dynamik. Als gedankliche Stütze kannst du so kalkulieren:
Wenn du aktuell 40 Hosts erwartest und eine Reserve von 0,25 ansetzt, planst du mit 50 Hosts. Das führt dich z. B. von /27 (30 Hosts) zu /26 (62 Hosts) – eine Entscheidung, die spätere Umstellungen vermeiden kann.
Typische Fehler bei VLSM und wie du sie vermeidest
- Zu klein geplant: Ein /28 für „10 Geräte“ wirkt passend, wird aber schnell zu eng. Lösung: Reserve einplanen und Wachstum realistisch bewerten.
- Subnetzgrenzen missachtet: Netze beginnen an falschen Offsets und überlappen. Lösung: Blockgröße aus Präfix ableiten und nur passende Startadressen nutzen.
- Keine Dokumentation: VLSM wird unübersichtlich, wenn Zweck und Bereich nicht sauber festgehalten werden. Lösung: IPAM/Tabellen mit Owner, Zweck, DHCP-Range, Gateway.
- Unstrukturierte Vergabe: „Freie Lücken“ werden zufällig gefüllt, Summarization wird unmöglich. Lösung: Hierarchisches Schema und Reserven pro Zone/Standort.
- VPN/Hybrid-Kollisionen: RFC1918 wird mehrfach genutzt und kollidiert später. Lösung: Adressräume unternehmensweit koordinieren.
VLSM und Routing-Design: Übersicht behalten trotz unterschiedlicher Präfixe
Ein häufiger Vorbehalt lautet: „VLSM macht Routing unübersichtlich.“ Das stimmt nur bei unstrukturierter Umsetzung. Wenn du VLSM in Blöcken planst, kannst du Subnetze weiterhin zusammenfassen. Beispiel: Du reservierst pro Standort einen /20-Block, darin liegen alle VLANs als unterschiedlich große Netze. Nach außen announcest du trotzdem nur das /20 (Summarization), während intern detailliert geroutet wird. Die CIDR-Grundlage dafür findest du in RFC 4632.
Tooling und Dokumentation: Ohne IPAM wird VLSM schnell teuer
VLSM ist besonders effizient, wenn du es konsequent dokumentierst. Selbst eine gut gepflegte Tabelle ist besser als „Wissen im Kopf“. In professionellen Umgebungen ist IPAM (IP Address Management) der Standard, weil es Konflikte verhindert, Reserven sichtbar macht und Prozesse unterstützt (z. B. Freigaben, Audits, DNS/DHCP-Integration).
- Minimal: zentrale Tabelle mit CIDR, Zweck, VLAN-ID, Gateway, DHCP-Range, Reserven
- Fortgeschritten: IPAM mit Rollen, Workflows, API, Integration in DNS/DHCP
- Operativ: klare Vergaberegeln (wer darf neue Netze anlegen, wie werden Reserven genutzt?)
Outbound-Links für verlässliche technische Referenzen
- RFC 4632: Classless Inter-Domain Routing (CIDR)
- RFC 1918: Private IPv4-Adressbereiche
- RFC 3021: /31 für Punkt-zu-Punkt-Links
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.
