BGP Soft Reconfiguration vs. Route Refresh: Betrieb und Memory-Impact

Wenn du BGP-Policies änderst (Prefix-Lists, Route-Maps, Communities), willst du die neuen Regeln anwenden, ohne die BGP-Session hart zu resetten. Dafür gibt es zwei Mechanismen: Soft Reconfiguration (Inbound) und Route Refresh. Beide erreichen „Policy neu auswerten“, aber mit sehr unterschiedlichen Nebenwirkungen. Soft Reconfiguration hält eine Kopie der ungefilterten Updates im Speicher – gut für Forensik und ältere Gegenstellen, aber teuer in Memory. Route Refresh fordert Updates beim Nachbarn erneut an – meist der moderne Standard, aber abhängig von der Fähigkeit des Peers und potenziell „laut“ im Update-Traffic. Dieses Tutorial erklärt Betrieb, Trade-offs und Best Practices.

Das Ziel: Policies ändern ohne Session-Reset

Ein harter Reset (clear ip bgp) kann Traffic beeinflussen, weil Routen neu gelernt werden müssen. Soft Mechanismen sollen stattdessen nur die Policy-Neubewertung triggern, ohne die TCP-Session zu reißen.

• Hard Reset: Session down/up, Routen-Churn, potenzieller Traffic-Impact
• Soft Mechanismen: Session bleibt, Policy wird neu angewendet
• Wichtig: Inbound- und Outbound-Änderungen unterscheiden

Route Refresh: der moderne Standard

Route Refresh ist ein BGP-Capability-Mechanismus. Wenn beide Peers Route Refresh unterstützen, kann ein Router den Nachbarn bitten, die Routen erneut zu senden, damit die lokale Inbound-Policy neu ausgewertet wird. Das spart Memory auf dem Router, erzeugt aber Update-Traffic.

• Vorteil: kein dauerhaftes Speichern aller Pre-Policy Updates
• Vorteil: für große Tables (Full Table) meist die bessere Wahl
• Nachteil: hängt vom Peer ab, erzeugt Refresh-Update-Last

Inbound Soft Refresh per Route Refresh

clear ip bgp 203.0.113.1 soft in

Outbound Soft Refresh (Policy neu announcen)

clear ip bgp 203.0.113.1 soft out

Soft Reconfiguration Inbound: „Kopie der Rohdaten“

Soft Reconfiguration (Inbound) speichert die unmodifizierten, vom Nachbarn empfangenen Updates (Pre-Policy). Dadurch kann der Router später jederzeit die Inbound-Policy neu anwenden – ohne den Nachbarn erneut zu fragen. Das ist betrieblich bequem, aber speicherintensiv.

• Vorteil: unabhängig von Peer-Fähigkeiten
• Vorteil: du kannst „received-routes“ auch nachträglich ansehen
• Nachteil: hoher Memory-Impact, besonders bei vielen Prefixes

Soft Reconfiguration aktivieren (Inbound)

router bgp 65000
 neighbor 203.0.113.1 soft-reconfiguration inbound

Memory-Impact: Warum Soft Reconfiguration teuer ist

Bei Soft Reconfiguration hält der Router zusätzlich zur BGP-RIB eine Kopie der empfangenen Routen pro Neighbor. Bei Full Tables kann das schnell in viele hundert MB oder mehrere GB gehen – abhängig von Plattform, AFI/SAFI und Anzahl Peers.

Denkmuster für Speicherverbrauch

$\text{Memory}\approx \text{Prefixes}\times \text{Peers}\times \text{AttributeSize}\times \text{Copies}$

• Mehr Prefixes → mehr Memory
• Mehr Peers → linear mehr Memory
• Mehr Attribute (Communities/Ext-Communities) → mehr Memory
• „Copies“ steigt durch Soft Reconfiguration

Betriebsperspektive: Wann Soft Reconfiguration trotzdem sinnvoll ist

