Layer-3-Diagramme: Routing, Subnetze und Gateways sauber darstellen

Layer-3-Diagramme sind das wichtigste Werkzeug, um Routing, Subnetze und Gateways so darzustellen, dass Betrieb, Security und externe Partner dieselbe Netzrealität verstehen. Während Layer-2-Pläne zeigen, wie Switches VLANs transportieren, erklären Layer-3-Pläne, wie Daten zwischen Netzen fließen: Wo liegt das Default Gateway? Welche Router oder Firewalls routen zwischen Segmenten? Welche Prefixe gehören zu welchem Standort, welcher VRF oder welcher Zone? Und welche Routing-Protokolle sorgen dafür, dass Pakete zuverlässig den richtigen Weg finden – inklusive Redundanz und Failover? Ohne diese Sicht entstehen typische Probleme: falsche Annahmen über Erreichbarkeit, unklare Zuständigkeiten bei Incident Response, riskante Changes im WAN oder „Routing-Spaghetti“ in der Cloud. Ein guter Layer-3-Plan ist nicht überladen, aber präzise: Er dokumentiert Subnetze, Routing-Domänen, Next-Hops, Schlüsselpfade und Kontrollpunkte. Dieser Leitfaden zeigt, wie Sie Layer-3-Diagramme sauber aufbauen, welche Informationen zwingend hinein müssen, wie Sie Routing (statisch, OSPF, BGP) verständlich kennzeichnen und wie Sie Gateways, VRFs und Standorte so kombinieren, dass Ihre Dokumentation im Alltag wirklich hilft.

Was ein Layer-3-Diagramm leisten muss

Ein Layer-3-Diagramm ist eine „Landkarte“ für IP-Connectivity. Es beantwortet nicht nur „Was ist verbunden?“, sondern vor allem „Über welchen Pfad und über welches Gateway?“. Damit ist es das Kernartefakt für Troubleshooting („Warum kommt dieses Subnetz nicht ins Internet?“), für Security („Welche Zone routet wohin?“) und für Planung („Wie binden wir einen neuen Standort an?“). Der Fokus liegt auf Routing-Entscheidungen, nicht auf Switching-Details.

• Subnetze/Prefixe: Welche Netze existieren, wo sind sie verortet und welchem Zweck dienen sie?
• Gateways: Wo liegt das Default Gateway für ein Subnetz (Router, Firewall, SVI, Cloud Gateway)?
• Routing-Domänen: Welche VRFs, Routing-Instanzen oder Mandanten gibt es?
• Routing-Verfahren: Static Routes, OSPF/IS-IS, BGP, Policy-Routing – auf geeigneter Abstraktionsebene.
• Redundanz: Primär-/Sekundärpfade, ECMP, Failover-Mechanismen, Default-Route-Strategie.

Physische, Layer-2- und Layer-3-Sicht sinnvoll trennen

Ein häufiger Dokumentationsfehler ist das Vermischen von Ebenen. Layer-3-Diagramme werden unlesbar, wenn sie gleichzeitig jeden Switchport, jedes VLAN und jedes Routingdetail abbilden sollen. Der richtige Ansatz ist ein Satz aus Ansichten: Layer 1/2 zeigt Verkabelung und VLAN-Transport, Layer 3 zeigt IP-Pfade und Gateways. Sie verknüpfen diese Welten über eindeutige Objekte: Standorte, Geräte, Interfaces und VRFs – aber Sie zeichnen nicht alles in ein Bild.

• Layer 1/Physik: Racks, Patchfelder, Links, Medien
• Layer 2: VLANs, Trunks, STP, LACP
• Layer 3: Subnetze, Gateways, Routing, VRFs, WAN/Internet-Pfade
• Verknüpfung: gleiche Geräte-/Interface-IDs, konsistente Standortkürzel, Links auf Source of Truth

Subnetze und Prefixe verständlich darstellen

Subnetze sind das Fundament jedes Layer-3-Plans. Sie sollten nie nur als „10.10.0.0/24“ auftauchen, sondern immer mit Zweck und Kontext: Standort, Zone, VRF und Kritikalität. In der Praxis ist ein IPAM-Register (Prefix, Owner, Status, Zweck) die Source of Truth – das Diagramm zeigt eine lesbare, verdichtete Ansicht. Für private IPv4-Adressbereiche ist RFC 1918 die grundlegende Referenz; für IPv6-Adressarchitektur RFC 4291.

