Layer-3 Diagramme: Routing Domains, Areas, BGP Sessions und Summaries

Layer-3 Diagramme sind die zentrale „Landkarte“ für Routing in modernen IT-Netzwerken. Sie zeigen nicht Kabel und Patchfelder (Layer 1) und auch nicht VLAN-Trunks oder STP-Logik (Layer 2), sondern die entscheidenden Fragen für Betrieb und Architektur: Welche Routing Domains existieren? Wo liegen IGP-Areas oder IS-IS-Level-Grenzen? Welche BGP Sessions verbinden Standorte, Datacenter, Provider und Cloud? Wo wird aggregiert, gefiltert oder geleakt? Und welche Summaries sorgen dafür, dass Routing skalierbar bleibt, statt in tausenden Einzelpräfixen zu ersticken? In vielen Unternehmen sind Routing-Konfigurationen zwar vorhanden, aber der Kontext fehlt – und genau dann werden Changes riskant und Incidents langsam. Ein gutes L3-Diagramm macht Pfade, Boundaries und Intent sichtbar: Es zeigt, wie Traffic laufen soll, wo die „Kontrollpunkte“ im Routing sind und welche Designprinzipien gelten. Dieser Artikel erklärt, wie Sie Layer-3 Diagramme professionell erstellen: Routing Domains, Areas, BGP Sessions und Summaries verständlich zeichnen – als wiederverwendbare, pflegefähige Artefakte für Rechenzentrum, Campus, WAN und Hybrid-Cloud.

Warum L3-Diagramme im Alltag den größten ROI liefern

Routing ist der Teil des Netzwerks, der im Betrieb am häufigsten als Ursache oder Verstärker auftaucht: falsche Default-Route, unerwarteter Pfad über den Backup-Link, Route Leaks zwischen VRFs, ungewollte Redistribution oder ein BGP-Neighbor, der zwar „up“ ist, aber falsche Attribute propagiert. Ohne L3-Diagramm wird Troubleshooting zur Rekonstruktion: Teams sammeln Befehlsausgaben, vergleichen Tabellen und versuchen, das „Bild im Kopf“ zu bauen. Mit einem guten L3-Diagramm startet die Diagnose an der richtigen Stelle: an Domänengrenzen, Transits und Pfadlogik. Gleichzeitig wird Architekturarbeit schneller, weil neue Anforderungen (neue Sites, neue Cloud-Region, neue Partner) gegen ein klares Modell geplant werden können.

• MTTR sinkt: Pfade, Peering-Punkte und Boundaries sind sofort sichtbar.
• Changes werden sicherer: Summaries, Filters und Default-Handling sind dokumentiert statt implizit.
• Skalierung wird planbar: Route-Aggregation und Failure Domains sind bewusst gestaltet.
• Teamfähigkeit: Neue Kolleginnen und Kollegen verstehen das Routingmodell schneller.

Die Leitfrage eines Layer-3 Diagramms

Ein L3-Diagramm beantwortet eine klare Leitfrage: „Wie werden Präfixe zwischen Routing Domains ausgetauscht, und welche Pfade gelten als normal, Backup und Ausnahme?“ Daraus folgt automatisch, was in das Diagramm gehört: Domänen, Boundaries, Sessions, Summaries, Default-Pfade und – wenn nötig – die wichtigsten Policy-Hinweise. Alles, was rein Layer 2 oder Layer 1 ist, bleibt draußen. Wenn Sie den OSI-Denkrahmen als Ordnungshilfe nutzen möchten, ist eine kompakte Übersicht hilfreich, z. B. Cloudflare zum OSI-Modell.

Routing Domains: Was Sie im L3-Diagramm als „Container“ darstellen sollten

In modernen Netzen ist „das Routing“ selten eine einzige Domäne. Häufig gibt es mehrere Routing Domains, die bewusst voneinander getrennt sind: Campus, WAN, Datacenter, Cloud-Transit, Management und ggf. Tenant-spezifische VRFs. Ein L3-Diagramm wird erst lesbar, wenn Sie diese Domains als Container darstellen. Das verhindert, dass Sessions und Präfixe im „freien Raum“ schweben.

Typische Routing Domains in Enterprise-Netzen

• Campus/Core Domain: häufig IGP (OSPF/IS-IS) mit klaren Area/Level-Grenzen.
• WAN/SD-WAN Domain: oft BGP-orientiert (Overlay/Underlay), Hubs, Breakouts, Policy-Steuerung.
• Datacenter Domain: L3-Fabric (eBGP oder iBGP), DC-Edge, Service-Tiers.
• Cloud/Transit Domain: VPN/Direct-Connectivity-Gateways, Transit-VPC/VNet-Modelle, Route-Policies.
• Management Domain: OOB/Management-VRF, streng kontrollierte Pfade.

