Ein Scope-of-Work-Template (SoW) für die Beschaffung eines Cisco-Router-Konfigurationsservices beschreibt Leistung, Abgrenzungen, Deliverables und Abnahme so eindeutig, dass Angebote vergleichbar sind und Nachträge nur über einen klaren Change-Prozess entstehen. Dieses Muster ist als Copy/Paste-Grundlage gedacht und kann für Büro, Filiale, Zentrale oder Data-Center-Edge angepasst werden.
Projektkontext und Zielsetzung
Dieses Kapitel definiert, warum das Projekt durchgeführt wird und was am Ende „fertig“ bedeutet. Damit vermeiden Sie Interpretationsspielräume.
- Projektname/Referenz: <Projekt>, <Ticket-/RFP-ID>
- Standort(e)/Umfang: <Anzahl Standorte>, <Typ: Büro/Filiale/Zentrale/DC>
- Ziel: betriebsfertige Cisco-Router-Konfiguration inkl. Abnahme und Übergabe
- Definition of Done: Abnahmeprotokoll bestanden, Deliverables vollständig übergeben
Leistungsumfang (In Scope)
Listen Sie Leistungen so konkret wie möglich. Jedes „Feature“ ist entweder enthalten oder nicht enthalten. Optionales wird als Option gekennzeichnet.
- Ist-Analyse/Anforderungsaufnahme (Inputs prüfen, Lückenliste)
- Design/Implementierungsplanung (HLD/LLD light, je nach Bedarf)
- Security-Baseline: SSH-only, Management-Restriktionen, NTP/Syslog, optional SNMPv3
- WAN-Konfiguration: Provider-Übergabe, Default-Route, optional Dual-ISP/Tracking
- LAN-Integration: VLAN-Gateways (Subinterfaces/SVIs), DHCP-Relay (falls benötigt)
- Routing: Static/OSPF/EIGRP/BGP gemäß Anforderung und Design
- NAT: PAT/Overload, No-NAT (wenn VPN), optional Static PAT/Portforwards
- VPN: Site-to-Site (IKEv2/IPsec), optional GRE/VTI/DMVPN nach Scope
- Policies: ACLs/Segmentierung nach Policy-Matrix (Guest/IoT/MGMT)
- Tests/Abnahme: Pre-/Post-Checks, Pfadtests, UAT (wenn gefordert)
- Dokumentation und Handover: Configs, Pläne, Runbooks, Rollback
- Go-Live-Begleitung/Hypercare (optional, Umfang klar definieren)
Leistungsabgrenzung (Out of Scope)
Definieren Sie explizit, was nicht geliefert wird. Das verhindert „Scope-Schleifen“ und macht Nachträge kontrollierbar.
- Provider-Entstörung (Carrier-Tickets), sofern nicht explizit beauftragt
- Hardwarebeschaffung/Logistik/RMA, sofern nicht explizit beauftragt
- Switching/WLAN-Design und -Konfiguration, sofern nicht explizit beauftragt
- Firewall-Policy-Redesign (außer explizit im Scope), Applikationssupport
- Neue Anforderungen nach Abnahme (z. B. zusätzliche VLANs/VPNs) ohne Change Request
Input- und Mitwirkungspflichten des Auftraggebers
Dieses Kapitel reduziert Projektrisiko, weil es beschreibt, welche Informationen und Zugänge erforderlich sind. Fehlen Inputs, entsteht Verzögerung oder Zusatzaufwand.
- Providerdaten: IP/Subnetz, Gateway, VLAN-Tagging/PPPoE, MTU, ggf. BGP-Parameter
- LAN-Daten: VLAN-IDs, Subnetze, DHCP/DNS, Trunk-/Uplink-Informationen
- Policy-Matrix: erlaubte Flows (Quelle/Ziel/Ports), Owner, Logging-Anforderungen
- VPN-Informationen: Peers, Netze, PSK/Zertifikate, Rekey/DPD-Vorgaben
- Zugänge: Remote-Zugriff, OOB/Console (oder Remote-Hands), Wartungsfenster
- Abnahme-Tester: Ansprechpartner für UAT und Sign-off
Technische Mindeststandards (Pflichtanforderungen)
Diese Standards sind nicht optional. Sie sichern Betrieb, Audit und Supportfähigkeit. Anbieter müssen Abweichungen schriftlich begründen.
- SSH-only, Telnet deaktiviert, HTTP/HTTPS deaktiviert (wenn nicht benötigt)
- Managementzugriff auf definiertes Management-Subnetz beschränkt
- NTP aktiv, Log-Timestamps aktiv (datetime msec)
- Syslog an zentralen Server, definierter Log-Level
- Konfig-Backups vor/nach Change, versioniert mit Ticket-ID
- Bei BGP: Outbound-Filterpflicht und Prefix-Limits
- Bei VPN: No-NAT verpflichtend und SA-/Traffic-Nachweis
Beispiel: Mindest-Hardening (Referenztext)
Der Anbieter konfiguriert SSHv2 als einziges Managementprotokoll.
VTY-Zugriffe werden per Access-Class auf das Management-Subnetz begrenzt.
NTP und zentrale Syslog-Weiterleitung mit Zeitstempeln sind verpflichtend.
Deliverables (Liefergegenstände) und Formate
Deliverables sind konkret zu benennen. „Dokumentation“ ohne Mindestinhalt ist nicht ausreichend. Jeder Liefergegenstand ist als Datei/Format zu definieren.
- Konfigurationen: Running-/Startup-Config als Text (pre/post), inkl. Versionsstand
- Geräteinfo: Modell, Seriennummer, IOS/IOS XE, Lizenzstatus
- IP-/VLAN-Plan und Interface-Plan (WAN/LAN, Übergaben, Trunks)
- Routing/NAT/VPN-Übersicht: Peers, Netze, Policies, No-NAT
- Monitoring-Doku: NTP/Syslog/SNMPv3, Alarmkatalog
- Abnahmeprotokoll: Pre-/Post-Checks, Pfadtests, UAT/Failover-Tests (wenn Scope)
- Rollback-Plan: Trigger, Schritte, Validierung, Notfallzugang
- Runbook/SOP: Standardchecks für WAN/VPN/Routing/CPU/Errors
Abnahme (Acceptance Criteria) und Testanforderungen
Abnahme ist „Pass/Fail“ und muss messbar sein. Fordern Sie CLI-Outputs und End-to-End-Tests. Ohne Abnahmekriterien können Anbieter „fertig“ behaupten, obwohl die Qualität unklar ist.
- Pre-/Post-Checks: definierter Kommandosatz, Outputs als Textdatei
- Connectivity: Gateway/Default, Internetpfad (Ping/Traceroute)
- NAT: Translations sichtbar bei Testtraffic (wenn NAT im Scope)
- VPN: IKEv2/IPsec SAs aktiv, Paketzähler steigen (wenn VPN im Scope)
- Segmentierung: Guest/IoT/MGMT gemäß Policy-Matrix wirksam
- Failover: Link-Down/Path-Down Test dokumentiert (wenn Dual-WAN/HA im Scope)
Beispiel: Pflicht-CLI-Checks (Abnahmeanhang)
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 policy-map interface
show logging | last 50
show processes cpu sorted
Projektablauf und Meilensteine
Ein SoW benötigt einen klaren Ablauf, damit Liefertermine und Abhängigkeiten planbar sind. Meilensteine sollten an Deliverables und Abnahme gekoppelt sein.
- M1: Kickoff + Inputprüfung abgeschlossen (Lückenliste)
- M2: Design/Template freigegeben (HLD/LLD light, Variablenmodell)
- M3: Pre-Staging abgeschlossen (Baseline, Monitoring, vorbereitete Config)
- M4: Implementierung/Cutover durchgeführt
- M5: Abnahme bestanden (inkl. UAT/Failover, wenn Scope)
- M6: Handover abgeschlossen (alle Deliverables übergeben)
Change- und Scope-Control (damit keine Nachtrags-Schleifen entstehen)
Dieses Kapitel legt fest, wie Änderungen nach Vertragsstart behandelt werden. Ohne Change-Control wird jedes zusätzliche VLAN oder jeder neue VPN-Tunnel zu einem Streitpunkt.
- Änderungen nur per Change Request (CR) mit schriftlicher Freigabe
- CR enthält: Beschreibung, Impact, Aufwand, Risiko, Abnahme
- Standard Changes (Template-basiert) vs. Sonderfälle (T&M)
- Notfallchanges: schnelle Stabilisierung, danach vollständige Doku
Support, Hypercare und SLA (optional)
Wenn Support Teil der Beschaffung ist, muss er messbar sein. Definieren Sie Servicefenster, Prioritäten und Reaktionszeiten sowie klare Abgrenzungen.
- Servicezeiten: 8×5 / 12×5 / 24×7
- Prioritäten P1–P4 mit Kriterien und Zielwerten
- Hypercare: Dauer, Umfang, Monitoring-Tuning, Reporting
- Abgrenzung: Provider, Hardware-RMA, Applikationen
Preis- und Angebotsstruktur (Vergleichbarkeit sicherstellen)
Fordern Sie eine klare Aufschlüsselung: Pauschalen für Standards, Tagessätze für Sonderfälle, Reise- und Nebenkosten getrennt. Zusätzlich muss der Anbieter seine Annahmen offenlegen.
- Preis je Standort (Standard-Template) und Preis für Sonderfeatures (VPN, Dual-WAN, BGP, QoS)
- Rollen/Tagessätze (Junior/Senior), Mindestabrechnungseinheit
- Reisekostenregeln und Genehmigungsprozess
- Annahmenliste: Inputs vollständig, Change-Fenster, Remote-Hands, Zugang
Qualitätssicherung: Mindestanforderungen an Dokumentation und Übergabe
Abschließend fixieren Sie, was „professionell“ bedeutet: versionierte Konfig, nachvollziehbare Tests, Runbook und Rollback. Das reduziert Betriebskosten sofort.
- Pre-/Post-Check Outputs sind Teil der Lieferung
- Konfigversionierung (pre/post) mit Ticket-ID
- Rollback-Plan inklusive Validierungschecks
- Runbook/SOP als betriebsfähige Kurzform
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.












