Subnetting-Doku: Wie Sie Netze sauber und verständlich dokumentieren

Eine gute Subnetting-Doku ist der Unterschied zwischen „wir haben irgendwie IPs“ und einem Netzwerk, das sauber wächst, sicher segmentiert bleibt und im Incident schnell verstanden wird. Subnetting selbst ist technisch kein Hexenwerk: Präfix wählen, Gateway definieren, DHCP-Bereich setzen. Das Chaos entsteht meistens erst später – wenn Standorte hinzukommen, VLANs wachsen, VPNs und Cloud-Anbindungen Overlaps riskieren oder wenn mehrere Teams parallel Änderungen durchführen. Dann tauchen typische Probleme auf: überlappende Netze, falsch dokumentierte Gateways, widersprüchliche DHCP-Scopes, fehlende Reserven, und niemand weiß, warum ein /27 existiert, während der Rest /24 ist. Eine verständliche Subnetting-Dokumentation macht Netze nicht nur „auflistbar“, sondern erklärbar: Sie zeigt Struktur, Zweck, Zonenbezug, Verantwortlichkeiten und die Logik, wie neue Netze vergeben werden. In diesem Leitfaden lernen Sie, wie Sie Subnetze sauber dokumentieren, welche Felder wirklich nötig sind, wie Sie CIDR verständlich darstellen, wie Sie Reserven planen und wie Sie Ihre Dokumentation so gestalten, dass sie auch nach Jahren noch funktioniert.

Warum Subnetting-Dokumentation so oft unterschätzt wird

Subnetze sind die Grundlage fast aller Netzwerkfunktionen: Routing, Segmentierung, Firewall-Policies, DHCP, DNS, Monitoring und vieles mehr. Wenn die Subnetting-Doku unvollständig oder uneinheitlich ist, werden Fehlerbilder schwer nachvollziehbar. Viele Teams dokumentieren zwar „10.10.10.0/24“, aber nicht, wo geroutet wird, welche Zone es ist, wer verantwortlich ist oder welche Reserven existieren. Genau diese Zusatzinformationen sind in Betrieb, Security und Audits entscheidend.

• Schnelleres Troubleshooting: Pfad, Gateway-Ort und zuständige Systeme sind sofort klar.
• Weniger Konflikte: Overlaps, doppelte statische IPs und falsch gesetzte DHCP-Ranges werden vermieden.
• Bessere Security: Subnetze sind Zonen zugeordnet und Kommunikationsbeziehungen sind nachvollziehbar.
• Skalierbarkeit: Reserven und Zuweisungslogik verhindern „Flickenteppich“-Subnetting.
• Onboarding: Neue Mitarbeitende verstehen Struktur und Regeln, ohne jedes Detail erfragen zu müssen.

Grundlagen: CIDR, Präfix und „wie groß ist ein Netz?“

Damit Subnetting-Dokumentation für Einsteiger und Fortgeschrittene verständlich bleibt, sollten Sie CIDR nicht nur als Kürzel verwenden, sondern einheitlich erklären. CIDR (Classless Inter-Domain Routing) beschreibt mit einem Präfix, wie viele Bits für das Netz reserviert sind, z. B. /24, /26, /28. Je größer die Zahl, desto kleiner das Netz (weniger Hostadressen). In der Dokumentation ist es hilfreich, neben dem Präfix auch die nutzbare Hostanzahl (IPv4) und typische Reserven zu nennen. Für eine verständliche Einführung in IP-Adressierung eignet sich RIPE NCC: Understanding IP addressing.

Dokumentationsregel: CIDR immer mit Kontext angeben

• Subnetz: 10.20.30.0/24
• Zweck: Clients intern Standort BER
• Gateway: 10.20.30.1 (SVI auf ber-sw-core-01)
• DHCP: 10.20.30.50–10.20.30.200, Lease 24h
• Reserviert: .2–.49 Infrastruktur, .201–.254 Wachstum

Subnetting-Doku als Struktur: Standort, Zone, Funktion

Damit Netze nicht „wild“ entstehen, brauchen Sie ein Ordnungssystem. In vielen Unternehmen funktioniert eine dreidimensionale Struktur sehr gut: Standort (wo ist das Netz), Zone (Sicherheitsdomäne/Routingdomäne) und Funktion (wofür wird es genutzt). Dieses Schema ist sowohl für klassische On-Prem-Netze als auch für hybride Umgebungen geeignet.

