Design Reviews: Checkliste für Telco-Topologien

Design Reviews sind im Telco-Umfeld die wichtigste Qualitätsbarriere zwischen „Design auf dem Papier“ und „stabiler Betrieb im Netz“. Carrier-Topologien sind groß, heterogen und hochkritisch: Core/Backbone, Metro, Access, Internet Edge, Peering/Transit, 4G/5G-Transport, Telco Cloud, Security-Farms, Wholesale/Business-Services – alles greift ineinander. Ein Fehler in der Topologie oder in einer Policy wirkt deshalb nicht lokal wie in einem kleinen Enterprise-Netz, sondern kann ganze Regionen, Kundenprodukte oder Partnerverbindungen betreffen. Genau deshalb braucht es strukturierte Design Reviews: nicht als bürokratische Pflicht, sondern als systematisches Prüfen von Annahmen, Failure Domains, Schutzmechanismen, Kapazität, Security-Zonen, Betriebskonzepten und Upgradepfaden. Ein gutes Review stellt die richtigen Fragen, zwingt zu messbaren Kriterien (SLO/SLA, N-1, Konvergenzzeiten, Kapazitätsreserven) und prüft, ob Design und Betrieb zusammenpassen (Wartungsfenster, Monitoring, NOC/SOC-Prozesse). Dieser Artikel liefert eine praxistaugliche Checkliste für Telco-Topologien – so strukturiert, dass Einsteiger damit sicher durch Reviews kommen, Fortgeschrittene schneller Lücken finden und Profis konsistente Standards über Core, Metro und Access hinweg etablieren können.

Design Review im Telco-Kontext: Ziel, Scope und Output

Ein Design Review ist kein Meeting, in dem „alle einmal nicken“. Es ist ein Prozess mit klaren Ergebnissen: Akzeptieren, akzeptieren mit Auflagen oder ablehnen mit konkreten Änderungsanforderungen. Damit Reviews funktionieren, muss Scope definiert sein: Welche Domäne wird geprüft (Core, Metro, Access, Service Edge, Transport/Optik, Telco Cloud)? Welche Schnittstellen sind betroffen? Und welcher Zeithorizont gilt (MVP vs. Zielbild)? Der Output sollte immer dokumentiert sein: Annahmen, Risiken, Entscheidungspunkte, offene Punkte, Test- und Rolloutplan.

• Ziel: Risiken früh erkennen, bevor sie als Incident oder teure Umbauten auftreten.
• Scope: Domäne plus Schnittstellen (z. B. Metro↔Core, Access↔BNG, Edge↔Interconnect).
• Output: Review-Protokoll mit Anforderungen, Risiken, Akzeptanzkriterien und Testplan.
• Erfolgskriterium: Design ist wartungsfähig, beobachtbar und N-1-fähig – nicht nur „funktioniert“.

Die Review-Struktur: Von Anforderungen zu Failure Domains

Die beste Review-Reihenfolge ist: Anforderungen → Topologie → Control Plane → Data Plane → Security → Betrieb. Damit vermeiden Sie, dass Detaildiskussionen (z. B. Timer) geführt werden, bevor klar ist, welche SLO/SLA erreicht werden müssen. Außerdem sollten Sie früh Failure Domains definieren: Welche Ausfälle sind „normal“ (Link, Linecard, PoP, Trasse)? Welche dürfen Kunden spüren? Was ist N-1, was ist N-2? Ohne diese Begriffe bleibt „hochverfügbar“ eine leere Phrase.

• Anforderungen: SLA/SLO, Wachstum, Latenz, Jitter, Loss, Verfügbarkeit, Wartungsfenster.
• Failure Domains: Link/Node/PoP/Region/SRLG, Wartungs- und Schutzfallannahmen.
• Kontrollen: Schutzmechanik, Kapazitätsreserven, Monitoring und Playbooks.
• Nachweis: Tests, Simulationen, Messpläne und Abnahmekriterien.

Checkliste: Anforderungen und Annahmen

Ein Telco-Design scheitert häufig an unausgesprochenen Annahmen. Deshalb sollte jedes Review mit Klarheit starten: Welche Dienste laufen darüber? Welche Kundengruppen? Welche Traffic-Matrix? Welche Peak-Zeiten? Welche regulatorischen Vorgaben? Und welche künftigen Upgrades sind geplant? Ohne diese Angaben sind Topologieentscheidungen (Ring vs. Mesh, OTN vs. Ethernet, GPON vs. XGS-PON) nicht seriös bewertbar.

