Routing-Dokumentation: IGP/BGP, Policies, Communities und Pfade

Eine saubere Routing-Dokumentation ist der Unterschied zwischen einem Netzwerk, das „irgendwie“ funktioniert, und einem Netzwerk, das planbar, sicher und schnell entstörbar ist. Gerade in Enterprise-Umgebungen mit mehreren Standorten, hybrider Cloud, SD-WAN, Internet-Edge und strengen Security-Anforderungen entstehen Routing-Probleme selten durch fehlende Protokolle, sondern durch fehlenden Kontext: Welche IGP-Domänen existieren? Wo endet eine Area? Welche BGP-Policies gelten an welchem Peering? Welche Communities steuern Traffic Engineering? Welche Pfade sind bevorzugt, welche sind Backup? Ohne nachvollziehbare Dokumentation wird Routing zum Bauchgefühl, Änderungen werden riskant und Incidents dauern länger, weil Teams erst rekonstruieren müssen, warum eine Route so aussieht, wie sie aussieht. Dieser Artikel zeigt, wie Sie Routing-Dokumentation professionell aufbauen: für IGP (OSPF/IS-IS) und BGP, inklusive Policies, Communities, Summaries, Pfadlogik, Validierungschecks und Governance, damit Routing als Living Documentation im Betrieb zuverlässig funktioniert.

Warum Routing-Dokumentation im Betrieb so häufig fehlt

Routing wird oft „in der Konfiguration“ dokumentiert: Prefix-Listen, Route-Maps, Policies, Filter – alles steht irgendwo auf Routern. Das Problem: Konfiguration ist Umsetzung, nicht Erklärung. Sie zeigt selten die Architekturabsicht, die Grenzen (Boundaries) und die Begründung für Trade-offs. Zusätzlich sind Routing-Designs über viele Geräte verteilt: Ohne zentrale Sicht ist unklar, welche Regeln global gelten und welche nur lokal als Ausnahme entstanden sind.

• Verteilte Wahrheit: Policy-Logik ist auf vielen Geräten fragmentiert.
• Fehlende Intent-Ebene: „Warum wird Route X bevorzugt?“ steht nicht im Config.
• Drift: Ähnliche Standorte unterscheiden sich, weil lokale Fixes nie zurückgeführt wurden.
• Komplexe Abhängigkeiten: Routing, Segmentierung (VRFs), NAT, Firewalls und Cloud-Transits greifen ineinander.

Das Zielbild: Routing als Modell statt als Gerätesammlung

Gute Routing-Dokumentation beschreibt nicht jedes Interface und nicht jede Zeile Policy, sondern ein Modell aus Domänen, Grenzen, Pfaden und Regeln. Sie beantwortet im Kern vier Fragen:

• Domänen: Welche Routing-Domänen existieren (IGP- und BGP-Scope, VRFs, Tenants)?
• Grenzen: Wo wird verteilt, aggregiert, gefiltert oder geleakt (Area-Border, Route-Reflector, Transit)?
• Pfadlogik: Welche Pfade sind primär, welche sekundär, und wodurch wird das gesteuert?
• Policies: Welche Prefixe dürfen wohin, mit welchen Attributen, und mit welchen Ausnahmen?

Artefakte, die eine Routing-Dokumentation in Enterprise-Netzen braucht

Statt eines monolithischen Dokuments funktioniert Routing-Doku am besten als Set kleiner, klarer Artefakte. Die folgenden Bausteine decken die meisten Anforderungen ab und lassen sich gut aktuell halten.

• Routing-Topologie als Layered View: L3-Sicht mit Domänen, Peers, Transits, Boundaries und Default Paths.
• IGP-Design-Notiz: Areas/Levels, Summaries, Redistribution-Grenzen, Failure Domains.
• BGP-Design-Notiz: AS-Struktur, iBGP/eBGP, Route Reflection, Policies, Communities, TE-Strategie.
• Policy-Katalog: standardisierte Policy-Bausteine (Import/Export), Prefix-Klassen, Ausnahmen.
• Community- und Tagging-Referenz: Bedeutung, Format, Verantwortlichkeit, Beispiele.
• Validation & Runbooks: Standardchecks, Troubleshooting-Flows, Post-Change-Validierung.