Areas und Levels: IGP-Topologien verständlich zeichnen

IGP-Diagramme (OSPF/IS-IS) werden oft zu technisch oder zu vage. Für ein L3-Diagramm ist entscheidend, dass Areas/Levels als Struktur sichtbar sind und die „Grenzrouter“ klar markiert werden. Sie müssen nicht jede LSA- oder Metric-Logik zeichnen – aber Sie sollten sichtbar machen, wo Summaries entstehen, wo Default Routes injiziert werden und wo Redistribution stattfindet.

OSPF: Was ins Diagramm gehört

• Area-Container: Area 0 (Backbone) und Nicht-Backbone-Areas als klar abgegrenzte Flächen.
• ABRs: Area Border Router als Rollenbadge, weil sie für Summaries/Inter-Area-Flow entscheidend sind.
• Default-Origination: wo wird eine Default Route erzeugt oder verteilt (z. B. am WAN-Edge)?
• Summarization: wo werden Site-Prefixe zu einer Summary zusammengefasst?
• Redistribution-Punkte: Übergänge IGP↔BGP oder IGP↔Static als „hochrisikoreiche Boundaries“ markieren.

IS-IS: Was ins Diagramm gehört

• Level-1/Level-2: L1 als „Site/Access“-Bereich, L2 als Backbone/Transit (je nach Design).
• L1/L2-Router: Übergangsknoten deutlich markieren.
• Summaries/Leak-Regeln: falls genutzt, als Boundary-Notizen sichtbar machen.

BGP Sessions: Peering sichtbar machen, ohne das Diagramm zu überladen

BGP ist in vielen Netzen die zentrale Policy-Engine: Provider-Anbindungen, Multi-Homing, WAN-Overlays, Datacenter-Fabrics und Cloud-Transits arbeiten häufig mit BGP. Gute L3-Diagramme zeigen BGP Sessions als „Beziehungen“ zwischen Rollen: Edge↔Provider, Hub↔Spoke, RR↔Client, DC-Leaf↔Spine, Cloud-Gateway↔On-Prem. Entscheidend ist, dass Sie Session-Typ und Kontext sichtbar machen, ohne in Konfigdetails zu ertrinken.

Welche BGP-Informationen im Diagramm wirklich helfen

• iBGP vs. eBGP: klar unterscheiden (z. B. durch Linienart oder Label).
• ASNs: eigenes AS und externe ASNs an den richtigen Stellen (Provider, Partner, Cloud).
• Route Reflectors: RR-Cluster als Strukturcontainer mit Clients (wichtig für Skalierung und Failure Domains).
• Session-Zweck: Transit, Peering, Backup, Private Interconnect (kurz, nicht als Essay).
• Policy-Hinweise: z. B. „Default nur von Provider A“, „No-Transit“, „Community X steuert LocalPref“ (als knappe Annotation).

Wenn Sie Begriffe oder Protokolldetails sauber referenzieren möchten, eignet sich der RFC Editor als stabile Quelle für Internet-Standards.

Summaries: Aggregation als eigenes Diagramm-Element

Summaries sind der unterschätzte Schlüssel für Routing-Skalierung. Ohne Aggregation explodieren Routingtabellen, Failure Domains werden zu groß, und ein einzelner Site-Change kann unerwartet globale Effekte haben. In vielen Umgebungen existieren Summaries zwar in Configs, aber nicht als dokumentiertes Konzept. Ein L3-Diagramm sollte Summaries deshalb bewusst als Objekte darstellen: „Dieser Standort exportiert 10.42.0.0/16“ statt „hier gibt es viele /24“. Das macht Grenzen sichtbar und erleichtert Fehlersuche bei Blackholing oder Leaks.

Was bei Summaries dokumentiert werden sollte

• Summary-Prefix: der aggregierte Block (z. B. pro Site/Region).
• Aggregation Point: wo wird die Summary erzeugt (Hub, ABR, DC-Edge, Cloud-Transit)?
• Leak-Ausnahmen: welche spezifischen Prefixe dürfen ausbrechen (z. B. für Migrationen)?
• Failure- und Blackhole-Schutz: z. B. Nullroute/Discard-Strategie oder Conditional Advertisement (wenn genutzt).
• Validierungschecks: woran erkennt man, dass Aggregation korrekt ist (Prefix-Anzahl, Best-Path, Reachability)?

Default Paths und Exit-Strategie: Pfadlogik lesbar darstellen

Viele Routingprobleme sind keine „Protokollprobleme“, sondern Pfadlogikprobleme: falscher Exit, unerwarteter Backhaul, asymmetrische Pfade über stateful Firewalls oder NAT. Ein L3-Diagramm sollte deshalb Default Paths bewusst zeigen: Wo ist der bevorzugte Exit (Internet Breakout, Hub, Datacenter)? Welche Pfade gelten als Backup? Welche Kriterien steuern die Auswahl (LocalPref, MED, IGP-Metric, SD-WAN SLA)?

