Ein Audit der Cisco-Router-Konfiguration deckt Sicherheitsrisiken, Stabilitätsprobleme und Performance-Bremsen auf, bevor sie zu Incidents werden. Ziel ist nicht „alles neu“, sondern eine strukturierte Prüfung mit nachvollziehbaren Findings: Was ist riskant, was kostet Leistung, was fehlt für Betrieb und Compliance. Dieser Leitfaden zeigt eine praxisnahe Audit-Methodik, typische Schwachstellen und konkrete CLI-Checks, mit denen Sie Risiken identifizieren und die Router-Performance optimieren.
Audit-Zielbild: Sicherheit, Stabilität, Performance und Betrieb
Ein professionelles Router-Audit betrachtet vier Ebenen gleichzeitig: Management-Sicherheit, Control-Plane-Stabilität, Datenpfad-Performance und Betriebsfähigkeit (Monitoring, Logs, Backups). Nur so entstehen Maßnahmen, die im Alltag wirken.
- Sicherheit: unautorisierte Zugriffe verhindern, Angriffsflächen minimieren
- Stabilität: Konvergenz, Failover, Control-Plane-Last, Fehlerzähler
- Performance: Durchsatz unter Features (NAT, IPsec, QoS), Drops, MTU/MSS
- Betrieb: Logging, NTP, SNMPv3, Doku, Konfigversionierung
Audit-Vorgehen: So strukturieren Sie die Prüfung
Bewährt ist ein Ablauf in Phasen: Datenerhebung, Risikoanalyse, Performanceanalyse, Priorisierung und Maßnahmenplan. Damit bleibt das Audit reproduzierbar und für Teams nachvollziehbar.
- Scope festlegen: Standorte, WANs, VPNs, Routing-Protokolle, SLA
- Snapshot ziehen: Konfiguration, Status, Zählerstände, Logs
- Findings klassifizieren: kritisch/hoch/mittel/niedrig + Business-Impact
- Quick Wins vs. Design-Themen trennen
- Maßnahmenplan mit Tests und Rollback definieren
Audit-Datenerhebung: Mindestset an CLI-Kommandos
show version
show inventory
show license summary
show running-config
show ip interface brief
show interfaces counters errors
show ip route summary
show ip protocols
show processes cpu sorted
show processes memory sorted
show logging | last 200
Security-Risiken finden: Die häufigsten Findings
In der Praxis sind Security-Findings meist „Low-Hanging Fruits“: offene Management-Zugänge, unsichere Protokolle, fehlende AAA-Standards oder unvollständige Logging-Ketten. Diese Punkte haben hohe Wirkung bei vergleichsweise geringem Änderungsaufwand.
Management-Plane: Zugriff und Authentifizierung
- Telnet aktiv oder SSH nicht restriktiv (keine Access-Class)
- Management aus „any“ erreichbar (kein Management-VLAN/ACL)
- Geteilte Accounts, schwache Secrets, fehlende Rollen
- AAA fehlt oder kein Accounting (keine Nachvollziehbarkeit)
Checks: Management-Sicherheit schnell prüfen
show running-config | include line vty|transport input|access-class|ip ssh|username|aaa
show ip ssh
Unnötige Services und Informationsabfluss
- HTTP/HTTPS-Server aktiv ohne Bedarf
- CDP auf WAN-Interfaces aktiv
- SNMPv2c mit Community-Strings statt SNMPv3
Checks: Unnötige Services erkennen
show running-config | include ip http|cdp run|snmp-server community|snmp-server group|snmp-server user
Policy-Risiken: ACLs und Segmentgrenzen
Ein Router fungiert oft als Segment-Gateway. Häufige Risiken sind „Any-Any“-Regeln, fehlende Trennung von Guest/IoT und nicht dokumentierte Ausnahmen.
- Guest kann interne Netze erreichen
- IoT/Printer haben breite Zugriffe ohne Notwendigkeit
- Management-Ports (SSH/SNMP) sind aus produktiven Netzen offen
Checks: ACL- und Interface-Zuordnung prüfen
show access-lists
show running-config | include ip access-group|access-class
Stabilitätsrisiken: Control Plane, Routing und Failover
Viele „mysteriöse“ Ausfälle sind Control-Plane- oder Konvergenzprobleme: Routing-Flaps, fehlendes Tracking, instabile Nachbarschaften oder zu aggressive Timers. Das Audit sollte genau diese Indikatoren sichtbar machen.
Routing: Nachbarschaften, Routenqualität, Loops vermeiden
- OSPF/EIGRP Nachbarn flappen (Instabilität, Timer-Mismatch, L2-Probleme)
- BGP ohne Prefix-Filter (Risiko von Routenleaks)
- Unkontrollierte Redistribution (Loops, Routenfluten)
Checks: Routing-Stabilität
show ip route
show ip route summary
show ip ospf neighbor
show ip eigrp neighbors
show bgp summary
Failover: Link-Down vs. Path-Down
Ein häufiger Befund ist „Failover existiert, aber funktioniert nur bei Link-Down“. Wenn der ISP-Upstream kaputt ist, bleibt der Router auf einem toten Pfad. IP SLA/Tracking behebt das.
- Kein IP SLA/Tracking bei Dual-WAN
- Failback führt zu Flapping (keine Hysterese/Delay)
Checks: Tracking und IP SLA
show ip sla statistics
show track
show ip route 0.0.0.0
Performance optimieren: Typische Bremsen und Messpunkte
Router-Performance wird häufig durch aktivierte Features bestimmt: NAT, IPsec, QoS und Logging. Ein Audit bewertet, ob diese Features korrekt dimensioniert sind und ob Drops/Fehlerzähler auf MTU, Queueing oder CPU-Bottlenecks hinweisen.
CPU/Memory: Engpässe und Ursachen
- Hohe CPU durch Crypto, NAT oder QoS (softwarebasiert)
- Spikes durch zu detailliertes Logging oder Debugging
- Memory Pressure durch viele Sessions oder große Routing-Tabellen
Checks: Ressourcen und Top-Prozesse
show processes cpu sorted
show processes memory sorted
show platform resources
Interface-Fehler und Drops: Layer-1/2 als Performance-Killer
CRC-Errors, Input Drops oder Output Drops deuten häufig auf Kabel/Transceiver, Duplex/Speed, Queueing oder MTU-Probleme hin. Diese Werte sind auditrelevant, weil sie direkt Nutzererfahrung beeinflussen.
Checks: Fehlerzähler und Drops
show interfaces counters errors
show interfaces | include line protocol|duplex|speed|MTU
show interfaces summary
MTU/MSS: Häufiger Befund bei VPN und PPPoE
VPN und PPPoE erhöhen Overhead. Wenn PMTUD blockiert wird, entstehen Fragmentierung und sporadische Verbindungsprobleme. MSS-Clamping ist ein verbreiteter Quick Win.
interface GigabitEthernet0/1
ip tcp adjust-mss 1360
NAT und VPN als Audit-Fokus: Stabilität und Performance
NAT und VPN sind in Büros/Filialen die häufigsten Ursachen für „läuft manchmal“. Ein Audit prüft, ob No-NAT-Regeln für VPN existieren, ob Übersetzungen plausibel sind und ob IPsec SAs Pakete zählen.
NAT: Was ein Audit erkennen sollte
- Inside/Outside falsch gesetzt
- ACL matcht nicht (falsche Wildcards, falsche Netze)
- No-NAT fehlt für VPN-Traffic
- Zu viele Translations (Kapazität) oder ungewöhnlich viele Misses
Checks: NAT-Health
show ip nat translations
show ip nat statistics
show running-config | include ip nat inside|ip nat outside|ip nat inside source
VPN: Was ein Audit erkennen sollte
- IKEv2 SA steht, aber IPsec SA zählt keine Pakete (Selektoren/NAT/Routing)
- Uneinheitliche Kryptoprofile (Interoperabilitätsrisiko)
- Hohe Crypto-CPU bei Last (Kapazitätsrisiko)
Checks: VPN-Health
show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
QoS-Audit: Wenn Priorisierung mehr schadet als hilft
QoS ist häufig falsch dimensioniert: Shaping zu niedrig, falsche Klassen, oder Policies auf dem falschen Interface. Das führt zu Drops und schlechter Voice/Video-Qualität trotz „QoS aktiv“.
- Shaping muss zur realen WAN-Bandbreite passen
- Voice (EF) braucht LLQ, aber nicht „alles“ darf Priority sein
- Policies gehören ans egress-WAN, nicht zufällig ins LAN
Checks: QoS-Policies und Zähler
show policy-map interface
show running-config | section policy-map
show running-config | section class-map
Monitoring und Betrieb: Ohne Sichtbarkeit keine Optimierung
Ein Performance-Audit ist nur nachhaltig, wenn Monitoring standardisiert ist. Sonst sind Probleme nach zwei Wochen wieder „unsichtbar“. Mindeststandard sind NTP, Syslog und SNMPv3; optional NetFlow/IPFIX für Traffic-Transparenz.
- NTP synchron: Logs korrelierbar, Incidents nachvollziehbar
- Syslog zentral: Interface-Flaps, VPN-Events, Routing-Änderungen
- SNMPv3: sichere Metriken für CPU, Interfaces, Tunnelstatus
Checks: Monitoring-Baseline
show ntp status
show logging | last 50
show running-config | include logging host|snmp-server|ntp server
Findings priorisieren: Risiko x Aufwand x Impact
Ein gutes Audit liefert nicht nur eine Liste, sondern Prioritäten. Quick Wins sind oft: SSH-Restriktionen, Syslog/NTP, SNMPv3, Guest-Segmentierung, IP SLA Tracking. Design-Themen sind: BGP-Policies, VRF-Segmentierung, ZBFW, Redistribution.
Beispiel-Kategorien für Priorisierung
- Kritisch: Offene Management-Zugriffe, fehlende BGP-Filter, fehlende No-NAT bei VPN
- Hoch: Kein zentrales Logging/NTP, instabile Routing-Nachbarschaften, hohe CPU unter Last
- Mittel: Unsaubere Interface-Descriptions, inkonsistente Naming-Standards, fehlende Abnahmeprotokolle
- Niedrig: kosmetische Konfig, nicht genutzte Kommentare, Dokumentationsformalia
Audit-Deliverables: Was am Ende vorliegen sollte
Damit das Audit umsetzbar bleibt, müssen Findings und Maßnahmen klar dokumentiert sein. Ziel ist eine Roadmap, die Changes in kontrollierten Schritten ermöglicht.
- Findings-Liste mit Risiko, Impact, Empfehlung und Testfall
- Konfig-Snippets für Quick Wins (Template-fähig)
- Maßnahmenplan inkl. Change-Fenster, Abnahme- und Rollback-Kriterien
- Messpunkte für Performance (Baseline vs. Zielwerte)
Standard-Post-Checks nach Optimierungen
Nach jeder Optimierung sollten Sie die gleichen Checks wiederholen, um den Effekt messbar zu machen und unbeabsichtigte Nebenwirkungen zu vermeiden.
show ip interface brief
show interfaces counters errors
show processes cpu sorted
show processes memory sorted
show ip route summary
show logging | last 50
show ip nat statistics
show crypto ipsec sa
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.












