Cisco-Router-Troubleshooting: Internet weg/langsam, VPN-Abbrüche, Routing-Fehler

Wenn Internet „weg“ oder „langsam“ ist, VPNs abbrechen oder Routing plötzlich falsche Wege nimmt, liegt die Ursache meist nicht an einem einzelnen Befehl, sondern an einem Zusammenspiel aus Layer-1/2, WAN-Pfad, NAT, MTU/MSS, Crypto-Status und Routing-Entscheidungen. Dieses Troubleshooting-Tutorial liefert eine praxiserprobte Vorgehensweise mit klaren Checks und erwarteten Ergebnissen, damit Sie Probleme systematisch eingrenzen und schnell stabilisieren können.

Troubleshooting-Methodik: Erst stabilisieren, dann optimieren

Arbeiten Sie immer vom Einfachen zum Komplexen und sichern Sie zuerst die Betriebsfähigkeit: Management-Zugang, Zeit/Logs, Basis-Connectivity. Danach analysieren Sie Performance (Drops, MTU, CPU) und erst zuletzt Detailfeatures (QoS, Policies).

• Symptom präzisieren: „weg“ (Down) vs. „langsam“ (Degradation) vs. „sporadisch“
• Betroffene Domäne klären: nur ein VLAN, nur ein Standort, nur ein Ziel?
• Baseline prüfen: Link, IP, Default-Route, DNS, NAT, VPN, Routing-Nachbarn
• Änderungen/Events: letzter Change, Providerarbeiten, Strom, Kabel, neue Policies

Erste Datenerhebung (Snapshot) – immer zuerst

show clock
show version
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show logging | last 80
show processes cpu sorted
show processes memory sorted

Problem 1: Internet weg (keine Erreichbarkeit)

Bei „Internet weg“ prüfen Sie in dieser Reihenfolge: physischer Link, IP-Konfiguration, Gateway/ARP, Default-Route und NAT. Viele Fehler entstehen durch Provider-Übergaben, falsches VLAN-Tagging oder fehlende Default-Route.

Schritt 1: WAN-Link und Interface-Status

show ip interface brief
show interfaces | include GigabitEthernet0/0|line protocol|MTU
show interfaces counters errors

• Erwartet: WAN-Interface ist up/up, keine auffälligen CRC/Errors
• Hinweis: viele CRC/Errors deuten auf Kabel/SFP/Portparameter

Schritt 2: Gateway-Erreichbarkeit und ARP

show ip arp | include 198.51.100.1
ping 198.51.100.1
traceroute 198.51.100.1

• Erwartet: ARP-Eintrag für Gateway vorhanden und Ping erfolgreich
• Wenn ARP fehlt: VLAN/Encapsulation, falsches Subnetz oder Provider-Hand-off prüfen

Schritt 3: Default-Route und Next-Hop

show ip route 0.0.0.0
show ip route | include 0.0.0.0

• Erwartet: Default-Route zeigt auf das Provider-Gateway
• Fehlt die Route: Internet ist aus Sicht des Routers nicht erreichbar

Schritt 4: NAT prüfen (wenn interne Netze betroffen)

show ip nat statistics
show ip nat translations

• Erwartet: bei aktivem Client-Traffic erscheinen dynamische Translations
• Keine Translations: NAT-ACL matcht nicht oder inside/outside falsch

Problem 2: Internet langsam (Degradation)

Bei „langsam“ ist der Link oft up, aber es gibt Drops, Fehlerzähler, MTU/MSS-Probleme oder CPU-Engpässe durch NAT/VPN/QoS. Ziel ist, objektive Messpunkte zu finden: Drops, RTT, Paketverlust und Auslastung.

Schritt 1: Fehlerzähler und Drops

show interfaces counters errors
show interfaces | include input errors|CRC|drops|output drops|queue

• Viele Input Errors/CRC: Layer-1/2 Problem (Kabel/SFP/Port)
• Output Drops/Queue Drops: Queueing/Shaping/QoS oder Bandbreite zu niedrig

Schritt 2: CPU/Memory – typische Performance-Bremse

show processes cpu sorted
show processes memory sorted
show platform resources

• Erwartet: CPU stabil im Normalbereich; keine dauerhaften Spitzen
• Hohe CPU: häufig Crypto, NAT, QoS oder exzessives Logging

Schritt 3: MTU/MSS – sporadische Langsamkeit und Timeouts

Fragmentierung oder blockiertes PMTUD führt oft zu „manche Seiten gehen, manche nicht“ oder zu langsamen HTTPS-Verbindungen. MSS-Clamping ist ein gängiger Quick Win bei PPPoE/VPN.

show interfaces | include MTU
show running-config | include ip tcp adjust-mss

interface GigabitEthernet0/1
 ip tcp adjust-mss 1360

Schritt 4: Pfadmessung (Latenz und Loss)

ping 8.8.8.8 repeat 20
traceroute 1.1.1.1

• Hoher Paketverlust: Providerpfad, lokale Drops oder MTU/Queueing
• Hohe RTT: Upstream-Auslastung, QoS/Shaping oder Routing-Umwege

Problem 3: VPN-Abbrüche (Site-to-Site oder Remote Access)

VPN-Abbrüche entstehen häufig durch instabile WAN-Pfade, NAT-T-Probleme, Rekey/DPD-Timeouts, MTU/MSS oder asymmetrisches Routing. Wichtig ist die Unterscheidung: IKEv2 SA flappt oder nur IPsec SA zählt keine Pakete.

