Cisco-Router-Konfiguration: Häufige Fehler von Kunden beim Requirements-Briefing

Die häufigsten Probleme in Cisco-Router-Projekten entstehen nicht durch IOS/IOS XE oder „schwierige Befehle“, sondern durch unvollständige oder widersprüchliche Requirements im Briefing. Fehlende Providerdaten, unklare Segmentierungsregeln oder nicht definierte Abnahmekriterien führen zu Verzögerungen, Nachträgen und vermeidbarer Downtime. Dieser Leitfaden zeigt typische Kundenfehler beim Requirements-Briefing und wie Sie sie mit einer klaren Inputstruktur, testbaren Kriterien und einfachen Checklisten zuverlässig vermeiden.

Fehlerbild: „Internet soll gehen“ ohne Provider-Übergabedaten

Ohne WAN-Details kann niemand belastbar konfigurieren oder testen. In der Praxis fehlen häufig VLAN-Tagging, MTU oder PPPoE-Daten – und das fällt erst im Change-Fenster auf.

• Fehlt oft: IP/Subnetz, Gateway, VLAN-Tag, PPPoE-User/Pass, MTU
• Folge: Link up, aber kein Internet; zusätzlicher Aufwand für Abstimmung/Provider
• Vermeidung: Providerdatenblatt als Pflichtanhang, Vorab-Pfadtests definieren

Minimaldaten WAN (Pflichtliste)

• Übergabe: Port, Medium, VLAN (falls tagging), CPE/Modem-Rolle
• Adressierung: IP/Subnetz, Gateway, ggf. zusätzliche Routen
• Zugang: PPPoE (falls relevant), Credentials
• MTU: Provider-Vorgabe, Besonderheiten (z. B. PPPoE)

Fehlerbild: Unklarer IP-/VLAN-Plan („macht ihr mal“)

Wenn Rollen-VLANs, Subnetzgrößen und Gateway-Regeln nicht festgelegt sind, entstehen Ad-hoc-Entscheidungen. Das führt zu Drift und erschwert späteres Troubleshooting sowie Multi-Standort-Rollouts.

• Fehlt oft: VLAN-Rollen (Users/Guest/IoT/MGMT), Subnetzgrößen, Gateway-Standard
• Folge: inkonsistente VLANs, schwer skalierbar, Nacharbeiten beim nächsten Standort
• Vermeidung: Rollenliste + IP-Schema pro Standort, /64-/24-/26-Standards definieren

Subnetting-Hinweis (typische Standardisierung)

Für kleinere Segmente (Voice/IoT) wird häufig /26 genutzt: 64 Adressen, 62 nutzbar. Solche Standards gehören ins Briefing.

$2^6=64$

Fehlerbild: Segmentierung ohne Policy-Matrix

„Guest darf nicht ins LAN“ ist gut, reicht aber nicht für IoT, Drucker, POS oder Admin-Zugriffe. Ohne Policy-Matrix wird jede Regel zur Diskussion – und damit zur Nachtragsquelle.

• Fehlt oft: Quelle/Ziel/Ports/Protokolle, Owner, Logging-Anforderungen
• Folge: zu breite Regeln („permit any“), Sicherheitsrisiko oder ständige Rückfragen
• Vermeidung: Policy-Matrix als Pflichtanhang, Rollenmodell (Admin/Support/User)

Fehlerbild: VPN-Anforderung ohne Tunnelmatrix

VPN-Projekte scheitern häufig an fehlenden Details: welche Netze, welche Peers, welche Kryptovorgaben? Ohne Matrix kommt es zu „Tunnel up, kein Traffic“ und langen Debug-Sessions.

• Fehlt oft: Peer-IP/FQDN, lokale/remote Netze, PSK/Zertifikate, Rekey/DPD
• Folge: Interoperabilitätsprobleme, No-NAT vergessen, MTU/MSS-Probleme
• Vermeidung: VPN-Matrix (Peers, Netze, Crypto-Policy), No-NAT als Pflicht

VPN-Checks, die ins Briefing gehören sollten

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

Fehlerbild: Dual-ISP gewünscht, aber kein Failover-Verhalten definiert

„Zwei Leitungen“ ist nicht gleich „Redundanz“. Ohne klare Definition (Primary/Backup vs. Active/Active) und ohne Path-Tracking bleibt Dual-WAN oft instabil oder nutzlos.

