Failure-Scenario Design: Was passiert bei Link-, Node- und PoP-Ausfall?

Failure-Scenario Design ist im Telco- und Provider-Umfeld die Disziplin, Ausfälle nicht erst im Incident kennenzulernen, sondern sie vorab systematisch zu modellieren: Was passiert bei Link-Ausfall, Node-Ausfall und PoP-Ausfall – und zwar technisch, kapazitiv und operativ? In großen Carrier-Netzen ist Verfügbarkeit kein Zufall, sondern das Ergebnis klarer Annahmen (N-1/N-2), bewusst definierter Fehlerdomänen und sauber abgestimmter Schutzmechanismen auf mehreren Ebenen (Optik, Ethernet, IP/MPLS, Segment Routing, Services). Die größte Gefahr liegt dabei selten im „einfachen“ Link-Down, sondern im Zusammenspiel: ein Link fällt aus, Traffic verlagert sich auf einen Schutzpfad, der in der Busy Hour schon knapp ist; eine Control Plane wird durch Flaps belastet; stateful Services verlieren Symmetrie; Monitoring wird durch den Ausfall eines Managementpfads blind; und plötzlich ist aus einem lokalen Ereignis ein regionaler Kundenimpact geworden. Failure-Scenario Design sorgt dafür, dass Sie diese Kettenreaktionen erkennen, bevor Sie in Produktion laufen. Dafür braucht es eine klare Methodik: Szenarien definieren, erwartetes Verhalten der Topologie festlegen, Kapazität im Schutzfall berechnen, Konvergenzzeiten und QoE messen, und die Ergebnisse in Blueprints, Wartungsfenster und NOC/SOC-Playbooks übersetzen. Dieser Artikel erklärt praxisnah, wie Sie Failure-Scenario Design aufbauen und welche Fragen Sie bei Link-, Node- und PoP-Ausfällen beantworten müssen, damit Ausfälle kontrolliert bleiben und für Kunden möglichst kaum spürbar sind.

Was ist ein Failure Scenario und warum reicht „Redundanz“ als Antwort nicht aus?

Ein Failure Scenario ist eine konkret formulierte Ausfallsituation inklusive Scope, Zeitverhalten und Schutzannahmen. Beispiel: „Ein 100G-Link im Metro-Ringsegment zwischen Knoten A und B fällt aus, während Busy Hour läuft, und der Ringschutz schaltet in 50 ms um“. Oder: „Ein kompletter PoP fällt aus (Strom/Brandabschnitt), alle dort terminierenden Services müssen auf PoP B übernehmen“. Redundanz ist nur ein Baustein. Ohne Szenario bleibt offen, ob die Redundanz echt ist (keine Shared Risks), ob Kapazität im Schutzfall reicht (N-1-Headroom), ob Konvergenzzeiten den SLA entsprechen, und ob Betrieb und Monitoring den Zustand überhaupt korrekt erkennen.

• Szenario statt Schlagwort: „N-1“ muss konkret heißen: welches Element fällt aus, wann und wie lange?
• Mehr als Connectivity: Entscheidend sind QoE (RTT/Jitter/Loss), Sessions, Steuerung und Betriebsfähigkeit.
• Schutzfall ist Normalfall: Wartungsfenster sind geplante Ausfälle; Failure-Design gilt dafür identisch.
• Nachweis statt Vertrauen: Verhalten muss getestet, gemessen und als Standard dokumentiert sein.

Die Methodik: Szenarien katalogisieren, dann designen

In Carrier-Netzen lohnt sich ein standardisierter Szenario-Katalog, der pro Domäne (Core, Metro, Access, Service Edge, Transport/Optik) wiederkehrende Failure Cases abdeckt. Der Katalog definiert Eingangsbedingungen (Traffic, Busy Hour, Schutzmechanik aktiv), erwartete Reaktionen (FRR, Ring-Switch, BGP/IGP-Konvergenz), Erfolgskriterien (SLO, Paketverlustbudget, Session-Stabilität) und Messpunkte (Probes, Queue-Drops, Control-Plane-Events). Daraus entsteht ein Design, das nicht nur „redundant“ ist, sondern im gewünschten Schutzfallprofil stabil arbeitet.

