Cisco-Router für Network Resilience: Link-Redundanz und Routing-Convergence

Network Resilience mit Cisco-Routern bedeutet: Ausfälle von Links, Providern oder Pfaden führen nicht zum Stillstand, sondern zu einem kontrollierten Failover mit messbarer Convergence-Zeit. In Enterprise-Umgebungen sind „zweite Leitung“ und „zweite Default-Route“ allein nicht ausreichend, weil viele Ausfälle nicht als Link-down auftreten (Path-down, Provider-Routing, DNS- oder Upstream-Probleme). Ein resilientes Design kombiniert Link-Redundanz (physisch/logisch), Pfadüberwachung (IP SLA/Tracking), saubere Routing-Policies (Static/OSPF/BGP) und klare KPI-Definitionen für Umschaltzeiten. Dieser Leitfaden zeigt praxistaugliche Muster für Link-Redundanz und Routing-Convergence inklusive CLI-Evidence.

Resilience-Ziele: Welche KPIs Sie festlegen müssen

Ohne KPIs ist Failover „gefühlt“. Definieren Sie Zielwerte und messen Sie sie: Detection-Zeit (wie schnell wird der Fehler erkannt), Convergence-Zeit (wie schnell ist Routing stabil) und Recovery-Zeit (wann ist Service wirklich nutzbar).

• Detection: Link-down oder Path-down wird erkannt
• Convergence: Routing/Policy schaltet um, ohne Loops/Blackholes
• Service Recovery: DNS/SaaS/VPN wieder stabil nutzbar

KPIs als Zeitkette (vereinfacht)

$\mathrm{MTTR}\_\mathrm{Failover}=\mathrm{Detection}+\mathrm{Convergence}+\mathrm{Service}\_\mathrm{Recovery}$

Link-Redundanz: Physisch ist Pflicht, logisch ist Kür

Resilience beginnt mit echter Diversität: unterschiedliche Kabelwege, unterschiedliche CPEs, idealerweise unterschiedliche Provider. Zwei Links auf demselben Medienweg sind keine echte Redundanz.

• Physisch: diverse Trassen, unterschiedliche Übergabepunkte
• Provider: Dual-ISP reduziert Single-Provider-Risiko
• CPE/Hardware: separate Modems/NTUs, getrennte Stromversorgung
• Routing: getrennte Next-Hops, definierte Prioritäten

Warum „Link up“ nicht reicht: Path-Down als häufigster Ausfalltyp

Viele WAN-Probleme sind Path-Down: der Link ist up, aber Upstream-Routing oder DNS/Internet-Ziele sind nicht erreichbar. Ohne Pfadüberwachung bleibt der Router auf dem „toten“ Pfad.

• Provider-Routing-Fehler: Link up, aber kein Internet/kein Hub
• Upstream-Blackholes: einzelne Ziele nicht erreichbar
• Asymmetrie: Return Path bricht stateful Traffic
• Symptom: „manchmal geht’s“ statt „alles down“

Design Pattern 1: Static Routes + Tracking (einfaches, robustes Failover)

Für viele Branches ist Static + Tracking die beste Balance: geringe Komplexität, klare Failover-Logik, gute Messbarkeit. Entscheidend ist IP SLA mit stabilen Probe-Targets.

• Primärroute mit Track
• Backuproute mit höherer Administrative Distance
• Probe-Targets: intern (Hub/Resolver) und extern (Public DNS) je Use Case

CLI: IP SLA + Track + Default Failover (Muster)

ip sla 10
 icmp-echo 1.1.1.1 source-interface GigabitEthernet0/0
 frequency 5
 timeout 1000
ip sla schedule 10 life forever start-time now
track 10 ip sla 10 reachability
ip route 0.0.0.0 0.0.0.0  track 10

ip route 0.0.0.0 0.0.0.0  200

Verifikation

show ip sla statistics
show track
show ip route 0.0.0.0

Design Pattern 2: OSPF Resilience (Convergence durch IGP)