• Fehlt oft: Umschaltkriterien (Link-Down vs. Path-Down), Zielwerte, Testplan
• Folge: „Link up, Internet down“, Flapping, ungeplante Session-Abbrüche
• Vermeidung: IP SLA/Tracking als Standard, Failover-Testfälle definieren

Fehlerbild: NAT wird „vergessen“ oder Verantwortlichkeit ist unklar

Wenn nicht klar ist, ob NAT am Router oder an der Firewall stattfindet, entstehen doppelte oder widersprüchliche Regeln. Das ist einer der häufigsten Gründe für „Internet geht nicht“ nach Changes.

• Fehlt oft: NAT-Owner (Router vs. Firewall), Quellnetze, No-NAT für VPN
• Folge: unerwartete NAT-Übersetzungen, VPN-Traffic bricht, Inbound-Services unsicher
• Vermeidung: NAT-Ownership schriftlich festlegen, NAT-Policy dokumentieren

NAT-Checks (briefing-tauglich)

show ip nat statistics
show ip nat translations

Fehlerbild: Security/Hardening wird als „optional“ behandelt

Wenn Hardening nicht im Briefing steht, wird es oft reduziert oder später als Zusatzaufwand verhandelt. Das rächt sich in Audits und erhöht das Risiko von Brute-Force- oder Scan-Angriffen.

• Fehlt oft: SSH-only, Management-ACL, AAA/Accounting, Syslog/NTP
• Folge: offene Managementports, keine Audit-Spuren, Compliance-Risiko
• Vermeidung: Hardening-Baseline als Pflichtanforderung definieren

Fehlerbild: Abnahme ist nicht definiert („wenn es läuft, ist es fertig“)

Ohne Abnahmekriterien sind Projekte nie wirklich fertig. Dann beginnt das „Schleifen“: Diskussionen über Funktionsumfang, Performance und Verantwortlichkeiten.

• Fehlt oft: Pre-/Post-Checks, UAT-Tests, Failover-Tests, Dokumentationsumfang
• Folge: unklare Qualität, spätere Nacharbeiten, Streit über „fertig“
• Vermeidung: Abnahme als Pass/Fail definieren, Outputs als Deliverable

Pre-/Post-Checks als Mindestset

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

Fehlerbild: Kein Change-Fenster, kein Notfallzugang, kein Rollback

Auch die beste Planung schützt nicht vor Provider-Überraschungen. Wenn Console/OOB nicht verfügbar ist und Rollback nicht vorbereitet wurde, wird ein kleiner Fehler zur langen Downtime.

• Fehlt oft: OOB/Console-Zugang, Remote-Hands, Rollback-Trigger und Schritte
• Folge: verlängerte Ausfälle, hektische Änderungen, erhöhtes Risiko
• Vermeidung: Rollback-Plan + Notfallzugang als Pflicht im Briefing

Fehlerbild: Requirements ohne Prioritäten und „Nicht-Ziele“

Wenn alles „kritisch“ ist, kann ein Anbieter nicht sinnvoll planen. Priorisieren Sie Anforderungen und definieren Sie bewusst, was nicht umgesetzt wird. Das stabilisiert Zeitplan und Budget.

• Fehlt oft: Prioritäten (Must/Should/Could), Non-Goals, Exclusions
• Folge: Scope-Drift, Nachträge, verspätete Go-Lives
• Vermeidung: MoSCoW-Priorisierung, Exclusions schriftlich

Praktische Gegenmaßnahme: Input-Template für ein sauberes Briefing

Mit einem festen Input-Template vermeiden Sie die meisten Fehler. Diese Liste kann als Standardformular vor jedem Projekt genutzt werden.

• Standortdaten: SiteID, Ansprechpartner, Wartungsfenster, Remote-Hands
• WAN: IP/Subnetz, Gateway, VLAN/PPPoE, MTU, Providerkontakt
• LAN: VLAN-Rollen, Subnetze, Gateway-Standard, DHCP/DNS
• Routing: Static/OSPF/BGP, Pfadpräferenzen, Filteranforderungen
• NAT/VPN: NAT-Owner, No-NAT, VPN-Matrix (Peers/Netze/Crypto)
• Security: Hardening-Baseline, Managementnetz, AAA, Logging/Audit
• Abnahme: Pre-/Post-Checks, UAT, Failover-Tests, Deliverables
• Rollback: Trigger, Schritte, OOB/Console-Zugang

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.