Greenfield Telco Design: Neue Netze von Grund auf aufbauen

Greenfield Telco Design: Neue Netze von Grund auf aufbauen ist eine seltene, aber strategisch besonders wirkungsvolle Chance. „Greenfield“ bedeutet: Es gibt keine Altlasten, keine historisch gewachsenen Sonderlösungen und keine vererbten Topologiezwänge – dafür aber einen hohen Erwartungsdruck. Ein neues Telco-Netz muss von Tag 1 skalieren, hohe Verfügbarkeit liefern, regulatorische Anforderungen erfüllen, operativ beherrschbar sein und gleichzeitig wirtschaftlich wachsen können. Wer hier falsch startet, bezahlt den Fehler über Jahre: zu große Failure Domains, unklare Segmentierung, fehlende Automatisierung, zu komplexe Control Plane oder unzureichende Observability führen später zu teuren Umbauten. Ein professionelles Greenfield Telco Design beginnt deshalb nicht mit Gerätelisten, sondern mit einem Zielbild und einem Bauplan: Domänen (Core–Metro–Access), PoP-Klassen, Interconnect-Strategie (IXP/PNI/Transit), Service-Plattformen (L3VPN, Internet, Wholesale, Mobile Backhaul), Resilienzprofile (N-1, Geo-Redundanz), Kapazitätskorridore, Security-Zonen sowie einem Operating Model (NOC/SOC, Change, Telemetrie, Runbooks). Dieser Artikel zeigt, wie Sie ein Telco-Netz von Grund auf so planen, dass neue Kunden und Services ohne ständigen Umbau integriert werden können – mit klaren Schritten, Best Practices und typischen Stolperfallen.

Greenfield heißt nicht „einfacher“: Die typischen Fallstricke am Anfang

Der größte Fehler im Greenfield ist, die Freiheit zu überschätzen und die Entscheidungslast zu unterschätzen. Ohne klare Designprinzipien entsteht schnell ein „Feature-Museum“: zu viele Technologien, zu viele Ausnahmen und zu wenig Standardisierung. Ebenso gefährlich ist, zu lange nur auf dem Papier zu planen. Ein Greenfield Telco braucht früh eine minimale, aber vollständige Referenzarchitektur (Blueprints, Datenmodell, Monitoring, Security), die dann iterativ skaliert. Erfolg heißt: wenige, saubere Standards, die in Wellen ausgerollt werden.

• Technologie-Overload: Zu viele Protokolle und Optionen führen zu OPEX-Explosion und Fehlerquote.
• Zu große Failure Domains: „Ein Ring für alles“ oder „ein PoP für alles“ rächt sich schnell.
• Observability zu spät: Ohne Day-0 Telemetrie wird Troubleshooting teuer und langsam.
• Security nachgelagert: Trust Levels und Zonen müssen am Anfang stehen, nicht am Ende.

Schritt 1: Zielbild definieren – Services, Regionen, SLAs und Wachstum

Bevor Sie eine Topologie zeichnen, müssen Sie wissen, wofür das Netz gebaut wird. Ein Telco-Netz ist selten „nur Internet“. Typische Servicefamilien sind: Residential Broadband (FTTH/HFC/xDSL), Business (L3VPN/L2, Internet Access, SD-WAN Underlay), Wholesale/Bitstream, Mobile Transport (Backhaul/Midhaul/Fronthaul) sowie Plattformdienste (DNS, CGNAT, Security, CDN-Caches). Dazu kommen Regionen und Wachstumsannahmen: Welche Städte/Cluster zuerst, welche Dichte, welche Peak-Profile? Aus diesen Anforderungen leiten Sie Architekturziele ab.

• Servicekatalog: Welche Produkte werden angeboten, welche Isolation ist nötig (Multi-Tenant), welche QoS-Klassen?
• SLA/SLO: Verfügbarkeit, Jitter/Loss, maximale RTT, Schutzfallprofile (N-1) pro Serviceklasse.
• Geografie: Regionen/PoPs, Latenzanforderungen, Interconnect-Hotspots, regulatorische Grenzen.
• Wachstum: Kundenwachstum, Traffic-Mix, Busy Hour, Heavy-Hitter-Profil (Video/Cloud/Gaming).

Schritt 2: Domänenarchitektur festlegen – Core, Metro, Access und Service Edge

Eine klare Domänenarchitektur ist der wichtigste Hebel für spätere Skalierung. Der Core transportiert, Metro aggregiert und verteilt, Access bindet an, und die Service Edge integriert Produkte und Policies. Dieses Prinzip verhindert, dass jeder neue Kunde eine Core-Änderung auslöst. Gleichzeitig definiert es Failure Domains: Ein Access-Problem darf nicht den Core destabilisieren, und ein Service-Edge-Change darf nicht die gesamte Transportdomäne beeinflussen.

