ADRs für Netzwerkentscheidungen: Beispiele für BGP, EVPN, SD-WAN

ADRs für Netzwerkentscheidungen (Architecture Decision Records) sind ein pragmatisches Werkzeug, um komplexe technische Entscheidungen im Netzwerk dauerhaft nachvollziehbar zu machen. In der Netzwerktechnik entstehen Entscheidungen selten „aus dem Lehrbuch“: BGP-Policy vs. Einfachheit, EVPN/VXLAN vs. klassische VLAN-Topologien, SD-WAN vs. traditionelles MPLS – und fast immer spielen Constraints mit hinein (Provider, Latenz, Security, Betrieb, Kosten, Skills). Ohne ADRs bleiben die Gründe oft implizit: „So haben wir es halt gemacht.“ Das rächt sich später bei Incident-Analysen, Vendor-Übergaben, Audits oder wenn Teams wachsen: Neue Engineers verstehen die Architektur, aber nicht die Entscheidung. ADRs lösen genau dieses Problem, indem sie Entscheidungen als kleine, versionierbare Dokumente festhalten: Kontext, Optionen, Entscheidung, Konsequenzen und Nachweise. Der Effekt ist unmittelbar: Changes werden sicherer, weil klar ist, welche Annahmen gelten; Standardisierung wird leichter, weil Entscheidungen nicht jedes Mal neu diskutiert werden; und Drift lässt sich besser erkennen, weil Intent dokumentiert ist. Dieser Artikel zeigt, wie Sie ADRs im Netzwerk sinnvoll einsetzen, welche Struktur sich bewährt und enthält konkrete Beispiel-ADRs für BGP, EVPN/VXLAN und SD-WAN – so geschrieben, dass sie direkt als Vorlage in Ihre Dokumentation übernommen werden können.

Was ist ein ADR und warum ist es im Netzwerk so wirkungsvoll?

Ein ADR ist ein kurzer, fokussierter Entscheidungsdatensatz. Er beschreibt nicht die gesamte Architektur, sondern genau eine Entscheidung (z. B. „eBGP vs. iBGP im Data-Center-Fabric“, „EVPN als Control Plane“, „SD-WAN-Overlay mit Dual-Transport“). Im Netzwerk ist das besonders hilfreich, weil viele Entscheidungen Pfad- und Sicherheitsimplikationen haben, die sich später nur schwer rekonstruieren lassen. Ein ADR wirkt wie ein „Gedächtnis“ der Architektur: Er macht sichtbar, warum etwas so ist und welche Alternativen bewusst verworfen wurden.

• Nachvollziehbarkeit: Warum nutzen wir Communities? Warum ist MTU 9000? Warum ist das Underlay eBGP?
• Beschleunigte Reviews: Diskussionen werden kürzer, weil Kontext dokumentiert ist.
• Audit-Readiness: Entscheidungen über Segmentierung, Controls und Logging sind begründet.
• Onboarding: Neue Engineers verstehen schneller, welche Prinzipien gelten.
• Vendor-Übergaben: Dienstleister erhalten nicht nur „was“, sondern „warum“.

Als allgemeine Orientierung für strukturierte Architekturentscheidungen sind ADR-Ansätze im Software- und Plattformbereich etabliert; ein sehr verbreiteter Ausgangspunkt ist die Beschreibung von ADRs (Format und Idee) bei adr.github.io.

ADRs vs. Diagramme vs. Standards: Wie die Artefakte zusammenspielen

Netzwerkdokumentation besteht typischerweise aus Diagrammen, Standards/Guidelines, Runbooks und Inventar/SoT-Daten. ADRs ergänzen diese Artefakte, ersetzen sie aber nicht.

• Diagramme zeigen Struktur und Pfade („wie sieht es aus?“).
• Standards definieren Regeln („wie machen wir es üblicherweise?“).
• Runbooks/SOPs beschreiben Abläufe („wie betreiben wir es?“).
• SoT/CMDB hält Stammdaten („was ist real vorhanden?“).
• ADRs erklären Entscheidungen („warum ist es so?“).

