Site icon bintorosoft.com

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

Red Snapper

Network Engineer Intently Analyzing Data Server Racks in a Neon-Lit High Tech Data Center

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.

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.

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“.

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.

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.

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.

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.

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.

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.

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.

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

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