eBGP mit mehreren Providern: Traffic Engineering mit Communities (DE-Praxis)

Bei eBGP Multi-Homing mit zwei (oder mehr) Providern ist Traffic Engineering in der Praxis weniger „Magie“ und mehr saubere Policy: Du steuerst Outbound über Local Preference in deinem AS und Inbound über Communities (plus optional AS-Path Prepending). In Deutschland ist dieses Modell besonders relevant, weil viele Unternehmen mehrere Carrier/Upstreams nutzen (Redundanz, Preis, Latenz), während Provider sehr häufig Community-basierte Policies für LocalPref, Export-Scopes oder Blackholing anbieten. Entscheidend ist: Communities sind provider-spezifisch – du baust also ein internes TE-Design, das sich pro Provider „übersetzen“ lässt.

Grundmodell: Outbound vs. Inbound sauber trennen

Multi-Provider TE scheitert oft, weil Outbound und Inbound vermischt werden. Outbound kannst du in deinem AS zuverlässig steuern. Inbound ist nur indirekt steuerbar und hängt von Provider-Policies ab.

• Outbound (du entscheidest): Local Preference, iBGP-Policy, IGP-Kosten zum Edge
• Inbound (Provider entscheidet): Provider-Communities, AS-Path Prepending, ggf. MED (selten sinnvoll)
• Guardrail: immer Filtering + Prefix-Limits, bevor TE „schön“ gemacht wird

Community-Baukasten: Welche Typen in der Praxis vorkommen

Provider-Communities sind im Kern „Steuercodes“. Typische Klassen sind: LocalPref-Setzung im Provider, Export-Scopes (nur DE, nur EU, global), AS-Pfad-Prepend durch Provider sowie Blackhole/RTBH. Die genauen Werte variieren je Provider und Vertrag.

• LocalPref-Communities: Provider bevorzugt/benachteiligt deine Route intern
• Scope-Communities: Route nur in bestimmten Regionen/Peers exportieren
• Prepend-Communities: Provider hängt sein AS mehrfach an (Inbound-TE)
• Blackhole-Communities: gezieltes Droppen (DDoS/RTBH), nur mit klaren Prozessen

DE-Praxis: Ein internes Community-Schema als Übersetzungsschicht

Damit du nicht pro Provider komplett neue Policies baust, definierst du interne Communities als „Intent“ und mapst diese am jeweiligen Provider-Edge auf dessen Communities. So bleibt dein Design konsistent, auch wenn du den Provider wechselst oder einen dritten Carrier hinzunimmst.

• Interne Communities: „PRIMARY“, „BACKUP“, „DE-ONLY“, „EU-ONLY“, „BLACKHOLE“
• Pro Provider: Route-Map übersetzt intern → Provider-Community-Werte
• Vorteil: Policies sind lesbar und auditierbar

Beispiel: interne Communities definieren

ip community-list standard CL_INT_PRIMARY permit 65000:100
ip community-list standard CL_INT_BACKUP  permit 65000:200
ip community-list standard CL_INT_DEONLY  permit 65000:300
ip community-list standard CL_INT_EUONLY  permit 65000:310
ip community-list standard CL_INT_BH      permit 65000:666

Outbound-Steuerung: Local Preference als stabile Grundlage

Outbound-TE ist dein „sicherer Hebel“: Du setzt LocalPref inbound pro Provider. Damit legst du fest, welcher Upstream standardmäßig Exit ist. Für echte Redundanz kombinierst du das mit Tracking (z. B. IP SLA) und einem klaren Failover-Design.

Inbound Route-Map: Provider A bevorzugen

route-map RM_IN_PROV_A permit 10
 set local-preference 200
route-map RM_IN_PROV_B permit 10

set local-preference 100

Neighbor-Zuordnung

router bgp 65000
 neighbor 192.0.2.1 remote-as 64501
 neighbor 198.51.100.1 remote-as 64502
 neighbor 192.0.2.1 route-map RM_IN_PROV_A in
 neighbor 198.51.100.1 route-map RM_IN_PROV_B in