• Scope: Link, Node, PoP, Trasse/SRLG, Service-Farm-Cluster, Control-Plane-Komponente.
• Time behavior: Sub-50ms (FRR/Ring), Sekunden (IGP), Minuten (Service-Failover/DR).
• Impact model: Welche Services hängen daran? Welche Kundenklassen? Welche SLOs gelten?
• Guardrails: Abbruch- und Rollbackkriterien für Changes, die solche Szenarien triggern könnten.

Grundlagen: Schutzmechanismen und Ebenen sauber abstimmen

Ein zentraler Punkt im Failure-Scenario Design ist die Koordination der Schutzebenen. In vielen Telco-Netzen existieren mehrere Schutzmechanismen parallel: optische Restoration im DWDM/ROADM, Ethernet-Ringschutz, IP-FRR (z. B. LFA/Remote-LFA), MPLS-TE/Segment Routing TE und zusätzlich BGP/IGP-Konvergenz. Wenn diese Ebenen unkoordiniert gleichzeitig reagieren, entsteht Flapping, Pfadinstabilität oder unnötig lange Umschaltungen. Ein gutes Design definiert daher primäre und sekundäre Schutzebenen pro Domäne.

• Primärschutz festlegen: Welche Ebene soll den häufigsten Fehler abfangen (z. B. IP-FRR im Core, Ring-Switch im Metro)?
• Timer-Hierarchie: Schnellster Mechanismus zuerst, langsamere Mechanismen als Backup mit Hysterese.
• Observability: Umschaltzeit, Paketverlust, QoE und Route-Churn müssen messbar sein.
• Stateful Services beachten: Pfadwechsel kann Sessions brechen, wenn Symmetrie nicht gesichert ist.

Link-Ausfall: Was passiert, wenn ein Pfad plötzlich fehlt?

Ein Link-Ausfall ist das häufigste Szenario und sollte im Idealfall „unsichtbar“ bleiben. Doch ob er unsichtbar bleibt, hängt stark von Topologie, Schutzmechanik und Kapazität ab. Im Core wird Link-Ausfall oft durch FRR abgefangen (subsekund), im Metro durch Ringschutz oder IP-FRR, im Access durch Dual-Homing oder Segmentierung. Das Failure-Scenario Design fragt hier nicht nur „ist ein alternativer Pfad vorhanden?“, sondern „wie schnell, wie stabil, und mit welcher Qualität wird umgeschaltet?“

Link-Ausfall im Core/Backbone

Im Core sollte Link-Ausfall idealerweise durch FRR abgefangen werden, bevor IGP/BGP konvergiert. Das reduziert Paketverlust und verhindert, dass Echtzeitdienste spürbar werden. Entscheidend ist, dass Repair-Pfade topologisch sinnvoll sind und nicht über Engpässe laufen, die im Schutzfall congested sind.

• Erwartetes Verhalten: FRR aktiv, Umschaltung in Millisekunden bis wenigen Zehntelsekunden, danach IGP-Stabilisierung.
• Risiko: Schutzpfad führt über lange Umwege oder Engpasslinks; Queue-Drops steigen.
• Messpunkte: QoE-Probes PoP-to-PoP, Queue-Drops pro Klasse, Route-Churn/IGP-Events.
• Designcheck: Repair-Pfad existiert für alle kritischen Links (Coverage) und ist kapazitiv validiert.

Link-Ausfall im Metro-Ring

In Ringen ist Link-Ausfall häufig gut beherrschbar, wenn Ringgrößen begrenzt sind und Ringschutzpfade ausreichend dimensioniert sind. Das Szenario muss prüfen, wie sich der Ring im Schutzfall verhält: Pfadlänge, zusätzliche Latenz, mögliche Hotspots und die Frage, ob mehrere gleichzeitige Ereignisse (z. B. Wartung plus Ausfall) toleriert werden.

• Erwartetes Verhalten: Ringschutz schaltet um, Traffic fließt über Gegenrichtung, Stabilisierung ohne Flapping.
• Risiko: Schutzpfad ist in Busy Hour überlastet; Kundenerlebnis verschlechtert sich trotz „Redundanz“.
• Messpunkte: Linkauslastung im Schutzfall, RTT/Jitter/Loss, Drops in Aggregationsuplinks.
• Designcheck: N-1-Headroom pro Ringsegment und klare Ringgrenzen (keine Megaringe).

