Ein klassisches Szenario in Enterprise-Netzwerken: Ein Branch kann problemlos andere Netzwerke pingen, aber eine geschäftskritische Applikation reagiert nicht. Solche Probleme treten häufig auf, wenn Routing, MTU-Einstellungen oder Policies (ACLs, Firewall, QoS) inkonsistent sind. Eine strukturierte Troubleshooting-Methode ist entscheidend, um die Ursache schnell zu identifizieren und die Anwendung wiederherzustellen.
1. Problemdefinition und Scope
Bevor mit der Analyse begonnen wird, sollte das Problem genau eingegrenzt werden:
- Welche Endpunkte und Anwendungen sind betroffen?
- Ist das Problem nur bei einer Applikation oder global im Branch sichtbar?
- Welche Protokolle verwendet die Applikation (TCP, UDP, HTTP, etc.)?
- Gibt es kürzliche Änderungen an Routing, Firewall, VPN oder QoS?
ping
traceroute
telnet
2. Layer-3 Routing Checks
Auch wenn ICMP-Pings erfolgreich sind, kann die Routing-Tabelle für Applikationstraffic fehlerhaft sein:
- Prüfen, ob spezifische Routen zum Ziel vorhanden sind und die Next-Hops korrekt sind
- Static Routes, OSPF- oder BGP-Routen auf Inkonsistenzen prüfen
- Default Route und VPN-Routing prüfen
show ip route
show ip route vrf
show ip ospf neighbor
show ip bgp summary
Route-Matching auf Applikationshost
Die Applikation kann Traffic über ein anderes Interface senden als Ping-Tests. Prüfen Sie Source-IP und Routing-Entscheidung:
traceroute source
show ip route | include via
3. MTU- und Fragmentierungsprüfung
Applikationen, insbesondere solche mit großen Payloads, reagieren nicht, wenn die MTU auf dem Pfad zu klein ist:
- Ping mit “Don’t Fragment” Flag testen
- Path MTU Discovery überprüfen
- VPN-Tunnel (IPSec, GRE) berücksichtigen, da Tunnel Overhead die effektive MTU reduziert
ping size 1500 df-bit
ping size 1400 df-bit
show interfaces
4. Firewall- und Policy-Checks
Firewall-Regeln oder ACLs können ICMP erlauben, aber TCP/UDP für die Applikation blockieren:
- Inbound/Outbound ACLs prüfen
- Stateful Firewall: Ist die Session korrekt aufgebaut?
- VPN/Overlay Policies auf Applikationsports prüfen
show access-lists
show run | section access-list
show ip nat translations
show crypto ipsec sa
QoS und Rate-Limiting
QoS-Policies oder Rate-Limits können Applikationstraffic verzögern oder droppen:
show policy-map interface
show interface | include drops
5. TCP-Level-Diagnose
Wenn ICMP funktioniert, TCP aber nicht, können folgende Prüfungen helfen:
- TCP Handshake prüfen: SYN/SYN-ACK/ACK
- Packet Capture auf Branch oder Firewall durchführen
- Check auf RST-Pakete oder Timeouts
tcpdump -i host and port
show conn detail | include
6. End-to-End Tracing und Telemetrie
Tools wie Traceroute, NetFlow, sFlow oder Router-Telemetrie können helfen, Engpässe oder Droppoints zu identifizieren:
- Traceroute für Applikationsports
- NetFlow/SFlow: Top Talker, Top Prefixes, Drop-Points
- Correlation mit Routing-Events und Tunnelzustand
traceroute port
show flow monitor cache
show platform telemetry
7. Hypothesenbildung und Test
Nach Sammlung der Daten wird eine Hypothese erstellt und schrittweise validiert:
- Beispiel MTU: Reduzierte Paketgröße auf 1400 testen
- Beispiel Routing: Temporäre Static Route auf Branch konfigurieren
- Beispiel Policy: ACL temporär lockern und testen
configure terminal
ip route 8. Remediation und Rollback
Nach Bestätigung der Ursache erfolgt die kontrollierte Remediation:
- Konfigurationsänderungen schrittweise einspielen
- Rollback-Plan definieren für unerwartete Effekte
- Monitoring aktivieren, um Stabilität sicherzustellen
configure terminal
ip route 9. Post-Incident Dokumentation
Nach erfolgreicher Fehlerbehebung sollten alle Schritte dokumentiert werden:
- Timeline der Diagnoseschritte
- Root Cause Analysis (z.B. MTU mismatch, ACL-Block, falsches Routing)
- Lessons Learned für zukünftige Vorfälle
- Update Runbooks und Monitoring Alerts
| Time | Event | Source | Action Taken |
|------------|-------------------------------------------|------------|---------------------------|
| 09:05 | Branch App nicht erreichbar | NOC Alert | Ping OK, TCP Fail |
| 09:10 | MTU auf Tunnel geprüft | Router1 | Ping df-bit 1500 failed |
| 09:15 | MTU auf 1400 getestet | Router1 | TCP handshake erfolgreich |
| 09:20 | Firewall ACL geprüft | FW1 | Keine Blockierung |
| 09:25 | Remediation durchgeführt | Router1 | Config angepasst |
| 09:30 | Anwendung stabil | Monitoring | Verified |
Best Practices
- Systematisch vorgehen: Routing → MTU → Policy → TCP → Telemetrie
- ICMP allein ist kein Indikator für funktionierende Applikationen
- MTU und Tunnel Overhead früh prüfen
- Kontrollierte Hypothesenbildung und Testumgebung nutzen
- Dokumentation und RCA nach jedem Vorfall erstellen
- Monitoring Alerts für Drops, Session-Timeouts und Flapping aktivieren
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.