Inbound-TE mit Communities: Der saubere Workflow

Inbound-TE bedeutet: Du markierst bestimmte Prefixes (oder Subsets) mit internen Communities und übersetzt diese beim Export zum jeweiligen Provider in dessen Community-Set. Wichtig: Inbound-TE ist selten perfekt. Du arbeitest mit Wahrscheinlichkeiten und misst nach.

• Schritt 1: Prefix-Klassen definieren (kritisch vs. unkritisch, DE/EU/global)
• Schritt 2: Interne Communities setzen (Intent)
• Schritt 3: Pro Provider Übersetzung anwenden (Provider-Communities)
• Schritt 4: Verifizieren (Looking Glass, NetFlow, Traffic-Graphs)

Praxisbeispiel: Zwei Provider, drei Traffic-Ziele

Ein häufiges Enterprise-Szenario: Provider A ist „Low Latency“ (z. B. Richtung Cloud/IX), Provider B ist „Cost Efficient“ oder Backup. Du willst: (1) Standard inbound über A, (2) Backup über B, (3) bestimmte Prefixes nur regional announcen.

• Default inbound: Provider A bevorzugen (Community für höheren LocalPref im Provider)
• Backup inbound: Provider B (Provider A soll diese Prefixes weniger bevorzugen)
• Scope: bestimmte Netze nur DE/EU announcen (Scope-Community)

Prefix-Listen: Owned Prefixes sauber whitelisten

ip prefix-list PL_OWNED seq 10 permit 203.0.113.0/24
ip prefix-list PL_OWNED seq 20 permit 198.51.100.0/24
ip prefix-list PL_ANY   seq 5  permit 0.0.0.0/0 le 32

Interne Communities setzen (Intent pro Prefix)

route-map RM_TAG_INT permit 10
 match ip address prefix-list PL_OWNED
 set community 65000:100 additive
route-map RM_TAG_DEONLY permit 10

match ip address prefix-list PL_OWNED

set community 65000:300 additive

Provider-Übersetzung: interne → Provider-Communities (Pattern)

Jetzt kommt der provider-spezifische Teil. Du mapst interne Communities auf Provider-Communities. Die Zahlen sind Platzhalter – in der Praxis nimmst du exakt die Werte aus dem Provider-Community-Guide.

Provider A: Übersetzung (Beispielpattern)

ip community-list standard CL_PROVA_LP_HIGH permit 64501:1100
ip community-list standard CL_PROVA_SCOPE_DE permit 64501:2100
ip community-list standard CL_PROVA_PREP_2  permit 64501:3102
route-map RM_OUT_PROV_A deny 5

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

match ip address prefix-list PL_OWNED

match community CL_INT_PRIMARY

set community 64501:1100 additive
route-map RM_OUT_PROV_A permit 20

match ip address prefix-list PL_OWNED

match community CL_INT_DEONLY

set community 64501:2100 additive

Provider B: Übersetzung (Beispielpattern)

ip community-list standard CL_PROVB_LP_HIGH permit 64502:1200
ip community-list standard CL_PROVB_SCOPE_EU permit 64502:2200
route-map RM_OUT_PROV_B deny 5

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

match ip address prefix-list PL_OWNED

match community CL_INT_BACKUP

set community 64502:1200 additive
route-map RM_OUT_PROV_B permit 20

match ip address prefix-list PL_OWNED

match community CL_INT_EUONLY

set community 64502:2200 additive

Neighbor-Anwendung + Communities senden

router bgp 65000
 neighbor 192.0.2.1 remote-as 64501
 neighbor 198.51.100.1 remote-as 64502
 neighbor 192.0.2.1 route-map RM_OUT_PROV_A out
 neighbor 198.51.100.1 route-map RM_OUT_PROV_B out
 neighbor 192.0.2.1 send-community
 neighbor 198.51.100.1 send-community