• Standort: ber, muc, ham oder Standortnummern
• Zone: internal, dmz, guest, mgmt, iot/ot
• Funktion: clients, servers, voice, printers, wlan, cameras

Namensschema für Subnetze

• Schema: <funktion>-<zone>-<standort>
• Beispiele: clients-internal-ber, servers-internal-ber, guest-untrusted-ber, mgmt-restricted-ber
• Regeln: klein, keine Umlaute/Leerzeichen, Bindestrich als Trenner

Welche Felder in jede Subnetting-Doku gehören

Die wichtigste Entscheidung ist: Welche Informationen sind Pflicht und welche optional? Pflichtfelder müssen immer ausgefüllt werden, sonst wird die Doku unzuverlässig. Optionale Felder nutzen Sie nur, wenn sie in Ihrer Umgebung echte Entscheidungen unterstützen. So verhindern Sie „Feldinflation“ und halten die Doku pflegbar.

Pflichtfelder pro Subnetz

• Name: nach Konvention (z. B. clients-internal-ber)
• Subnetz (CIDR): IPv4 und ggf. IPv6-Präfix
• Standort: Kürzel/Bezeichnung
• Zone/VRF: Sicherheitsdomäne bzw. Routing-Domäne
• VLAN-ID: wenn VLAN-basiert
• Gateway: IP + Gateway-Ort (Gerät/Interface)
• Adressvergabe: DHCP ja/nein, Scope-Referenz, ggf. Relay
• DNS: Resolver/Domain (oder Standardverweis)
• Owner: verantwortliches Team/Person
• Status: geplant, aktiv, deprecated, retired

Optionale Felder, die oft sinnvoll sind

• DHCP-Range: Start/Ende, Lease-Time
• Reservierte Bereiche: Infrastruktur, statische IPs, Wachstum
• Kommunikationsbeziehungen: high-level „darf wohin?“ (Security-Flow)
• MTU/QoS: bei abweichenden Anforderungen (Storage/VoIP/Overlay)
• Letzter Review: Datum, nächster Review, Change-Referenz

Subnetting verständlich machen: Blockgrößen, Reserven und Wachstum

Eine Doku ist dann gut, wenn sie nicht nur den Ist-Zustand zeigt, sondern auch erklärt, wie Wachstum geplant ist. Das wichtigste Konzept ist die Reservenplanung: Nicht jedes Subnetz muss „auf Kante“ dimensioniert sein. Ein zu knappes Netz führt schnell zu ad hoc Erweiterungen und damit zu Intransparenz. Ein zu großes Netz kann Segmentierung und Broadcast-Domänen unnötig aufblasen. Die Lösung ist: bewusst dimensionieren und dokumentieren, welche Reservebereiche vorgesehen sind.

Pragmatische Reserve-Regeln (IPv4)

• Infrastruktur-Block: z. B. .2–.49 (Gateways, Switch/AP/Controller, statische Systeme)
• DHCP-Block: z. B. .50–.200 (Clients, dynamische Geräte)
• Wachstum: z. B. .201–.254 für künftige Erweiterungen oder Reservierungen

Dokumentationshinweis: Warum ein /26 oder /27?

Wenn Sie kleinere Netze wie /26 oder /27 nutzen, dokumentieren Sie die Begründung: „nur Drucker und Scanner“, „IoT mit strikt begrenzter Hostanzahl“, „punkt-zu-punkt Transitnetz“. Das verhindert, dass später „einfach noch ein paar Geräte“ hineingeschoben werden und die ursprüngliche Logik zerstören.

Subnetting und VLANs: Beziehung sauber dokumentieren

In vielen Enterprise-Netzen gilt „ein VLAN – ein Subnetz“. Diese Kopplung ist einfach zu betreiben und reduziert Fehler. Wichtig ist, dass Sie die Beziehung in der Doku eindeutig halten: VLAN-ID, VLAN-Name, Subnetz, Gateway und Zone/VRF gehören zusammen. Für VLAN-Tagging ist IEEE 802.1Q die maßgebliche Referenz.

Empfohlenes Subnetz-&-VLAN-Feldset

• VLAN: 120
• VLAN-Name: clients-internal-ber
• Subnetz: 10.12.0.0/24
• Gateway: 10.12.0.1 (SVI auf ber-sw-core-01)
• Zone/VRF: internal / vrf-corp

Gateway und Routing klar festhalten: Wo wird geroutet?