• Core: Hohe Resilienz, kurze Konvergenz, policy-arm, klare Korridore und PoP-Strategie.
• Metro: Aggregation, Ring/Mesh-Design, Wachstumspfade, Kapazitätsstufen, regionale Ausstiege.
• Access: Technologie-spezifisch (PON, HFC, xDSL, Mobile), kleine Failure Domains, klare Oversubscription-Regeln.
• Service Edge: VRFs/Services, Internet Edge, Wholesale-Interfaces, Security-Zonen, Service-Farms.

Schritt 3: PoP-Klassen definieren – Super-PoP, Regional-PoP, Edge-Site

Greenfield-Designs gewinnen enorm, wenn Standorte klassifiziert werden. Nicht jeder PoP muss alles können. Super-PoPs tragen hohe Interconnect-Dichte (IXPs, PNIs, mehrere Transits) und häufig zentrale Service-Farms. Regional-PoPs dienen als Aggregations- und Breakout-Punkte. Edge-Sites (Access-nahe Standorte) sind primär für Terminierung und lokale Aggregation zuständig. PoP-Klassen erlauben standardisierte Blueprints und planbare Kosten.

• Super-PoP: Kernstandort mit Multi-Carrier, Multi-IXP, großen Service-Farms und hoher Kapazität.
• Regional-PoP: Regionale Aggregation, lokale Breakouts, ggf. CDN/Anycast-Services, A/B-Zonen für Wartung.
• Edge-Site: Access-Anbindung, geringe Komplexität, starke Standardisierung, OOB-Zugriff als Pflicht.
• Designregel: Funktionen folgen PoP-Klasse; das reduziert Betriebskosten und vermeidet Überdesign.

Schritt 4: Transport- und Underlay-Architektur wählen – IP/MPLS, Segment Routing, OTN

Im Greenfield können Sie die Underlay-Architektur bewusst wählen. Häufig ist ein IP/MPLS- oder SR-basierter Transport die pragmatische Basis, weil er Multi-Service trägt und sich gut mit QoS, FRR und Automatisierung kombinieren lässt. Optische Layer (DWDM/ROADM, ggf. OTN) können darunter liegen und Kapazität effizient bereitstellen. Wichtig ist, nicht alles gleichzeitig „maximal modern“ zu machen: Ein stabiles Underlay ist wichtiger als frühe Featurebreite.

• IP/MPLS: Reifer Multi-Service-Transport, gut für L3VPN, TE-Optionen, bewährte Betriebsmodelle.
• Segment Routing (SR-MPLS/SRv6): Modernes TE/FRR-Konzept, gut für Automatisierung; SR-MPLS oft pragmatischer Einstieg.
• Optischer Layer: DWDM/ROADM für Kapazität und Reichweite; klare Schnittstelle IP-over-DWDM oder Router+Transponder.
• Entscheidungskriterium: Betriebskompetenz, Serviceanforderungen, Skalierungsbedarf, Tooling/Telemetrie.

Schritt 5: Topologie-Entscheidungen – Ring, Partial Mesh, hierarchische Korridore

Im Greenfield lohnt sich eine bewusste Kombination: Metro oft in kleineren Ringen oder als Partial Mesh, Core in einem resilienten Mesh aus wenigen PoPs und Korridoren. Full Mesh ist selten wirtschaftlich. Stattdessen werden strategische Korridore gebaut, die ECMP ermöglichen und SRLG-Diversität berücksichtigen. Entscheidend ist, Schutzfallpfade nicht zu lang werden zu lassen und N-1-Headroom konsequent zu planen.

• Core Mesh: Wenige Knoten, hohe Kapazität, klare Korridore, gute Latenzprofile.
• Metro Partial Mesh: Kleine Ringe plus Chord Links für bessere Lastverteilung und kürzere Umwege.
• Access Aggregation: Dual-homing in regionale PoPs, klare Oversubscription-Regeln.
• SRLG-Diversität: Trassen, MMR, Power und optische Ketten als Designparameter, nicht als Nachgedanke.

Schritt 6: Service-Architektur – L3VPN, Internet Edge, Wholesale, Mobile Transport

Ein neues Netz sollte Services als modulare Bausteine behandeln. Dazu gehören standardisierte Design Patterns für Business-Kunden (L3VPN Hub-and-Spoke, Dual-Homing, Internet Breakout), für Wholesale (Bitstream/Layer-2-Vorleistungen), für Internet (Peering/Transit, Anycast DNS, DDoS-Mitigation) und für Mobile (Backhaul/Midhaul, Synchronisation). Die Service Edge ist die Plattform: Hier sitzen VRFs, Policies, Kundentrennung und die Integration in Security-Zonen.