Ein gutes Muster ist: ADR verweist auf Diagramme (Views), auf Standards (z. B. BGP Communities), auf SoT-Objekte (VRFs/Sites) und auf Runbooks (BGP-Troubleshooting). Dadurch wird das ADR klein, aber maximal verlinkt.

Wann Sie im Netzwerk ein ADR schreiben sollten

Nicht jede Kleinigkeit braucht ein ADR. Es lohnt sich vor allem bei Entscheidungen mit hoher Halbwertszeit oder hohem Risiko. Eine praktische Heuristik: Wenn Sie die Entscheidung in sechs Monaten plausibel erklären müssen, schreiben Sie ein ADR.

• Routing- und Policy-Entscheidungen: BGP-Design, Communities, Route-Filtering, Summarization-Strategien
• Overlay-Entscheidungen: EVPN/VXLAN, Control-Plane-Wahl, Anycast Gateway
• WAN-Strategie: SD-WAN vs. MPLS, Transportmix, Failover-Logik, QoS-Strategie
• Security-Boundaries: VRF-/Zonenmodell, zentrale vs. dezentrale Firewalls, East-West Controls
• Operative Trade-offs: „einfacher Betrieb“ vs. „maximale Optimierung“, Monitoring- und Evidence-Ansatz

Der ADR-Standard im Netzwerk: Aufbau, der sich bewährt

Ein Netzwerk-ADR sollte so standardisiert sein, dass Reviewer sofort wissen, wo sie was finden. Eine praxistaugliche Struktur:

Metadaten

• Status: draft / accepted / deprecated / superseded
• Owner: accountable Rolle/Team
• Datum: Entscheidung und letzte Review
• Scope: Site/Region/Domain (DC, WAN, Campus, Cloud)
• Referenzen: Diagramme, Standards, SoT-Objekte, Tickets

Kontext

• Welche Anforderungen, Constraints und Risiken existieren?
• Welche Alternativen wurden betrachtet?

Entscheidung

• Was wird umgesetzt (klar und testbar formuliert)?

Konsequenzen

• Positive Effekte, Nachteile, Betriebsaufwand
• Was muss sich im Betrieb ändern (Monitoring, Runbooks, Skills)?

Evidence und Validierung

• Welche Messpunkte/Tests belegen, dass die Entscheidung funktioniert?
• Welche Kennzahlen/SLIs beobachten wir dauerhaft?

ADRs versionierbar machen: Docs-as-Code und Pull Requests

ADRs entfalten ihre volle Wirkung, wenn sie versioniert und reviewt werden. Das funktioniert in Git hervorragend: Jede Entscheidung ist ein kleines Textdokument (Markdown/HTML), das als Pull Request durch das Team geht. So entstehen Audit Trail und Qualitätssicherung automatisch.

• Review-Regeln: Domain Owner + Operations oder Security (je nach Impact)
• CI-Checks: Links, Metadatenpflicht, Diagramm-Rendering (falls Diagram-as-Code)
• Superseding: neue ADRs verweisen auf alte („supersedes ADR-001“) und markieren diese als superseded

Plattformreferenzen für PR/MR-Workflows: GitHub Pull Requests und GitLab Merge Requests.

Beispiel-ADR: BGP-Design für Internet Edge mit Communities

Das folgende Beispiel ist als direkt nutzbare Vorlage formuliert. Sie können es als eigenes ADR-Dokument übernehmen.

Metadaten

• Status: accepted
• Owner: Network Edge Domain Owner
• Scope: Internet Edge (global), alle PoPs
• Referenzen: BGP-Protokollgrundlagen RFC 4271, BGP Communities RFC 1997, Large Communities RFC 8092

Kontext

• Mehrere Provider-Uplinks pro PoP, aktive/aktive Nutzung mit kontrollierter Pfadsteuerung.
• Policy-Anforderungen: Präferenz pro Region, Blackholing bei DDoS, selektive Announcement-Steuerung.
• Operative Anforderungen: Policies müssen schnell, konsistent und auditierbar sein; kein „per-Neighbor“-Wildwuchs.
• Constraints: unterschiedliche Provider-Supportlevel, begrenzte Zeit für manuelle Policy-Pflege, Outsourcing-Anteile im Betrieb.