Viele Subnetz-Dokus scheitern an einem Detail: Sie nennen das Gateway, aber nicht den Ort. In der Praxis ist das entscheidend – etwa wenn Gateways auf dem Core-Switch liegen, auf einer Firewall (Subinterfaces), auf einem Router-on-a-stick oder in einer VRF. Dokumentieren Sie daher „Gateway-IP“ und „Gateway-Device/Interface“ sowie optional „Gateway-Typ“.

Gateway-Felder, die Missverständnisse verhindern

• Gateway-IP: 10.12.0.1
• Gateway-Gerät: ber-sw-core-01
• Gateway-Typ: SVI / Routed Interface / Firewall-Subinterface
• Routing-Domäne: VRF-Name (falls vorhanden)

DHCP- und DNS-Bezug dokumentieren: Ohne diese Infos bleibt Subnetting „halb“

Ein Subnetz ist im Betrieb selten allein. DHCP und DNS sind die häufigsten Abhängigkeiten, die bei Problemen übersehen werden. Deshalb sollte Ihre Subnetting-Doku immer eine Referenz enthalten: Wo ist der DHCP-Scope? Gibt es DHCP-Relay/IP Helper? Welche DNS-Resolver werden verteilt? Welche Domain-Suffixe gelten? Für DNS-Standards ist der RFC Editor eine zuverlässige Quelle, wenn Sie technische Details nachschlagen möchten.

DHCP-Template (kurz, aber vollständig)

• Scope-Name: dhcp-clients-internal-ber
• Range: 10.12.0.50–10.12.0.200
• Lease: 24h
• Relay: ip helper auf ber-sw-core-01
• Reservierungen: kritische Geräte mit MAC/Hostname referenzieren

DNS-Referenz pro Subnetz

• Resolver: corp-dns-01/02
• Domain: corp.example
• Besonderheiten: Split-DNS, interne/externe Zonen (falls relevant)

Security-Kontext: Subnetze als Teil der Segmentierung dokumentieren

Subnetting-Dokumentation ist nicht nur „Netztechnik“, sondern auch Security-Grundlage. Subnetze sollten einer Sicherheitszone zugeordnet sein, und es sollte klar sein, über welche Kontrollpunkte (Firewall/ACL/Proxy/NAC) Kommunikation gesteuert wird. Sie müssen keine vollständigen Regelwerke in die Subnetzliste schreiben, aber ein high-level Flow hilft enorm: „Clients dürfen nur via Proxy ins Internet“ oder „IoT darf nur zu NTP und Management-Server“. Für Policy- und Zonenkonzepte ist der NIST-Leitfaden zu Firewalls und Firewall Policies eine hilfreiche Referenz.

Minimaler Security-Block pro Subnetz

• Zone: internal / dmz / guest / mgmt / iot
• Kontrollpunkt: Firewall-Cluster XY, ACL auf Core, Proxy Z
• Flows (high-level): erlaubte Ziele/Services in Stichworten

IPv6 in der Subnetting-Doku: Präfixe und Vergabe sauber ergänzen

Auch wenn IPv4 häufig dominiert: Eine moderne Dokumentation sollte IPv6 strukturiert mitführen, zumindest als Plan. Wichtig sind Präfixzuweisung (pro Standort/Zone), Adressvergabe (SLAAC/DHCPv6), Router Advertisements und DNS-AAAA-Strategie. Der häufigste Fehler ist „IPv6 läuft irgendwie mit“ – ohne Firewalling und ohne Dokumentation. Das kann Sicherheitslücken erzeugen.

IPv6-Felder, die Sie mindestens dokumentieren sollten

• IPv6-Präfix: z. B. 2001:db8:120::/64 (Beispiel)
• Vergabe: SLAAC, DHCPv6 oder statisch
• Gateway/RA: wer sendet RAs, welche Policy gilt
• DNS: AAAA-Records, Resolver, Domain

Darstellung und Lesbarkeit: So wird Subnetting-Doku „anfängerfreundlich“

Die beste Struktur hilft wenig, wenn sie nicht schnell gelesen werden kann. Deshalb lohnt sich ein konsistentes Layout. Auch wenn Sie kein spezielles IPAM nutzen, können Sie Ihre Dokumentation so gestalten, dass sie klar, filterbar und auditfähig ist.

• Ein Subnetz = eine Zeile/ein Datensatz: keine Mischtexte, keine „Sammelnetze“ ohne Aufschlüsselung
• Klare Spalten: Name, CIDR, Zone, VLAN, Gateway, DHCP, Owner, Status
• Verlinkungen: Link zur VLAN-Doku, zum Standort, zum Runbook, zum Change
• Versionierung: Review-Datum und Owner sichtbar (auch bei Exporten)

