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

Red Snapper

3 weeks ago

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.