Cisco-Router-Konfiguration für BGP Dual-ISP: Design und Verifikation

BGP Dual-ISP auf Cisco-Routern ist das Standarddesign, wenn Sie echte Provider-Redundanz, Traffic-Engineering und saubere Failover-Eigenschaften benötigen. Im Unterschied zu „zwei Default-Routen“ steuert BGP nicht nur den Ausfall, sondern auch den bevorzugten Pfad (Inbound/Outbound) – vorausgesetzt, Filter, Prefix-Limits und Policies sind korrekt umgesetzt. Dieser Leitfaden zeigt ein praxiserprobtes Dual-ISP-Design mit BGP, die wichtigsten Policy-Bausteine und eine Verifikations-Checkliste, mit der Sie Stabilität und Routenhygiene objektiv nachweisen.

Designziele: Was Dual-ISP mit BGP liefern soll

Bevor Sie konfigurieren, definieren Sie das gewünschte Verhalten: Welche Leitung ist primär? Wollen Sie Load-Balancing? Welche Präfixe announcen Sie? Wie reagieren Sie auf Path-Ausfälle?

• Outage-Resilienz: ISP-Ausfall ohne lange Unterbrechung
• Outbound-Steuerung: bevorzugter Exit (LocalPref, Default-Handling)
• Inbound-Steuerung: welcher ISP wird von außen bevorzugt (AS-Path, Communities, MED)
• Routenhygiene: nur autorisierte Präfixe announcen, inbound filtern, Prefix-Limits
• Betriebsfähigkeit: Monitoring, Logging, klare Abnahme-Tests

Vorbereitung: Voraussetzungen und Inputs

BGP Dual-ISP steht und fällt mit korrekten Providerdaten und einem sauberen Adress-/ASN-Setup. Klären Sie diese Punkte, bevor Sie in Policies investieren.

• Eigenes ASN (öffentlich) oder Provider-ASN (wenn vom ISP vorgegeben)
• Eigene Präfixe, die announced werden dürfen (z. B. /24)
• ISP1/ISP2: Peer-IPs, Remote-ASNs, ggf. MD5/Authentication, max-prefix Vorgaben
• Transport: eBGP direkt am Hand-off oder über L3-Transit
• Default-Strategie: Full Table vs. Default-only (Designentscheidung)

Architektur: Primary/Backup oder Active/Active?

Dual-ISP kann als Primary/Backup oder Active/Active betrieben werden. Active/Active ist anspruchsvoller, weil Inbound/Outbound-Pfade kontrolliert und Monitoring sauber aufgebaut sein müssen. Für viele Unternehmen ist Primary/Backup der robustere Start.

• Primary/Backup: einfacher, deterministisch, weniger Policy-Komplexität
• Active/Active: bessere Ausnutzung, aber mehr Policy- und Testaufwand
• Empfehlung: zuerst stabil Primary/Backup, danach optional TE/Load-Balancing

Routenhygiene: Filterpflicht und Prefix-Limits als Mindeststandard

Bei BGP ist „default deny“ Pflicht: ohne Prefix-Lists/Route-Maps riskieren Sie Routenleaks. Zusätzlich schützen Prefix-Limits vor Route-Flooding und Fehlkonfigurationen.

• Outbound: nur autorisierte eigene Präfixe announcen
• Inbound: akzeptieren, was benötigt wird (Default oder Full Table), ggf. zusätzliche Filter
• maximum-prefix: Grenze pro ISP setzen, Warnschwelle + Restart
• Logging: neighbor-changes protokollieren

Beispiel: Outbound Prefix-Filter (nur eigene Netze)

ip prefix-list OUT-PFX seq 10 permit 203.0.113.0/24
ip prefix-list OUT-PFX seq 99 deny 0.0.0.0/0 le 32
route-map RM-OUT permit 10

match ip address prefix-list OUT-PFX

Grundkonfiguration: eBGP zu zwei Providern (Gerüst)

Das BGP-Gerüst enthält Neighbor-Definitionen, Logging und Outbound-Policy. Inbound-Policies steuern anschließend die bevorzugten Pfade. Halten Sie das Gerüst klar und wiederholbar.

Beispiel: BGP-Gerüst mit zwei Upstreams

router bgp 65010
 bgp log-neighbor-changes
neighbor 192.0.2.1 remote-as 65001

neighbor 192.0.2.1 description ISP1

neighbor 192.0.2.1 route-map RM-OUT out

neighbor 192.0.2.1 maximum-prefix 100000 90 restart 5
neighbor 198.51.100.1 remote-as 65002

neighbor 198.51.100.1 description ISP2

neighbor 198.51.100.1 route-map RM-OUT out

neighbor 198.51.100.1 maximum-prefix 100000 90 restart 5

Outbound-Design: Welcher ISP wird für ausgehenden Traffic bevorzugt?

Outbound-Steuerung erfolgt bei vielen Designs über Local Preference (bei iBGP) oder über Default-Route-Strategien, wenn der Edge selbst der Entscheidungspunkt ist. In einem einfachen Edge-Design können Sie bevorzugte Routen über Attribute/Policies kontrollieren.

Praxisansatz: ISP1 primär, ISP2 sekundär (Policy-Logik)

• Inbound von ISP1: höhere Präferenz setzen
• Inbound von ISP2: geringere Präferenz setzen
• Bei Ausfall: BGP withdraw → Pfadwechsel automatisch