• Sind die Services und Zielgruppen klar (Residential, Business, Wholesale, Mobile Backhaul, Cloud Onramp, IPTV)?
• Gibt es definierte SLO/SLA-Ziele (Verfügbarkeit, Latenz, Jitter, Loss, Restore-Time) und Messmethoden?
• Ist die Traffic-Matrix bekannt oder plausibel modelliert (Peak, Upstream-Anteil, Wachstum, Heavy Flows)?
• Sind Wachstumsannahmen dokumentiert (12/24/36 Monate) inklusive Upgradepfaden?
• Sind Betriebsannahmen geklärt (Wartungsfenster, NOC/SOC, Field Services, Remote Hands)?

Checkliste: Topologie und Failure Domains

Topologie ist der Rahmen für alles Weitere. Im Review muss klar werden, ob die gewählte Topologie zu Kosten, Resilienz und Betrieb passt. Besonders wichtig sind Failure Domains und Shared Risk: Zwei Links sind nur dann redundant, wenn sie nicht denselben kritischen Pfad teilen (Trasse, MMR, Strom, Verstärkerstandort). Außerdem sollte das Review bewerten, ob die Domänengrenzen sinnvoll sind: zu große Ringe oder zu flache Hierarchien erhöhen Blast Radius und erschweren Wartung.

• Ist die Topologie passend (Ring/Line/Partial Mesh/Hub-and-Spoke) und sind Gründe dokumentiert?
• Sind Failure Domains klar (Link, Node, PoP, Region) und sind N-1/N-2-Annahmen festgelegt?
• Sind SRLGs/Shared Risks berücksichtigt (Trassen, MMR, Strompfade, optische Ketten)?
• Gibt es A/B-Zonen oder vergleichbare Anti-Affinity-Mechanismen für Wartungsfähigkeit?
• Sind Übergaben zwischen Domänen (Core/Metro/Access/Service Edge) sauber definiert?

Checkliste: Kapazitätsdesign und Schutzfallqualität

Viele Designs funktionieren im Normalbetrieb und brechen im Schutzfall. Ein professionelles Review fragt deshalb: Was passiert bei Ausfall oder Wartung? Wo fließt Traffic dann? Werden Links congested? Steigen RTT/Jitter/Loss? Kapazitätsdesign ist nicht nur „Linkauslastung“, sondern auch Queue-Drops, Microbursts und Servicepriorisierung. In Telco-Netzen ist Schutzfallqualität oft gleichbedeutend mit Kundenerlebnis.

• Ist Busy-Hour-Dimensionierung vorhanden (Peak, nicht Durchschnitt) und sind Upgrade-Trigger definiert?
• Ist N-1-Headroom an Engpässen geplant (Metro-Uplinks, Service-Farms, Interconnects, Ringsegmente)?
• Gibt es eine Schutzfall-Traffic-Analyse (Worst Case) und ist das Ergebnis akzeptiert?
• Ist QoS end-to-end geplant (Klassenmodell, Shaping/Policing, Trust Boundaries) inklusive Schutzfallbetrieb?
• Sind Oversubscription-Regeln definiert (PON, HFC, Access-Aggregation, Backhaul) und messbar?

Checkliste: Control Plane Design und Konvergenz

Die Control Plane ist in Carrier-Netzen ein Hochwertziel und eine Stabilitätsachse. Reviews sollten prüfen: IGP-Design (OSPF/IS-IS), iBGP-Design (Route Reflectors), BGP-Policies an Interconnects, Timer-Disziplin und Schutz vor Instabilität. Ebenso wichtig ist Konvergenz: Wie schnell wird umgeroutet? Wie vermeiden Sie Flaps? Welche Komponenten dürfen niemals überlastet werden (RRs, PCE, BNG, UPF-Controller)?

• Ist das IGP-Design konsistent (Areas/Levels, Auth, Metrikregeln, Timer) und skaliert es?
• Ist iBGP sauber geplant (RR-Hierarchie, Session-Templates, Max-Prefix, Policy) und wartungsfähig?
• Sind FRR-Mechanismen (IP/MPLS/SR) definiert und sind Repair-Pfade topologisch sinnvoll?
• Sind Konvergenz- und Stabilitätsziele messbar (z. B. Umschaltzeiten, Route-Churn, Flap-Dämpfung)?
• Ist Control Plane Protection umgesetzt (CoPP, Peer-Härtung, Rate Limits, ACLs)?

Checkliste: Data Plane und Service-Architektur