Schritt 1: IKEv2/IPsec Status prüfen

show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail

• IKEv2 SA flappt: Pfad instabil, DPD, Peer-Erreichbarkeit, UDP 500/4500
• IKEv2 SA stabil, IPsec zählt keine Pakete: Selektoren/NAT/Routing

Schritt 2: Logs auf VPN-Events filtern

show logging | include IKEV2|IPSEC|CRYPTO

• Erwartet: klare Hinweise auf Rekey/DPD/Peer-Timeouts
• Viele Resets: häufig WAN-Loss, MTU oder Provider-NAT

Schritt 3: NAT und No-NAT für VPN prüfen

Ein Klassiker: VPN-Traffic wird genattet, dadurch passen Selektoren nicht. Ergebnis: Tunnel „up“, aber Traffic bricht oder ist einseitig.

show running-config | include ip nat inside|ip nat outside|ip nat inside source
show ip nat translations

• Erwartet: keine NAT-Translations für VPN-Subnetze
• Wenn doch: No-NAT fehlt oder Reihenfolge/Route-Map ist falsch

Schritt 4: MTU/MSS speziell für VPN

show interfaces | include MTU
show running-config | include ip tcp adjust-mss

• Erwartet: MSS-Clamping ist gesetzt, wenn VPN/PPPoE im Pfad ist
• Symptom bei MTU: große Downloads/HTTPS instabil, kleine Pings ok

Problem 4: Routing-Fehler (falscher Pfad, kein Rückweg, Flapping)

Routing-Probleme zeigen sich als „ein Netz geht, das andere nicht“ oder als Umwege im Traceroute. Häufige Ursachen sind fehlende Rückrouten, falsche Administrative Distance, Redistribution ohne Filter oder instabile Nachbarschaften.

Schritt 1: Routing-Tabelle und Route-Quellen prüfen

show ip route
show ip route summary
show ip protocols

• Erwartet: Zielnetze existieren, Quelle (S/O/D/B) ist plausibel
• Fehlende Route: kein Forward-Pfad oder kein Default

Schritt 2: Nachbarschaften (OSPF/EIGRP/BGP) stabil?

show ip ospf neighbor
show ip eigrp neighbors
show bgp summary

• Flapping: L2-Probleme, Timer-Mismatch, instabile WANs oder CPU-Last
• BGP Idle/Active: Peer nicht erreichbar, ACL/Firewall, falsche Parameter

Schritt 3: Policy-Routing (PBR) und Route-Maps als Hidden Cause

PBR kann Traffic gezielt umleiten. Bei Fehlern wirkt das wie „Routing kaputt“, obwohl die Routing-Tabelle korrekt ist. Daher PBR immer explizit prüfen.

show running-config | include ip policy route-map
show route-map

Schritt 4: Traceroute mit Source – Rückweg sichtbar machen

traceroute 10.20.10.10 source 10.10.10.1
ping 10.20.10.10 source 10.10.10.1

• Wenn Hinweg ok, Rückweg fehlt: Remote-Seite braucht Route zurück
• Wenn Umweg: Kosten/AD/Policies prüfen

Quick-Win Checklisten: Symptome zu Ursachen mappen

Diese Zuordnung hilft, schneller in die richtige Richtung zu prüfen, statt „alles“ zu debuggen.

Internet weg

• WAN up/down: physischer Link, Provider-Hand-off, VLAN/PPPoE
• Gateway nicht erreichbar: ARP, Subnetz, Port-/VLAN-Mismatch
• Default-Route fehlt: statische Route/Tracking, Routing-Protokoll
• Nur Clients betroffen: NAT inside/outside, NAT-ACL, DNS

Internet langsam

• CRC/Input Errors: Kabel/SFP/Portparameter
• Output Drops: Shaping/QoS/Bandbreite, Queueing
• Hohe CPU: NAT/VPN/QoS, Logging, zu viele Sessions
• HTTPS instabil: MTU/MSS, PMTUD blockiert

VPN-Abbrüche

• IKEv2 SA flappt: WAN-Loss, DPD, UDP 500/4500/ESP, Peer-Path
• IPsec zählt keine Pakete: Selektoren, No-NAT, Routing, asymmetrischer Pfad
• Performance schlecht: MTU/MSS, Crypto-CPU, QoS

Routing-Fehler

• Route fehlt: Protokoll/Redistribution/Filter, Default-Route
• Falscher Pfad: AD/Kosten/Policies, PBR, BGP Attributes
• Flapping: L2/Provider/CPU, Timer, Instabilität im Underlay

Standard-SOP: Pre-/Post-Checks für reproduzierbare Fehleranalyse

Wenn Sie Troubleshooting standardisieren, sparen Sie Zeit und vermeiden blinde Flecken. Diese SOP eignet sich als Runbook für Betrieb und Change-Fenster.

Pre-Check Snapshot

show ip interface brief
show interfaces counters errors
show ip route summary
show processes cpu sorted
show logging | last 50

Feature-spezifische Checks (nur wenn relevant)

show ip nat statistics
show ip nat translations
show crypto ikev2 sa
show crypto ipsec sa
show policy-map interface

Post-Check nach Fix

show ip interface brief
show ip route
show interfaces counters errors
ping 8.8.8.8 repeat 10
traceroute 1.1.1.1

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.