BGP und Default Route: Wann sinnvoll, wann gefährlich

Eine Default Route (0.0.0.0/0) über BGP ist in vielen Unternehmensnetzen der pragmatische Standard: weniger Routen, weniger Ressourcenverbrauch, einfache Failover-Logik. Gleichzeitig kann eine falsch verteilte Default Route extrem gefährlich sein – sie kann Traffic in Blackholes schicken, asymmetrische Pfade erzeugen oder komplette Standorte „vom Internet trennen“, obwohl BGP-Sessions noch established sind. Dieser Beitrag erklärt, wann BGP-Default sinnvoll ist und wann du sehr vorsichtig sein musst.

Was bedeutet „Default Route über BGP“?

Statt tausende Internetpräfixe (Full Routes) zu lernen, übernimmt dein Router eine einzige Route, die alle unbekannten Ziele abdeckt. Der Upstream/Provider wird damit zum „Gateway of last resort“ für dein Netz.

$\text{0.0.0.0/0}=\text{Match für alle IPv4-Ziele}$

• Weniger Routen im RIB/FIB → weniger RAM/CPU
• Einfacheres Edge-Design (besonders Single-Homed)
• Failover oft über BGP-Policy oder zweite Default möglich

Wann ist eine BGP-Default Route sinnvoll?

In vielen typischen Enterprise-Szenarien ist eine Default Route die beste Wahl, weil du keine vollständige Internet-Sicht brauchst. Du willst „ins Internet raus“, nicht das Internet optimieren.

• Single-Homed Internet-Anbindung (ein Provider, ein Exit)
• Branch/Filiale: alles Richtung Zentrale/Provider
• SD-WAN/Hub-and-Spoke: zentrale Egress-Policy
• Hardware mit begrenzten Ressourcen (kein Full Table)

Praxisvorteil: Schlankes Routing

Mit Default Route ist die Routing-Tabelle klein, Updates sind minimal und Konvergenz ist in der Regel einfacher zu betreiben.

Wann ist es gefährlich oder ungeeignet?

Eine Default Route ist dann riskant, wenn dein Netz mehrere gleichwertige Exits hat und du feingranular steuern musst, oder wenn „Session up“ nicht gleich „Internet ok“ ist. Besonders gefährlich wird es, wenn du Defaults unkontrolliert in interne Bereiche verteilst.

• Multihoming mit komplexem Traffic Engineering (Full/Partial Routes sinnvoller)
• Asymmetrische Pfade durch Default + Statefulness (Firewall/NAT/VPN)
• Default wird in Bereiche verteilt, die keinen funktionierenden Rückweg haben
• Upstream liefert Default, obwohl Transit nur teilweise funktioniert

Merker: „Default Route kann Blackholes maskieren“

Wenn alles über /0 geht, fällt ein fehlendes spezifisches Präfix nicht auf – der Traffic „hat ja eine Route“, kommt aber nicht zwingend an.

Typische Default-Designs mit BGP

In der Praxis siehst du drei Muster: Default vom Provider lernen, Default im eigenen AS erzeugen und per iBGP verteilen, oder Default gezielt nur an bestimmte Nachbarn announcen.

• Default inbound vom Provider (du konsumierst nur /0)
• Default zentral erzeugen (Edge) und iBGP-intern verteilen
• Default selektiv an Branch-Router verteilen (Policy)

Default Route nur annehmen: Prefix-List inbound

Wenn du bewusst nur eine Default Route vom Provider willst, filtere inbound streng. So verhinderst du, dass du „aus Versehen“ eine Teil- oder Full Table lernst.

Inbound nur /0 erlauben

Router# configure terminal
Router(config)# ip prefix-list IN-DEFAULT-ONLY seq 10 permit 0.0.0.0/0
Router(config)# ip prefix-list IN-DEFAULT-ONLY seq 999 deny 0.0.0.0/0 le 32
Router(config)# router bgp 65001

Router(config-router)# neighbor 203.0.113.1 remote-as 64500

Router(config-router)# neighbor 203.0.113.1 prefix-list IN-DEFAULT-ONLY in

Router(config-router)# end

Verifikation

Router# show ip bgp 0.0.0.0
Router# show ip route 0.0.0.0
Router# show ip bgp neighbors 203.0.113.1 received-routes

Default Route verteilen: kontrolliert per Route-Map

Wenn du intern iBGP betreibst (z. B. mit Route Reflectors), willst du die Default Route oft zentral einspeisen und verteilen. Das sollte immer mit Filtern und klarer Policy passieren, damit nicht jeder Router „blind“ eine Default erhält.

Default ins BGP bringen (nur wenn im RIB vorhanden)

Ein häufiges Muster ist, eine statische Default Route (oder eine vom Provider gelernte) im RIB zu haben und sie dann in BGP zu announcen.

