BGP Policy Design: Route-Maps, Prefix-Lists, Communities als Baukasten

BGP ist kein „Plug-and-Play“-Routing, sondern ein Policy-Protokoll: Du entscheidest aktiv, welche Prefixes du annimmst, welche du weitergibst und welche Pfade bevorzugt werden. Genau dafür sind Prefix-Lists, Route-Maps und Communities der zentrale Baukasten auf Cisco Routern. Ein sauberes Policy-Design verfolgt drei Ziele: Sicherheit (nur erlaubte Routen), Stabilität (keine Route-Leaks/Flaps) und Steuerbarkeit (Traffic Engineering über Attribute). Dieser Artikel zeigt praxisnahe Muster, die du als Baseline in Enterprise- und Multi-Homing-Umgebungen verwenden kannst.

Der Baukasten: Wer macht was?

Die drei wichtigsten Werkzeuge ergänzen sich. Prefix-Lists definieren „welche Prefixes“, Route-Maps definieren „welche Policy“, Communities definieren „welches Label“ für interne Steuerung oder Provider-Interaktion.

• Prefix-List: präzises Matching von Prefixes (Whitelist/Blacklist)
• Route-Map: if/then-Logik (match → set), Reihenfolge ist entscheidend
• Communities: Tags für Klassifikation, Export/Import-Policies, TE

Designprinzip 1: Default Deny – immer explizit erlauben

Ein robustes BGP-Design startet mit „deny all“ und erlaubt dann gezielt. Das verhindert Route-Leaks und schützt dich vor Fehlinseraten (z. B. Full Table ins IGP oder falsche Default Route).

• Inbound: nur erwartete Prefixes akzeptieren (oder Full Table bewusst)
• Outbound: nur eigene/authorisierte Prefixes announcen
• Immer: Prefix-Limit setzen (Schutz vor Explosionsfällen)

Prefix-List Whitelist Beispiel

ip prefix-list PL_OUT_OWNED seq 10 permit 203.0.113.0/24
ip prefix-list PL_OUT_OWNED seq 20 permit 198.51.100.0/24
ip prefix-list PL_OUT_OWNED seq 100 deny 0.0.0.0/0 le 32

Designprinzip 2: Route-Maps als „Policy-Pipeline“ (Order matters)

Route-Maps werden sequenziell ausgewertet. Der erste passende Eintrag entscheidet. Daher ist eine klare Struktur wichtig: erst Drop-Regeln (deny), dann Policy-Set (permit), am Ende ein expliziter Default-Deny (oder „implizit deny“ bewusst nutzen).

Route-Map Grundgerüst

route-map RM_OUT permit 10
 match ip address prefix-list PL_OUT_OWNED
 set community 65000:100 additive
route-map RM_OUT deny 100

match ip address prefix-list PL_ANY

Catch-All Prefix-List (für explizites deny)

ip prefix-list PL_ANY seq 5 permit 0.0.0.0/0 le 32

Communities: Das Label-System für Steuerung

Communities sind die wichtigste Abstraktionsschicht: Du definierst intern, was ein Prefix „ist“ (z. B. Prod, Guest, DMZ, Backup-Path) und nutzt diese Labels für Policies – statt überall IP-Listen zu pflegen. Zusätzlich nutzen viele Provider Communities für Steuerung (z. B. LocalPref, Blackhole, Export-Regionen).

• Interne Communities: Klassifikation und konsistente Policies
• Provider Communities: Traffic Engineering und Export-Steuerung
• Best Practice: Community-Schema dokumentieren

Community-Liste und Matching

ip community-list standard CL_PROD permit 65000:100
ip community-list standard CL_GUEST permit 65000:200

Inbound Policy: Routen filtern und Pfade auswählen

Inbound ist Sicherheit und Stabilität: Hier verhinderst du Route-Leaks, akzeptierst nur gewünschte Prefixes und setzt Attribute wie Local Preference für Pfadwahl in deinem AS.

Inbound Filter + LocalPref (Beispiel)

ip prefix-list PL_IN_ALLOWED seq 10 permit 0.0.0.0/0
ip prefix-list PL_IN_ALLOWED seq 20 permit 10.0.0.0/8 le 24
route-map RM_IN permit 10

match ip address prefix-list PL_IN_ALLOWED

set local-preference 200
route-map RM_IN deny 100

match ip address prefix-list PL_ANY

Merker: Local Preference steuert Outbound-Pfad in deinem AS

$\text{Higher LocalPref} \to \text{bevorzugter Exit}$

Outbound Policy: nur autorisierte Prefixes announcen

