Garantie & Support für Cisco-Router-Konfiguration: Wie ein ideales SLA aussieht

Garantie und Support für eine Cisco-Router-Konfiguration entscheiden darüber, ob ein Projekt nach dem Go-Live stabil bleibt oder bei den ersten Randfällen zum Eskalationsthema wird. Ein ideales SLA (Service Level Agreement) regelt nicht nur Reaktionszeiten, sondern auch Umfang, Abgrenzungen, Eskalation, Change-Prozesse, Monitoring und die Frage, was als „Konfigurationsfehler“ gilt. Dieser Leitfaden zeigt, wie ein praxisnahes SLA für Cisco-Router-Konfiguration aufgebaut sein sollte – von Gewährleistung und Hypercare bis zu 24×7-Betrieb.

Garantie vs. Support vs. Managed Service: Begriffe sauber trennen

Viele Missverständnisse entstehen, weil „Garantie“ und „Support“ unscharf verwendet werden. Ein SLA sollte diese Begriffe klar definieren, damit Erwartungen und Verantwortung eindeutig sind.

• Garantie/Gewährleistung: Korrektur von Fehlern innerhalb des vereinbarten Scopes (zeitlich begrenzt)
• Support: Unterstützung bei Störungen und Fragen, oft mit Reaktionszeiten
• Managed Service: laufender Betrieb inkl. Monitoring, Incident-, Problem- und Change-Management

Was ein ideales SLA zwingend enthalten muss

Ein gutes SLA ist konkret, messbar und testbar. Es definiert Servicezeiten, Prioritäten, Reaktions- und Wiederherstellungsziele sowie klare Abgrenzungen zu Provider, Hardware und Applikationen.

• Servicezeiten: 8×5, 12×5, 24×7 (inkl. Feiertage/Zeitzonen)
• Prioritäten (P1–P4) mit objektiven Kriterien
• Reaktionszeit, Workaround-Zeit, Wiederherstellungsziel (RTO) je Priorität
• Eskalationspfad und Kommunikationsrhythmus (Status-Updates)
• Scope und Exclusions (was ist enthalten, was nicht?)

Prioritätenmodell (P1–P4): So wird das SLA praktisch

Ein Prioritätenmodell verhindert Diskussionen im Incident. Für jede Priorität sollten klare Beispiele und messbare Kriterien enthalten sein.

• P1 (kritisch): Standort/Service down, POS/klinisch/Produktion betroffen, kein Workaround
• P2 (hoch): Teilfunktion down oder starke Degradation, Workaround möglich
• P3 (mittel): Einschränkung ohne unmittelbaren Business-Stop, geplante Behebung
• P4 (niedrig): Beratung/Optimierung/Anfragen ohne Zeitdruck

Beispielhafte Zielwerte (an Ihre Umgebung anpassen)

• P1: Reaktion 15–30 min (24×7), Workaround 1–2 h, Wiederherstellung 4–8 h
• P2: Reaktion 1 h, Workaround 4 h, Wiederherstellung 1–2 Werktage
• P3: Reaktion 4–8 h, Behebung nach Planung (z. B. 5 Werktage)
• P4: Reaktion 1–3 Werktage, nach Vereinbarung

Konfigurations-Garantie: Was als „Fehler“ gilt

Damit „Garantie“ nicht zur Grauzone wird, muss das SLA definieren, was als Konfigurationsfehler innerhalb des Scopes gilt und was als Change/Neuanforderung (billable) behandelt wird.

• Garantiefall: Umsetzung weicht vom vereinbarten LLD/Scope ab
• Garantiefall: Failover/VPN/NAT funktioniert nicht gemäß Abnahmekriterien
• Garantiefall: Security-Baseline wurde nicht umgesetzt (z. B. SSH-only, Logging)
• Nicht Garantiefall: Provider-Fehler, Hardwaredefekt, ISP-Routing, Applikationsbug
• Nicht Garantiefall: neue Anforderungen nach Abnahme (neue VLANs, neue VPNs)

Hypercare: Die wichtigste SLA-Phase direkt nach Go-Live

In den ersten Tagen nach dem Go-Live treten häufig Randfälle auf: Lastspitzen, Provider-Eigenheiten, unerwartete Applikationspfade. Ein ideales SLA enthält daher eine Hypercare-Phase mit enger Begleitung.

• Dauer: typischerweise 5–10 Werktage (oder 1–2 Wochen)
• Erweiterte Erreichbarkeit und schnellere Reaktionszeiten
• Monitoring-Tuning (Schwellenwerte, Alarmkatalog, Korrelation)
• Feinjustierung: MTU/MSS, QoS, VPN-Parameter, Routing-Preferences

Scope im SLA: Was Support konkret abdeckt

Ein SLA muss präzise festlegen, welche Komponenten und Funktionen abgedeckt sind. Besonders wichtig: NAT/VPN/Routing, Dual-ISP-Mechanismen und Security-Policies sind typische Incident-Ursachen.