Optionen

• Option A: klassische LocalPref/AS-Path Prepending pro Peer, ohne Communities
• Option B: Standardisierte Community-Policy (Standard Communities + Large Communities), pro Prefix setzbar
• Option C: zentrale Route-Server/Controller-Policy (komplex, abhängig von Plattform)

Entscheidung

• Wir nutzen BGP Communities und Large Communities als primären Policy-Mechanismus.
• Alle externen Announcements werden über eine standardisierte Policy-Pipeline verarbeitet (Ingress Tagging → Policy Decisions → Egress Actions).
• Es gibt ein versioniertes Community-Register: Bedeutung, Owner, erlaubte Nutzung, Rezertifizierung von Sonderfällen.
• Blackhole wird als definierter Mechanismus umgesetzt (Community-Trigger, klare Guardrails, Logging).

Konsequenzen

• Vorteile: konsistente Steuerung, schneller Incident-Response (z. B. DDoS Blackhole), weniger Peer-spezifische Sonderlogik, bessere Auditfähigkeit.
• Nachteile: höhere Disziplin bei Naming/Registrierung, Schulungsbedarf („Community-Sprache“), CI/Review für neue Communities erforderlich.
• Betrieb: Runbook für „BGP Policy Change“ und „Blackhole Activation“ wird verpflichtend; Monitoring auf Route Counts und Neighbor States.

Evidence und Validierung

• Pre-/Post-Checks bei Policy-Changes: Prefix-Visibility, Route Counts, Traffic Shift, keine unerwarteten Leaks.
• SLIs: BGP Session Uptime, Route Table Stability, Time-to-Mitigation bei DDoS (intern).
• Regelmäßige Rezertifizierung: Community-Ausnahmen und Provider-spezifische Actions.

Beispiel-ADR: EVPN/VXLAN als Data-Center-Fabric Overlay

EVPN/VXLAN ist ein typisches Thema, das ohne ADR später schwer zu begründen ist: Warum Overlay? Warum EVPN? Wie sieht das Underlay aus? Welche Trade-offs werden akzeptiert?

Metadaten

• Status: accepted
• Owner: DC Network Architecture Owner
• Scope: Rechenzentrum Fabrics (Leaf/Spine)
• Referenzen: EVPN RFC 7432, VXLAN RFC 7348

Kontext

• Multi-Tenant/VRF-Anforderungen, hohe Skalierung bei VLAN/Segment-Anzahl, schnelle Moves/Adds/Changes.
• Bedarf nach L2/L3-Services über mehrere Racks hinweg, mit klarer Segmentierung und reduzierter STP-Abhängigkeit.
• Operative Anforderungen: standardisierte Fabric, klare Failure Domains, automatisierbare Provisionierung.
• Constraints: heterogene Serveranforderungen, Migration von legacy VLANs, begrenzte Maintenance Windows.

Optionen

• Option A: klassisches L2 (STP) + L3 Distribution (VLAN Stretching über Trunks)
• Option B: L3-only Fabric ohne L2-Stretching (maximal robust, aber Migration/Use Cases eingeschränkt)
• Option C: EVPN/VXLAN Overlay über L3 Underlay, Anycast Gateway, VRF-basiertes Segmentmodell

Entscheidung

• Wir setzen EVPN/VXLAN als Overlay ein, mit Leaf/Spine L3 Underlay.
• Segmente werden als VNIs modelliert, Gateway wird als Anycast auf Leafs bereitgestellt.
• STP im Fabric wird minimiert; L2 existiert dort, wo nötig, aber der Standardpfad ist L3 + EVPN Control Plane.
• Tenant/Zone-Trennung erfolgt über VRFs, nicht über „VLAN-Listen“; VLANs sind lokale Segment-IDs, VNIs sind die globale Overlay-ID.

Konsequenzen

