BGP Policy Diagramme: Communities, Prefs und Exporte sichtbar machen

BGP Policy Diagramme sind der schnellste Weg, um Routing-Intent sichtbar zu machen: Welche Prefixe werden wohin exportiert, welche Communities markieren sie, und welche Prefs (z. B. Local Preference) entscheiden über den bevorzugten Pfad? In vielen Netzwerken existiert eine erstaunlich große Diskrepanz zwischen „BGP läuft“ und „BGP ist verstanden“. Konfigurationen sind vendor-spezifisch, Policies wachsen historisch, Ausnahmen kommen im Incident hinzu – und irgendwann weiß niemand mehr, warum Provider A bevorzugt wird, warum bestimmte Netze nicht announced werden oder warum ein DDoS-Blackhole nicht greift. Genau hier helfen BGP Policy Diagramme: Sie übersetzen abstrakte Policy-Logik in klar lesbare Sichten, die Betrieb, Architektur, Security und Audit gleichermaßen nutzen können. Statt nur Nachbarbeziehungen zu zeichnen, zeigen gute Policy-Diagramme die Semantik: Ingress-Markierung (Tagging) mit Communities, Policy-Pipelines, Export-Regeln pro Peer, Pref-Entscheidungen im eigenen AS, und die Kontrolle von Leaks durch Filter und Grenzen. Dieser Artikel erklärt, wie Sie BGP Policy Diagramme professionell aufbauen, welche Diagrammtypen sich bewährt haben und wie Sie Communities, Prefs und Exporte so darstellen, dass sie im Troubleshooting tatsächlich helfen – ohne zu Spaghetti-Plänen zu werden.

Warum klassische BGP-Topologiepläne für Policies nicht reichen

Ein klassisches BGP-Diagramm zeigt meistens Router und Sessions: Wer peer’t mit wem (iBGP/eBGP), vielleicht noch ASNs und IPs. Das ist wichtig, aber es beantwortet nicht die Fragen, die im Betrieb wirklich wehtun:

• Warum geht Traffic über Provider A statt B? (LocalPref, MED, AS-Path Prepend, Communities)
• Warum sieht ein Partner unser Prefix nicht? (Export-Filter, Route Maps/Policies, Route Targets/Communities)
• Warum leaken wir Routen? (fehlende Ingress-Filter, falsche Default-Actions, unklare Policy-Boundaries)
• Warum funktioniert Blackholing nicht? (falsche Community, falsches Neighbor-Mapping, fehlende Provider-Unterstützung)
• Welche Prefixe werden global, regional oder gar nicht announced? (Export-Klassen, Region-Pinning, No-Export)

BGP Policy Diagramme ergänzen die Topologie um eine „Policy-Ebene“. Sie machen sichtbar, welche Regeln entlang der Pipeline wirken, statt den Leser in Konfigurationsblöcken suchen zu lassen.

Grundbegriffe: Communities, Prefs, Exporte und Policy-Pipelines

Damit Diagramme konsistent bleiben, sollten Sie eine klare Begriffslogik verwenden:

• Communities: Attribute, die Routen markieren, um später Entscheidungen zu treffen oder Aktionen beim Provider auszulösen. Standard Communities sind in RFC 1997 beschrieben, Large Communities in RFC 8092.
• Local Preference: iBGP-internes Attribut zur Pfadpräferenz (höher gewinnt). Entscheidet oft über „Primary/Secondary“ Provider.
• Export Policy: Regeln, welche Routen an welchen Nachbarn announced werden (inkl. Manipulation wie Prepend oder Community-Setzen).
• Ingress Policy: Regeln, die eingehende Routen klassifizieren (Tagging, Filter, Pref setzen).
• Policy-Pipeline: eine definierte Abfolge aus Tagging → Entscheidung → Export, idealerweise standardisiert und wiederholbar.

Als Basisreferenz für BGP selbst ist RFC 4271 geeignet. Für das Ziel „Diagramme, die man lesen kann“ ist wichtig: Sie müssen nicht jedes RFC-Detail zeigen, sondern die für Ihr Netz relevanten Entscheidungsstellen.

Das Diagramm-Portfolio: Welche BGP Policy Diagramme ein Team wirklich braucht

Ein einzelnes Diagramm kann Policies, Exporte, Communities und Präferenzen nicht sauber erklären. Bewährt hat sich ein Portfolio aus klaren Views („One Diagram per Question“):

