RFP-Template für Cisco-Router-Konfiguration: Scope, SLA und Acceptance Criteria

Ein gutes RFP-Template für Cisco-Router-Konfiguration verhindert zwei typische Probleme: unklare Leistungsabgrenzung (Scope Creep) und nicht messbare Abnahme („es läuft irgendwie“). Damit Anbieter vergleichbare Angebote abgeben, müssen Scope, SLA und Acceptance Criteria eindeutig definiert sein – inklusive Deliverables, Testfällen, Evidence und Rollback-Regeln. Dieses Template ist so formuliert, dass es direkt in eine Ausschreibung übernommen werden kann und „production-grade“ Anforderungen abprüft.

RFP-Rahmen: Ziel, Kontext und Liefergegenstand

Beschreiben Sie kurz, was Sie erreichen wollen, und welche Umgebung betroffen ist. Anbieter benötigen Kontext, ohne dass Sie Ihr internes Design vollständig offenlegen müssen.

• Ziel: Router-Konfiguration und produktiver Betrieb gemäß definierten Standards
• Umfang: Anzahl Standorte/Geräte, Standorttypen (HQ/Branch/DC-Edge)
• WAN: Providerarten (DIA/MPLS/Metro-E/LTE), Dual-ISP ja/nein
• Services: Internet, VPN, Routing, Segmentierung, Monitoring, QoS (falls relevant)
• Constraints: Change Windows, 24/7 Anforderungen, Compliance/Audit

Scope of Work: In-Scope Leistungen (Pflichtliste)

Definieren Sie In-Scope als konkrete Arbeitspakete. Jedes Paket muss ein Ergebnis liefern (Deliverable) und später testbar sein.

• Assessment: Requirements-Workshop, Ist-Analyse, Risiko-/Abhängigkeitsliste
• Design: HLD/LLD, IP-Plan (falls beauftragt), Routing-/VPN-/Security-Design
• Build: Konfiguration(en), Templates/Variablenmodell (bei Multi-Site)
• Security Baseline: SSH/AAA/RBAC, Logging/NTP, MGMT-Only, ggf. CoPP
• Implementierung: Remote/Onsite Cutover, Change-Plan, Kommunikationsplan
• Validation: Pre-/Post-Checks, UAT/ATP, KPI-Nachweise
• Handover: As-Built, Backups, Runbooks, Knowledge Transfer

Out of Scope: Explizite Ausschlüsse (Scope-Creep-Schutz)

Listen Sie typische Ausschlüsse auf. Anbieter sollen Abweichungen als Option oder Change Request bepreisen, nicht stillschweigend einpreisen oder später nachfordern.

• Provider-Support außerhalb definierter Eskalationsunterstützung
• Endgeräte/Client-Support (PCs, Drucker, WLAN-Clients)
• Applikationssupport (SaaS/PACS/ERP) außerhalb Connectivity-Nachweis
• Firewall-Policy-Redesign (wenn nicht ausdrücklich im Scope)
• Langfristiger Betrieb ohne separaten Managed-Service-Vertrag

Technische Anforderungen: Mindeststandard „production-grade“

Definieren Sie Mindeststandards, die jeder Anbieter erfüllen muss. Das macht Angebote vergleichbar und verhindert „billig aber riskant“.

• Management: SSH-only, VTY Access-Class (MGMT-Only), Exec-Timeout
• AAA/RBAC: zentrale Authentifizierung, Accounting (Exec, optional Commands)
• Logging: NTP synchronized, Syslog zentral, Zeitstempel mit msec
• Resilience: Dual-ISP/Tracking (wenn relevant), definierte Failover-Tests
• Security: Segmentierungs-Policies (ACL/VRF), Anti-Scan Baselines
• Operability: Monitoring-Integration (SNMPv3/Telemetry), Alarmkatalog

Evidence-Outputs (Beispielanforderung)

Anbieter muss als Deliverable eine Evidence-Sammlung liefern, die mindestens umfasst:
show version
show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show ip ssh
show ntp status
show logging | last 100
show running-config | include line vty|access-class|aaa|logging host

Deliverables: Was der Anbieter final übergeben muss

Deliverables sind der Kern der Abnahme. Ohne klare Deliverables ist „fertig“ nicht definierbar.

• As-Built Report (inkl. Versionen, Interfaces, IP-Plan, Routing/VPN/Policies)
• Konfigurationsdateien: PRE/POST running-config und startup-config
• Template-Paket: Baseline + Module + Variablenmodell (wenn beauftragt)
• UAT/ATP Protokoll: Testfälle, Ergebnisse, Evidence, Pass/Fail
• Runbook: Incident Quick Snapshot + Change/Upgrade/Rollback SOP
• Monitoring-Setup: Parameter, Alarmkatalog, KPI-Definitionen