Link-Ausfall im Access

Im Access ist Link-Ausfall oft gleichbedeutend mit Kundenimpact, wenn Segmentierung fehlt. Bei FTTH kann ein Feeder-Ausfall viele Kunden betreffen, bei HFC ein Segment, bei Mobile Backhaul ein Standortcluster. Daher ist das wichtigste Designprinzip: Access-Failure Domains klein halten und klare Upgrade- und Redundanzpfade haben.

• Erwartetes Verhalten: Dual-Homing/Backup-Pfad übernimmt, oder Impact bleibt auf kleines Segment begrenzt.
• Risiko: Große Feeder-Bündel ohne Diversität; ein Link nimmt Tausende Kunden mit.
• Messpunkte: Segment-KPIs (Busy Hour), Session-Failures, Alarmkorridore pro Region/PoP.
• Designcheck: Segmentierung (PON Split/Service Group/Backhaul-Cluster) und SRLG-Diversität dokumentiert.

Node-Ausfall: Ein Gerät fällt weg – was übernimmt, was bricht?

Node-Ausfall ist komplexer als Link-Ausfall, weil er mehrere Links, Sessions und Funktionen gleichzeitig betrifft. In Provider-Netzen sind Nodes oft Rollen: Core-Router, Metro-Aggregator, PE/Service-Edge, OLT-Aggregator, Border-Router oder Security-Farm-Gateway. Ein Failure Scenario muss daher rollenbasiert sein: Was passiert, wenn ein bestimmter Rollentyp ausfällt? Wie wirkt das auf Routing, auf Services, auf Kapazität und auf Betrieb?

Node-Ausfall im Core: Routing- und Pfadstabilität

Im Core ist Node-Ausfall zwar selten, aber kritisch. Designziel ist, dass ein einzelner Core-Knoten ausfallen kann, ohne dass das Netz in instabile Konvergenz oder massive Pfadverlängerungen gerät. Dafür braucht es ausreichende Topologie (Partial Mesh), FRR-Coverage, sowie stabile Control-Plane-Parameter.

• Erwartetes Verhalten: Traffic wird über verbleibende Core-Knoten umgeleitet; Konvergenz bleibt kontrolliert.
• Risiko: Zentraler Knoten mit hoher Transitlast; Ausfall erzeugt Hotspots und QoE-Einbrüche.
• Messpunkte: Pfadänderungen, QoE-Probes, Engpassauslastung, Control-Plane-CPU/Events.
• Designcheck: Keine „Supernodes“ ohne Kapazitätsreserve; SRLGs und PoP-Zonen berücksichtigen.

Node-Ausfall im Metro: Aggregationsknoten als Blast-Radius-Verstärker

Metro-Aggregationsknoten bündeln viele Access-Standorte. Ein Node-Ausfall kann daher regionalen Impact erzeugen, wenn Dual-Homing nicht konsequent umgesetzt ist. Das Failure-Scenario Design sollte klar definieren, welche Access-Cluster bei Ausfall auf welchen zweiten Aggregationsknoten schwenken und ob dabei Kapazität und QoS noch passen.

• Erwartetes Verhalten: Dual-Homed Access-Knoten schwenken auf zweite Aggregation; Kundenimpact minimal.
• Risiko: Viele Standorte sind „single-homed“ oder teilen Shared Risk; Ausfall trifft ganze Cluster.
• Messpunkte: Uplink-Auslastung nach Umschaltung, Queue-Drops, Session-Failures, Ringzustände.
• Designcheck: Dual-Homing als Standard, A/B-Zonen im PoP, N-1-Headroom im Schutzfall.

Node-Ausfall an der Service Edge: Statefulness und Symmetrie

Service-Edge-Knoten (PE/BNG/CGNAT/Firewall/UPF) sind häufig stateful oder zumindest policy-intensiv. Node-Ausfall kann hier Sessions kappen, selbst wenn Routing sauber umschaltet. Ein gutes Szenario modelliert daher die Session- und State-Ebene: Gibt es graceful drain? Gibt es State-Sync? Wird Symmetrie erzwungen? Wie schnell kann ein Standby übernehmen, und wie viel Last verträgt der verbleibende Cluster?