IGP-Dokumentation: OSPF/IS-IS nachvollziehbar abbilden

IGP-Dokumentation ist dann gut, wenn sie Failure Domains und Grenzen sichtbar macht. In der Praxis bedeutet das: Areas/Levels, ABRs/L1-L2-Übergänge, Summarization-Punkte, Redistribution und Default-Route-Verhalten. OSPF und IS-IS sind unterschiedlich, aber die Dokumentationslogik ist sehr ähnlich.

Was in einer IGP-Doku immer stehen sollte

• Domänen-Layout: OSPF Areas oder IS-IS Levels, inklusive Zweck (z. B. Campus vs. WAN vs. DC).
• Grenzrouter: ABRs (OSPF), L1/L2-Router (IS-IS), inklusive Rolle und Standort.
• Summaries: welche Prefix-Bereiche werden wo aggregiert, und warum?
• Default Route: wo entsteht sie, wie wird sie verteilt, wann wird sie entzogen?
• Redistribution: wo wird zwischen IGP/BGP/Static verteilt, mit welchen Filtern?
• Konvergenzerwartung: Zielwerte, Timer-Prinzipien, Abhängigkeiten (z. B. BFD).

Summaries und Boundaries als „Stabilitätsanker“

Routing wird stabiler und skalierbarer, wenn Summaries bewusst platziert sind. Dokumentieren Sie Summaries nicht nur als Prefix, sondern mit Boundary, Motivation und Nebenwirkungen (Blackholing-Risiko, Leak-Ausnahmen, DR-Szenarien). Ein praktischer Standard ist, Summaries als „Policy-Objekte“ zu führen: Prefix + Boundary + Leak-Regeln + Validierungschecks.

BGP-Dokumentation: AS-Struktur, Peering-Modelle und Route Reflection

BGP-Dokumentation ist häufig die anspruchsvollste, weil BGP nicht nur „Konnektivität“ liefert, sondern Policy-Engine ist: Import/Export, Traffic Engineering, Multi-Homing, Cloud-Transits, Partnernetze und Security-Anforderungen. Eine gute BGP-Doku beschreibt zuerst das Modell (AS-Struktur, iBGP/eBGP, RRs), dann die Policies (Prefix-Klassen, Attribute), dann die Communities (Steuerung), und schließlich die erwarteten Pfade.

Minimaler BGP-Überblick, der im Betrieb hilft

• AS-Nummern: internes AS, externe AS der Provider/Partner/Cloud-Peers.
• Peering-Typen: iBGP intern, eBGP zu Providern/Partnern/Cloud, inkl. Multihop-Logik.
• Route-Reflector-Design: RRs, Cluster-IDs, Redundanz, Clients pro Domäne.
• Rollen: Edge, Transit, Hub, DC-Core, Cloud-Gateway.
• Prefix-Klassen: z. B. „Site-LAN“, „DC-Services“, „Cloud-Tiers“, „DMZ“, „Management“.

Policy-Intent statt Konfigzeilen

Dokumentieren Sie Policies als Intent: „Was soll passieren?“ statt „welche Route-Map-Zeile?“. Ein guter Standard ist eine Policy-Matrix pro Peering:

• Import: welche Prefix-Klassen werden akzeptiert, welche verworfen, welche Attribute werden gesetzt?
• Export: welche Prefix-Klassen dürfen raus, welche nur eingeschränkt, welche niemals?
• Default Handling: wird eine Default Route akzeptiert/erzeugt? Unter welchen Bedingungen?
• Safety Nets: Max-Prefix, RPKI/Filter-Strategie (wenn vorhanden), Bogon-Filter, Dampening-Policy (falls genutzt).

Communities: Das zentrale Steuerinstrument dokumentieren

Communities sind in vielen Netzen der „Schlüssel“ für Traffic Engineering und Policy-Entscheidungen. Wenn ihre Bedeutung nicht dokumentiert ist, wird Betrieb gefährlich: Teams setzen Communities falsch, Provider-Policies greifen unerwartet, oder Standorte verhalten sich uneinheitlich. Eine Community-Referenz ist deshalb Pflicht.

Was eine Community-Referenz enthalten sollte