OSPF bietet schnelle Konvergenz in internen Netzen, wenn Area-Design und Timer passen. Für WAN-Edges wird OSPF oft innerhalb des Unternehmens genutzt, während Internet/WAN-Provider per Static/BGP angebunden sind.

• Stabilität: passive-interface für Zugangsports, nur definierte Neighbors
• Area-Design: Backbone/Stub-Strategien zur Skalierung
• Convergence: Timers/Hello/Dead nur sinnvoll tunen, nicht blind aggressiv

CLI: OSPF-Checks für Resilience

show ip ospf neighbor
show ip route ospf
show logging | include OSPF

Design Pattern 3: BGP Dual-ISP (Edge-Resilience mit Policies)

Für Enterprise-Edges und größere Standorte ist Dual-ISP mit eBGP üblich. Resilience entsteht durch Session-Überwachung, strikte Policies (Prefix-Filter) und definierte Egress/Ingress-Steuerung. Ohne Policies wird BGP zur Risikoquelle.

• Egress: Local Preference intern steuern
• Ingress: Provider-Communities/Prepend (best effort)
• Schutz: max-prefix, Prefix-Lists und Route-Maps
• Convergence: Session-Down → schnelle Umschaltung, ohne Flap-Schleifen

CLI: BGP-Checks für Resilience

show bgp summary
show ip route 0.0.0.0
show logging | include BGP

Convergence-Tuning: Messbar statt „Timer drehen“

Convergence kann man optimieren, aber nur mit Messung. Zu aggressive Timer erhöhen Flaps und CPU. Beginnen Sie mit stabilen Defaults und messen Sie Failover-Zeiten in UAT.

• Messung: Detection (Track down) + Routing-Umschaltung + Service-Test
• Optimierung: Probe-Frequenz/Timeout, Track-Delays, Routing-Policy
• Warnung: zu aggressive Hello/Dead Timer erhöhen Instabilität

CLI: Convergence Evidence (während Failover-Test)

show ip sla statistics
show track
show ip route 0.0.0.0
show logging | last 50

Resilience-Fallen: Asymmetrie, NAT/VPN und Statefulness

Resilience scheitert oft nicht am Routing, sondern an Statefulness: Firewalls, NAT und VPN erwarten symmetrische Pfade. Bei Active/Active Dual-ISP entstehen sonst sporadische Abbrüche.

• Asymmetrischer Return Path: stateful Sessions brechen
• NAT: Translation-State kann beim Providerwechsel wechseln
• VPN: Tunnel-Rekey/DPD kann bei Pfadwechsel flappen
• Mitigation: klare Egress-Policies, Failover bevorzugen, UAT unter Last

Monitoring: Resilience als Betriebs-KPI

Resilience muss im NOC sichtbar sein: Track-Events, RTT/Loss, Link-Flaps und Umschaltzeiten. Ohne Monitoring werden Failover-Probleme erst im Incident entdeckt.

• Alarme: Track down, IP SLA Degradation, Interface errors/drops
• KPIs: Failover-Zeit, Flap-Rate, VPN SA-Flaps (falls relevant)
• Logs: Syslog zentral, NTP synchronized

CLI: Operability Snapshot

show ip sla statistics
show track
show interfaces counters errors
show interfaces | include output drops|queue
show ntp status
show logging | last 50

UAT/Acceptance: Failover-Testplan (Pflicht)

Failover gilt nur als abgenommen, wenn er getestet und dokumentiert ist. Testen Sie Link-down und Path-down, und messen Sie Umschaltzeit plus Service-Recovery.

• Test 1: Link-down ISP1 → ISP2 übernimmt (Zeit messen)
• Test 2: Path-down (Upstream block) → Tracking greift
• Test 3: Rückkehr ISP1 → keine Flap-Schleife, stabile Recovery
• Test 4: VPN/Business-Apps (falls Scope) bleiben stabil

CLI: Evidence-Set (Copy/Paste)

show ip route 0.0.0.0
show ip sla statistics
show track
ping 1.1.1.1 repeat 20
traceroute 1.1.1.1
show logging | last 100

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.