Data Plane Design betrifft die Frage, wie Services tatsächlich transportiert werden: L2VPN/L3VPN, EVPN/VXLAN, Carrier Ethernet, Internet/CGNAT, IPTV/Multicast, Mobile Backhaul, Telco Cloud. Reviews sollten prüfen, ob Serviceketten und Breakouts topologisch sinnvoll sind oder Hairpinning erzeugen. Außerdem ist Statefulness entscheidend: NAT, Firewalls, UPF und BNG sind zustandsbehaftet und verlangen Symmetrie oder State-Sync.

• Sind Servicebausteine klar definiert (L2/L3VPN, EVPN, Internet Edge, Wholesale, Mobile) und standardisiert?
• Sind Breakout-Standorte (regional/zentral) bewusst gewählt, um Latenz und Backbone-Last zu optimieren?
• Sind stateful Services HA-fähig (Active/Active oder Active/Standby) inklusive Drain/Failover-Strategie?
• Ist MTU/Encapsulation konsistent (MPLS, VXLAN, SRv6, IPoDWDM/OTN) um Fragmentierung zu vermeiden?
• Sind Multicast-Designs (IPTV) robust (IGMP/PIM, Rendezvous/Source, Failover) und segmentiert?

Checkliste: Transport/Optik und physische Ebene

In Telco-Topologien ist „physisch“ oft der wahre Single Point of Failure. Reviews sollten daher prüfen: Trassen, MMRs, Cross-Connects, DWDM/ROADM-Design, optische Margen, Schutzebenen (optisch vs. IP) und die Koordination zwischen Layern. Auch hier gilt: Schutz darf nicht doppelt und unkoordiniert wirken, sonst entsteht Flapping.

• Sind physische Diversität und SRLGs nachweisbar (Trassen, Einführungen, MMR, Strom)?
• Ist optisches Budget/Margin konservativ geplant (OSNR/Power/ROADM-Kaskaden) und upgradefähig?
• Ist die Schutzebene klar (optisch/OTN/Ethernet vs. IP) und sind Timer/Policies abgestimmt?
• Sind Kapazitätsroadmaps für Wellenlängen/Ports definiert (100G/400G/800G) inklusive Triggern?
• Ist die Entstörfähigkeit gegeben (Messpunkte, OTDR/Power, Alarmkorrelation, Runbooks)?

Checkliste: Security by Design – Zonen, Trust Levels, Zugriff

Security muss in Telco-Designs topologisch sichtbar sein. Ein Review sollte prüfen, ob Zonen und Trust Levels umgesetzt sind (Management, Control, Transport, Service Edge, Customer, Interconnect, Cloud) und ob Trust Boundaries echte Kontrollen haben: Allowlisting, Auth, Logging, Anti-Spoofing und Rate Limits. Zusätzlich ist Managementzugriff kritisch: Bastion/PAM, MFA, AAA, Break-Glass und Auditability.

• Sind Zonen/VRFs sauber getrennt und sind erlaubte Flows dokumentiert (Default-Deny, explizite Leaks)?
• Ist Management getrennt (OOB oder Management-VRF) und Zugriff nur über Jump Hosts/PAM möglich?
• Sind Customer/Partner-Übergaben abgesichert (uRPF/Ingress-Filter, BCP38-Logik, Rate Limits, Logging)?
• Sind Control-Plane- und Routing-Schutzmaßnahmen implementiert (Max-Prefix, TTL-Security, ACLs, CoPP)?
• Ist Logging/Audit (Admin-Aktionen, Policy-Deployments) manipulationssicher und zentral verfügbar?

Checkliste: Observability, Telemetrie und NOC/SOC-Betrieb

Ein Design ist nur dann „fertig“, wenn es beobachtbar ist. Reviews sollten prüfen, ob Telemetriepfade, Labels/Tags, SLO-Alarme und Probes existieren – und ob sie mit Zonen und Standortklassen korrelieren. Dazu gehört auch die Frage, ob das NOC/SOC den Entstörprozess tatsächlich durchführen kann: Gibt es Runbooks? Gibt es Abhängigkeiten? Sind KPIs sinnvoll oder erzeugen sie Alarmflut?

• Ist eine Telemetrie-Topologie geplant (PoP-Collector, regionaler Aggregator, zentrale Plattform) mit HA/Buffering?
• Sind Datenarten definiert (Metriken/Logs/Events/Flows/Probes) inklusive Retention und Downsampling?
• Gibt es SLO-orientierte Alarme (QoE, Drops, Session-Failures) statt nur Schwellenwertlärm?
• Sind Dashboards/Views nach Zone/PoP/Service standardisiert und Ownership ist klar?
• Sind Incident- und Escalation-Prozesse dokumentiert (NOC/SOC, Partner, Field) und getestet?

Checkliste: Wartungsfenster, Rollout und Change-Sicherheit

