Cisco-Router-Konfigurationsservice: RFP/TOR-Leitfaden, damit Anbieter nicht „schleifen“

Ein RFP/TOR (Request for Proposal / Terms of Reference) für einen Cisco-Router-Konfigurationsservice muss so präzise sein, dass Anbieter nicht „schleifen“ können: keine vagen Formulierungen, keine offenen Scope-Kanten, keine unmessbaren Abnahmen. Ziel ist ein Dokument, das Anforderungen, Randbedingungen, Deliverables, Testkriterien, Zeitplan und SLA so eindeutig beschreibt, dass Angebote vergleichbar sind und Nachträge begründet werden müssen – nicht „gefühlte Zusatzaufwände“. Dieser Leitfaden zeigt, wie Sie ein TOR strukturieren und welche Pflichtinhalte Sie aufnehmen sollten.

Grundprinzip: „Testbar“ statt „Best Effort“

Alles, was nicht messbar ist, wird später verhandelbar. Formulieren Sie Anforderungen daher als prüfbare Kriterien: „erlaubt/gesperrt“, „Failover in X Sekunden“, „Logs zentral sichtbar“, „Abnahmeprotokoll mit Outputs“.

• Jede Anforderung bekommt ein Abnahmekriterium (Pass/Fail)
• Scope-Grenzen schriftlich: Router vs. Firewall vs. Provider vs. Switch
• Deliverables als Liste mit Format und Mindestinhalten
• Änderungen nur über Change-Prozess (keine „Nebenbei“-Erweiterungen)

TOR-Struktur: Kapitel, die jedes RFP enthalten sollte

Eine klare Struktur verhindert, dass Anbieter „Lücken“ nutzen. Halten Sie das Dokument kompakt, aber vollständig. Referenzieren Sie Anhänge (IP-Plan, Standortliste, Policy-Matrix), statt alles in Fließtext zu verstecken.

• Projektübersicht und Ziele
• Scope (In/Out) und Verantwortlichkeiten
• Technische Anforderungen (WAN/LAN/Routing/NAT/VPN/Security/QoS)
• Standards und Compliance (Hardening, Logging, AAA)
• Abnahme (Pre-/Post-Checks, UAT, Failover-Tests)
• Deliverables (Dokumente, Konfigs, Runbooks)
• Projektplan, Meilensteine, Change- und Kommunikationsplan
• SLA/Hypercare/Support (optional)
• Preisstruktur und Annahmen (Tagessätze, Pauschalen, Reisekosten)

Scope sauber schneiden: Was ist enthalten und was explizit nicht?

„Schleifen“ entsteht fast immer durch unklare Scope-Kanten. Definieren Sie In-Scope und Out-of-Scope explizit, inklusive Abhängigkeiten. Das schützt beide Seiten – und macht Angebote vergleichbar.

• In-Scope: Router-Konfiguration, Tests, Doku, Übergabe, optional Go-Live-Begleitung
• Out-of-Scope (Beispiele): Switch-Konfiguration, WLAN-Design, Provider-Entstörung, Firewall-Policy-Redesign
• Abhängigkeiten: welche Inputs liefert der Auftraggeber (IP-Plan, Providerdaten, Zugang)?
• RACI: wer macht was (Responsible/Accountable/Consulted/Informed)

Technische Mindestanforderungen: Baseline, die jeder Anbieter erfüllen muss

Definieren Sie Mindeststandards, die nicht „optional“ sind. So vermeiden Sie, dass Anbieter günstiger anbieten, indem sie Hardening, Monitoring oder Abnahme weglassen.

• Sicheres Management: SSH-only, Management-ACL, Session-Timeout
• Logging/Audit: NTP, Syslog zentral, Zeitstempel aktiviert
• Segmentierung: Guest/IoT/POS Regeln nach Policy-Matrix
• NAT/VPN: No-NAT für VPN, dokumentierte NAT-Quellnetze
• Routing: klare Pfadlogik, Filterpflicht bei BGP (falls Scope)
• Backup/Restore: Pre-Backup und Post-Backup, Rollback-Plan

Beispiel: Mindest-Hardening als TOR-Textbaustein

Der Router muss mit SSHv2 betrieben werden. Telnet sowie HTTP/HTTPS-Management sind zu deaktivieren.
VTY-Zugriffe sind auf ein definiertes Management-Subnetz zu begrenzen (Access-Class).
NTP und zentrale Syslog-Weiterleitung sind verpflichtend zu konfigurieren (mit Zeitstempeln).

Policy-Matrix als Pflichtanhang: Damit Regeln nicht „interpretiert“ werden

Wenn Segmentierung gefordert ist, brauchen Sie eine Policy-Matrix: Quelle, Ziel, Ports, Zweck, Owner. Ohne Matrix wird „erlaubt nach Bedarf“ später zur Nachtragsquelle.

• Quelle: VLAN/Subnetz/Rolle (z. B. Guest, IoT, Users, MGMT)
• Ziel: Subnetz/Service (z. B. DNS, NTP, ERP, VPN-Targets)
• Ports/Protokolle: konkret (TCP/443, UDP/53, UDP/123)
• Zweck und Owner: warum existiert die Regel, wer verantwortet sie?
• Logging-Anforderung: Muss der Flow geloggt werden (ja/nein)?

Abnahme und Tests: Der wichtigste Hebel gegen „schleifen“

Definieren Sie Tests als Pflichtdeliverable. Ein Anbieter kann dann nicht behaupten, etwas sei „fertig“, wenn der Test fehlt. Nutzen Sie Pre-/Post-Checks, Pfadtests und bei Redundanz Failover-Tests.

