BGP Dual-Homing mit Cisco-Routern: Risiken, Policies und Betriebsmodell

BGP Dual-Homing (Dual-ISP) mit Cisco-Routern ist die Enterprise-Lösung für echte Provider-Redundanz und Traffic-Steuerung. Im Gegensatz zu einfachen Dual-ISP-Setups mit statischen Routen geht es hier um Policies: welche Präfixe announct werden, welche Routen akzeptiert werden, wie Inbound/Outbound beeinflusst wird und wie Sie Routenleaks und Instabilität verhindern. Der Preis für diese Kontrolle ist Komplexität im Design und Betrieb. Dieser Leitfaden beschreibt typische Risiken, praxistaugliche Policy-Bausteine und ein Betriebsmodell, das BGP stabil und auditierbar macht.

Wann BGP Dual-Homing sinnvoll ist

BGP lohnt sich, wenn Sie mehr wollen als „Internet failover“: eigene öffentliche Präfixe, planbare Pfade, Inbound/Outbound-Engineering oder strenge Enterprise-SLAs. Für reine Branch-Internet-Redundanz ist Static+Tracking oft ausreichend.

• Eigene ASN und öffentliche Präfixe vorhanden (Provider Independent oder Provider Assigned mit Design-Constraints)
• Dual-ISP mit Anforderungen an Pfadsteuerung und stabilen Failover
• Inbound Traffic Engineering (z. B. Präferenz bestimmter Provider)
• Hochverfügbarkeit für publik erreichbare Services (DMZ/Ingress)

Risiken: Warum BGP im Enterprise „Policy first“ ist

Die größten Risiken sind nicht BGP selbst, sondern fehlende Leitplanken. Ohne Filterpflicht können Routenleaks entstehen. Ohne Prefix-Limits kann eine Provider-Fehlkonfiguration Ihre Router belasten. Ohne klares Default-Handling entsteht Instabilität.

• Routenleak: ungewollte Präfixe werden an Provider oder intern weitergegeben
• Route Table Flood: zu viele Präfixe, CPU/Memory steigt, Convergence wird langsam
• Asymmetrie: Return Path weicht ab (NAT/VPN/Stateful Services betroffen)
• Instabile Sessions: Flaps, Dämpfung, Rekonvergenz in Peakzeiten
• Fehlende Operability: keine Nachweise, keine Runbooks, keine KPIs

Grundarchitektur: eBGP zu zwei ISPs, iBGP/IGP intern

Ein praxistaugliches Muster ist: eBGP zu ISP1 und ISP2 am Edge, intern ein klares IGP (OSPF) oder iBGP, und eine strikte Trennung zwischen „Edge Policy“ und „Campus Routing“.

• Edge Router: eBGP Sessions zu beiden ISPs
• Intern: Default-Route-Verteilung oder iBGP/OSPF abhängig von Design
• Security: Filterpflicht inbound/outbound (Prefix-Lists/Route-Maps)
• Resilienz: BFD/Tracking optional, aber Tests und Monitoring Pflicht

Policy-Baustein 1: Outbound-Filter (Was Sie announcen dürfen)

Outbound ist die wichtigste Schutzmaßnahme: Sie dürfen nur Ihre eigenen öffentlichen Präfixe announcen. Alles andere wird explizit geblockt. Das muss pro ISP gleich streng sein.

Prefix-List Outbound (Beispiel)

ip prefix-list PL-OUT-PUBLIC seq 10 permit 203.0.113.0/24
ip prefix-list PL-OUT-PUBLIC seq 99 deny 0.0.0.0/0 le 32

Route-Map Outbound (Beispiel)

route-map RM-OUT-ISP1 permit 10
 match ip address prefix-list PL-OUT-PUBLIC
route-map RM-OUT-ISP1 deny 99

Policy-Baustein 2: Inbound-Filter und Prefix-Limits (Was Sie akzeptieren)

Inbound-Policies schützen Sie vor ungewollten oder übermäßigen Routen. Besonders wichtig sind max-prefix und ein klarer Modus: Default-only oder Full Routes. Full Routes erhöhen Ressourcenbedarf erheblich.

• Default-only: weniger Komplexität, weniger Ressourcen, häufig ausreichend
• Full Routes: mehr Kontrolle, aber CPU/Memory und Convergence kritisch
• max-prefix: Pflicht, um Route Flooding abzufangen

Neighbor max-prefix (Beispiel)

router bgp 65010
 neighbor 198.51.100.1 remote-as 65001
 neighbor 198.51.100.1 maximum-prefix 1000 90 warning-only