Darstellungsregeln für Pfade

• Primärpfad: solide Linie, prominent.
• Backuppfad: gestrichelte Linie oder dünner, aber eindeutig.
• Policy-Steuerung: kurze Labels („LP=200“, „COMM:REGION-DE“, „SLA>=X“), ohne zu detailverliebt zu werden.
• Asymmetrie-Hinweis: dort markieren, wo asymmetrischer Verkehr kritisch ist (Firewalls, NAT, Load Balancer).

Boundaries: Die kritischen Übergänge, die im Diagramm sichtbar sein müssen

Die gefährlichsten Stellen im Routing sind Übergänge: IGP↔BGP Redistribution, Inter-VRF Leaks, Provider↔Enterprise Peering, Cloud↔On-Prem Transit. Diese Boundaries sind typische Root-Cause-Zonen für Route Leaks, Blackholes, Default-Route-Fehler oder Prefix Explosion. Ein professionelles L3-Diagramm markiert diese Boundaries explizit – idealerweise mit einem „Kontrollpunkt“-Symbol oder einem Rahmen.

Boundary-Typen, die Sie im Diagramm kennzeichnen sollten

• Redistribution: zwischen IGP und BGP oder zwischen VRFs (falls vorhanden).
• Filtering/Policy: Import/Export-Filter, Max-Prefix-Schutz, Bogon-Filter (als Hinweis).
• Aggregation: Summarization-Punkt (siehe oben).
• Security-Kontrollpunkt: wenn Routingpfade durch stateful Controls laufen (nur als Hinweis, nicht als Regelwerk).

Diagramm-Layouts nach Einsatzfall: Campus, WAN, Datacenter, Cloud

Ein L3-Diagramm für ein Campusnetz sieht anders aus als für ein Datacenter-Fabric oder ein SD-WAN. Der Diagrammtyp bleibt „Layer 3“, aber die Schwerpunkte variieren. Das ist wichtig, damit die Diagramme nicht generisch und damit nutzlos werden.

Campus L3 Diagramm

• IGP-Areas/Levels, ABRs/L1L2-Router, Default-Origination
• L3-Gateways für Access-Segmente als Rollenhinweis (ohne VLAN-Listen)
• Uplinks zu WAN/Internet Edge als klare Transits

WAN/SD-WAN L3 Diagramm

• Hubs/Spokes, Underlay/Overlay-Transits (auf konzeptioneller Ebene)
• Default-Exit-Strategie (local breakout vs. backhaul)
• BGP-Session-Typen, Pfadpräferenzen und Failover-Logik

Datacenter L3 Diagramm

• Fabric-Model (Spine/Leaf als Rollen), eBGP/iBGP, RRs (falls iBGP)
• DC-Edge und externe Peers (WAN, Internet, Cloud Interconnect)
• Summaries/Route Targets (nur wenn relevant und knapp)

Cloud/Hybrid L3 Diagramm

• Cloud-Gateways/Transits, On-Prem Peers, VPN/Direct Connectivity als L3-Beziehung
• Routing-Domänen (z. B. Prod/Non-Prod) als Container
• Prefix-Austauschlogik (Import/Export) als kurze Policy-Hinweise

Für cloudnahe Architekturdiagramme helfen offizielle Icon-Sets als gemeinsame Symbolsprache, z. B. AWS Architecture Icons oder Azure Architecture Icons.

Welche Daten Sie nicht ins L3-Diagramm schreiben sollten

Ein häufiger Grund für unlesbare L3-Diagramme ist „Datenfriedhof“: jede Subnetzliste, jede Interface-IP, jede Route-Map. Diese Informationen gehören in Source-of-Truth-Systeme, Konfig-Repositories oder LLDs, nicht in die L3-Grafik. Das Diagramm soll das Modell vermitteln, nicht den vollständigen Ist-Zustand in Textform duplizieren.

• Keine vollständigen Prefix-Listen pro Standort (stattdessen Summaries + Referenz)
• Keine Interface-IP-Tabelle (stattdessen Peering-Beziehungen und Rollen)
• Keine vollständigen Community-Kataloge (stattdessen Verweis auf Community-Referenzseite)
• Keine „Policy-Map-Textblöcke“ (stattdessen Intent-Labels: Import/Export Klassen)

Source of Truth verknüpfen: Diagramme als Verweisschicht