• Business Services: VRF-basierte L3VPN-Patterns, klare Kundentrennung, QoS-End-to-End.
• Internet Edge: Multi-IXP/Multi-Carrier, deterministische Policies, kapazitive N-1-Planung.
• Wholesale: Saubere Übergabepunkte, klare Topologiegrenzen, Skalierung über Templates.
• Mobile Transport: Latenz- und Sync-Anforderungen berücksichtigen; QoS und Timing als First-Class-Design.

Schritt 7: IP- und SID-Planung – Hierarchien, Summarization, Wachstum

Adressdesign entscheidet über spätere Skalierung. Ein Greenfield sollte IP-Adressierung hierarchisch aufbauen: Region → PoP → Rolle → Link/Loopback. Damit wird Summarization möglich, Routing bleibt schlank, und neue Standorte passen in ein Schema. Für IPv6 gilt das besonders: Aggregation ist ein Kernvorteil. Wenn Segment Routing genutzt wird, braucht es zusätzlich einen SID-Plan, der dieselbe Hierarchie widerspiegelt.

• Hierarchie: Region/PoP/Rolle als Struktur, damit Betrieb und Automatisierung einfach bleiben.
• Summarization: Reduziert Routingkomplexität, begrenzt Blast Radius von Änderungen.
• IPv6-first Mindset: Dual-Stack sauber planen, statt IPv6 „später“ als Sonderprojekt zu behandeln.
• Source of Truth: Adressen und SIDs versioniert, auditierbar und automatisierbar verwalten.

Schritt 8: Resilienzdesign – N-1, Fast Reroute, Geo-Redundanz

Resilienz muss im Greenfield von Anfang an als System geplant werden: Pfadvielfalt, schnelle Failover-Mechanismen und Schutzfallkapazität. N-1 ist meist der wirtschaftliche Standard. N-2 wird selektiv eingesetzt (z. B. für zentrale PoPs oder kritische Dienste). Fast Reroute (FRR) reduziert Paketverlust, aber nur, wenn Coverage und Schutzpfadqualität nachgewiesen sind. Geo-Redundanz (Disaster Recovery) betrifft nicht nur Links, sondern auch Service-Plattformen und Managementsysteme.

• N-1-Headroom: Schutzfälle sind normal (Wartung), daher Reserve konsequent planen.
• FRR-Coverage: Link- und Node-Schutz für kritische Segmente messbar prüfen.
• PoP-Redundanz: A/B-Zonen, getrennte Strompfade, getrennte MMR/Trassen.
• Geo-DR: Kritische Services in mehreren Regionen, klarer Failover- und Recovery-Prozess.

Schritt 9: Security by Design – Zonen, Trust Levels und Management-Netz

Security ist im Greenfield am günstigsten. Sie definieren Trust Levels, VRFs/Zonen, erlaubte Flows, Logging und Zugriffskontrollen, bevor der Betrieb „später“ Workarounds bauen muss. Ein separates Management-Netz (OOB oder Management-VRF) ist Pflicht, ebenso wie CoPP/Control-Plane-Schutz auf zentralen Routern. Für Telco-Cloud und MEC sind East-West-Kontrollen (Network Policies, Service Mesh) wichtig, damit Segmentierung nicht nur auf dem Papier existiert.

• Zonenmodell: Management, Infrastructure, Tenant, Interconnect, Security-Farm – mit Default-Deny und Allowlisting.
• OOB/Management: Getrennter Zugriffspfad, Bastion/PAM, MFA, Audit-Logs.
• Control Plane Protection: CoPP, ACLs, Rate Limits, Session-Härtung für BGP/IGP.
• Logging/Telemetry: Security-Events zentral korrelierbar, nicht nur lokal auf Geräten.

Schritt 10: Observability Day 0 – Telemetrie-Topologie, QoE und Topologie-Visualisierung

Ein Greenfield-Netz sollte „observability-first“ sein. Das heißt: Telemetrie, Logs und QoE-Probes sind Teil des ersten Rollouts, nicht eines späteren Projekts. Besonders effektiv sind Latenz-Maps und perzentilbasierte KPIs (p95/p99), weil sie Schutzfallprobleme und Congestion früh sichtbar machen. Eine Topologie-Visualisierung mit Failure Domains und SRLG-Tags hilft Engineering und NOC, dieselbe Realität zu sehen.

• Telemetrie: Kapazität, Queue-Drops, Errors, Control-Plane-Events, Session-Flaps.
• QoE-Probes: RTT/Jitter/Loss zwischen PoPs, zu Service-Edges und zu Interconnect-Zielen.
• Event-Korrelation: Changes/Wartungen markiert, damit Regressionen schnell zugeordnet werden.
• Topologie-Views: PoP-Klassen, Korridore, SRLGs, Failure Domains als Drilldown.