AS-Path Prepending: Backup-TE als „grober Hammer“

Wenn Provider-Communities für Inbound-LP nicht verfügbar sind oder nicht den gewünschten Effekt haben, ist Prepending die robuste Notlösung. Es ist grob, aber breit kompatibel. In Deutschland ist Prepending besonders gängig für „Backup-ISP soll nur im Failover ziehen“.

Prepend Richtung Provider B (Backup)

route-map RM_OUT_PROV_B permit 30
 match ip address prefix-list PL_OWNED
 set as-path prepend 65000 65000 65000

Pitfall

• Prepending wirkt nicht überall gleich (Remote-AS Policies können das übersteuern)
• Bei vielen Prefixes führt Prepending zu komplizierterem Troubleshooting

Blackholing (RTBH): Nur mit Prozess und Schutzmechanismen

RTBH ist extrem wirksam, aber muss sauber abgesichert sein: Nur ein dedizierter „/32 Hostroute“-Mechanismus oder ein enger Prefix-Workflow, damit du nicht versehentlich legitimen Traffic droppst.

• Nur definierte Prefix-Länge erlauben (typisch /32 oder /128)
• Separate Route-Map nur für Blackhole
• Operativer Ablauf: Ticket, Freigabe, Zeitfenster, Verifikation

BH-Whitelist (IPv4 /32 Beispiel)

ip prefix-list PL_BH seq 10 permit 203.0.113.123/32
route-map RM_OUT_BH permit 10

match ip address prefix-list PL_BH

match community CL_INT_BH

set community 64501:666 additive

Guardrails: Was du IMMER brauchst (DE-Praxis-Baseline)

Multi-Provider ohne Guardrails ist eine Einladung für Route-Leaks und Outages. Diese Punkte sind Baseline, bevor du TE optimierst.

• Outbound Whitelist: nur owned Prefixes announcen
• Inbound Filter: mindestens Default/gewünschte Routen, oder Full Table bewusst
• Prefix-Limits pro Neighbor (mit Warnschwelle)
• Maximale Prefix-Länge und Bogon-Filter (Inbound)
• Dokumentiertes Community-Mapping pro Provider

Maximum-Prefix (Beispiel)

router bgp 65000
 neighbor 192.0.2.1 maximum-prefix 100000 90 restart 5
 neighbor 198.51.100.1 maximum-prefix 100000 90 restart 5

Verifikation: Wirkt die Community wirklich?

Du verifizierst in drei Ebenen: (1) Router sendet Community, (2) Provider akzeptiert und setzt Policy, (3) Traffic folgt tatsächlich dem erwarteten Pfad. Ohne diese Kette bleibt TE nur „Konfig hübsch“.

Auf dem Router prüfen

show ip bgp neighbors 192.0.2.1 advertised-routes
show ip bgp neighbors 198.51.100.1 advertised-routes
show ip bgp <prefix>

In der eigenen Domäne prüfen (Outbound Exit)

show ip bgp <prefix>
show ip route <next-hop>

Im Betrieb prüfen (Traffic-Realität)

• NetFlow/Telemetry: Inbound/Outbound Volumen pro Provider
• Looking Glass / Traceroutes von externen Standorten
• Provider-Portale/Communities: bestätigte Anwendung

Typische Pitfalls und schnelle Gegenchecks

Wenn TE „nicht wirkt“, liegt es meist nicht an BGP, sondern an einem der Klassiker: Communities werden nicht gesendet, Route-Map matcht nicht, Prefix ist nicht announced, oder Provider-Policy ist anders als gedacht.

• send-community fehlt → Provider sieht keine Communities
• Route-Map Reihenfolge falsch → permit/deny greift unerwartet
• Prefix nicht in BGP (nicht „network“ oder nicht redistributet)
• Provider-Community falsch (Zahlendreher, falsche Richtung)

Quick Checks

show ip bgp summary
show ip bgp neighbors 192.0.2.1 advertised-routes
show route-map
show ip prefix-list
show ip community-list

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.