• Prefix/Mask: z. B. 10.20.30.0/24 oder 2001:db8:120::/64
• Name/Zweck: z. B. „USER-FLOOR2“, „SERVER-APP“, „MGMT“
• Zuordnung: Standort/Site, Zone, VRF/Tenant
• Status: planned/active/deprecated (besonders wichtig bei Migrationen)

Gateways sauber dokumentieren: „Wo wird geroutet?“

Im Layer-3-Design ist die wichtigste Frage oft nicht das Subnetz selbst, sondern das Gateway: Welches Gerät routet den Traffic? Liegt das Default Gateway auf einem Router, auf einer Firewall, auf einem L3-Switch (SVI), in einer Cloud-Gateway-Komponente oder in einer virtuellen Appliance? Ein Diagramm muss diese Entscheidung sichtbar machen, weil davon Security-Policies, Failover-Verhalten und Troubleshooting abhängen.

• Gateway-Typ: SVI auf L3-Switch, Router-Interface, Firewall-Interface, Cloud Gateway
• Gateway-IP: optional als Interface-Label, wenn nicht zu sensibel (oder als Muster, z. B. „.1“)
• HA-Modell: HSRP/VRRP, aktive/passive Firewall, ECMP – als Prinzip
• Policy-Point: routet „nur“ oder erzwingt auch Security (Firewall-Zonenübergang)?

Routing-Domänen: VRFs, Mandanten und Sicherheitszonen

Moderne Netzwerke sind selten „ein großer Routing-Topf“. VRFs (Virtual Routing and Forwarding) trennen Routing-Tabellen, häufig nach Mandanten, Sicherheitszonen oder Umgebungen (Prod/Dev). Cloud-Umgebungen nutzen ähnliche Konzepte (separate VPC/VNet, Routing Tables). Ein gutes Layer-3-Diagramm zeigt diese Domänen als klare Container: Jede VRF/Domain enthält ihre Prefixe und Gateways, und Verbindungen zwischen Domänen sind explizit (z. B. über Firewall, NAT oder definierte Route Leaks).

• VRF-Container: z. B. VRF-PROD, VRF-MGMT, VRF-GUEST
• Inter-VRF-Kommunikation: nur über definierte Kontrollpunkte (Firewall/Proxy) oder dokumentierte Route Leaks
• Zone vs. VRF: Zone ist Security-Logik, VRF ist Routing-Logik – beides kann zusammenfallen, muss aber nicht
• Cloud-Parallele: VPC/VNet + Routing Tables als analoges Modell

Routing im Diagramm kennzeichnen: Statisch, OSPF, BGP und Default Routes

Layer-3-Diagramme werden erst dann wirklich nützlich, wenn Routing nicht „magisch“ wirkt. Sie müssen nicht jede Route zeichnen, aber Sie sollten sichtbar machen, wie Routing grundsätzlich funktioniert: Welche Protokolle laufen in welcher Domäne? Wo sind Routing-Grenzen? Wo findet Redistribution statt? Und wie wird der Default-Route-Pfad ins Internet oder ins WAN realisiert?

Statische Routen sinnvoll darstellen

Statische Routen sind in Edge- und Spezialfällen üblich, etwa für kleine Außenstellen, DMZ-Sonderpfade oder als Backup. Im Diagramm genügt oft ein Pfeil mit Next-Hop und Scope, z. B. „Static: 10.50.0.0/16 via FW-A“. Wichtig ist, statische Pfade als solche zu markieren, weil sie bei Änderungen leicht vergessen werden.

• Notation: „Static: Prefix → Next-Hop“
• Scope: welche Domäne/VRF ist betroffen?
• Redundanz: zweite statische Route mit höherer Administrative Distance (als Prinzip) dokumentieren

OSPF im Diagramm: Areas, ABRs und Nachbarschaften

OSPF ist in Campus- und Data-Center-Netzen verbreitet. Für Diagramme reicht es meist, Areas, ABRs und die OSPF-Domänen zu zeigen, statt jede Nachbarschaft auszuschreiben. Markieren Sie Backbone/Area 0, Area-Grenzen und die Geräte, die zwischen Areas vermitteln. Als technische Referenz ist RFC 2328 (OSPFv2) hilfreich.