L3-Diagramme werden besonders stark, wenn sie auf führende Datenquellen verlinken: Prefixe, VRFs, Sites, Circuits, Peerings. So bleibt das Diagramm schlank und gleichzeitig überprüfbar. In vielen Teams übernimmt ein IPAM/DCIM/CMDB-System die führende Rolle; das Diagramm zeigt die Struktur und verlinkt auf Details. Wenn Sie NetBox nutzen, hilft die NetBox Dokumentation, um Prefixe, VRFs, Sites und Tags so aufzubauen, dass sie als Single Point of Reality dienen.

• Prefixe: im IPAM, Diagramm zeigt Summaries/Scopes.
• VRFs/Tenants: als Container im SoT, Diagramm zeigt Beziehungen und Leak-Punkte.
• Circuits: Provider-Links als Objekte, Diagramm zeigt Transits und Redundanz.
• Ownership: Teams/Owner als Metadaten für schnellere Eskalation im Incident.

Standards und Metadaten: Damit L3-Diagramme als „Living Documentation“ funktionieren

Ein L3-Diagramm ist nur dann nützlich, wenn es vertrauenswürdig ist. Vertrauen entsteht durch Metadaten und klare Regeln: Owner, Scope, Last Updated, Version und Review-Zyklen. Zusätzlich braucht es Diagrammstandards (Linienarten, Symbole, Legende), damit alle im Team dieselbe Sprache sprechen.

Minimaler Diagrammstandard für L3

• Linienarten: solid = primärer Pfad, dashed = Backup, dotted = control/keepalive (falls relevant)
• Container: Domains/Areas/VRFs als Rahmen mit Namen
• Session-Labels: iBGP/eBGP, ASNs, RR-Cluster, kurz und konsistent
• Summary-Objekte: Aggregation als eigenes Element mit Boundary
• Metadaten: Owner, Last updated, Scope (Region/Umgebung), Version

Definition of Done: Wann ein L3-Diagramm aktualisiert werden muss

Diagramme veralten nicht, weil niemand „gerne zeichnet“, sondern weil Prozesse Updates nicht erzwingen. Ein pragmatischer Ansatz: Wenn ein Change Routingpfade, Sessions, Areas, Summaries oder Boundaries betrifft, ist das L3-Diagramm Teil der Done-Kriterien. Damit wird Dokumentation automatisch zum Betriebsasset.

• Neue Site/Region angebunden
• Neue BGP Session oder neues Peering
• Änderung an Default-Exit-Strategie (DIA vs. Backhaul)
• Neue Summary oder Änderung von Aggregationsgrenzen
• Redistribution/Leak-Änderungen zwischen Domänen/VRFs

Wenn Sie Change- und Knowledge-Management prozessorientiert aufsetzen möchten, bietet ITIL Best Practices hilfreiche Leitplanken für nachvollziehbare Änderungen und Dokumentationspflichten.

Praktische Anti-Pattern: Was L3-Diagramme unbrauchbar macht

• „Alles in einem Bild“: L1/L2/L3 gemischt; Lösung: Layered Views mit klarer Leitfrage.
• Keine Boundaries: Areas/Transits/Leaks sind unsichtbar; Lösung: Container und Kontrollpunkte markieren.
• Prefix-Friedhof: alle /24 im Diagramm; Lösung: Summaries + Verlinkung auf IPAM.
• Keine Pfadlogik: primär/backup unklar; Lösung: Linienarten und kurze Policy-Labels.
• Metadaten fehlen: niemand vertraut dem Stand; Lösung: Owner + Last updated verpflichtend.
• Policy nur in Config: Communities/Import/Export nicht dokumentiert; Lösung: Intent-Annotationen und Referenzseiten.

Checkliste: Layer-3 Diagramme für Routing Domains, Areas, BGP Sessions und Summaries

• Das Diagramm beantwortet die Leitfrage „Prefix-Austausch und Pfadlogik zwischen Routing Domains“
• Routing Domains sind als Container dargestellt (Campus, WAN, DC, Cloud, Management)
• IGP-Struktur ist sichtbar (OSPF Areas oder IS-IS Levels, ABR/L1L2-Übergänge, Default-Origination)
• BGP Sessions sind klar unterschieden (iBGP/eBGP, ASNs, RR-Cluster, Session-Zweck)
• Summaries sind als eigene Objekte dokumentiert (Prefix, Aggregation Point, Leak-Ausnahmen, Validierungschecks)
• Default Paths und Backup-Pfade sind lesbar (Linienarten, kurze Policy-Hinweise, Asymmetrie-Markierungen)
• Boundaries sind explizit markiert (Redistribution, Filter, Leak-Punkte, Transits)
• Das Diagramm dupliziert keine Tabellen (keine vollständigen Prefix- oder Interface-IP-Listen)
• Metadaten sind verpflichtend (Owner, Scope, Last updated, Version) und Updates sind Teil der Done-Kriterien
• Outbound-Links referenzieren Primärquellen (RFC Editor, Cloud Icon Sets, ITIL für Prozessrahmen)

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.