Cisco-Router-Konfiguration: Vertragsmodelle im Vergleich (Projekt vs. Retainer)

Bei Cisco-Router-Konfigurationen entscheidet das Vertragsmodell oft stärker über Projekterfolg als der reine Tagessatz. Ein Projektvertrag (Fixpreis oder Time & Material) eignet sich für klar definierte Veränderungen mit eindeutigen Deliverables und Abnahme. Ein Retainer (monatliches Kontingent/Servicepaket) ist sinnvoll, wenn regelmäßig Changes, Rollouts, Incident-Support oder Standardpflege anfallen. Der Unterschied liegt nicht nur in der Abrechnung, sondern in Steuerung, Risiko, SLA und der Frage, wie schnell Sie im Betrieb handlungsfähig sind. Dieser Leitfaden vergleicht beide Modelle praxisnah und zeigt, wie Sie das passende Modell wählen.

Begriffsdefinition: Projektvertrag vs. Retainer

Ein Projektvertrag hat ein konkretes Ziel und endet mit Abnahme und Übergabe. Ein Retainer ist ein laufendes Modell mit verfügbarer Kapazität, definierten Reaktionszeiten und meist einem wiederkehrenden Leistungsumfang.

• Projekt: einmaliges Vorhaben (Assessment → Design → Implementierung → Handover)
• Retainer: laufende Unterstützung (Changes, Standards, Hypercare, Incidents)

Projektmodell: Wann es passt

Ein Projektmodell ist ideal, wenn der Scope klar ist und Sie ein Ergebnis zu einem definierten Zeitpunkt brauchen. Es eignet sich besonders für Rollouts, Migrationen, Dual-ISP-Designs oder neue VPN-Topologien mit eindeutiger Abnahme.

• Einmalige Umsetzung: neuer Standort, Router-Migration, ISP-Wechsel
• Klare Deliverables: Config pre/post, IP-/Interface-Plan, Runbooks, Abnahme
• Definierte Tests: Pre-/Post-Checks, UAT, Failover-Tests (wenn Scope)
• Klare Exclusions: Router vs. Firewall vs. Provider vs. Switch

Projektmodell: Typische Preislogik

• Fixpreis (Pauschale): gut bei standardisiertem Scope (Template-Rollout)
• Time & Material: sinnvoll bei unklaren Anforderungen oder vielen Abhängigkeiten
• Optional: Change-Fenster/Go-Live als separater Block (Nacht/Wochenende)

Projektmodell: Stärken und Schwächen

Die Stärke ist Planbarkeit, wenn Requirements sauber sind. Die Schwäche ist Reibung, wenn nach Projektende sofort neue Anforderungen auftauchen oder Betriebsthemen noch „nachschwingen“.

• Stärken: klarer Scope, klare Abnahme, gute Budgetkontrolle
• Schwächen: Nachträge bei Scope-Drift, weniger Flexibilität im Tagesbetrieb
• Risiko: fehlende Inputs (Provider/Policy/VPN-Matrix) machen Projekte teuer

Retainer-Modell: Wann es passt

Ein Retainer ist sinnvoll, wenn Sie kontinuierlich Bedarf haben: regelmäßige Changes, viele Standorte, wiederkehrende VPN-/Routing-Anpassungen, Monitoring-Tuning oder Incident-Unterstützung. Retainer sind besonders stark, wenn Standards gepflegt und Drift kontrolliert werden sollen.

• Regelmäßige Changes: VLANs, Policies, NAT-Ausnahmen, QoS-Anpassungen
• Multi-Standort-Betrieb: Template-Pflege, Rollout-Wellen, Drift-Control
• Incident-Support: schnelle Reaktionsfähigkeit mit definiertem SLA
• Lifecycle: IOS/IOS XE Upgrades, Lizenz-/Zertifikat-Rotation, Security-Hardening

Retainer-Modell: Typische Preislogik

• Monatliches Stunden-/Tageskontingent (Use-it-or-lose-it oder rollover)
• Servicepaket nach Tier (Basic/Standard/Enterprise) mit festen Leistungen
• SLA-Staffelung: Reaktionszeiten abhängig von Priorität und Servicefenster

Retainer-Modell: Stärken und Schwächen

Die Stärke ist operative Geschwindigkeit und Kontinuität. Die Schwäche ist, dass es ohne klaren Leistungsumfang „ausfransen“ kann. Ein guter Retainer braucht deshalb ein sauberes Runbook für Anfragen und ein Priorisierungsmodell.

