Site icon bintorosoft.com

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

Red Snapper

Create a visual aid showing the process of data integration from multiple sources. Include steps like data extraction, transformation, and loading (ETL).

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.

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.

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.

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.

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.

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

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.

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.

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)

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.

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

Sie erhalten

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.

Exit mobile version