• Erwartetes Verhalten: Failover innerhalb des Clusters; neue Sessions werden stabil aufgebaut; bestehende Sessions möglichst erhalten oder kontrolliert beendet.
• Risiko: Asymmetrische Pfade brechen stateful Verarbeitung; ein Node-Ausfall erzeugt Massen-Reconnects.
• Messpunkte: Session-Failures, Error-Rates, NAT-Port-Auslastung, Firewall state-table, UPF-Throughput.
• Designcheck: Clustergrenzen, A/B-Zonen, deterministisches Steering und Kapazitätsreserve im N-1-Fall.

PoP-Ausfall: Wenn ein ganzer Standort wegfällt

PoP-Ausfall ist das klassische Disaster-Szenario im Regionalmaßstab: Stromausfall, Brandabschnitt, Flooding, MMR-Problem, großflächige Baumaßnahme oder Sicherheitsereignis. Ein PoP ist mehr als „ein Routerstandort“: Dort können Interconnects, Service-Farms, Managementzugänge, Telemetrie-Collector, optische Knoten und Field-Logistik zusammenlaufen. Daher muss ein PoP-Ausfall-Szenario sowohl Datenpfade als auch Betriebsfähigkeit abdecken.

PoP-Ausfall im Core/Backbone

Wenn ein Core-PoP ausfällt, muss das Netz weiterhin erreichbar bleiben, ohne dass die verbleibenden PoPs überlasten. Topologisch bedeutet das: Core darf nicht auf „zwei Super-PoPs“ zentriert sein, sondern braucht hinreichend alternative Korridore und eine stabile Control Plane. Außerdem müssen Interconnects so verteilt sein, dass der Verlust eines PoPs nicht alle externen Pfade kappt.

• Erwartetes Verhalten: Traffic reroutet über andere Core-PoPs; Konvergenz stabil; keine globale Instabilität.
• Risiko: Viele Services und Interconnects sind in einem PoP konzentriert; Ausfall erzeugt großen Serviceimpact.
• Messpunkte: Externe Reachability, QoE über Regionen, Interconnect-Auslastung, Route-Churn.
• Designcheck: Multi-PoP-Strategie, diverse Trassen, SRLG-Modelle, verteilte Interconnects.

PoP-Ausfall in Metro/Region: Dual-Region und Zonen-Design

In vielen Netzen ist ein regionaler PoP der Aggregations- und Service-Edge-Punkt. Fällt er aus, muss eine zweite Region übernehmen (Geo-Redundanz). Das ist nur möglich, wenn Services und Datenpfade vorbereitet sind: zweite Abführung, alternative Serviceketten, angepasste Policies, und ausreichende Kapazität über Regionengrenzen hinweg.

• Erwartetes Verhalten: Access-Cluster schwenken auf sekundären PoP; Services laufen weiter, ggf. mit degradiertem Profil.
• Risiko: Sekundär-PoP hat nicht genug Kapazität oder kann bestimmte Services nicht terminieren.
• Messpunkte: Regionale QoE-Probes, Service-KPIs (BNG/UPF/NAT), Transportengpass-Overlays.
• Designcheck: PoP-Klassen (A/B), Service-Placement-Regeln, definierte Degradation-Profile im DR-Fall.

PoP-Ausfall und Betrieb: Management/Telemetrie müssen überleben

Ein PoP-Ausfall kann Entstörung erschweren, wenn Managementzugänge oder regionale Telemetrie dort zentralisiert sind. Failure-Scenario Design sollte daher prüfen, ob OOB/Management und Telemetrie-Topologie eine eigene Redundanz haben: alternative Bastions, alternative Collectors, Buffering, und klare Priorisierung kritischer Betriebsdaten.

• Erwartetes Verhalten: Zugriff auf verbleibende Netzelemente bleibt möglich; Monitoring liefert weiterhin valide Daten.
• Risiko: Zentraler Collector/Bastion fällt aus; NOC/SOC wird blind oder handlungsunfähig.
• Messpunkte: Management-Path-KPIs, Collector-HA-Status, Alarmkorridore für „Blindheit“.
• Designcheck: Regionale Redundanz für Management/Telemetry, klare Trust Boundaries und Allowlists.