• Neighbor & Role View: Peers nach Rollen (Transit, Peering, Partner, Customer, Internal) – ohne Policy-Details.
• Ingress Tagging View: welche Nachbarn/Route-Quellen bekommen welche Tags/Communities und welche LocalPref.
• Decision View: wie wird aus Tags/Pref/Metriken der bevorzugte Pfad abgeleitet (Policy-Logik auf hoher Ebene).
• Export Matrix View: welche Prefix-Klassen (global, regional, no-export, blackhole) gehen an welche Peers.
• Community Catalog View: Register der Communities mit Bedeutung, Owner, erlaubter Nutzung, Rezertifizierung.
• Troubleshooting Flow View: „Wenn Route X falsch läuft, prüfe diese Gates“ – als visueller Ablauf.

So kann jede Zielgruppe schnell die richtige Sicht wählen: On-Call braucht Troubleshooting und Export, Architektur braucht Decision und Ingress, Security/Audit braucht Catalog und Boundaries.

Neighbor & Role View: Peers nach Funktion gruppieren

Die erste Ebene sollte Ihr BGP-Ökosystem in Rollen zerlegen. Das reduziert sofort Komplexität und erleichtert das Lesen der späteren Policy-Views.

• Transit Provider: liefern Full Table oder Teilmengen, tragen meist den Großteil des Internet-Routings.
• Peering: Austausch mit IX/PNI, häufig selektiv (nur eigene/peering-relevante Prefixe).
• Partner/Private Peers: definierte Bilateral-Routen, oft mit spezifischen Policies.
• Customers: Kundenprefixe, strikte Ingress-Filter, oft Blackhole- und Export-Controls.
• Internal: iBGP/RR, DCI, Cloud-Onramps – rein interne Verteilung.

Best Practice: In dieser View werden nur ASNs, Peer-Namen, Regionen und Rollen gezeigt. Keine Communities, keine Route Maps. Ziel: Orientierung.

Ingress Tagging View: Communities und LocalPref als „Klassifizierung“ sichtbar machen

Die wichtigste Idee für verständliche BGP Policies ist die Trennung von „Klassifizierung“ und „Aktion“. Ingress Policies sollten primär klassifizieren: Routen bekommen Tags und Prefs, die später ausgewertet werden. Das lässt sich hervorragend als Diagramm darstellen.

Was Sie in der Ingress-View zeigen sollten

• Quelle → Tag: TransitA → COMMUNITY:IN:TRANSIT_A, PeeringIX → COMMUNITY:IN:PEER_IX, CustomerX → COMMUNITY:IN:CUST_X.
• Quelle → LocalPref: z. B. TransitA = 200, TransitB = 150, Peering = 220 für „lokal bevorzugen“.
• Filter-Gates: Max-Prefix, IRR/RPKI-Validierung (wenn genutzt), Prefix-Listen (Customer nur eigene).
• Scope: global vs. regional (z. B. „EU Peers setzen REGION=EU“).

Visualisieren Sie diese Logik als Pipeline: Ingress → Filter → Tagging → Pref. Dadurch sehen Leser sofort, welche Routenklasse entsteht, ohne die gesamte Policy zu lesen.

Decision View: Wie Prefs und Communities Pfade entscheiden

Der Decision View beantwortet: „Warum gewinnt Pfad A?“ In BGP gibt es eine standardisierte Auswahllogik, aber in der Praxis steuern Sie sie über Attribute. Ein Diagramm sollte diese Entscheidungen als „Gates“ darstellen, nicht als RFC-Text.

Ein praxistaugliches Entscheidungsmodell als Diagramm

• Gate 1: LocalPref (höher gewinnt) – zeigt Primary/Secondary und Peering-Präferenz.
• Gate 2: Policy Overrides (z. B. „Do not use“, „traffic engineering community“, „blackhole“).
• Gate 3: AS-Path Manipulation (Prepend beeinflusst eingehende Pfade aus dem Internet, nicht zwingend interne Auswahl).
• Gate 4: MED/IGP cost (je nach Design relevant oder bewusst ignoriert).
• Gate 5: Tie-break (Router-ID, etc.) – meist nicht entscheidend, aber als „Fallback“ erwähnbar.

Wichtig: Der Decision View ist keine vollständige BGP-Entscheidungstabelle. Er zeigt Ihre relevanten Hebel und welche davon Sie bewusst nutzen oder vermeiden.

Export Matrix View: Exporte, No-Export und Region-Pinning sichtbar machen

Exporte sind in der Praxis der häufigste Fehlerbereich: entweder wird zu wenig announced (Reachability-Probleme) oder zu viel (Leaks). Eine Export Matrix ist daher extrem wertvoll. Sie muss nicht tabellarisch sein; sie kann auch als Diagramm mit Kantenklassen und Legende umgesetzt werden.

