Ein Subnetzrechner liefert die Adressberechnung. Für einen brauchbaren Netzwerkplan brauchen Sie außerdem belastbare Host-Anforderungen, Kapazitätsreserven und eine Prüfung auf Überschneidungen, bevor Sie Routing-Domänen verbinden. Dieses Beispiel verteilt vier IPv4-Netze innerhalb von 10.42.0.0/22, ergänzt absichtlich ein überlappendes Partnernetz und bereitet das Ergebnis für ein technisches Review auf. Das Szenario ist synthetisch und beschreibt kein Kundennetz.
Die hier verlinkten Netzwerktools habe ich entwickelt. Nutzen Sie sie, um einen Entwurf zu berechnen und zu prüfen. Gleichen Sie ihn anschließend mit Ihrem Adressbestand und den geplanten Verbindungen ab. Ein Browserergebnis zeigt weder, was bereits produktiv eingesetzt wird, noch welche Routen Ihr Unternehmen zulassen sollte.
Beginnen Sie mit dem Bedarf, nicht mit einer bevorzugten Netzmaske
Ein neuer Standort benötigt in diesem Beispiel 200 Adressen für Office, 100 für Production, 50 für Management und 20 für Guest. Diese Zahlen enthalten bereits Gateways, Infrastrukturadressen und die vereinbarte Wachstumsreserve je Gruppe. Sie beschreiben weder Personen noch Switchports oder aktuell aktive DHCP-Leases. Die englischen Gruppennamen bleiben als eindeutige Bezeichnungen im gesamten Beispiel erhalten.
Diese Unterscheidung beeinflusst die Netzgröße. Steht Office für 200 heute eingesetzte Laptops, müssen weitere Adressverbraucher und das geplante Wachstum vor der Berechnung hinzukommen. Telefon und Laptop können jeweils eine Adresse belegen; ein redundantes Gateway kann mehrere benötigen. Bei Gästen zählen gleichzeitige Clients und das Lease-Verhalten, nicht nur die Besucherzahl am Empfang.
Halten Sie diese Annahmen neben den Bedarfszahlen fest. Klären Sie mit dem Verantwortlichen, was während eines Geräteaustauschs gleichzeitig funktionieren muss, wenn alte und neue Systeme vorübergehend parallel laufen. Ein Subnetz kann den heutigen Bestand aufnehmen und trotzdem für die erste Migration zu klein sein. Die durch binäre Rundung entstehende Restkapazität ist noch keine abgestimmte Wachstumsplanung.
Der übergeordnete Block 10.42.0.0/22 reicht von 10.42.0.0 bis 10.42.3.255. Er gehört zum privaten IPv4-Adressraum und eignet sich für diese synthetische interne Planung. Prüfen Sie in einem echten Projekt, ob Ihr Unternehmen den Block tatsächlich diesem Standort zugewiesen hat und ob er andernorts reserviert ist. Private Adressen sind wiederverwendbar, aber nicht weltweit eindeutig.
Die Gruppenbezeichnungen beschreiben den vorgesehenen Zweck. Verschiedene Subnetze erzwingen noch keine Sicherheitstrennung. Für den Verkehr zwischen Production und Office brauchen Sie weiterhin eine Routing-Entscheidung, Firewall-Regeln und eine ausdrückliche Festlegung der erlaubten Kommunikation.
Vergeben Sie die größten Netze zuerst
Mit Variable Length Subnet Masking, kurz VLSM, vergeben Sie innerhalb eines übergeordneten Blocks unterschiedlich große Subnetze. Für die gewöhnlichen IPv4-LAN-Subnetze dieses Beispiels wählen Sie den kleinsten Zweierpotenz-Block, dessen Adresszahl nach Abzug von Netz- und Broadcastadresse den Bedarf deckt. Diese Konvention gilt nicht pauschal für jeden IPv4-Präfix oder jede Cloud-Plattform.
Office benötigt 200 nutzbare Adressen. Ein /25 liefert 126 und reicht deshalb nicht; ein /24 bietet 254. Production passt in ein /25, Management in ein /26 und Guest in ein /27. Wenn Sie mit dem größten Netz beginnen, lassen sich die notwendigen Blockgrenzen leichter einhalten. Verstreute kleine Zuweisungen können zwar genügend Adressen übrig lassen, aber keinen passend ausgerichteten größeren Block.
Öffnen Sie die VLSM-Planungsseite und starten Sie dort das Tool in AdeOS. Die Einstiegsseite erläutert die Funktion; sie enthält keinen direkt eingebetteten Rechner. Tragen Sie 10.42.0.0/22 als übergeordneten Block und 200, 100, 50 sowie 20 als Anforderungen ein. Vergleichen Sie das Ergebnis mit der unabhängig berechneten Referenz.
| Gruppe | Bedarf | CIDR | Nutzbare IPv4-Adressen | Nutzbarer Bereich |
|---|---|---|---|---|
| Office | 200 | 10.42.0.0/24 | 254 | 10.42.0.1–10.42.0.254 |
| Production | 100 | 10.42.1.0/25 | 126 | 10.42.1.1–10.42.1.126 |
| Management | 50 | 10.42.1.128/26 | 62 | 10.42.1.129–10.42.1.190 |
| Guest | 20 | 10.42.1.192/27 | 30 | 10.42.1.193–10.42.1.222 |
Die Referenz wurde mit dem Modul ipaddress aus der Python-Standardbibliothek unabhängig vom Browsertool berechnet. Alle Subnetze liegen im übergeordneten Block, decken den jeweiligen Bedarf und überschneiden sich nicht untereinander. Ihre Broadcastadressen lauten in derselben Reihenfolge 10.42.0.255, 10.42.1.127, 10.42.1.191 und 10.42.1.223. Prüfen Sie diese Grenzen zusätzlich zur Kapazitätsanzeige: Eine plausible Hostzahl beweist noch keine korrekte Netzadresse.
Die vier Blöcke belegen 480 der insgesamt 1.024 Adressen. Unvergeben bleiben 544 Adressen, aufgeteilt in 10.42.1.224/27 und 10.42.2.0/23. Es handelt sich um zwei CIDR-Blöcke, obwohl das verbleibende Adressintervall zusammenhängend ist. Alle 544 Adressen lassen sich nicht durch einen einzigen korrekt ausgerichteten CIDR-Präfix ausdrücken.
Unvergebener Adressraum ist etwas anderes als freie Hostkapazität in einem zugewiesenen Subnetz. Freie Office-Adressen gehören weiterhin zu Office. Management kann sie nicht ohne Designänderung mitnutzen. Ebenso bedeuten 544 unvergebene Adressen nicht 544 zusätzliche zuweisbare Endgeräteadressen: Künftige Subnetzgrenzen und Plattformreservierungen verringern diese Zahl.
Berechnen Sie die Kapazität für die tatsächliche Plattform neu
Die Tabelle verwendet die herkömmliche IPv4-LAN-Berechnung, nicht die Ressourcenkapazität von AWS. AWS dokumentiert seine IPv4-Subnetzreservierungen: Nach der üblichen Reservierungsregel stehen die ersten vier und die letzte Adresse jedes Subnetzes nicht für Ressourcen zur Verfügung. AWS beschreibt außerdem eine BYOIP-Ausnahme, die nicht Gegenstand dieses Beispiels mit privaten Adressen ist.
Nach der Standardregel von AWS bieten die gewählten Blockgrößen 251, 123, 59 und 27 zuweisbare Adressen. Damit erfüllen sie weiterhin alle Anforderungen des Beispiels, allerdings mit weniger Reserve. Ein /27, das einen Bedarf von 30 Adressen in einem gewöhnlichen LAN deckt, reicht nach dieser AWS-Regel nicht für 30 Ressourcenadressen.
Aus der Tabelle wird dadurch noch keine AWS-Architektur. Die Verteilung auf Availability Zones, dienstspezifische Belegungen, Netzwerkschnittstellen und Quotas können den Bedarf verändern. Prüfen Sie die Regeln für das konkrete Deployment. Übertragen Sie eine AWS-Berechnung nicht ungeprüft auf Azure, Google Cloud oder ein lokales VLAN.
Ergänzen Sie das Partnernetz und prüfen Sie die Überschneidung
Angenommen, ein Partner möchte nun 10.42.1.0/24 anbinden. Öffnen Sie die CIDR-Konfliktprüfung über den AdeOS-Startbutton. Geben Sie die vier zugewiesenen Präfixe und den Partnerpräfix ein. Lassen Sie den übergeordneten /22-Block bei diesem ersten Vergleich weg: Er enthält seine vier Teilnetze absichtlich und würde zusätzliche Befunde erzeugen, die keine konkurrierenden Zuweisungen darstellen.
Die unabhängig berechneten Beziehungen wurden auch im Live-Prüfer reproduziert. Die Oberfläche meldete unter „Conflicts“ sieben Befunde: drei Warnungen zu enthaltenen Subnetzen und vier informative Hinweise auf benachbarte Bereiche. Nur die drei Warnungen entsprechen den Partnerüberschneidungen in dieser Tabelle. Lesen Sie die Gesamtzahl daher nicht als sieben überlappende Netze. Benachbarte Bereiche sind keine Kollision; unterschiedlich große Nachbarn lassen sich außerdem nicht zwangsläufig zu einem einzigen exakten CIDR-Präfix zusammenfassen, ohne zusätzliche Adressen einzuschließen.
| Bestehende Zuweisung | Partnerpräfix | Adressbeziehung |
|---|---|---|
| Office: 10.42.0.0/24 | 10.42.1.0/24 | Keine Überschneidung |
| Production: 10.42.1.0/25 | 10.42.1.0/24 | Vollständig im Partnerpräfix enthalten |
| Management: 10.42.1.128/26 | 10.42.1.0/24 | Vollständig im Partnerpräfix enthalten |
| Guest: 10.42.1.192/27 | 10.42.1.0/24 | Vollständig im Partnerpräfix enthalten |
Der Partnerblock reicht von 10.42.1.0 bis 10.42.1.255. Er enthält Production, Management und Guest sowie den noch unvergebenen Block 10.42.1.224/27. Office ist nicht betroffen. Kopieren Sie nach der Prüfung den tatsächlichen Bericht in Ihre Review-Unterlagen. Bewahren Sie auch die Eingaben auf, damit ein anderer Engineer den Befund reproduzieren kann.
Eine Überschneidung beschreibt eine Adressbeziehung und beweist keinen Ausfall. Getrennte VRFs können Adressen absichtlich mehrfach verwenden. Auch in einer IPAM-Hierarchie überlappt ein übergeordneter Präfix naturgemäß seine Teilnetze. Betrieblich entscheidend ist, ob diese Bereiche in einem Routing-Kontext zusammenkommen sollen, in dem Zieladressen mehrdeutig werden.
Longest-Prefix-Matching ist dafür keine pauschale Lösung. Spezifischere lokale Routen können sich gegenüber einer zusammenfassenden Partnerroute durchsetzen. Dieselbe Zieladresse bezeichnet dadurch aber nicht zuverlässig zwei unterschiedliche Endpunkte. Rückwege, Routenimporte und der gewünschte Dienstzugriff bleiben zu prüfen. Eine flache CIDR-Liste kennt diese Anforderungen nicht.
Für AWS VPC Peering gilt eine konkretere Einschränkung als in der allgemeinen Routing-Betrachtung. AWS erlaubt kein Peering zwischen VPCs mit identischen oder überlappenden CIDR-Blöcken. Bei mehreren IPv4-CIDRs verhindert bereits eine Überschneidung das Peering, auch wenn Sie nur nicht überlappende Bereiche verwenden möchten. Weniger Routen auszuwählen hebt diese Plattformbeschränkung nicht auf.
Klären Sie die Adressentscheidung vor der Verbindung
Für ein hypothetisches neues Partnernetz wählen Sie stattdessen 10.43.0.0/24, sofern dessen Verantwortlicher und der übergreifende Adressbestand die Verfügbarkeit bestätigen. Dieser Block liegt außerhalb unseres Standort-/22 und überschneidet sich mit keiner der vier Zuweisungen. Ersetzen Sie den Partnereintrag und wiederholen Sie den Vergleich. Für diese fünf Einträge sind nun keine Überschneidungen zu erwarten.
Die Aussage ist bewusst begrenzt. Nicht berücksichtigte VPN-Pools, weitere Standorte, sekundäre Cloud-CIDRs oder Netze eines übernommenen Unternehmens bleiben ungeprüft. Gleichen Sie den neuen Bereich deshalb mit dem vollständigen Bestand ab, der für die geplante Verbindung relevant ist. Ein leerer Konfliktbericht auf Basis unvollständiger Eingaben ist leicht falsch zu verstehen.
Ein bestehendes Partnernetz lässt sich schwerer verschieben. Eine Umadressierung kann Änderungen an DHCP, DNS, Firewalls, Monitoring und Anwendungskonfigurationen erfordern. Planen Sie Übergang und Rückfall mit den Verantwortlichen der betroffenen Systeme. Eine produktive Abhängigkeit ist nicht migriert, nur weil ihr Präfix in der Tabelle geändert wurde.
NAT kann infrage kommen, wenn eine Umadressierung nicht praktikabel ist. Dafür entstehen eine zweite Adresssicht, Übersetzungszustände und zusätzlicher Aufwand bei der Fehlersuche. Anwendungen, die IP-Adressen in ihren Nutzdaten übertragen, können die Umsetzung erschweren. Legen Sie fest, welche Seite welchen Präfix sieht, wie Rückverkehr übersetzt wird und was beim Failover passiert. NAT ist kein allgemeiner Ausweg aus Cloud-Peering-Beschränkungen; gegebenenfalls ist ein anderes Verbindungsdesign erforderlich.
Benötigen die Domänen keine direkte Verbindung, kann die bestehende Trennung sinnvoll bleiben. Dokumentieren Sie diese Entscheidung und prüfen Sie sie erneut, sobald gemeinsame Dienste oder Route Leaking gefordert werden. Eine heute beabsichtigte Überschneidung kann eine spätere Integration einschränken.
Übergeben Sie einen technisch prüfbaren Plan
Halten Sie Zuweisungstabelle, genaue Prüfeingaben und tatsächlichen Bericht zusammen. Ergänzen Sie die Zuweisung des übergeordneten Blocks, Verwendungszweck, Routing-Domäne beziehungsweise VRF, einen benannten Verantwortlichen und einen Anlass für die nächste Überprüfung. Trennen Sie je Subnetz den geplanten Bedarf von der aktuell beobachteten Belegung. Vermerken Sie, ob Wachstum bereits eingerechnet ist und welche Reservierungsregel zur Kapazitätsberechnung gehört.
Zur Übergabe gehört auch die Verbindungsentscheidung: Welche Netze dürfen miteinander kommunizieren? Wurde der Partnerbereich geändert? Welche offenen Annahmen verhindern noch das Deployment? Kennzeichnen Sie vorgeschlagene Zuweisungen getrennt von produktiven. Ein gespeichertes Browserszenario kann Berechnungen reproduzierbar machen. Lokale Browserspeicherung ersetzt aber weder eine gemeinsame Änderungsdokumentation noch eine Synchronisierung zwischen mehreren Nutzern.
Für den dauerhaften Bestand beschreibt die IPAM-Dokumentation von NetBox Präfixe, Bereiche, einzelne Adressen und VRF-spezifische Hierarchien einschließlich überlappender Adressräume in getrennten VRFs. Solche Zusammenhänge gehören in eine verbindliche Bestandsführung. Eine getestete Integration zwischen dem Rechner und NetBox wird mit diesem Workflow nicht zugesagt.
Behandeln Sie Infrastructure-as-Code-Ausgaben als eigenen Prüfschritt. HashiCorp warnt bei cidrsubnets davor, bestehende Argumente zu verändern, sobald Adressen realer Infrastruktur zugewiesen wurden: Nachfolgende Zuweisungen können dadurch ungültig werden. Eine neue VLSM-Berechnung ist deshalb keine Freigabe, produktive Adresspläne neu zu sortieren. Bewahren Sie stabile Zuweisungen und prüfen Sie die Auswirkungen jeder Änderung.
Dieser Ablauf endet bei einem prüfbaren Adressplan. Er liefert keine unmittelbar einsetzbare Terraform-, Ansible- oder Routerkonfiguration und behauptet nicht, dass jedes Exportziel validiert wurde. Bevor Sie generierte Konfiguration übernehmen, berechnen Sie die tatsächlich entstehenden Präfixe unabhängig nach und prüfen Sie Syntax sowie Verhalten der Zielplattform.
Testen Sie das Beispiel vor dem Einsatz echter Netzdaten
Beginnen Sie mit dem VLSM-Planer, vergleichen Sie die vier Zuweisungen und ergänzen Sie anschließend 10.42.1.0/24 in der Konfliktprüfung. Bestätigen Sie die drei enthaltenen Teilnetze, ersetzen Sie den Partnerbereich durch das hypothetische 10.43.0.0/24 und prüfen Sie erneut. Die Übersicht der Netzwerktools bietet einen Einstieg, wenn Sie die Adressgrundlagen nachschlagen möchten.
Verwenden Sie für Vorführungen und geteilte Links synthetische Eingaben. Prüfen Sie URLs, Berichte und Screenshots vor der Weitergabe; auch private Adressen und Bezeichnungen können Infrastrukturstrukturen offenlegen. Setzen Sie nicht voraus, dass bei einem Browsertool grundsätzlich keine Daten den Browser verlassen.
Der Rechner kann keine Geräte entdecken, doppelt verwendete Endpunktadressen nachweisen, Routing-Regeln validieren, sämtliche Cloud-Quotas prüfen oder eine Sicherheitsarchitektur freigeben. Dieses Beispiel behandelt ausschließlich IPv4. Für einen Hybrid-Cloud- oder Industrienetzplan können Sie ein Infrastruktur-Design-Review anfragen, sobald Anforderungen und Adressbestand vorliegen. Als Grundlage eignen sich Zuweisungen, Überschneidungsbefunde und die geplante Kommunikation besser als ein Screenshot mit grünem Prüfergebnis.