• Vorteile: bessere Skalierung, klarere Failure Domains, weniger Layer-2-Fehlerklassen, konsistente Segmentierung, bessere Automatisierbarkeit.
• Nachteile: höhere Komplexität (Control Plane + Overlay), höhere Anforderungen an Monitoring (EVPN Sessions, VTEPs, MTU), Skills/Training notwendig.
• Betrieb: neue Runbooks für „EVPN Route Type Issues“, „VTEP Reachability“, „MTU/Fragmentation“. Zusätzlich Fabric-Health Monitoring (BGP/EVPN State, VNI/VRF Consistency).

Evidence und Validierung

• Pre-/Post-Checks bei Segment-Onboarding: VNI/VRF Konsistenz, MAC/IP Learning, Anycast Gateway Reachability.
• SLIs: Fabric Convergence Time, EVPN Session Stability, Overlay Packet Loss, MTU Compliance.
• Drift-Checks: Abgleich SoT (VNIs/VRFs) gegen Device Config, Findings erzeugen Tasks.

Beispiel-ADR: SD-WAN für Site Connectivity mit Dual Transport

SD-WAN ist ein Bereich, in dem „Marketingbegriffe“ schnell die Realität überdecken. Ein ADR schafft Klarheit: Welche Ziele, welche Transportarten, welche Failover-Logik, welche Controls (SASE/Firewall), welche Messbarkeit?

Metadaten

• Status: accepted
• Owner: WAN Domain Owner
• Scope: alle Branch Sites, Hubs und Cloud On-Ramps
• Referenzen: Architektur-/Prozessrahmen ITIL, SLO-Grundlagen Google SRE SLOs

Kontext

• Viele Standorte, heterogene Leitungen, Bedarf nach schneller Bereitstellung und zentraler Policy-Steuerung.
• Geschäftskritische Anwendungen benötigen definierte SLA-/SLO-Ziele (Loss/Latenz/Jitter), v. a. für Voice/Video.
• Security-Anforderungen: zentrale Sichtbarkeit, kontrollierte Internet Breakouts, Option auf SASE-Integration.
• Constraints: Kosten, Provider-Lieferzeiten, begrenzte lokale IT, Outsourcing/Remote Hands.

Optionen

• Option A: reines MPLS (stabil, teuer, lange Lead Times)
• Option B: Dual ISP + klassisches Routing (BGP/OSPF) pro Site (machbar, aber operativ schwer zu standardisieren)
• Option C: SD-WAN Overlay über Dual Transport (Broadband + optional MPLS/LTE), zentrale Policy und SLA-basierte Pfadwahl

Entscheidung

• Wir führen SD-WAN als Standard für Site Connectivity ein, mit Dual Transport (Broadband + LTE/5G oder MPLS je nach Site-Klasse).
• Applikationen werden in Traffic-Klassen modelliert (Business Critical, Standard, Guest), mit SLA-basierten Policies.
• Internet Breakout folgt einem klaren Modell: lokal nur für definierte Klassen, sonst zentral oder via SASE (je nach Compliance).
• Onboarding pro Site erfolgt über standardisierte Templates (Interface Profiles, Tunnel Profiles, QoS/Policy Sets) und wird dokumentiert.

Konsequenzen

• Vorteile: schnellere Site-Rollouts, bessere Pfadsteuerung, bessere Sichtbarkeit (Performance), vereinheitlichte Policies, einfachere Skalierung.
• Nachteile: zusätzliche Control-Plane/Overlay-Komplexität, Vendor-Abhängigkeit, Policy-/Template-Governance notwendig.
• Betrieb: Runbooks für „Site Degradation“, „Tunnel Down“, „Policy Misclassification“; regelmäßige Review der Traffic-Klassen; Rezertifizierung lokaler Breakouts.

Evidence und Validierung

• SLIs: Site-to-Hub Loss/Latenz/Jitter pro Klasse, Tunnel Uptime, Failover-Zeit.
• Post-Checks pro Site: Pfadverifikation für kritische Services, DNS/NTP/AAA Reachability, Logging-Flow.
• Audit-Evidence: Policies, Breakout-Regeln, Logs/Reports als Evidence-Paket.