• Namensschema: z. B. COMM-LOCALPREF-HIGH, COMM-NOEXPORT, COMM-REGION-DE.
• Format: Standard-Community (16-bit:16-bit) oder Large Community (3x 32-bit), inklusive Konvention.
• Bedeutung: präzise Wirkung (z. B. LocalPref setzen, Provider-Announcement steuern, Blackholing triggern).
• Scope: wo gilt sie (nur intern, nur Edge, nur Provider X)?
• Owner: wer darf neue Communities definieren, wer reviewt Änderungen?
• Beispiele: typische Kombinationen und „Do/Don’t“ (z. B. welche Communities sich ausschließen).

Als technische Referenz für BGP und Communities eignen sich IETF-Dokumente; ein stabiler Einstiegspunkt ist der RFC Editor, über den Sie Protokollstandards und Begriffe nachvollziehbar verlinken können.

Pfade und Traffic Engineering: „Erwartetes Verhalten“ dokumentieren

Routing-Dokumentation ist erst dann wirklich betrieblich nützlich, wenn sie das erwartete Pfadverhalten beschreibt. Das heißt: Wo geht Traffic im Normalfall lang? Was ist der Backup-Pfad? Welche Attribute steuern das? Und wie erkennt man, dass das Verhalten abweicht?

Praktische Pfad-Dokumentation pro Domäne

• Default Paths: pro Standort/VRF, inkl. bevorzugtem Upstream (DIA vs. Hub vs. DC).
• Exit-Policy: welche Sites brechen lokal aus, welche backhaulen?
• Failover: was passiert bei Linkausfall, RR-Ausfall, Provider-Ausfall?
• Symmetrie: wo ist asymmetrischer Verkehr akzeptabel, wo problematisch (Firewalls, NAT, Statefulness)?
• Messpunkte: welche Monitoring-Signale belegen den Pfad (NetFlow, Telemetry, BGP-States, RTT/Loss)?

Redistribution und Route Leaks: Die gefährlichsten Stellen dokumentieren

Viele schwer zu diagnostizierende Routing-Probleme entstehen an Übergängen: Redistribution zwischen IGP und BGP, Inter-VRF Leaks, Cloud-Route-Imports, statische Default Routes oder alte „temporäre“ Leaks. Diese Punkte sind hochkritisch und sollten in der Doku besonders hervorgehoben werden.

Checkliste für Übergangspunkte

• Ort: welches Gerät/Cluster ist Boundary?
• Regelwerk: welche Prefix-Klassen dürfen übergehen, welche niemals?
• Attribute: welche Attribute werden gesetzt (Tagging/Community/Metric)?
• Schutz: Max-Prefix, Filter, Default-Deny-Prinzip für Leaks.
• Ausnahmen: befristete Leaks mit Owner, Risiko, Ablaufdatum.

Routing-Dokumentation und Segmentierung: VRFs, Zonen und Policies verknüpfen

Routing existiert selten „pur“. In modernen Netzen ist Routing eng mit VRFs und Security-Zonen gekoppelt. Dokumentieren Sie deshalb Routing nicht losgelöst, sondern verknüpfen Sie:

• VRF-Kontext: Routing-Domänen pro VRF (BGP/IGP-Instanzen, Default Paths, Transits).
• Zone/Trust Boundary: wo sitzt der Kontrollpunkt (Firewall/Proxy) im Pfad?
• Policy-Intent: welche Kommunikation ist erlaubt, und wo wird sie geprüft?

Für die Strukturierung von Kontrollzielen (z. B. Segmentierung, Logging, Change-Disziplin) sind praxisnahe Kataloge wie die CIS Controls hilfreich, weil sie technische und betriebliche Maßnahmen in überprüfbare Themenblöcke übersetzen.

Validierungschecks: Routing-Dokumentation muss prüfbar sein

Dokumentation senkt MTTR nur, wenn sie im Incident schnell in konkrete Checks übersetzt werden kann. Deshalb sollten Routing-Dokumente immer einen Validierungsteil enthalten: Welche Zustände sind „normal“? Welche Abweichungen sind kritisch? Welche Kommandos oder Monitoring-Signale belegen das?

Beispiele für Standardchecks