• Pre-Checks: Baseline vor Change (Interfaces, Routing, CPU, Logs)
• Post-Checks: gleiche Kommandos + Pfadtests (Ping/Traceroute)
• UAT: anwendungsnahe Tests (Business-Apps, VPN, Voice/Video)
• Failover: Link-Down und Path-Down (bei Dual-WAN/HA)
• Dokumentation: Outputs als Textdatei, mit Zeit und Ticket-ID

Beispiel: Abnahme als TOR-Textbaustein (prüfbar)

Der Anbieter liefert ein Abnahmeprotokoll mit Pre-/Post-Checks inkl. CLI-Outputs.
Die Abnahme gilt als bestanden, wenn:
- Default-Route und Internetpfad (Ping/Traceroute) funktionieren,
- NAT-Translations bei Testtraffic sichtbar sind,
- VPN (sofern im Scope) aktive SAs und steigende Paketzähler zeigt,
- Segmentierung (Guest/IoT) gemäß Policy-Matrix wirksam ist.

Deliverables im TOR: Format, Mindestinhalt und „Definition of Done“

Schreiben Sie Deliverables nicht als „Doku“, sondern als konkrete Artefakte mit Mindestinhalt. So können Anbieter nicht „ein paar Zeilen“ als Dokumentation verkaufen.

• Finale Running- und Startup-Config (pre/post) versioniert, mit Ticket-ID
• IP-/VLAN-Plan und Interface-Plan (Ports, Rollen, Übergaben)
• Routing/NAT/VPN-Übersicht (Policies, Peers, No-NAT, Prefix-Listen)
• Monitoring-Doku (NTP/Syslog/SNMPv3, Alarmkatalog)
• Abnahmeprotokoll (Pre-/Post-Checks, UAT, Failover)
• Rollback-Plan (Trigger, Schritte, Validierung, Notfallzugang)
• Runbook/SOP (Standardchecks bei WAN/VPN/Routing/CPU)

CLI-Checkliste als verpflichtender Anhang (Beispiel)

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

Change-Management im TOR: So vermeiden Sie „Scope-Slip“ im Betrieb

Ohne Change-Prozess wird jedes neue VLAN oder jede zusätzliche VPN-Anbindung zur Diskussion. Definieren Sie daher Change-Klassen, Review, und wie Zusatzaufwand kalkuliert wird.

• Standard Change: Template-basiert, feste Zeiten/Preise
• Normal Change: Planung + Review, definierte Abnahme
• Emergency Change: schnelle Stabilisierung, danach vollständige Doku
• Zusatzleistungen nur nach schriftlicher Freigabe (Change Request)

SLA/Hypercare im TOR: Wenn Support Teil des Deals ist

Wenn Sie Support wünschen, definieren Sie Servicezeiten, Prioritäten und Reaktionszeiten. Ohne klare Definition wird Support „Best Effort“ und damit unplanbar.

• Servicefenster: 8×5, 12×5, 24×7
• Prioritäten P1–P4 mit objektiven Kriterien
• Hypercare: Zeitraum, Umfang, Monitoring-Tuning
• Abgrenzung: Provider-Entstörung, Hardware-RMA, Applikationssupport

Preisstruktur: So verhindern Sie versteckte Nachträge

Viele Nachträge entstehen, weil Anbieter Annahmen machen. Fordern Sie daher eine Annahmenliste und eine transparente Preislogik: Pauschalen für Standards, Tagessätze für Sonderfälle, klare Reisekostenregeln.

• Pauschale pro Standort (Standard-Template) vs. Time-and-Material für Sonderfälle
• Tagessätze/Rollen (Junior/Senior), Mindestabrechnungseinheit
• Reisekosten: Regeln, Freigabeprozess, Obergrenzen
• Annahmenliste: Inputs vollständig? Change-Fenster? Remote-Hands?

Vergleichbarkeit der Angebote: Bewertungsmatrix als Pflicht

Damit Anbieter nicht „billig durch Weglassen“ sind, benötigen Sie eine Bewertungsmatrix: Gewichtung von Technik, Deliverables, Abnahme, SLA und Preis. So wird Qualität messbar.

• Technischer Fit (Design, Standards, Risikoansatz)
• Deliverables-Qualität (vollständig, verständlich, betriebsfähig)
• Abnahme/Tests (klar, vollständig, reproduzierbar)
• Projektplan und Ressourcen (Verfügbarkeit, Erfahrung)
• Preis und Annahmen (transparent, realistisch, geringe Nachtragsgefahr)

Praktischer TOR-Qualitätscheck: 12 Fragen, die „Schleifen“ verhindern

Wenn Sie diese Fragen im TOR beantworten können, ist die Chance hoch, dass Anbieter nicht über Lücken nachverhandeln können.

• Welche Features sind im Scope (WAN/LAN/Routing/NAT/VPN/QoS/Security)?
• Welche Inputs liefert der Auftraggeber, bis wann?
• Wie sieht die Policy-Matrix aus (Quelle/Ziel/Ports/Owner)?
• Welche Abnahmetests sind Pflicht und wie wird „bestanden“ definiert?
• Gibt es Dual-WAN/HA – und welche Failover-Tests sind verbindlich?
• Wer ist Owner für NAT (Router vs. Firewall)?
• Welche Logging/NTP/SNMP-Standards sind verpflichtend?
• Wie werden Konfigs versioniert (pre/post, Ticket-ID)?
• Wie sieht der Rollback-Plan aus (Trigger, Schritte, Notfallzugang)?
• Welche Dokumente sind Deliverables und in welchem Format?
• Welche SLA/Hypercare-Leistungen sind enthalten (falls gewünscht)?
• Welche Annahmen macht der Anbieter – und wie werden Abweichungen bepreist?

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.