Eine Cisco-Router-Konfiguration wird schnell, günstig und stabil, wenn die notwendigen Daten vorab vollständig vorbereitet sind. In der Praxis entstehen Verzögerungen und Nachträge fast immer durch fehlende Provider-Details, unklare IP-/VLAN-Pläne, nicht definierte Policies oder unvollständige VPN-Informationen. Diese Checkliste zeigt, welche Informationen Sie vor Projektstart sammeln sollten, damit Design, Umsetzung, Abnahme und Betrieb ohne „Schleifen“ funktionieren.
Projekt- und Standortbasis: Kontext, Scope und Verantwortlichkeiten
Ohne klare Rahmenbedingungen wird jedes technische Detail zur Diskussion. Definieren Sie daher zuerst den Scope und die Beteiligten – insbesondere bei mehreren Standorten.
- Standort(e): SiteID, Adresse, Rack/Power, Wartungsfenster, Remote-Hands
- Scope: WAN, VLANs, Routing, NAT, VPN, QoS, Monitoring (ja/nein)
- Abgrenzung: Router vs. Firewall vs. Switch vs. Provider (Owner je Bereich)
- Kontakte: Provider, interner Betrieb, Security, Ansprechpartner für UAT
- Change-Infos: Ticket-ID, Kommunikationsplan, Eskalationspfad
Geräte- und Plattformdaten: Hardware, Software und Lizenzen
Die Plattform bestimmt Features (z. B. VPN-Durchsatz, IPsec-Optionen, IOS XE). Stellen Sie sicher, dass Modell, Versionen und Lizenzen bekannt sind, bevor Anforderungen festgezurrt werden.
- Routermodell und Seriennummer
- IOS/IOS XE-Version und Feature-Set/Lizenzstatus
- Module/Ports (SFP, WAN-Module), Medien (Kupfer/Glas)
- Geplante Performance: NAT/VPN/QoS-Last, gleichzeitige Sessions
CLI-Infos, die Sie vorab bereitstellen können (Ist-Stand)
show version
show inventory
show license summary
WAN/ISP-Daten: Provider-Übergabe (häufigster Engpass)
Für „Internet geht nicht“-Fehler ist fast immer die Provider-Übergabe verantwortlich: IPs, VLAN-Tagging, PPPoE oder MTU fehlen. Sammeln Sie diese Daten zwingend vorab.
- Übergabe: Port/Medium, Hand-off (Ethernet, VLAN), CPE/Modem-Rolle
- Adressierung: öffentliche IP/Subnetz, Gateway, ggf. statische Routen
- Authentifizierung: PPPoE-User/Pass (falls relevant), Zugangsdaten
- MTU/Providerbesonderheiten (z. B. PPPoE, Carrier-Policies)
- Dual-ISP (wenn vorhanden): beide Providerparameter vollständig
LAN-Daten: VLAN-Rollen, IP-Plan und Switch-Uplinks
Der Router kann VLAN-Gateways bereitstellen (Router-on-a-Stick) oder nur Edge sein (L3-Core). Dafür müssen VLANs, Subnetze und Uplink-Details feststehen.
- VLAN-Liste: IDs, Rollen (Users/Guest/IoT/Voice/MGMT)
- IP-Plan je VLAN: Subnetz, Gateway-IP, DHCP-Strategie
- Switch-Uplink: Trunk/Access, erlaubte VLANs, Native VLAN (falls genutzt)
- DHCP: lokaler DHCP vs. zentraler DHCP-Server (Relay erforderlich?)
- DNS: interne DNS-Server, Suchdomäne, Split-DNS (wenn relevant)
Subnetting-Orientierung: /26 als Standard für kleine Segmente
Für Voice/IoT wird häufig /26 genutzt: 64 Adressen, 62 nutzbar. Solche Standards sollten im IP-Plan festgelegt sein.
Routing-Daten: Static/OSPF/EIGRP/BGP und Pfadpräferenzen
Routing-Anforderungen müssen eindeutig sein: Welche Netze werden wo announced? Gibt es Summaries? Gibt es BGP-Policies? Unklarheiten hier führen zu Loops, falschen Pfaden oder Instabilität.
- Routingmodell: Static, OSPF, EIGRP, BGP (und warum)
- Nachbarn/Peers: IPs, ASNs (bei BGP), Area/Process (bei OSPF)
- Pfadpräferenz: Primary/Backup, Active/Active, Failover-Kriterien
- Filterpflicht: Prefix-Lists/Route-Maps, max-prefix (bei BGP)
- Summarization: aggregierbares IP-Schema pro Standort (wenn Multi-Standort)
NAT-Daten: Verantwortlichkeit, Quellnetze, No-NAT und Inbound-Services
NAT ist eine der häufigsten Fehlerquellen. Klären Sie vorab, ob NAT auf Router oder Firewall liegt, welche Netze Internetzugang erhalten und welche Ausnahmen (No-NAT) gelten.
- NAT-Owner: Router oder Firewall (klar festlegen)
- NAT-Quellnetze: welche VLANs dürfen ins Internet?
- No-NAT: VPN-Subnetze und Ausnahmen (Pflicht bei Site-to-Site)
- Inbound: Portweiterleitungen/Static PAT (Port, Ziel, Owner, Zweck)
- Logging-Anforderung: NAT/Inbound-Events protokollieren (ja/nein)
VPN-Daten: Tunnelmatrix, Kryptostandards und Betrieb
VPN gelingt nur, wenn eine Tunnelmatrix vorliegt. Ohne Peers, Netze und Kryptoparameter entsteht „Tunnel up, kein Traffic“. Sammeln Sie daher alle VPN-Infos strukturiert.
- VPN-Typ: Site-to-Site, Remote Access, GRE/VTI/DMVPN (wenn relevant)
- Peers: IP/FQDN, Primary/Backup, Ansprechpartner
- Interessante Netze: lokale/remote Subnetze oder Tunnel-IPs
- Authentifizierung: PSK oder Zertifikate, Key-Handling
- Krypto-Policy: IKEv2, Cipher/Hash, DH/PFS, Rekey/DPD
- MTU/MSS-Vorgaben: MSS-Clamping erforderlich (ja/nein)
VPN-Verifikationsinfos, die Sie einplanen sollten
show crypto ikev2 sa
show crypto ipsec sa
show crypto session detail
Security- und Policy-Daten: Segmentierung, Management und Audit
Security-Anforderungen müssen im Vorfeld als Policy-Matrix vorliegen. Besonders wichtig: Guest/IoT-Regeln, Managementzugriffe und Audit/Logging. Ohne klare Policies wird entweder zu viel erlaubt oder der Betrieb blockiert.
- Policy-Matrix: Quelle/Ziel/Ports/Protokolle, Zweck, Owner
- Managementnetz: erlaubte Admin-Subnets, SSH-only, AAA (falls gefordert)
- Hardening-Baseline: deaktivierte Services, Session-Timeouts, Zugriffsbeschränkung
- Logging/Audit: NTP, Syslog-Ziele, Log-Level, Aufbewahrung
- SNMP: v3 ja/nein, NMS-IP(s), Contact/Location
Monitoring- und Betriebsdaten: Syslog, SNMP, Alarmkatalog
Ein Router ist erst betriebsbereit, wenn Monitoring integriert ist. Legen Sie Ziele, Protokolle und Alarmkriterien fest, damit der Betrieb nicht „blind“ startet.
- Syslog: Server-IP(s), Log-Level, Quellinterface
- SNMPv3 (optional): User/Group, Auth/Priv, erlaubte NMS-IPs
- Alarmkatalog: WAN down/flaps, Path-down, VPN down, Neighbor down, CPU hoch
- Reporting: Verfügbarkeit/Top Incidents (falls gefordert)
Abnahme- und Testdaten: Pre-/Post-Checks, UAT, Failover
Ohne Abnahme bleibt „fertig“ verhandelbar. Definieren Sie daher Tests, Zielwerte und UAT-Fälle, die der Anbieter nachweisbar erfüllen muss.
- Pre-/Post-Checks: definierter CLI-Kommandosatz, Outputs als Textdatei
- Pfadtests: definierte Ziele (Internet/Cloud/Zentrale), Ping/Traceroute
- UAT: Business-Apps, VPN-Zugriffe, Voice/Video (wenn relevant)
- Failover-Tests: Link-Down und Path-Down (bei Dual-WAN/HA)
- Abnahmekriterien: Pass/Fail je Testfall
Minimaler Abnahme-Kommandosatz
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip nat statistics
show ip nat translations
show crypto ikev2 sa
show crypto ipsec sa
show logging | last 50
show processes cpu sorted
Rollback- und Notfallzugang: Damit Fehler nicht zur Downtime werden
Ein Projekt ohne Rollback ist ein Risiko. Stellen Sie sicher, dass Notfallzugang (Console/OOB) und klare Rollback-Trigger vorhanden sind.
- Notfallzugang: Console/OOB oder Remote-Hands, Zugangsdatenprozesse
- Rollback-Trigger: Managementverlust, WAN instabil, Routing-Loop, VPN kritisch down
- Rollback-Schritte: letzte stabile Config, Validierungschecks
- Backup-Strategie: pre/post, versioniert, wiederauffindbar
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.












