Eine saubere Routing-Dokumentation ist in Unternehmensnetzwerken oft der entscheidende Faktor, ob Störungen in Minuten oder in Stunden gelöst werden. Routing ist die „Logik des Verkehrsflusses“: Es bestimmt, wie Subnetze miteinander kommunizieren, wie Standorte verbunden sind, wie Internet-Breakouts funktionieren und welche Pfade im Failover-Fall genutzt werden. In der Praxis entstehen Probleme selten, weil OSPF oder BGP „kompliziert“ sind, sondern weil Informationen fehlen: Welche OSPF-Areas gibt es? Wo liegen ABRs? Welche BGP-Peers existieren, welche Policies greifen, welche Default-Routen sind gewollt? Welche statischen Routen sind temporär, welche dauerhaft – und warum? Ohne nachvollziehbare Dokumentation wird jedes Routing-Change riskant, und im Incident ist unklar, ob ein Problem an Nachbarschaften, Route-Maps, Prefix-Listen, Redistribution oder einer veralteten statischen Route liegt. Dieser Leitfaden zeigt, wie Sie OSPF, BGP und Static Routes verständlich festhalten – mit praxiserprobten Templates, klaren Ebenen (Design vs. Betrieb), sinnvollen Diagrammen und Prozessen, die Aktualität sicherstellen.
Warum Routing-Dokumentation im Alltag so viel bewirkt
Routing-Dokumentation ist keine „Papierarbeit“, sondern ein Betriebsmittel. Sie reduziert Ausfallzeiten, erleichtert Kapazitäts- und Redundanzplanung und ist ein Sicherheitsfaktor: Fehlkonfigurationen im Routing können Traffic unbeabsichtigt umleiten, Segmentierungsgrenzen aushebeln oder externe Netze exponieren. Für Teams ist Routing-Doku außerdem ein gemeinsamer Referenzpunkt zwischen Netzwerk, Security, Cloud und Applikation.
- Schnelleres Troubleshooting: Pfade, Next-Hops, Zuständigkeiten und Policies sind nachvollziehbar.
- Sicherere Changes: Impact-Analyse gelingt, weil Abhängigkeiten und Redistribution klar sind.
- Stabile Redundanz: Failover-Mechanismen (ECMP, Präferenzen, Tracking) sind dokumentiert und testbar.
- Audit- und Übergabefähigkeit: Providerwechsel, M&A oder Outsourcing werden planbarer.
- Wissenssicherung: Routing-Know-how bleibt nicht an einzelnen Personen hängen.
Dokumentationsprinzip: Trennen Sie Design, Umsetzung und Betrieb
Routing-Dokumentation wird besonders dann gut, wenn sie in drei Ebenen organisiert ist. So finden Einsteiger den Überblick, Profis die Details und der Betrieb konkrete Handlungsanweisungen.
- Architektur (HLD): Routing-Domänen, Standorte, Redundanzprinzip, Internet-Edge, Sicherheitsgrenzen.
- Technische Umsetzung (LLD): OSPF-Areas, BGP-Sessions, Redistribution, Summaries, Filter, Timer, ASNs.
- Betrieb (Runbooks): Prüfpfade, typische Fehlerbilder, Change-Checklisten, Monitoring- und Eskalationswege.
Ein Diagramm, eine Frage
Routing-Diagramme scheitern oft daran, dass sie alles gleichzeitig zeigen wollen. Nutzen Sie lieber mehrere Diagramme: ein WAN-/BGP-Übersichtsdiagramm, ein OSPF-Area-Diagramm, eine Edge/Internet-Policy-Sicht. So bleibt die Darstellung lesbar und wartbar.
Was in jede Routing-Dokumentation gehört
Unabhängig davon, ob Sie OSPF, BGP oder statische Routen nutzen: Es gibt ein Kernset an Informationen, das nahezu immer benötigt wird. Wenn Sie diese Basis konsequent pflegen, vermeiden Sie die meisten typischen Routing-„Überraschungen“.
Pflichtinhalte (Kernset)
- Routing-Domänen: VRFs, Mandanten, interne/externe Domänen, Übergänge.
- Geräte-Rollen: Core, Edge, Border, ABR/ASBR, Route Reflector (falls genutzt).
- Adress- und Linkkonzept: Transitnetze, Loopbacks, Punkt-zu-Punkt-Links, Nummerierungslogik.
- Protokolle und Scope: wo läuft OSPF, wo BGP, wo statisch (und warum).
- Redundanz: aktive/aktive vs. aktiv/passiv, ECMP, Präferenzen, Failover-Trigger.
- Policies: Import/Export-Filter, Summarization, Default-Strategie, Redistribution-Regeln.
- Ownership: Verantwortliche Teams, Review-Zyklen, Change-Prozess und Ticket-Referenzen.
Optionale Inhalte (je nach Umgebung sehr sinnvoll)
- Timer/Parameter: Hello/Dead-Interval (OSPF), Hold/Keepalive (BGP), BFD-Einsatz.
- Security-Aspekte: Authentisierung, MD5/Keychain (OSPF), TTL-Security/MD5 (BGP), ACLs für Routing-Ports.
- Operational Data: Monitoring-KPIs, Log-Quellen, Baselines (Nachbarschaften, Prefix-Anzahlen).
OSPF dokumentieren: Areas, Rollen und Summarization verständlich festhalten
OSPF ist in vielen Unternehmensnetzwerken das Standard-IGP (Interior Gateway Protocol). Es ist robust, aber in großen Umgebungen nur dann gut beherrschbar, wenn Areas, ABRs, Summaries und Redistribution sauber dokumentiert sind. Technische Grundlagen und Begriffe finden Sie in der OSPF-Spezifikation RFC 2328 (OSPFv2) sowie für OSPFv3 in RFC 5340.
OSPF-Template für die Dokumentation
- OSPF-Process/Instance: Name/ID je VRF oder Domäne
- Router-ID: Quelle (Loopback X), Eindeutigkeit garantiert
- Areas: Area-IDs, Zweck, welche Standorte/Segmente enthalten sind
- ABRs: Geräte, die Areas verbinden (inkl. Rolle/Standort)
- ASBRs: Geräte, die externe Routen einspeisen (Redistribution-Punkte)
- Area-Typen: normal/stub/NSSA (wenn genutzt) und Begründung
- Summarization: wo wird zusammengefasst, welche Prefixe, warum
- Authentication: ja/nein, Methode, Scope
- Konvergenz: Timer/BFD-Policy (high-level), Failover-Intention
OSPF-Area-Übersicht als Tabelle
Eine praxistaugliche Darstellung ist eine Area-Tabelle, die auf einen Blick zeigt: Area-ID, Standort/Scope, ABR(s), Zusammenfassungen und Besonderheiten. Das ist im Incident oft wertvoller als lange Textblöcke.
Typische OSPF-Fallen, die in der Doku explizit adressiert werden sollten
- Unklare Router-ID-Strategie: Router-IDs wechseln nach Reboots, Nachbarschaften brechen.
- Redistribution ohne Kontrolle: externe Routen fluten OSPF (zu viele LSAs), Instabilität.
- Fehlende Summaries: große Netze ohne Aggregation erhöhen LSA-Last und Komplexität.
- Inkonsequente Area-Typen: Stub/NSSA uneinheitlich, Default-Verhalten unklar.
- Timer-Mischbetrieb: unterschiedliche Hello/Dead-Interval verhindern Nachbarschaften.
BGP dokumentieren: Peers, Policies und Pfadsteuerung beherrschbar machen
BGP ist das dominierende Protokoll für WAN, Provider-Anbindungen, Multi-Homing, SD-WAN-Edges und zunehmend auch in Data-Center-Designs. Der Schlüssel zur BGP-Dokumentation sind nicht nur Peer-IPs, sondern Policies: Was importieren wir? Was exportieren wir? Wie steuern wir Pfade (Local Preference, MED, Communities, AS-Path)? BGP-Grundlagen und Begriffe sind in der Spezifikation RFC 4271 (BGP-4) beschrieben.
BGP-Template für die Dokumentation
- ASN: eigenes ASN, private/public, je VRF/Domain (falls relevant)
- Peer-Liste: Peer-Name, Peer-IP, Remote ASN, Session-Typ (eBGP/iBGP)
- Peer-Rolle: Provider, Partner, DC-Edge, Cloud-Gateway, Route Reflector Client
- Transport: Interface/VRF, Source IP, Multi-hop ja/nein, BFD ja/nein
- Import-Policy: Prefix-Filter, Max-Prefix, Communities, LocalPref-Setzung
- Export-Policy: welche Prefixe, Aggregation, Communities, AS-Path Prepend
- Pfadsteuerung: Kriterien und Ziel (Primär/Backup, Geo-Preference, Traffic Engineering)
- Default-Strategie: Default-Route von Provider? Mehrere Defaults? Präferenzlogik?
- Security: Auth (MD5/Keychain), TTL Security, ACLs auf TCP/179
- Operational Limits: Max Prefix, Dampening (falls), Alarme, Eskalationswege
Policy-Dokumentation: „Warum“ statt nur „was“
Gerade bei BGP sollten Sie die Begründung dokumentieren: Warum setzen wir LocalPref für Provider A höher? Warum exportieren wir bestimmte Prefixe nicht? Warum nutzen wir Communities für Blackholing oder Traffic Steering? Ohne diese Intention sind spätere Änderungen riskant, weil man die Designziele nicht mehr kennt.
Typische BGP-Fallen, die Sie in der Doku absichern sollten
- Fehlende Prefix-Filter: Route Leaks, unerwünschte Routenannahme oder -advertisement.
- Keine Max-Prefix-Grenzen: bei Fehlverhalten des Peers wird die Routing-Tabelle überflutet.
- Unklare Default-Route-Logik: Asymmetrische Pfade und unerwartete Internet-Breakouts.
- Community-Nutzung ohne Standard: Bedeutung von Communities wird vergessen oder falsch interpretiert.
- Fehlende Dokumentation von iBGP-Design: Route Reflectors, Cluster-IDs, Redundanz unklar.
Statische Routen dokumentieren: Einfach, aber besonders gefährlich ohne Governance
Statische Routen wirken simpel: Zielprefix + Next-Hop. Genau deshalb werden sie häufig unkontrolliert eingesetzt – und genau deshalb werden sie gefährlich, wenn sie nicht sauber dokumentiert sind. Statische Routen sind sinnvoll für sehr kleine Netze, für Edge-Szenarien, für definierte Übergänge (z. B. zu Firewall/DMZ) oder als gezielte „Ausnahme“. Sie werden zum Problem, wenn sie als Dauerlösung für dynamische Umgebungen dienen oder wenn niemand mehr weiß, warum sie existieren.
Template für statische Routen
- Zielprefix: CIDR (z. B. 10.50.0.0/16)
- Next-Hop/Interface: IP oder Interface, ggf. Tracking
- Scope: in welcher VRF/Zone gilt die Route?
- Begründung: warum statisch statt dynamisch?
- Owner: verantwortliches Team
- Lifetime: dauerhaft oder temporär (mit Ablaufdatum)
- Abhängigkeiten: welche Services/Standorte hängen daran?
- Fallback: gibt es Backup-Route oder Tracking (IP SLA, BFD, Interface-Tracking)?
Statische Routen als „technische Schulden“ markieren
Wenn statische Routen nur Übergangslösungen sind, markieren Sie sie in der Doku bewusst als temporär und verknüpfen Sie sie mit einem Ticket/Projekt. Das verhindert, dass provisorische Routen jahrelang bleiben und später unvorhersehbare Pfade erzwingen.
Redistribution dokumentieren: Der Ort, an dem viele Netzwerke „leise“ kaputtgehen
Redistribution (Umverteilung) verbindet Routing-Welten: OSPF bekommt statische Routen, BGP bekommt interne Prefixe, oder umgekehrt. Das ist häufig notwendig, aber extrem fehleranfällig, wenn Filter und Metriken nicht sauber dokumentiert sind. Viele Instabilitäten entstehen durch unkontrollierte Redistribution oder fehlende Route-Tags, die Loops verhindern.
Pflichtfelder für Redistribution-Doku
- Quelle: welches Protokoll wird redistributiert (static, connected, OSPF, BGP)?
- Ziel: in welches Protokoll wird eingespeist?
- Ort: Gerät(e)/VRF(s), an denen das passiert (ASBR/Border)
- Filter: Prefix-Listen/Route-Maps, was ist erlaubt, was verboten?
- Metriken: Default-Metric, Typ (OSPF E1/E2), Intention
- Loop-Prevention: Tags/Communities, Regeln zur Vermeidung von Rückeinspeisung
- Risiko-Statement: was ist der schlimmste Fall bei Fehlkonfiguration (Route Leak, Loop, Blackhole)?
Parameter und Konvergenz: Dokumentieren Sie Zielwerte, nicht nur Zahlen
Timer, BFD, ECMP und Tracking sind oft der Unterschied zwischen „Failover klappt“ und „Failover dauert zu lange“. In der Dokumentation sollten Sie jedoch nicht nur Parameterwerte notieren, sondern die Zielsetzung: Welche Konvergenzzeit ist gewünscht? Welche Pfade sollen aktiv/aktiv laufen? Welche Events triggern Failover (Link Down, BFD Down, SLA-Check)?
- Konvergenzziel: z. B. „Failover WAN innerhalb 5–10 Sekunden“
- Methode: BFD für Peer-Detection, Tracking für Default-Routen, ECMP im Core
- Monitoring: welche Events/Alarme zeigen Konvergenzprobleme?
- Testplan: wie wird Failover regelmäßig getestet (ohne Produktionsrisiko)?
Routing-Diagramme: Welche Grafiken in der Praxis am meisten helfen
Für Routing sind Diagramme besonders effektiv, wenn sie nicht „jede Route“ zeigen, sondern Pfade und Grenzen. Folgende Diagrammtypen haben sich bewährt:
- WAN-/BGP-Übersicht: Standorte, Provider, Peers, Primär/Backup, Internet-Breakouts.
- OSPF-Area-Karte: Areas, ABRs, Summaries, ASBRs.
- Edge/Default-Policy: wo entstehen Default-Routen, wie wird Präferenz gesteuert?
- VRF-/Zonenübersicht: Routing-Domänen, Übergänge, Kontrollpunkte (Firewall/Policy).
Für konsistente Symbolik nutzen viele Teams etablierte Icon-Sets wie die Cisco Network Topology Icons, auch in herstellerneutralen Umgebungen.
Runbooks für Betrieb: Prüfpfade für OSPF, BGP und Static Routes
Eine Routing-Doku ist erst dann wirklich betrieblich, wenn sie Runbooks enthält: konkrete Prüfpfade, die im Incident funktionieren. Das reduziert Eskalationen und sorgt dafür, dass auch weniger erfahrene Kolleginnen und Kollegen systematisch vorgehen.
Runbook-Checkliste OSPF
- Nachbarschaften (Neighbor State) prüfen, betroffene Interfaces und Area-Zugehörigkeit
- Router-ID und Area-Typ plausibilisieren
- LSA-Überblick (unerwartete externe LSAs?), Summaries und Default-Information
- Timer-Mismatch und Authentisierung prüfen
- Fallback: Konfig-Delta zum letzten Change, Rollback-Option
Runbook-Checkliste BGP
- Session State (Idle/Active/Established), TCP/179 Erreichbarkeit, Source IP/VRF prüfen
- Prefix-Anzahlen (received/advertised), Max-Prefix-Events, Filter/Route-Maps prüfen
- Default-Route-Logik und Pfadattribute (LocalPref, MED, AS-Path) prüfen
- Community-Interpretation verifizieren (insbesondere Provider-Communities)
- Fallback: Traffic-Shift-Plan (z. B. LocalPref ändern) mit Freigabeprozess
Runbook-Checkliste statische Routen
- Next-Hop Reachability (ARP/ND, Interface State), Tracking-Status
- Route Presence in RIB/FIB, eventuelle konkurrierende dynamische Routen
- Temporäre Routen identifizieren (Ablaufdatum, Ticket)
- Asymmetrie prüfen (Rückweg vorhanden?)
- Fallback: Backup-Route aktivieren oder Change zurückrollen
Security und Compliance: Routing-Dokumentation ohne Informationsleck
Routing-Dokumentation kann sensible Informationen enthalten: Peers, Edge-Design, Management-Netze, Provider-Circuit-IDs. Schützen Sie die Dokumentation durch rollenbasierte Rechte, Audit-Trails und eine klare Trennung: Betriebsrelevante Details ja, Geheimnisse wie Passwörter oder Keys gehören in ein Secret-Management. Als Orientierung für dokumentierte Sicherheitsmaßnahmen und Zugriffsschutz eignet sich der BSI IT-Grundschutz.
Best Practices: So bleibt Routing-Dokumentation dauerhaft aktuell
Routing-Dokumentation veraltet nicht wegen fehlender Tools, sondern wegen fehlender Prozessintegration. Die wirksamste Regel lautet: Kein Routing-Change ohne Doku-Update. Das gilt besonders für neue Peers, neue Areas, Redistribution-Änderungen, Default-Strategien und statische Ausnahmen.
- Change-Gate: Ticket enthält Link zur aktualisierten Routing-Doku (Peers/Areas/Policies/Runbooks).
- Definition of Done: Change gilt erst als abgeschlossen, wenn Doku und Post-Checks aktualisiert sind.
- Review-Zyklen: quartalsweise für Edge/BGP/Default-Policies, halbjährlich für OSPF-Area-Design und Summaries.
- Stichproben: regelmäßig prüfen: stimmen Peerlisten, Prefix-Filter, Max-Prefix, statische Routen mit Ablaufdaten?
- Versionierung: Dokumente und Diagramme mit Version, Datum, Owner und Gültigkeitsbereich versehen.
Checkliste: Routing-Dokumentation für OSPF, BGP und statische Routen
- Architektur (HLD) dokumentiert: Routing-Domänen/VRFs, Standorte, Edge, Redundanzprinzip
- OSPF dokumentiert: Router-IDs, Areas, ABRs/ASBRs, Area-Typen, Summaries, Authentisierung, Konvergenzziele
- BGP dokumentiert: ASN, Peer-Liste, Rollen, Import/Export-Policies, Prefix-Filter, Max-Prefix, Pfadsteuerung, Default-Strategie, Security
- Statische Routen dokumentiert: Zielprefix, Next-Hop, VRF/Zone, Begründung, Owner, Lifetime/Ablaufdatum, Tracking/Fallback
- Redistribution dokumentiert: Quelle/Ziel, Ort, Filter, Metriken, Tags/Loop-Prevention, Risiko
- Diagramme getrennt: WAN/BGP-Übersicht, OSPF-Areas, Edge/Default-Policy, VRF/Zonen
- Runbooks vorhanden: Prüfpfade für OSPF/BGP/Static, Monitoring- und Eskalationswege
- Dokumentation geschützt: rollenbasierte Rechte, Audit-Trail, Secrets getrennt verwalten
- Aktualität gesichert: Change-Gate, Reviews, Stichproben, Versionierung
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.