• Area-Container: z. B. Area 0 (Backbone), Area 10 (Campus), Area 20 (DC)
• ABR-Markierung: Router, die Areas verbinden (klar kennzeichnen)
• Summarization: falls genutzt, als Notiz („Summaries at ABR“) statt Detailtabellen

BGP im Diagramm: ASNs, Peering und Policy

BGP ist im WAN, an Internet-Edges und in modernen Data-Centern (Spine-Leaf) häufig der Standard. In Diagrammen sind ASNs, Peers und Peering-Typen (iBGP/eBGP) entscheidend, plus die Stellen, an denen Policies wirken (Route Maps, Communities, Local Preference) – auf hoher Ebene. Statt jedes Prefix-Set zu zeichnen, dokumentieren Sie Peering-Beziehungen und die Richtung von Route-Announcements. Grundlage ist RFC 4271.

• ASN pro Domäne: eigenes AS für DC, Edge, Provider-Connection (falls relevant)
• Peering-Typ: eBGP zum Provider, iBGP intern (klar markieren)
• Policy-Hinweis: z. B. „Outbound filtering“, „Default only“, „Community tagging“
• Redundanz: dual-homed Peering, ECMP oder bevorzugter Pfad (konzeptionell)

Default Gateway, Default Route und Internet Breakout

Zwei Begriffe werden oft verwechselt: Das Default Gateway ist die L3-Adresse, an die Hosts ihre Pakete schicken. Die Default Route ist die Route, die ein Router/Firewall nutzt, wenn kein spezifischerer Eintrag passt. In Diagrammen sollten beide Ebenen klar sein: Host → Gateway (im Subnetz), Router/Firewall → Default Route (zum nächsten Hop, Provider oder zentralen Breakout). Diese Klarheit verhindert typische Fehler in Incident Calls („Gateway stimmt doch, warum geht Internet nicht?“).

• Gateway-Ebene: pro Subnetz das Gateway-Gerät/HA-Paar dokumentieren
• Default-Route-Ebene: wohin geht 0.0.0.0/0 bzw. ::/0? (Provider, zentrale Firewall, SD-WAN-Hub)
• Breakout-Modell: zentral vs. lokal (pro Standort) – als Diagramm-Annotation
• Egress-Kontrolle: Proxy/NAT/Firewall als Kontrollpunkt klar markieren

Redundanz und Failover in Layer-3-Plänen sichtbar machen

Layer-3-Redundanz ist oft komplexer als „zwei Links“. Sie kann über mehrere Mechanismen entstehen: Routing-Konvergenz, ECMP, HSRP/VRRP, SD-WAN-Overlays, duale Provider, duale Firewalls. Ein gutes Diagramm zeigt nicht nur, dass Redundanz existiert, sondern wie sie sich im Normalzustand verhält: aktiver Pfad, Backup-Pfad, Lastverteilung. Das ist entscheidend für Change-Risiken und Incident-Entscheidungen.

• Primär/Backup: Pfeile oder Labels („Primary“, „Secondary“) für kritische Pfade
• ECMP: als „Equal Cost“ markieren (statt „irgendwie redundant“)
• HA Gateways: HSRP/VRRP-Paar als gemeinsames Gateway-Objekt zeichnen
• Routing-Konvergenz: Notiz „failover via OSPF/BGP convergence“ mit erwarteter Größenordnung (z. B. „fast reroute“ wenn genutzt, sonst ohne Zahlen)

WAN- und Standortdiagramme: Routing über Provider und SD-WAN

Für viele Unternehmen ist das wichtigste Layer-3-Diagramm das WAN: Standorte, Providerlinks, SD-WAN-Edges, Hubs, VPN-Overlays, BGP/OSPF-Grenzen. Hier sollten Sie besonders sauber trennen: Underlay (Providerleitungen) und Overlay (Tunnels/Policies). Für Dokumentation bedeutet das: zwei Layer im Diagramm oder zwei Diagramme. So vermeiden Sie, dass alles wie ein „Garnknäuel“ wirkt.

• Underlay: Providerlinks, Übergabepunkte, Circuit-IDs (optional als Referenz), Redundanzprinzip
• Overlay: SD-WAN, IPsec, GRE – Tunnelbeziehungen und Policy-Logik
• Routing-Grenzen: wo endet OSPF, wo beginnt BGP, wo findet Default-Distribution statt?
• Breakout: zentraler Internetzugang vs. lokaler Breakout pro Site