Schritt 11: Operating Model – NOC/SOC, Change, Wartungsfenster und Runbooks

Ein Netz ist nur so resilient wie sein Betrieb. Greenfield-Design muss daher ein Operating Model enthalten: Wer betreibt was (Ownership)? Wie laufen Changes ab (Pre-/Post-Checks, Rollback)? Wie werden Wartungsfenster geplant (Drain statt Cut)? Wie werden Incidents triagiert (NOC/SOC-Schnittstellen)? Und wie wird Wissen konserviert (Runbooks, Dokumentation, Design Reviews)? Ein entscheidender Punkt ist Standardisierung: Je mehr nach Blueprint, desto weniger „Feuerwehr“ im Betrieb.

• Change-Governance: Templates, Reviews, Automatisierung, Abnahme über KPIs.
• Maintenance Design: Controlled Drain, klare Exit-Kriterien, Canary-Changes in Failure Domains.
• Incident-Prozesse: Runbooks, Eskalationsketten, Postmortem-Loop zur Verbesserung.
• Dokumentation: Diagramme + Datenmodelle + Inventar als Source of Truth, nicht als PDF-Friedhof.

Schritt 12: Rollout-Plan – Pilot, Canary, Wellen und Wachstumspfad

Ein Greenfield wird selten an Tag 1 „fertig“. Erfolgreich ist ein gestufter Rollout: Pilot in einem kleinen Gebiet, dann Canary-PoPs, dann regionale Expansion. Jede Welle hat Abnahmekriterien und Rollback. Wichtig ist, dass die Architektur schon im Pilot vollständig ist (inkl. Telemetrie, Security, Management), aber in kleiner Skalierung. So sammeln Sie Betriebserfahrung, bevor Sie groß ausrollen.

• Pilot: Kleine Region, aber vollständige Architektur (Domänen, Security, Telemetrie, Runbooks).
• Canary: Neue Features zuerst in begrenztem Scope; klare Abbruchkriterien.
• Wellen: Rollout nach PoP-Klassen und Regionen; keine parallelen High-Risk-Changes in derselben Failure Domain.
• Wachstumspfad: Kapazitätsstufen, Upgrade-Trigger und Blueprint-Weiterentwicklung als Routineprozess.

Typische Stolperfallen im Greenfield Telco Design

Die häufigsten Fehler sind: zu viel Technik zu früh, fehlende Standardisierung, fehlende SRLG-Diversität, fehlende N-1-Headroom-Planung und fehlende Observability. Ebenso kritisch ist ein Zielbild, das nur den Normalbetrieb betrachtet. Telco-Netze leben von Wartung, Wachstum und Schutzfällen – und genau dort muss das Design stabil sein.

• Big Bang statt Wellen: Zu große Erstinbetriebnahme ohne Betriebserfahrung erhöht Risiko.
• Kein Blueprint: Jeder PoP wird anders; Betriebskosten steigen stark.
• Scheinredundanz: Redundanz ohne SRLG-Diversität; ein Ereignis trifft beide Pfade.
• Observability zu spät: Ohne Day-0 Telemetrie steigen MTTR und Incident-Kosten.
• Security nachträglich: Trust Levels fehlen; spätere Korrektur wird teuer und disruptiv.

Operative Checkliste: Greenfield Telco Design von Grund auf

• Sind Servicekatalog, Regionen und SLOs/SLA definiert (QoE p95/p99, Verfügbarkeit, Jitter/Loss, Schutzfallprofile), sodass das Zielbild klar ist?
• Ist die Domänenarchitektur festgelegt (Core–Metro–Access–Service Edge) mit klaren Failure Domains und einem policy-armen Core?
• Gibt es PoP-Klassen (Super/Regional/Edge) und wiederholbare Blueprints inkl. A/B-Zonen, SRLG-Diversität, Management/Telemetry?
• Ist Underlay/Transport bewusst gewählt (IP/MPLS oder SR, optischer Layer) und sind Topologie-Patterns (Ring/Partial Mesh/Hierarchie) wirtschaftlich und resilient geplant?
• Ist Service-Architektur modular (L3VPN/EVPN, Internet Edge, Wholesale, Mobile Transport) und sind Schnittstellen zum Core/Metro standardisiert?
• Ist IP-/IPv6- und ggf. SID-Plan hierarchisch, summarization-fähig und als Source of Truth versioniert?
• Sind Resilienzmechanismen (N-1-Headroom, FRR-Coverage, Geo-Redundanz) geplant, getestet und als Abnahmekriterien operationalisiert?
• Ist Security by Design umgesetzt (Zonen/Trust Levels, OOB/PAM/MFA, CoPP, Logging) und ist Observability Day 0 integriert (Telemetrie, QoE-Probes, Topologie-Visualisierung, Change-Korrelation)?

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.