Policy-Baustein 3: Outbound Traffic Engineering (Egress-Steuerung)

Outbound steuern Sie primär über Local Preference innerhalb Ihrer AS. Höhere Local Pref bedeutet: dieser ISP wird bevorzugt. Das ist der sauberste Mechanismus für Egress-Policy.

• ISP1 bevorzugen: höhere Local Pref für Routes von ISP1
• Backup: niedrigere Local Pref für ISP2
• Failover: bei Session down wechseln Pfade automatisch

Local Preference (Konzeptauszug)

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

set local-preference 100

Policy-Baustein 4: Inbound Traffic Engineering (Ingress-Steuerung)

Inbound ist schwieriger, weil er vom Internet abhängt. Typische Werkzeuge sind AS-Path Prepending (weniger attraktiv machen) und Community-Mechanismen des Providers. Ergebnis ist nie 100% garantiert, aber oft ausreichend steuerbar.

• AS-Path Prepending: ISP2 „länger“ machen, Traffic eher zu ISP1
• Provider Communities: sauberste Variante, wenn Provider unterstützt
• Selective Advertising: bestimmte Präfixe bevorzugt über einen ISP

Risiko Asymmetrie: NAT, State und Security-Policies

Dual-Homing führt oft zu asymmetrischem Traffic. Das ist bei reinem Outbound-Internet meist ok, kann aber bei stateful Security, NAT-Pinning oder bestimmten VPN-Szenarien Probleme verursachen.

• NAT: Rückweg kann über anderen ISP kommen (Pinning/Policy erforderlich)
• Stateful Firewalls: asymmetrische Flows können droppen
• Inbound Services: DNAT/Portforwards erfordern klare Ingress-Policy
• Mitigation: klare Ingress-Zuordnung, Policies, ggf. symmetrische Designs

Operational Model: Runbooks, Monitoring und KPIs für BGP

BGP im Enterprise braucht ein Betriebsmodell: Was ist P1? Welche Checks sind Pflicht? Wie wird eskaliert (Provider)? Ohne Standardchecks steigt MTTR und Risiko in Change Windows.

• Monitoring: BGP Session Up/Down, Prefix Counts, Flap-Rate
• Alerts: max-prefix near/triggered, Session flaps, Default-Route Verlust
• KPIs: Uptime der Sessions, Convergence-Zeit, Ingress/Egress-Verteilung
• Runbooks: standardisierte Diagnose + Provider-Evidence

CLI: BGP-Operability-Snapshot (Copy/Paste)

show bgp summary
show bgp ipv4 unicast
show ip route 0.0.0.0
show ip route summary
show interfaces counters errors
show logging | include BGP|LINEPROTO|LINK-
show processes cpu sorted

Change Management: Warum BGP-Änderungen besonders streng sein müssen

Schon kleine Änderungen an Prefix-Lists oder Route-Maps können große Auswirkungen haben. Deshalb sollten BGP-Changes immer peer-reviewed werden und mit Pre-/Post-Checks sowie Rollback-Plan erfolgen.

• Peer-Review Pflicht: Prefix-Lists, Route-Maps, max-prefix, Communities
• Pre-Checks: Prefix Counts, Default-Route, CPU, Logs
• Post-Checks: Policies greifen, keine Leaks, Sessions stabil
• Rollback: vorheriger Policy-Stand versioniert und schnell einspielbar

Pre-/Post-Checks für BGP-Changes (Evidence)

show bgp summary
show bgp ipv4 unicast
show ip route 0.0.0.0
show running-config | include router bgp|prefix-list|route-map|neighbor
show logging | last 50
show processes cpu sorted

End-to-End-Verifikation: Was Sie im UAT testen müssen

BGP Dual-Homing ist erst abgenommen, wenn Failover und Policy-Ziele nachweisbar funktionieren. Testen Sie Session-Down, Default-Handling, Ingress/Egress-Verhalten und – falls relevant – VPN/Inbound Services.

• Baseline: Prefix Counts je ISP, bevorzugter Egress-Pfad
• Test 1: ISP1 Session Down → Traffic läuft über ISP2
• Test 2: Failback → Rückkehr ohne Flapping
• Test 3: Inbound Steering (Prepend/Community) wirkt erwartbar (best effort)
• Test 4: Inbound Services erreichbar, NAT/Policies konsistent

Evidence-Set (Copy/Paste)

show bgp summary
show bgp ipv4 unicast
show ip route 0.0.0.0
show logging | include BGP
traceroute 1.1.1.1
show interfaces counters errors

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.