Cloud Layer-3-Diagramme: VPC/VNet, Routing Tables und Transit

In Cloud-Umgebungen sind Layer-3-Konzepte ebenfalls zentral, aber anders benannt: Subnetze, Route Tables, Internet Gateway/NAT Gateway, Transit Gateway, VNet Peering, private Endpoints. Ein gutes Diagramm sollte diese Komponenten als Routing-Knoten darstellen: Welche Subnetze haben welche Route Table? Wo ist der Egress? Wie ist On-Prem angebunden (VPN/Direct Connect/ExpressRoute/Interconnect)? Und wo findet Inspection statt (zentrale Firewall, Network Virtual Appliance)?

• Subnetzklassen: public/private/management (oder vergleichbare Kategorien)
• Routing Tables: pro Subnetzgruppe zugeordnet, nicht „irgendwo“
• Transit: TGW/Hub als Routing-Drehscheibe, Peering als Link
• Inspection: zentrale Firewall/Service, die zwischen Domänen routet oder filtert

Notation und Symbole: Damit Layer-3-Pläne sofort lesbar sind

Lesbarkeit entsteht durch Konsistenz. Entscheiden Sie sich für wenige Symbole und feste Beschriftungen. Für Router/Firewalls reicht oft ein generisches Icon, solange Rollen klar sind. Wichtiger als das Icon ist die Textlogik: Prefixe, Gateways, Protokolle, VRFs. Nutzen Sie außerdem Legenden: Farbcodes für VRFs/Zonen, Linientypen für Underlay/Overlay, Pfeile für Default-Route-Richtung.

• Linientypen: durchgezogen = L3-Link, gestrichelt = Tunnel/Overlay, gepunktet = Management (wenn relevant)
• Farbcodes: pro VRF oder Zone (nur wenn konsequent und in Legende erklärt)
• Link-Label: Interface/Linkname optional, wichtiger sind Protokoll und Rolle („OSPF Area 0“, „eBGP to ISP“)
• Prefix-Boxen: Subnetze als Boxen in Zonen/Standorten, statt auf jeden Link zu schreiben

Layer-3-Diagramm-Template: Pflichtfelder, die Audits und Betrieb erleichtern

Ein Template verhindert, dass Diagramme von Person zu Person völlig unterschiedlich aussehen. Gleichzeitig sorgt es für E-E-A-T in der Dokumentation: klare Verantwortlichkeit, nachvollziehbarer Stand, reproduzierbare Struktur. Halten Sie das Template schlank, aber verpflichtend.

• Metadaten: Owner (Teamrolle), Datum, Version, Scope (Site/Domain/VRF)
• Routing-Info: Protokolle (OSPF/BGP/Static), Area/ASN-Hinweise (high level)
• Gateway-Logik: Gateway-Geräte je Subnetzklasse, HA-Modell (HSRP/VRRP/Cluster)
• Default-Route-Logik: Breakout-Modell, zentrale Egress-Punkte, redundante Pfade
• Legende: Linientypen, Farbcodes, Abkürzungen (VRF, GW, Po, ECMP)

Schritt-für-Schritt: Ein sauberes Layer-3-Diagramm erstellen

Ein strukturierter Ablauf verhindert, dass Sie sich in Details verlieren. Beginnen Sie mit Domänen und Gateways, erst danach kommen Protokoll-Details. Für große Umgebungen erstellen Sie mehrere Diagramme: pro Standort, pro VRF, pro Domäne (WAN, DC, Cloud).

• Schritt 1: Scope festlegen (welche Site/VRF/Domain) und Diagramm in Ebenen strukturieren
• Schritt 2: Routing-Knoten platzieren (Core/Edge/Firewall/Cloud Transit), Rollen beschriften
• Schritt 3: Subnetze/Prefixe als Boxen eintragen (mit Zweck und Zuordnung)
• Schritt 4: Gateways je Subnetz markieren (SVI/Firewall/Router), HA-Prinzip notieren
• Schritt 5: Routing-Protokolle und Grenzen einzeichnen (Areas/ASNs, ohne Detailtabellen)
• Schritt 6: Default-Route und Egress-Pfade darstellen (zentral/lokal, primär/sekundär)
• Schritt 7: Redundanzlogik prüfen (ECMP, Backup, Failover) und im Diagramm klar labeln
• Schritt 8: Legende, Version, Owner und Links auf Register/SoT ergänzen