Prefix-Klassen definieren

• GLOBAL: Prefixe, die überall announced werden dürfen.
• REGIONAL: Prefixe, die nur in bestimmten Regionen/PoPs exportiert werden (z. B. aus Compliance- oder Performancegründen).
• PRIVATE: nur an Partner/Customers, nicht ins Internet.
• NO-EXPORT: darf nur intern oder zu bestimmten Nachbarn, nicht weiterverteilt (Standardcommunity „no-export“ ist in RFC 1997 beschrieben).
• BLACKHOLE: spezielle Präfixe oder /32-/128, die als DDoS-Mitigation announcen (häufig providerabhängig).

Die Matrix als Diagramm umsetzen

• Linke Seite: Prefix-Klassen (GLOBAL/REGIONAL/PRIVATE/NO-EXPORT/BLACKHOLE)
• Rechte Seite: Peer-Gruppen (Transit, Peering, Partner, Customers)
• Verbindungen: „allowed exports“ als klare Kanten, „blocked“ als fehlende Kante (oder als rote X-Markierung, wenn Sie das nutzen)
• Annotation: welche Community beim Export gesetzt wird (z. B. „set NO-EXPORT“, „set PREPEND-2“, „set BH-TRIGGER“)

So wird sofort sichtbar, ob Ihr Netz z. B. PRIVATE Prefixe versehentlich an Transits exportiert oder REGIONAL Prefixe falsch global announced werden.

Community Catalog: Das Register, das Policies stabil macht

Communities sind mächtig – und ohne Governance werden sie Chaos. Deshalb braucht jedes Netz, das Communities ernsthaft nutzt, ein Community-Register. Dieses Register ist ein Doku-Objekt, das Diagramme entlastet: Im Diagramm steht nur die Community-ID oder ein kurzer Alias; die Bedeutung steht im Catalog.

Felder, die ein Community Catalog enthalten sollte

• Community: Standard (16-bit:16-bit) oder Large (32-bit:32-bit:32-bit) – Large Communities sind in RFC 8092 beschrieben.
• Name/Alias: sprechender Kurzname (z. B. BH-TRIGGER, REGION-EU, EXPORT-NOPEER).
• Bedeutung: normativ, nicht „ungefähr“.
• Scope: intern, zu bestimmten Providern, global gültig.
• Owner: accountable Rolle/Team, plus Rezertifizierungsintervall.
• Allowed Usage: wer darf setzen, wo darf es gesetzt werden (Ingress/Export), welche Guardrails existieren.
• Provider Mapping: wenn provider-spezifisch, dokumentieren, welcher Provider welche Community versteht (ohne vertrauliche Vertragsdetails).

Best Practice: Treat Communities wie API-Contracts. Änderungen laufen über Reviews, und neue Communities werden wie Code eingeführt.

Blackholing und DDoS-Mitigation: Policies sichtbar machen, ohne zu viel zu verraten

Ein sensibler Bereich ist Blackholing. Sie wollen dokumentieren, wie der Prozess funktioniert, ohne operative Details zu veröffentlichen, die missbraucht werden könnten. Diagramme können hier helfen, weil sie den Mechanismus auf hoher Ebene zeigen:

• Trigger: eine definierte Community markiert ein Präfix als „blackhole candidate“.
• Gate: nur definierte Source (z. B. DDoS-System oder spezielles Prefix-Set) darf diese Community setzen.
• Export: nur an definierte Provider/Peers, die Blackhole akzeptieren; niemals an alle.
• Logging: jedes Setzen/Entfernen erzeugt Audit Trail (Ticket-ID, Change Log, SIEM Event).

Im Diagramm reicht ein „Blackhole Pipeline“ Block, der zeigt: Source → Tag → Export. Die konkreten Community-Werte können im internen Catalog stehen.

Policy-Diagramme für Audits: Segmentierung und Zugriffspfad-Nachweise

Auch wenn BGP auf den ersten Blick „Routing“ ist, spielt es in Audits eine Rolle: Exporte definieren, welche Netze erreichbar sind, und Policies definieren, wo Datenflüsse theoretisch hinlaufen könnten. Gute Diagramme unterstützen Audit-Readiness, wenn sie folgende Aspekte zeigen:

• Route Leak Prevention: Ingress-Filter, Prefix-Listen, Max-Prefix, Default-Deny im Export.
• Region-Pinning: welche Prefixe dürfen nur regional exportiert werden (z. B. Datenresidenz).
• Trust Boundaries: wo endet internes Routing und beginnt Provider-/Internet-Edge.
• Evidence-Verweise: Links auf Runbooks, Change-Prozesse, Community Catalog (nicht als Textwüste im Diagramm).