Router# configure terminal
Router(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.1
Router(config)# router bgp 65001
Router(config-router)# network 0.0.0.0
Router(config-router)# end

Default nur an bestimmte iBGP-Nachbarn announcen (Policy)

Router# configure terminal
Router(config)# ip prefix-list ONLY-DEFAULT seq 10 permit 0.0.0.0/0
Router(config)# route-map DEFAULT-ONLY-OUT permit 10

Router(config-route-map)# match ip address prefix-list ONLY-DEFAULT

Router(config-route-map)# end
Router(config)# router bgp 65001

Router(config-router)# neighbor 10.255.255.11 remote-as 65001

Router(config-router)# neighbor 10.255.255.11 route-map DEFAULT-ONLY-OUT out

Router(config-router)# end

Multihoming mit Default: Failover ja, Traffic Engineering begrenzt

Mit zwei Providern und nur Defaults kannst du Outbound-Failover gut lösen (z. B. über Local Preference). Feingranulare Outbound-Optimierung pro Ziel ist aber kaum möglich, weil du keine spezifischen Internetpräfixe kennst.

• Outbound-Failover: gut via Local Preference
• Outbound-Optimierung pro Ziel: limitiert ohne Full/Partial Routes
• Inbound-Optimierung: weiterhin schwierig, meist Communities/Prepend

Beispiel: ISP1 bevorzugen, ISP2 Backup (Local Pref)

Router# configure terminal
Router(config)# route-map LP-ISP1-IN permit 10
Router(config-route-map)# set local-preference 200
Router(config-route-map)# exit
Router(config)# route-map LP-ISP2-IN permit 10
Router(config-route-map)# set local-preference 100
Router(config-route-map)# end
Router(config)# router bgp 65001

Router(config-router)# neighbor 203.0.113.1 route-map LP-ISP1-IN in

Router(config-router)# neighbor 198.51.100.1 route-map LP-ISP2-IN in

Router(config-router)# end

Gefahr 1: „Session up“ aber Internet down (Partial Failure)

BGP kann established bleiben, obwohl ein Provider nur teilweise routet oder Upstream-Probleme hat. Mit Default Route wird dann weiterhin alles dorthin geschickt. Deshalb brauchst du Monitoring/Tracking und klare Operational Checks.

• BGP established ≠ End-to-End Reachability
• Tests gegen mehrere Ziele (DNS/Anycast) sind aussagekräftiger
• In kritischen Umgebungen: BFD/Tracking/Monitoring einplanen

Operational Checks

Router# show ip bgp summary
Router# show ip route 0.0.0.0
Router# traceroute 8.8.8.8
Router# ping 1.1.1.1

Gefahr 2: Default Route in falsche Bereiche leaken

Wenn du eine Default Route in iBGP/IGP unkontrolliert verteilst, kann ein Teilnetz plötzlich „alles nach oben“ schicken – auch wenn es dort keinen validen Rückweg gibt. Das erzeugt Blackholes oder asymmetrische Pfade, besonders bei Firewalls/NAT.

• Default nur dort verteilen, wo Rückrouting garantiert ist
• Filtern und Scope begrenzen (Route-Map, Prefix-List)
• Bei Branches: klare Hub-and-Spoke-Policy

Gefahr 3: Asymmetrische Pfade bei Statefulness (Firewall/NAT/VPN)

Wenn Outbound über Default Route Uplink A geht, aber Rückweg über Uplink B kommt, können stateful Firewalls/NAT Sessions verlieren. Das ist besonders relevant bei Dual-ISP und nur Default-Routen.

• Symmetrie planen (Policy, NAT-Design, Session-Pinning)
• ECMP vermeiden, wenn Statefulness kritisch ist
• Verifikation mit Traceroute aus beiden Richtungen

Best Practices: Default Route über BGP sicher betreiben

Mit diesen Regeln bleibt Default-Routing robust und nachvollziehbar – ohne die typischen Gefahren.

• Inbound strikt filtern (Default-only oder definierte Präfixsets)
• Outbound strikt filtern (nur eigene Präfixe announcen)
• maximum-prefix als Schutz aktivieren
• Local Pref für Outbound-Priorität nutzen (bei Multihoming)
• Default-Verteilung intern nur gezielt und dokumentiert
• Monitoring/Tracking gegen echte Internetziele

Max-Prefix Schutz (Beispiel)

Router# configure terminal
Router(config)# router bgp 65001
Router(config-router)# neighbor 203.0.113.1 maximum-prefix 10 90 restart 5
Router(config-router)# end

Verifikation: Default Route, BGP und Pfadwahl prüfen

Nach jeder Änderung prüfst du: Default im BGP vorhanden, in der Routing-Tabelle aktiv, und der tatsächliche Pfad funktioniert end-to-end.

Router# show ip bgp 0.0.0.0
Router# show ip route 0.0.0.0
Router# show ip bgp neighbors 203.0.113.1 received-routes
Router# traceroute 8.8.8.8

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.