• WAN: Interface, Default-Route, Tracking/IP SLA, Dual-ISP-Failover
• LAN: VLAN-Gateways, DHCP-Relay, Segment-Policies (Guest/IoT/POS)
• Routing: OSPF/EIGRP/BGP Nachbarschaften, Filter/Policies
• NAT: Overload, No-NAT, Portforwards (gemäß Dokumentation)
• VPN: IKEv2/IPsec, SA-Monitoring, DPD/Rekey, Tunnel-Routing
• QoS: policy-map, Shaping, Zähleranalyse (wenn im Scope)

Abgrenzungen (Exclusions): Damit der Support planbar bleibt

Abgrenzungen sind kein „Kleingedrucktes“, sondern schützen beide Seiten. Ohne Exclusions wird Support unendlich, und SLAs werden teuer oder unbrauchbar.

• Provider-Tickets und Carrier-Entstörung: wer kontaktiert wen?
• Hardwaredefekte/RMA: wer ist für Ersatz zuständig?
• Applikationsprobleme: nur Netzwerkpfad, nicht App-Fehler
• Security-Incidents außerhalb der Router-Konfig: Endpoint/Server/Cloud
• Neue Anforderungen: Changes sind separat nach Change-Prozess

Monitoring und Alerting: SLA ohne Telemetrie ist blind

Ein ideales SLA definiert, ob der Anbieter nur „reaktiv“ auf Tickets arbeitet oder proaktiv überwacht. Proaktiver Support erfordert Syslog, SNMPv3 und klare Alarmdefinitionen.

• Syslog: Interface up/down, VPN/Routing-Events, Auth-Fehler
• SNMPv3: CPU, Memory, Interface-Auslastung, Errors/Drops
• Path-Monitoring: IP SLA für „Link up, Internet down“
• Alarmkatalog: WAN down, Path-down, Flaps, VPN down, Neighbor down

Beispiel: Monitoring-Baseline (Auszug)

service timestamps log datetime msec
ntp server 192.0.2.10 prefer
logging host 192.0.2.20
logging trap informational
snmp-server group NMS v3 priv

snmp-server user snmpmon NMS v3 auth sha  priv aes 128 

Change-Management im SLA: Wie Updates und Anpassungen sauber laufen

Support ohne Change-Prozess führt zu Drift. Ein ideales SLA enthält daher einen definierten Change-Workflow mit Pre-/Post-Checks, Rollback und Abnahme – auch für kleine Anpassungen.

• Change-Klassen: Standard Change (Template), Normal Change, Emergency Change
• Pre-/Post-Checks als Pflicht, protokolliert
• Rollback-Plan und klare Stop/Go-Kriterien
• Konfig-Backups vor/nach Change, Versionierung mit Ticket-ID

Standard-Checks für Incident und Change (Runbook-Baustein)

show ip interface brief
show interfaces counters errors
show ip route 0.0.0.0
show processes cpu sorted
show logging | last 50

Reporting und KPI: Wie SLA-Leistung nachgewiesen wird

Ein SLA sollte messbar sein. Typische KPIs sind Verfügbarkeit, Mean Time to Acknowledge (MTTA), Mean Time to Restore (MTTR), Anzahl Incidents, Top Root Causes und Change-Erfolgsquote.

• Verfügbarkeit je Standort/Service (WAN, VPN, kritische Pfade)
• MTTA/MTTR je Priorität
• Incident-Reports (Root Cause, Maßnahmen, Prävention)
• Change-Reports (Erfolgsquote, Rollbacks, Lessons Learned)

Idealstruktur für SLA-Pakete: Bronze, Silber, Gold

In der Praxis werden SLAs oft als Stufenpakete angeboten. Wichtig ist, dass jedes Paket klar sagt, ob es reaktiver Support oder proaktiver Betrieb ist – und ob Hypercare enthalten ist.

• Bronze: 8×5 Support, definierte Reaktionszeiten, keine proaktive Überwachung
• Silber: 12×5 oder 8×7, proaktives Monitoring, monatliches Reporting
• Gold: 24×7, proaktives Monitoring, schnellste P1-Reaktion, Hypercare inklusive

Praktische SLA-Checks: Was Sie im Vertrag konkret verlangen sollten

Damit das SLA nicht theoretisch bleibt, sollten Sie konkrete Nachweise und Prozesse vertraglich festhalten. Diese Punkte machen SLAs operativ und überprüfbar.

• Definierte Prioritäten mit Beispielen und Zielwerten
• Alarmkatalog + Runbooks für WAN/VPN/Routing/CPU
• Hypercare-Umfang und Zeitfenster
• Change-Prozess inkl. Pre-/Post-Checks und Rollback
• Reporting-Intervalle und KPI-Definitionen
• Abgrenzungen: Provider, Hardware, Applikation, Security-Incident Handling

Operative Verifikation: CLI-Kommandos, die Support liefern können sollte

Ein guter SLA-Provider kann Incidents schnell objektivieren. Diese Kommandos sollten Bestandteil des Runbooks sein, um WAN, VPN, Routing und Performance zu validieren.

show ip interface brief
show interfaces counters errors
show ip route summary
show ip nat statistics
show crypto ikev2 sa
show crypto ipsec sa
show bgp summary
show ip ospf neighbor
show policy-map interface
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.