Beispiel: Inbound-Route-Maps (konzeptionelles Muster)

route-map RM-ISP1-IN permit 10
 set local-preference 200
route-map RM-ISP2-IN permit 10

set local-preference 150
router bgp 65010

neighbor 192.0.2.1 route-map RM-ISP1-IN in

neighbor 198.51.100.1 route-map RM-ISP2-IN in

Inbound-Design: Welcher ISP soll von außen bevorzugt werden?

Inbound-Traffic steuern Sie nur indirekt: über AS-Path-Prepending oder Provider-Communities (provider-spezifisch). AS-Path-Prepending ist universell, aber weniger „präzise“ als Communities.

Beispiel: AS-Path-Prepend auf ISP2 (Backup-Inbound)

route-map RM-OUT-ISP2 permit 10
 match ip address prefix-list OUT-PFX
 set as-path prepend 65010 65010 65010
router bgp 65010

neighbor 198.51.100.1 route-map RM-OUT-ISP2 out

Hinweis zu Communities

Provider-Communities sind leistungsfähig (z. B. LocalPref im Provider-Netz), aber providerabhängig. Dokumentieren Sie Community-Werte und testen Sie Änderungen in einem kontrollierten Change-Fenster.

Path-Ausfälle: BGP-Down vs. „Link up, Internet down“

BGP reagiert zuverlässig, wenn die Session down ist. Schwieriger sind Path-Ausfälle, bei denen Link und BGP-Sitzung „oben“ bleiben, aber Upstream/Transit gestört ist. Dafür benötigen Sie zusätzliche Pfadüberwachung und ggf. Routing-Entscheidungen mit Tracking.

• BGP-Session down: automatische Umschaltung durch Route Withdraw
• Path down bei Session up: IP SLA/Tracking zur zusätzlichen Bewertung
• Monitoring: Loss/RTT als Indikator, nicht nur Interface-Status

Beispiel: IP SLA als Path-Indikator (operativ)

ip sla 10
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now

Verifikation: BGP, Routen und Pfadpräferenzen nachweisen

Ein Dual-ISP-Setup gilt erst als fertig, wenn Sie objektiv zeigen können, dass Sessions stabil sind, nur autorisierte Präfixe announced werden und Failover wie geplant funktioniert.

Verifikation BGP-Status und Routenanzahl

show bgp summary
show bgp ipv4 unicast
show ip route bgp

Verifikation Outbound-Announces (Routen, die Sie senden)

show bgp neighbors 192.0.2.1 advertised-routes
show bgp neighbors 198.51.100.1 advertised-routes

Verifikation Inbound-Pfadpräferenz (praktisch)

traceroute 1.1.1.1
ping 8.8.8.8 repeat 20

Failover-Testplan: So testen Sie Dual-ISP sicher

Testen Sie Failover in kontrollierten Schritten. Dokumentieren Sie Umschaltzeit, Pfadänderungen und Serviceauswirkungen. In Enterprise-Umgebungen ist das Teil des Abnahmeprotokolls.

• Test 1: ISP1-BGP Session down (geplant) → Traffic muss über ISP2 laufen
• Test 2: ISP2-BGP Session down → Traffic muss über ISP1 laufen
• Test 3: Path-Degradation (Loss/RTT) beobachten, Alarmierung prüfen
• Test 4: Inbound-Verhalten prüfen (AS-Path/Communities wirken?)

Failover-Checks (SOP)

show bgp summary
show ip route 0.0.0.0
show ip route bgp
show logging | last 50

Typische Fehlerbilder und schnelle Ursachen

Wenn Dual-ISP instabil ist oder falsche Pfade nutzt, liegt es meist an fehlenden Filtern, unklaren Policies oder fehlender Pfadüberwachung. Diese Fehlerbilder sind besonders häufig.

• Routenleak-Risiko: kein Outbound-Filter (OUT-PFX fehlt)
• Kein deterministischer Outbound: fehlende Inbound-Policy/Präferenzlogik
• Inbound nicht steuerbar: Prepend/Communities nicht korrekt oder vom Provider ignoriert
• „Link up, Internet down“: BGP bleibt up, aber Transit gestört → IP SLA/Monitoring nötig
• CPU-Spikes: Full Table + Updates, Plattformressourcen prüfen

Minimaler Dual-ISP-BGP-Baukasten (Template-Auszug)

Dieses Template bündelt die wichtigsten Best Practices: Outbound-Filter, BGP-Gerüst, Prefix-Limits und optionales Prepending. Werte und ASNs sind Platzhalter und müssen an Ihre Umgebung angepasst werden.

ip prefix-list OUT-PFX seq 10 permit 203.0.113.0/24
ip prefix-list OUT-PFX seq 99 deny 0.0.0.0/0 le 32
route-map RM-OUT permit 10

match ip address prefix-list OUT-PFX
router bgp 65010

bgp log-neighbor-changes
neighbor 192.0.2.1 remote-as 65001

neighbor 192.0.2.1 description ISP1

neighbor 192.0.2.1 route-map RM-OUT out

neighbor 192.0.2.1 maximum-prefix 100000 90 restart 5
neighbor 198.51.100.1 remote-as 65002

neighbor 198.51.100.1 description ISP2

neighbor 198.51.100.1 route-map RM-OUT out

neighbor 198.51.100.1 maximum-prefix 100000 90 restart 5

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.