Konvergenz, Latenz und QoE: Technisches Verhalten messbar machen

Ein Failure Scenario ist nur dann wertvoll, wenn es messbare Kriterien hat. In Telco-Netzen sind das typischerweise: Umschaltzeit, Paketverlustbudget, zusätzliche Latenz im Schutzpfad, Jitterverhalten, Queue-Drops und Session-Stabilität. Wichtig ist, dass Sie zwischen „kurzzeitiger Umschaltung“ (FRR/Ring) und „langfristiger Stabilisierung“ (IGP/BGP, Service-Failover) unterscheiden. Beide Phasen müssen im Design abgedeckt sein.

• Umschaltzeit: Zeit bis Traffic wieder fließt (FRR/Ring vs. IGP/BGP).
• Paketverlustbudget: Wie viele Drops sind tolerierbar, ohne SLA/SLO zu brechen?
• Schutzpfad-Latenz: Zusätzliche RTT/Jitter durch Umwege; kritisch für Echtzeitdienste.
• Queue-Drops: Drops pro Klasse als Frühindikator für Congestion im Schutzfall.
• Session-KPIs: Reconnect-Spikes, Authentication-Failures, NAT/Firewall state pressure.

Kapazitätsdesign im Schutzfall: N-1 ist eine Rechenaufgabe, keine Hoffnung

Viele Netze sind im Normalbetrieb „grün“, aber im Schutzfall knapp. Failure-Scenario Design verlangt daher eine Schutzfall-Kapazitätsanalyse: Welche Last verschiebt sich wohin? Welche Links werden zu Hotspots? Welche Service-Farms bekommen mehr Sessions? Welche Interconnects werden stärker belastet? Zusätzlich sollte das Design definieren, wie degradiert werden darf: Manche Dienste können im DR-Fall ein reduziertes Profil fahren, während kritische Steuer- und Echtzeitdienste priorisiert werden.

• Traffic-Matrix: Schutzfallflüsse berechnen (Worst Case) statt nur Summen zu betrachten.
• N-1-Headroom: Engpässe identifizieren und kapazitiv aufrüsten oder segmentieren.
• Degradation-Profile: Prioritäten im DR-Fall: Control/Voice/Management vor Best Effort.
• Trigger: Messbare Schwellen, ab wann Segmentierung/Upgrade ausgelöst wird (Queue-Drops, QoE, Session-Failures).

Security-Szenarien: Ausfälle sind nicht immer „nur Technik“

Carrier-Incidents sind oft hybrid: Ein DDoS erzeugt Congestion wie ein Linkausfall, ein kompromittierter Account wirkt wie ein fehlerhafter Change, ein Route Leak kann globalen Impact verursachen. Failure-Scenario Design sollte daher auch Sicherheitsaspekte berücksichtigen: Was passiert, wenn Interconnects gefiltert werden müssen? Wenn ein Managementzugang gesperrt wird? Wenn eine Service-Farm isoliert werden muss? Topologie und Prozesse müssen das ermöglichen, ohne neue Ausfälle zu erzeugen.

• DDoS-Szenario: Traffic-Steering zu Scrubbing, Rate Limits, Schutz der Control Plane, Serviceprioritäten.
• Route-Leak-Szenario: Max-Prefix, Prefix-Filter, schnelle Rollbacks, isolierte Policy-Scopes.
• Management-Compromise: PAM/JIT, Break-Glass-Prozesse, Auditability, Notfall-Isolation.
• Containment ohne SPOF: Security-Maßnahmen dürfen nicht die einzige Connectivity abschneiden.

Tests und Validierung: Wie Sie Failure Scenarios in die Realität holen

Ein Szenario, das nie getestet wurde, ist eine Annahme. In Telco-Netzen sind Tests oft schwierig, aber es gibt praktikable Wege: Lab/Emulation für Control-Plane- und Policy-Logik, segmentweise Tests in Wartungsfenstern, Canary-Standorte, kontrollierte Link-Drains und gezielte Failover-Drills. Wichtig ist eine klare Testhierarchie: erst ungefährlich (Simulation), dann begrenzt (Canary), dann in der Fläche (rollierend). Jeder Test braucht Guardrails und Messpunkte.