Trotz Memory-Kosten gibt es valide Use-Cases: du willst Troubleshooting/Forensik und eine stabile Policy-Iteration, oder du peerst mit alten Geräten, die Route Refresh nicht sauber unterstützen. In Enterprise-Edges mit wenigen Prefixes ist der Memory-Impact oft akzeptabel.

• Legacy Peers ohne Route Refresh Capability
• Lab/Proof-of-Concept, bei dem „received-routes“ wichtig ist
• Enterprise mit kleiner Prefix-Menge (kein Full Table)

Route Refresh Risiken: Update-Storm und CPU-Spikes

Route Refresh spart Memory, kann aber Last erzeugen: Der Nachbar sendet viele Updates neu, die du neu verarbeiten musst. Bei großen Tables oder vielen Peers kann das CPU und Control Plane belasten. Deshalb: Refresh gezielt und in Wartungsfenstern nutzen, wenn du große Änderungen machst.

• Viele Prefixes: Refresh erzeugt hohe Update-Rate
• Viele Peers: parallele Refreshs können CPU spiken
• Best Practice: nicht alle Peers gleichzeitig refreshen

Inbound vs. Outbound: Was du wirklich „soft“ machen kannst

Inbound-Policy (was du annimmst) lässt sich gut per Route Refresh oder Soft Reconfiguration neu bewerten. Outbound-Policy (was du announcest) erfordert, dass du Updates erneut sendest – auch das geht „soft out“, aber es ist trotzdem ein Update-Event für den Nachbarn.

• Inbound: soft in (Refresh oder Local Re-eval)
• Outbound: soft out (re-advertise mit neuer Policy)
• Beide: können Route Churn erzeugen, je nach Umfang

Verifikation: Unterstützt der Peer Route Refresh?

Bevor du dich auf Route Refresh verlässt, prüfst du die Capabilities im Neighbor-Detail. Wenn Route Refresh nicht verhandelt wurde, ist Soft Reconfiguration (Inbound) die Alternative – oder du musst mit einem Reset leben.

Neighbor Capabilities prüfen

show ip bgp neighbors 203.0.113.1

Best Practices: So entscheidest du richtig

In modernen Netzen ist Route Refresh fast immer die Standardwahl. Soft Reconfiguration nutzt du nur, wenn du einen konkreten Grund hast – und dann selektiv, nicht global.

• Standard: Route Refresh, Soft Reconfiguration aus
• Soft Reconfiguration nur selektiv für einzelne Peers/AFIs
• Bei Full Table: Soft Reconfiguration vermeiden (Memory-Risiko)
• Refreshs seriell planen, nicht parallel über alle Peers

Troubleshooting: „received-routes“ und warum es manchmal fehlt

Viele Engineers wundern sich, dass show ip bgp neighbors ... received-routes nichts zeigt. Das ist normal: Ohne Soft Reconfiguration (Inbound) speichert IOS die Pre-Policy Updates nicht dauerhaft. Mit Route Refresh kannst du sie anfordern, aber nicht immer „historisch“ ansehen.

Received Routes sichtbar machen (mit Soft Reconfiguration)

router bgp 65000
 neighbor 203.0.113.1 soft-reconfiguration inbound

Dann prüfen

show ip bgp neighbors 203.0.113.1 received-routes

Quick-Runbook: Policy ändern mit minimalem Risiko

Diese Sequenz ist ein praxistauglicher Ablauf für Inbound-Policy-Änderungen, ohne die Session zu reißen. Sie enthält außerdem Guardrails gegen Überraschungen.

! 1) Baseline
show ip bgp summary
show ip bgp neighbors 203.0.113.1
! 2) Policy ändern (Prefix-List/Route-Map)
! 3) Soft anwenden

clear ip bgp 203.0.113.1 soft in
! 4) Verifizieren

show ip bgp 

show ip bgp neighbors 203.0.113.1 advertised-routes

show logging | include BGP

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.