Carrier-Designs müssen Changes überleben. Das Review sollte daher ein Wartungs- und Rolloutmodell verlangen: Maintenance Mode, Drain-Mechanismen, Canary-Rollouts, Pre-/Post-Checks, Rollback und Change-Governance. Außerdem muss geprüft werden, ob die Topologie A/B-Zonen und N-1-Kapazität bietet, damit Wartung nicht zu Kundenwirkung führt.

• Ist Maintenance Mode definiert (De-Preferencing, Drain, Hysterese) und operativ umsetzbar?
• Sind N-1- und Schutzfall-Tests geplant (unter Last) inklusive QoE-Probes und Queue-Drop-Checks?
• Gibt es Rollout-Blueprints für neue Standorte (Day-0 Observability, Abnahmecheckliste, Field-Standards)?
• Existieren Pre-/Post-Checks und Rollback-Mechanismen (Policy-as-Code, CI/CD Guardrails)?
• Sind Change-Fenster und Kommunikationswege definiert (Kundeninfo, Partner, interne Stakeholder)?

Checkliste: Dokumentation, Standards und Governance

Design Reviews bringen wenig, wenn Entscheidungen nicht dauerhaft festgehalten und durchgesetzt werden. Governance bedeutet: Blueprints versionieren, Abweichungen kontrollieren, Standards automatisiert prüfen und Lessons Learned aus Incidents zurück ins Design führen. Gute Dokumentation ist dabei nicht „viel Text“, sondern klare, eindeutige Artefakte: Diagramme, Tabellen, Konfigstandards, Tests, Ownership.

• Sind Blueprints/Standards versioniert und gibt es einen Prozess für Abweichungen mit Ablaufdatum (Deviation TTL)?
• Sind Ownership und Zuständigkeiten pro Domäne/Zone/Service klar (On-Call, Security Owner, Field Owner)?
• Sind Konfigstandards automatisiert prüfbar (Compliance, Drift-Detection, Policy-as-Code)?
• Ist Dokumentation vollständig (Topologie, IPAM, SRLG, Policies, Runbooks, Abnahmeprotokolle)?
• Gibt es einen Postmortem-Loop, der Standards verbessert statt Workarounds zu zementieren?

Typische Red Flags in Telco-Design Reviews

Ein guter Reviewer erkennt Muster, die fast immer zu späteren Problemen führen. Diese Red Flags sollten im Review explizit adressiert werden, weil sie selten „später“ von selbst besser werden. Besonders kritisch sind Scheinredundanz, fehlendes N-1-Headroom, unkoordinierte Schutzmechaniken, flache Managementzugänge und fehlende Observability.

• Scheinredundanz: Zwei Pfade, aber gleicher SRLG (Trasse/MMR/Strom) oder gleicher Kontrollpunkt.
• Kein Schutzfallmodell: Kapazität/ QoE im N-1-Fall nicht berechnet oder nicht getestet.
• Doppelte Schutzmechanik: Optik und IP schützen gleichzeitig ohne Koordination, Flapping-Risiko.
• Policy-Sprawl: Viele Ausnahmen, keine Standards, keine Reviewbarkeit.
• Monitoring fehlt: Keine Probes/Queue-Drops/SLOs; Erfolg nicht messbar.
• Management offen: Direkter Zugriff statt Bastion/PAM, keine Audit-Logs.

Operative Review-Checkliste als Blueprint: So führen Sie Design Reviews konsistent durch

• Kontext: Services, SLO/SLA, Traffic-Matrix, Wachstum, Betriebsannahmen dokumentiert?
• Topologie: Muster begründet, Failure Domains/SRLGs definiert, A/B-Zonen vorhanden?
• Kapazität: Busy Hour, N-1-Headroom, Engpassanalyse, QoS im Schutzfall geprüft?
• Control Plane: IGP/iBGP/RR-Design, FRR, Konvergenz-KPIs, CoPP umgesetzt?
• Data Plane: Servicebausteine, Breakout-Strategie, Statefulness/HA, MTU konsistent?
• Transport/Physik: Diversität, optische Margen, Schutzebene koordiniert, Upgradepfade geplant?
• Security: Zonen/Trust Levels, Managementzugriff, Anti-Spoofing, Auditability, Policies reviewbar?
• Observability: Telemetriepfade, Tags, Probes, SLO-Alarme, NOC/SOC-Runbooks vorhanden?
• Change/Rollout: Maintenance Mode, Tests unter Last, Canary/Rollback, Abnahmechecklisten definiert?
• Governance: Blueprint-Version, Deviation-Prozess, Ownership, Postmortem-Loop etabliert?

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.