Tooling: Excel starten, IPAM wachsen – aber nur eine Wahrheit

Viele Teams starten mit Tabellen. Das ist okay, solange Sie eine zentrale Quelle definieren und Change-Gates einführen. Spätestens bei vielen Standorten, vielen VLANs und hoher Änderungsfrequenz ist ein IP Address Management (IPAM) sinnvoll, weil es Struktur, Berechtigungen, Historie und Integrationen bietet. Ein verbreitetes Beispiel ist NetBox, das IPAM und DCIM kombiniert und sich gut als zentrale Quelle für Prefixe, VLANs und Standorte eignet.

Warnsignale, dass Tabellen nicht mehr reichen

• Regelmäßige IP-Konflikte oder Overlaps (insbesondere bei VPN/Cloud)
• Mehrere Teams ändern Netze parallel
• Subnets wachsen unkontrolliert, Reserven sind unbekannt
• Audits verlangen nachvollziehbare Änderungen und Verantwortlichkeiten

Prozess: So bleibt Ihre Subnetting-Doku aktuell

Subnetting-Dokumentation veraltet nicht wegen fehlender Tools, sondern wegen fehlender Prozessintegration. Die wirksamste Regel ist: Kein Netz-Change ohne Doku-Update. Das gilt für neue Subnetze, Anpassungen von DHCP-Ranges, Änderungen am Gateway-Ort oder die Einführung neuer Zonen/VRFs.

Change-Gate für Subnetze

• Jede Subnetzänderung hat ein Ticket/Change mit Begründung
• Subnetz-Datensatz wird angelegt/aktualisiert (CIDR, Name, Zone, VLAN, Gateway, DHCP/DNS)
• Post-Checks sind definiert (Erreichbarkeit Gateway, DHCP-Lease, DNS-Auflösung, Routing)
• Review-Datum wird gesetzt, Owner bleibt verantwortlich

Review-Routine (leicht, aber effektiv)

• Monatlich: Stichprobe von Subnetzen auf DHCP/Gateway/Owner-Korrektheit
• Quartalsweise: Overlap-Checks für VPN/Cloud/Partnernetze, Reserven prüfen
• Halbjährlich: Adressstrategie überprüfen (Wachstum, neue Zonen, IPv6-Fortschritt)

Typische Fehler in Subnetting-Dokus – und wie Sie sie vermeiden

• Nur CIDR, kein Kontext: Subnetz ohne Zone/Gateway/Owner ist operativ wertlos
• Keine Reserven: „DHCP nutzt alles“ führt zu Konflikten mit statischen IPs
• Gateway-Ort fehlt: IP ist bekannt, aber nicht, wo geroutet wird
• Overlaps ignoriert: VPN/Cloud/M&A ohne zentrale Planung verursacht Doppelvergabe
• Mehrere Wahrheiten: Tabelle, DHCP-Konsole, Wiki widersprechen sich
• Kein Prozess: Änderungen passieren, die Doku bleibt – Change-Gate fehlt

Checkliste: Subnetting-Doku, die sauber und verständlich bleibt

• Struktur definiert (Standort + Zone/VRF + Funktion) und Namenskonvention eingeführt
• Pflichtfelder pro Subnetz festgelegt (Name, CIDR, Zone/VRF, VLAN, Gateway-Ort, DHCP/DNS, Owner, Status)
• Reserven dokumentiert (Infrastruktur-/DHCP-/Wachstumsbereiche) und statische IP-Vergabe geregelt
• Gateway und Routing-Domäne eindeutig beschrieben (SVI/Firewall-Subinterface, VRF)
• DHCP-Scopes und DNS-Resolver als Referenz verknüpft (inkl. Relay/IP Helper, Lease-Time)
• Security-Kontext ergänzt (Zone, Kontrollpunkt, high-level Flows)
• IPv6 berücksichtigt (Präfixe, Vergabe, RA/DHCPv6, DNS-AAAA-Strategie)
• Eine führende Quelle definiert (Tabelle/IPAM) und „Parallel-Dokus“ vermieden
• Change-Gate eingeführt: kein Subnetz-Change ohne Update und Post-Checks
• Review-Zyklen etabliert, um Drift früh zu erkennen und Reserven regelmäßig zu prüfen

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.