Outbound ist „Reputation“: Ein falsches Announcement kann dein Netz und andere Netze beeinträchtigen. Daher announcest du nur Prefixes, die du wirklich besitzen und routen darfst – und idealerweise nur, wenn sie intern tatsächlich verfügbar sind.

Outbound Route-Map (Beispiel)

route-map RM_OUT permit 10
 match ip address prefix-list PL_OUT_OWNED
 set community 65000:100 additive
route-map RM_OUT deny 100

match ip address prefix-list PL_ANY

Nachbarn konfigurieren: Route-Maps und Communities aktiv nutzen

Route-Maps wirken nur, wenn sie am Neighbor angewendet werden. Außerdem musst du Communities senden, sonst „verschwinden“ sie am Übergang.

Neighbor Policy anwenden

router bgp 65000
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 route-map RM_IN in
 neighbor 203.0.113.1 route-map RM_OUT out
 neighbor 203.0.113.1 send-community

Traffic Engineering mit Communities: Praktische Muster

In Multi-Homing-Designs nutzt du Communities, um Traffic kontrolliert zu steuern, ohne überall LocalPref/AS-Path-Bastelei zu wiederholen. Typisch ist: Primär/Backup über LocalPref intern und Prepending extern.

• Outbound-Pfad: LocalPref im eigenen AS
• Inbound-Pfad: AS-Path Prepending oder Provider Communities
• Blackhole: spezielle Community (nur nach Provider-Policy)

AS-Path Prepending (Beispiel Outbound Richtung Backup-ISP)

route-map RM_OUT_BACKUP permit 10
 match ip address prefix-list PL_OUT_OWNED
 set as-path prepend 65000 65000 65000

Stabilität: Prefix-Limits, Soft Reconfiguration und sichere Changes

Policy-Fehler sind häufige Outage-Ursachen. Du reduzierst Risiko mit Guardrails: Prefix-Limits, klare Rollout-Prozesse und die Fähigkeit, Policies ohne Session-Reset zu testen.

• Prefix-Limit pro Neighbor (Schutz vor Route Explosion)
• Soft-Refresh statt hard reset (wenn möglich)
• Changes zuerst inbound testen (deny zuerst), dann outbound

Prefix-Limit Beispiel

router bgp 65000
 neighbor 203.0.113.1 maximum-prefix 100000 90 restart 5

Soft Refresh (wenn unterstützt)

clear ip bgp 203.0.113.1 soft in

Verification: Beweise, dass deine Policy wirkt

Nach jeder Änderung prüfst du: welche Prefixes werden akzeptiert/announced, welche Communities sind gesetzt, und ob Attribute wie LocalPref/AS-Path korrekt sind.

Inbound prüfen

show ip bgp neighbors 203.0.113.1 received-routes
show ip bgp <prefix>

Outbound prüfen

show ip bgp neighbors 203.0.113.1 advertised-routes

Policy prüfen

show route-map
show ip prefix-list
show ip community-list

Typische Pitfalls: Die häufigsten Policy-Fehler

Die meisten BGP-Probleme sind keine Protokollfehler, sondern Policy-Fehler. Diese Punkte solltest du bewusst gegenprüfen.

• Outbound Filter fehlt → Route Leak möglich
• send-community vergessen → Communities wirken nicht
• Route-Map Reihenfolge falsch → deny/permit greift unerwartet
• Prefix-List zu breit → unerwünschte Prefixes werden akzeptiert
• Keine Prefix-Limits → Risiko bei Fehlkonfigurationen

Quick-Template: Minimal sichere BGP Policy Baseline

Dieses Template kombiniert: Outbound Whitelist, Inbound Basic Filter, Communities senden und Prefix-Limit. Passe ASNs, IPs und Prefixes an.

ip prefix-list PL_ANY seq 5 permit 0.0.0.0/0 le 32
ip prefix-list PL_OUT_OWNED seq 10 permit 203.0.113.0/24
ip prefix-list PL_IN_ALLOWED seq 10 permit 0.0.0.0/0
route-map RM_IN permit 10

match ip address prefix-list PL_IN_ALLOWED

set local-preference 200

route-map RM_IN deny 100

match ip address prefix-list PL_ANY
route-map RM_OUT permit 10

match ip address prefix-list PL_OUT_OWNED

set community 65000:100 additive

route-map RM_OUT deny 100

match ip address prefix-list PL_ANY
router bgp 65000

neighbor 203.0.113.1 remote-as 64500

neighbor 203.0.113.1 route-map RM_IN in

neighbor 203.0.113.1 route-map RM_OUT out

neighbor 203.0.113.1 send-community

neighbor 203.0.113.1 maximum-prefix 100000 90 restart 5

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.