Acceptance Criteria: Abnahmebedingungen (messbar und evidence-basiert)

Acceptance Criteria müssen prüfbar sein. Definieren Sie Pass/Fail Regeln und Evidence-Anforderungen. Das schützt beide Seiten und reduziert Diskussionen.

• Connectivity: Internet/VPN/Routing gemäß Testfällen erreichbar
• Stabilität: keine Routing Flaps/Loops im Abnahmefenster
• Resilience: Failover-Test bestanden (Link-down und/oder Path-down, je Scope)
• Security: MGMT-Only umgesetzt, AAA/Accounting aktiv, Policies wirksam
• Auditability: NTP ok, Syslog sichtbar, Evidence Pack vollständig
• Operability: Monitoring sichtbar, Alarme getestet (mind. Interface down)

UAT/ATP Testfälle (Template-Auszug)

• Test 1: Default-Route vorhanden, Internet erreichbar (DNS + HTTPS)
• Test 2: VPN (falls Scope) SA up und Traffic-Counter steigen
• Test 3: Segmentierung (Guest→RFC1918 blockiert, Users→MGMT blockiert)
• Test 4: Failover (wenn Dual-ISP) Umschaltzeit messen, Services stabil
• Test 5: Monitoring/Logging: NTP synced, Syslog im SIEM/NOC sichtbar

Rollback-Anforderungen: Trigger, Zeitbox und Vorgehen

Rollback ist Pflichtbestandteil. Definieren Sie Trigger und eine Rollback-Zeitbox im Change Window. Ohne Zeitbox wird Rollback oft zu spät entschieden.

• Rollback-Trigger: Internet down, VPN kritisch down, Routing Loop/Flaps, Managementverlust
• Rollback-Strategie: Soft (Config) und/oder Hard (Startup/Image) je Projekt
• Rollback-Reserve: fest im Maintenance Window eingeplant
• Rollback-Evidence: Nachweis, dass alter Zustand wieder stabil ist

SLA/Support: Incident-Definition, Reaktionszeiten, Eskalation

Wenn Support Teil des RFP ist, definieren Sie Incident-Klassen und klare Reaktions-/Wiederherstellungsziele. „Response Time“ allein reicht nicht.

• Incident-Klassen: P1/P2/P3 mit Business-Definition
• Reaktionszeit: Zeit bis zur ersten qualifizierten Bearbeitung
• Restore/Workaround: Zielzeiten für Service-Wiederherstellung
• Eskalation: NOC → Senior Engineer → Hersteller/Provider
• RACI: Verantwortlichkeiten (Customer/Provider) eindeutig

Projektplan: Phasen, Timeline und Change Windows

Verlangen Sie einen realistischen Projektplan und definieren Sie, welche Informationen der Anbieter benötigt. In großen Rollouts ist die Wellenplanung Teil der Angebotsqualität.

• Phasenmodell: Assess–Design–Build–Validate–Handover
• Wellenrollout: Pilot, Batch, Stabilitätsfenster (bei Multi-Site)
• Change Windows: Zeiten, Kommunikationsplan, Stakeholder-Abnahme
• Risk Register: Risiken, Trigger, Mitigation, Owner

Preisstruktur: Transparenz, Annahmen und Change Requests

Ein RFP sollte Anbieter zwingen, Preisannahmen offen zu legen. Das reduziert spätere Nachforderungen und macht Angebote vergleichbar.

• Preismodell: Fixpreis vs. T&M, klare Leistungsgrenzen
• Annahmen: Anzahl Sites, Tunnel, VLANs, Routing-Peers, UAT-Umfang
• Onsite/Remote: Kriterien, wann Onsite nötig ist, Tagessätze/Spesen
• Change Requests: Prozess, Stundensätze, Genehmigungsworkflow

Anbieterauswahl: Einreichungsanforderungen für Vergleichbarkeit

Damit Anbieter nicht „schleifen“, definieren Sie eine klare Struktur für die Angebotsabgabe. So erhalten Sie vergleichbare Antworten.

• Executive Summary: Verständnis, Risiken, Vorgehen
• Technisches Design: Architektur, Routing/VPN/Segmentation, Security Baseline
• Methodik: Pre-/Post-Checks, UAT/ATP, Rollback
• Deliverables: vollständige Liste mit Beispiel-Gliederung
• SLA/Support: Incident-Definition, Zeiten, Eskalation
• Commercials: Preis, Annahmen, CR-Prozess, Zahlungsplan
• Referenzen: vergleichbare Projekte, Teamrollen, Zertifizierungen

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.