• IGP: Neighbor/Adjacency-States, Anzahl Routen, erwartete Summaries, SPF/LSA/LSDB-Indikatoren (je nach Protokoll).
• BGP: Session-State, Prefix-Anzahl, Routenattribute (LocalPref, AS-Path, MED), Community-Set, Best-Path-Entscheidung.
• Pfade: Traceroute/MTR aus definierten Messpunkten, RTT/Loss-Baselines, Flow-Logs.
• Guardrails: Max-Prefix Trigger, Route Leak Alarme, ungewöhnliche Default-Routen.

Governance: Wie Routing-Dokumentation aktuell bleibt

Routing ändert sich kontinuierlich: neue Prefixe, neue Standorte, neue Policies, Providerwechsel, Cloud-Routen. Ohne Prozesskopplung veraltet jede Doku. Die wirksamste Regel ist eine Definition of Done: Ein Routing-Change gilt erst als abgeschlossen, wenn Dokumentation und Validierungsnachweise aktualisiert sind.

Definition of Done für Routing-Changes

• Peering/Policy-Änderung ist im Policy-Katalog dokumentiert (Intent, Scope, Ausnahmen)
• Community-Referenz aktualisiert (falls neue Communities oder Bedeutungen)
• L3-Diagramm (Layered View) aktualisiert und datiert
• Validierungschecks ausgeführt und im Change verlinkt (Pre-/Post-Checks)
• Source of Truth aktualisiert (Prefixe, VRFs, Site-Transits, Owner)

Wenn Sie Change- und Knowledge-Management prozessorientiert ausrichten, kann ein ITIL-orientierter Rahmen helfen; ein Überblick dazu findet sich bei ITIL Best Practices.

Pragmatische Dokumentationsform: So bleibt Routing-Doku lesbar

Routing-Dokumentation wird schnell zu lang, wenn sie versucht, Konfiguration zu kopieren. Halten Sie sie schlank, indem Sie:

• Intent dokumentieren: Regeln, Grenzen, Pfade, nicht jede Zeile Policy
• Bausteine standardisieren: Prefix-Klassen, Policy-Patterns, Community-Katalog
• Verlinken statt duplizieren: auf Source of Truth (Prefixe/VRFs), Tickets, Diagramme, Runbooks
• Layered Views nutzen: L3-View für Routing, Security-View für Kontrollpunkte, Flow-Views für kritische Services

Typische Fehler in Routing-Dokumentation und wie Sie sie vermeiden

• Konfig-Kopien: führen zu Drift und sind schwer zu pflegen; besser Intent + Referenzen.
• Keine Boundaries: Areas/Transits/Leak-Punkte fehlen; Folge sind Leaks und Fehlinterpretationen.
• Communities ohne Katalog: „magische Zahlen“ sind ein Betriebsrisiko; Community-Referenz ist Pflicht.
• Keine Pfadbeschreibung: niemand weiß, was normal ist; Pfad- und Failover-Verhalten dokumentieren.
• Fehlende Validierungschecks: Änderungen werden nicht reproduzierbar geprüft; Standardchecks definieren.
• Ausnahmen ohne Ablauf: temporäre Leaks werden dauerhaft; Exception Records mit Ablaufdatum.

Checkliste: Routing-Dokumentation für IGP/BGP, Policies und Pfade

• Eine L3-Topologieansicht existiert (Domänen, Peers, Transits, Boundaries, Default Paths)
• IGP-Dokumentation beschreibt Areas/Levels, Summaries, Redistribution und Konvergenzerwartungen
• BGP-Dokumentation beschreibt AS-Struktur, Peering-Modelle, Route Reflection und Prefix-Klassen
• Policy-Katalog definiert Import/Export-Intent pro Peering, inklusive Schutzmechanismen und Ausnahmen
• Community-Referenz ist vollständig (Bedeutung, Scope, Owner, Beispiele, Do/Don’t)
• Pfade und Traffic Engineering sind dokumentiert (Primär/Backup, Failover-Logik, Symmetrieanforderungen)
• Übergänge (Redistribution, Inter-VRF Leaks) sind explizit dokumentiert und besonders geschützt
• Validierungschecks sind Bestandteil der Doku (Standardkommandos, Monitoring-Signale, Baselines)
• Source of Truth ist führend für Prefixe/VRFs/Sites; Doku verlinkt statt zu kopieren
• Definition of Done koppelt Routing-Changes an Doku-Updates, Reviews und Post-Checks

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.