Als allgemeine Kontrollreferenz für Logging, Change und Zugriff ist CIS Controls hilfreich, weil es Sicherheitsmaßnahmen in prüfbare Schritte übersetzt.

Layout-Regeln: So bleiben BGP Policy Diagramme lesbar

Policy-Diagramme scheitern oft an Visual Overload. Diese Regeln helfen, Komplexität zu reduzieren:

• Peers gruppieren: nach Rolle und Region, nicht als unstrukturierte Peer-Liste.
• Policies als Pipelines: statt „Rule 1–200“ lieber 3–6 Gates (Filter, Tag, Pref, Export Class, Provider Action).
• Legenden statt Textblöcke: Community-IDs im Diagramm, Bedeutung im Catalog.
• Linienarten nutzen: Control Plane (Sessions) gestrichelt, Data Plane (Traffic intent) als Pfeile, Exporte als dickere Kanten.
• Nur relevante Labels: „LocalPref=200“ ja, aber keine vollständigen Route-Maps im Diagramm.
• One Diagram per Question: Export-Matrix und Decision-View nicht in ein Bild pressen.

Operationalisierung: Diagramme als „Living Documentation“

BGP Policies sind lebendig: neue Provider, neue Peerings, neue Communities, neue Ausnahmen. Damit Diagramme nicht veralten, müssen sie Teil des Change-Prozesses sein.

• Definition of Done: keine Änderung an Communities/Prefs/Export-Regeln ohne Update der entsprechenden View (Ingress, Decision, Export Matrix, Catalog).
• Review-Workflow: Änderungen laufen über Pull Requests/Merge Requests, inklusive Peer Review durch Domain Owner und Operations.
• CI Checks: Pflichtfelder in Catalogs, Broken Links, veraltete Diagrammreferenzen, optional Linting von Policy-Objekten.

Für PR/MR-Workflows als Outbound-Referenz: GitHub Pull Requests und GitLab Merge Requests. Für CI-Automation: GitHub Actions.

Typische Anti-Pattern bei BGP Policy Diagrammen

• Nur Sessions, keine Semantik: man sieht Peerings, aber nicht, was exportiert wird; Lösung: Export Matrix und Tagging View.
• Communities ohne Register: niemand weiß, was sie bedeuten; Lösung: Community Catalog als Doku-Objekt mit Owner.
• Pref-Logik in Köpfen: Primary/Secondary wird „gefühlt“; Lösung: Decision View mit klaren Gates.
• Provider-spezifische Details überall: unwartbar; Lösung: Provider Mapping im Catalog, Diagramme zeigen nur Klassen.
• Keine Leak-Guards: Filter nicht sichtbar; Lösung: Ingress/Export-Filter als Gate markieren, Default-Deny konzeptionell zeigen.
• Alles in einem Diagramm: unlesbar; Lösung: „One Diagram per Question“ und Layered Views.

Checkliste: BGP Policy Diagramme für Communities, Prefs und Exporte

• Das Hauptkeyword „BGP Policy Diagramme“ ist als Diagramm-Portfolio umgesetzt (Neighbor/Roles, Ingress Tagging, Decision View, Export Matrix, Community Catalog, Troubleshooting Flow)
• Communities sind als Klassen/IDs im Diagramm sichtbar und in einem gepflegten Register dokumentiert (Standard: RFC 1997, Large: RFC 8092)
• Prefs (LocalPref) sind als primärer Entscheidungshebel dokumentiert und in einer Decision-View als Gate sichtbar
• Exporte sind als Prefix-Klassen modelliert (GLOBAL/REGIONAL/PRIVATE/NO-EXPORT/BLACKHOLE) und als Export Matrix nachvollziehbar
• Ingress- und Export-Filter (Leak Prevention) sind konzeptionell als Gates sichtbar (Max-Prefix, Prefix-Listen, Default-Deny)
• Blackholing ist dokumentiert (Trigger, Guardrails, Export Scope, Logging), ohne sensible Details zu veröffentlichen
• Diagramme sind lesbar (Gruppierung, Linienarten, Legende, minimale Labels, keine Konfig-Blöcke im Bild)
• Diagramme sind „living“ (DoD, PR/MR-Reviews, CI Checks), unterstützt durch GitHub PRs und GitHub Actions
• Primärquellen sind verlinkt: RFC 4271 (BGP), RFC 1997 (Communities), RFC 8092 (Large Communities)
• Security- und Auditbezug ist berücksichtigt (Controls, Logging, Change-Governance), orientierbar an CIS Controls

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.