ADRs für Netzwerkentscheidungen: Qualitätsregeln, die Reviewer lieben

Damit ADRs im Alltag akzeptiert werden, müssen sie kurz, klar und testbar sein. Diese Regeln haben sich bewährt:

• Eine Entscheidung pro ADR: nicht „BGP + QoS + Firewall“ in einem Dokument.
• Entscheidung als Satz: „Wir entscheiden X, weil Y, unter Constraints Z.“
• Optionen realistisch: mindestens zwei Alternativen, inklusive „nichts ändern“ wenn relevant.
• Konsequenzen ehrlich: Nachteile gehören rein, sonst sind ADRs Marketing.
• Evidence definieren: Welche Messpunkte beweisen Erfolg? (nicht erst im Audit überlegen)
• Superseding diszipliniert: neue ADRs verweisen auf alte, alte werden nicht gelöscht.

Integration in den Betrieb: ADRs mit Runbooks, SoT und Drift-Checks verknüpfen

Der größte Mehrwert entsteht, wenn ADRs nicht isoliert bleiben. Ein praxistaugliches Integrationsmodell:

• ADR → Runbook: jede Entscheidung, die neue Fehlerklassen einführt (EVPN, SD-WAN), braucht Troubleshooting-Runbooks.
• ADR → SoT: die normative Struktur (VRFs, Sites, VNIs, Circuits) wird als SoT-Objekte gepflegt (z. B. in NetBox).
• ADR → CI/Checks: Regeln werden automatisiert geprüft (Metadaten, Links, Renderbarkeit, Drift-Abgleich).
• ADR → Service Catalog: Entscheidungen beeinflussen Service-Offerings und SLIs/SLOs (z. B. SD-WAN Tiering).

Wenn Sie NetBox als Source of Truth verwenden, ist die API-Dokumentation hilfreich für Integrationen: NetBox REST API.

Typische Anti-Pattern bei Netzwerk-ADRs

• ADRs als Romane: niemand liest sie; Lösung: strikte Struktur, kurze Absätze, Verlinkung statt Wiederholung.
• Keine Alternativen: wirkt wie nachträgliche Rechtfertigung; Lösung: Optionen und Trade-offs dokumentieren.
• Keine Konsequenzen: Betrieb leidet; Lösung: Monitoring/Runbooks/Skills als Pflichtteil.
• ADRs ohne Owner: verrotten; Lösung: accountable Owner + Review-Datum.
• ADRs ohne Superseding: Historie bricht; Lösung: Status und Verweise standardisieren.

Checkliste: ADRs für Netzwerkentscheidungen mit Beispielen für BGP, EVPN und SD-WAN

• Das Hauptkeyword „ADRs für Netzwerkentscheidungen“ ist als Standard eingeführt (Template, Status, Owner, Scope, Referenzen)
• ADRs sind klein, fokussiert und enthalten mindestens Kontext, Optionen, Entscheidung, Konsequenzen und Evidence
• BGP-ADR dokumentiert Policy-Mechanik (Communities/Large Communities) und verweist auf RFCs (RFC 4271, RFC 1997, RFC 8092)
• EVPN/VXLAN-ADR beschreibt Underlay/Overlay, Segmentmodell und Betriebsfolgen und verweist auf Grundlagen (RFC 7432, RFC 7348)
• SD-WAN-ADR definiert Transportmix, Policy-Klassen, Breakout-Modell, SLIs/SLOs und Evidence
• ADRs sind versioniert und reviewed (PR/MR), mit klaren Review-Rollen (Domain Owner, Ops/Sec je nach Risiko)
• ADRs verlinken auf SoT/CMDB und Betriebsartefakte (Runbooks, Monitoring, Service Catalog) statt Stammdaten zu kopieren
• Superseding ist geregelt (accepted/deprecated/superseded), Historie bleibt erhalten
• Outbound-Links decken ADR-Grundlagen und Prozesse ab (ADR Format, ITIL, SRE SLOs, NetBox)

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.