• Simulation/Emulation: Routing, Policies, Konvergenzlogik, Service-Steering im Labor validieren.
• Geplante Drills: Link-Drain, Node-Drain, PoP-Zonenwartung in kontrollierten Fenstern.
• Canary-Rollouts: Erst kleine Scopes, klare Abbruchkriterien, automatische Rollbacks.
• Messpflicht: Pro Test QoE, Queue-Drops, Control-Plane-Events und Service-KPIs erfassen.

Dokumentation und Runbooks: Szenarien in Betrieb übersetzen

Failure-Scenario Design muss im Betrieb ankommen. Das heißt: Szenarien werden als Playbooks dokumentiert, an Zonen und Standortklassen gebunden und mit konkreten Schritten hinterlegt: Was prüft das NOC zuerst? Wann wird eskaliert? Welche automatisierten Checks laufen? Welche Degradation-Profile werden aktiviert? Ohne diese Übersetzung bleibt das Designwissen in Köpfen und nicht im System.

• Runbooks pro Domäne: Core/Metro/Access/Service Edge jeweils mit typischen Link-/Node-/PoP-Failure-Flows.
• Topologie-Labels: PoP-Klasse, Zone, SRLG und Owner als Pflichtfelder für schnelle Einordnung.
• Automation-Integration: Pre-/Post-Checks, Maintenance Mode, Drain-Workflows mit Approval und Logging.
• Postmortem-Loop: Jeder echte Incident verbessert Szenarien und Blueprints, nicht nur Tickets.

Typische Stolperfallen im Failure-Scenario Design

Die häufigsten Fehler sind „implizite Annahmen“ und „nur Normalbetrieb gedacht“. Außerdem wird oft Connectivity getestet, aber nicht QoE und nicht der Schutzfall unter Last. Besonders gefährlich ist Scheinredundanz durch Shared Risks und unkoordinierte Schutzmechanik zwischen Optik und IP. Ebenfalls kritisch: stateful Services werden wie stateless behandelt, und dann brechen Sessions im Failover.

• Scheinredundanz: Zwei Pfade, aber gleiche Trasse/MMR/Strom/optische Kette.
• Schutzfall ohne Headroom: N-1 führt zu Congestion; Wartungsfenster werden spürbar.
• Umschaltung ohne Hysterese: Flapping und Instabilität verschlimmern den Impact.
• Statefulness ignoriert: NAT/Firewall/UPF/BNG verlieren Symmetrie; Mass-Reconnects.
• Monitoring nicht resilient: Management/Telemetry fällt mit aus; Entstörung verzögert sich massiv.

Operative Checkliste: Link-, Node- und PoP-Ausfall designen

• Sind Failure Scenarios pro Domäne definiert (Link/Node/PoP) mit klaren Annahmen (Busy Hour, N-1/N-2, Schutzebene) und messbaren Erfolgskriterien (Umschaltzeit, Loss, QoE, Session-Stabilität)?
• Ist die Schutzebene koordiniert (Optik/Ethernet/IP/FRR), inklusive Timer-Hierarchie und Hysterese, um Flapping zu vermeiden?
• Sind SRLGs und physische Shared Risks dokumentiert und werden sie in Design Reviews und Change-Freigaben geprüft?
• Ist Schutzfallkapazität berechnet und verifiziert (Traffic-Matrix, Engpässe, Queue-Drops), inklusive definierter Degradation-Profile für DR-Fälle?
• Sind Node-Ausfälle rollenbasiert modelliert (Core, Metro-Aggregation, Service Edge, Access-Aggregation) und sind Failoverpfade sowie Clustergrenzen klar?
• Sind stateful Services wartungs- und ausfallsicher (Drain, Symmetrie/State-Sync, N-1-Headroom) und werden Session-KPIs überwacht?
• Sind Management und Telemetrie resilient (OOB/Management-VRF, regionale Collector, Buffering), damit Entstörung auch bei PoP-Ausfall möglich bleibt?
• Gibt es einen Test- und Drill-Plan (Simulation, Canary, geplante Drills) und werden Ergebnisse in Runbooks/Blueprints und Postmortems zurückgeführt?

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.