• Stärken: schnelle Umsetzung, weniger Onboarding-Aufwand pro Change
• Stärken: Standardpflege, kontinuierliche Verbesserungen, weniger Drift
• Schwächen: ohne klare In-/Out-of-Scope Regeln entstehen Erwartungskonflikte
• Risiko: „Alles ist dringend“ ohne Prioritätsmodell führt zu Friktion

Vergleich: Steuerung, Risiko und Ergebnisqualität

Projektverträge eignen sich für „ein Ziel, ein Abschluss“. Retainer eignen sich für „dauerhafte Betriebsqualität“. Die besten Ergebnisse entstehen häufig durch eine Kombination: Projekt + Retainer für Hypercare und Standardpflege.

• Steuerung: Projekt über Meilensteine; Retainer über Backlog/Prioritäten
• Risiko: Projekt hat Nachtragsrisiko; Retainer hat Scope-Abgrenzungsrisiko
• Qualität: Projekt liefert Handover; Retainer hält Standards dauerhaft ein
• Tempo: Retainer schneller bei Ad-hoc Changes; Projekt besser für große Umbauten

Welche Deliverables im Vertrag stehen müssen (beide Modelle)

Unabhängig vom Modell sollten bestimmte Deliverables und Abnahmekriterien verpflichtend sein. So verhindern Sie, dass Qualität „wegoptimiert“ wird.

• Konfig pre/post (running/startup), versioniert mit Ticket-ID
• Abnahmeprotokoll mit Pre-/Post-Checks (CLI-Outputs)
• IP-/Interface-Plan und Policy-Kurzfassung
• Rollback-Plan und Notfallzugang
• Monitoring-Setup (NTP/Syslog, optional SNMPv3) und Alarmkatalog

Retainer-Pflichtteile: Damit es nicht „ausfranst“

Ein Retainer funktioniert nur mit klaren Spielregeln. Definieren Sie daher Servicefenster, Prioritäten, Reaktionszeiten und einen standardisierten Request-Prozess.

• Servicefenster: 8×5/12×5/24×7
• Prioritäten P1–P4 mit objektiven Kriterien
• Reaktionszeit und Workaround-Zeit (Target, nicht „Best Effort“)
• Request-Template: Inputs (IP-Plan, Policy-Matrix, Change-Fenster)
• Kontingentregeln: rollover ja/nein, Mindestabrechnungseinheit

Projekt-Pflichtteile: Damit Anbieter nicht „schleifen“

Projektverträge scheitern häufig an Scope-Lücken. Die wichtigsten Gegenmaßnahmen sind ein sauberer Scope-of-Work, Pflichtinputs und testbare Abnahme. Dadurch werden Angebote vergleichbar und Nachträge kontrollierbar.

• In-/Out-of-Scope (Router vs. Firewall vs. Switch vs. Provider)
• Pflichtinputs: Providerdatenblatt, Policy-Matrix, VPN-Matrix
• Testplan: Pre-/Post-Checks, UAT, Failover (wenn Scope)
• Change-Prozess: Zusatzleistungen nur per Change Request

Entscheidungshilfe: Welche Fragen führen zum passenden Modell?

Diese Fragen helfen, das Modell objektiv zu wählen. In der Praxis ist oft „Projekt + Retainer (Hypercare/Standardpflege)“ die stabilste Kombination.

• Ist der Scope klar und einmalig? → Projekt
• Gibt es monatlich wiederkehrende Changes/Incidents? → Retainer
• Wie viele Standorte und wie viel Drift-Risiko existiert? → eher Retainer
• Brauchen Sie garantierte Reaktionszeiten? → Retainer mit SLA
• Ist ein großer Umbau geplant, danach aber Betriebssupport nötig? → Projekt + Retainer

Praktischer Nachweis im Betrieb: Standard-Checks als Vertragsteil

Wenn Sie Qualität vertraglich absichern wollen, verankern Sie ein Standard-Checkset. Es ist in Projekten Teil der Abnahme und im Retainer Teil des Incident-Runbooks.

show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show ip route summary
show ip nat statistics
show ip nat translations
show crypto ikev2 sa
show crypto ipsec sa
show ip sla statistics
show logging | last 50
show processes cpu sorted

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.