Typische Fehler in Layer-3-Diagrammen

• Subnetze ohne Zweck: nur Prefixe; Lösung: Name/Zweck/Zone/VRF ergänzen.
• Gateways fehlen: niemand weiß, wo geroutet wird; Lösung: Gateway-Geräte und HA-Modell markieren.
• Default-Route unsichtbar: Internetprobleme schwer erklärbar; Lösung: Egress-Pfade explizit einzeichnen.
• Protokolle nicht benannt: Routing wirkt „magisch“; Lösung: OSPF/BGP/Static klar kennzeichnen.
• Alles in einem Bild: unlesbar; Lösung: pro Domain/VRF/Site separate Views.
• Redundanz nur behauptet: „zwei Links“ ohne Verhalten; Lösung: primär/sekundär oder ECMP sauber labeln.
• Inkonsequente Namen: unterschiedliche VLAN/Prefix/VRF-Namen in Diagramm und Register; Lösung: Naming Standards und zentrale Source of Truth.

Aktualität sichern: Change-Gate und Review-Routine

Layer-3-Diagramme veralten schnell: neue Prefixe, neue VRFs, neue Provider, neue Cloud-Routen. Der wirksamste Mechanismus ist ein Change-Gate: Jede Änderung an Routing, Subnetzen oder Gateways gilt erst als abgeschlossen, wenn IPAM/SoT und Diagramm aktualisiert und verlinkt sind. Ergänzend hilft eine Review-Routine für Tier-1-Domänen (WAN, Perimeter, Core, Cloud Transit): monatlicher Quick-Check und quartalsweise Governance.

• Definition of Done: keine Change-Schließung ohne Update von IPAM/Diagramm/Links
• Review monatlich: Default-Route-Logik, kritische Prefixe, Provider-/Transitpfade
• Review quartalsweise: VRF-/Zonenmodell, Routing-Grenzen, Redundanzprinzipien
• Versionierung: Diagramme versionieren (Wiki-Versionen oder Git), damit Änderungen nachvollziehbar sind

Outbound-Links für verlässliche Referenzen

• RFC 1918: Private IPv4 Addressing
• RFC 4291: IPv6 Addressing Architecture
• RFC 2328: OSPF Version 2
• RFC 4271: Border Gateway Protocol 4
• IEEE Standards Association (ergänzend für L2/L3-nahe Normen)
• diagrams.net (draw.io) für Diagramme

Checkliste: Layer-3-Diagramme für Routing, Subnetze und Gateways sauber darstellen

• Das Diagramm hat klaren Scope (Site/Domain/VRF) und ist nicht überladen; große Umgebungen sind in mehrere Views aufgeteilt.
• Subnetze/Prefixe sind strukturiert dargestellt: Prefix, Name/Zweck, Zuordnung (Standort, Zone, VRF) und Status.
• Gateways sind sichtbar: pro Subnetz ist klar, welches Gerät routet (SVI/Router/Firewall/Cloud Gateway) und welches HA-Prinzip gilt.
• Routing-Domänen sind sauber getrennt: VRFs/Mandanten als Container, Inter-VRF-Pfade sind explizit und kontrolliert.
• Routing ist nicht „magisch“: statisch/OSPF/BGP sind markiert, Area-/ASN-Grenzen sind verständlich eingezeichnet.
• Default-Route und Egress sind eindeutig: Breakout-Modell (zentral/lokal), primäre/sekundäre Pfade und Kontrollpunkte (Proxy/NAT/Firewall) sind klar.
• Redundanz ist erklärbar: ECMP oder aktiv/backup ist gekennzeichnet, Failover-Verhalten ist im Normalzustand nachvollziehbar.
• Notation ist konsistent: Linientypen, Farben (wenn genutzt) und Labels folgen einer Legende.
• Metadaten sind Pflicht: Owner, Datum, Version, Scope-Hinweis und Links auf IPAM/SoT sind enthalten.
• Aktualität ist prozessintegriert: Change-Gate und regelmäßige Reviews halten Routing, Prefixe und Gateways dauerhaft korrekt.

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.