Greenfield IP-Planung: Neues Telco-Netz von Null richtig strukturieren

Greenfield IP-Planung ist die seltene Gelegenheit, ein neues Telco-Netz von Null so zu strukturieren, dass es auch nach Jahren noch skalierbar, sicher und betriebsfreundlich ist. In bestehenden Netzen kämpfen Teams oft mit historisch gewachsenen Prefix-Spaghetti, inkonsistenter /30-/31-Nutzung, unklaren Ownerships, Management-Netzen im falschen Kontext und Policies, die nur noch durch Ausnahmen funktionieren. Bei Greenfield-Projekten lässt sich genau das vermeiden – aber nur, wenn IP-Adressierung von Anfang an als Architekturdisziplin verstanden wird, nicht als „Adressvergabe“. Ein moderner Telco-IP-Plan muss heute mehr leisten als früher: Dual Stack (IPv4/IPv6) sauber abbilden, Metro- und Access-Wachstum unterstützen, MEC/Edge und Cloud-native Plattformen integrieren, VRFs und Multi-Tenant sauber trennen, uRPF/Anti-Spoofing ermöglichen, Routingtabellen klein halten und gleichzeitig eine Source of Truth liefern, aus der Automatisierung und Dokumentation entstehen. Das klingt viel – ist aber beherrschbar, wenn man mit einem klaren Blueprint startet: Hierarchie, Rollenblöcke, Standardpräfixe, Reserven, Naming und Prozesse. Dieser Artikel führt Sie Schritt für Schritt durch ein bewährtes Vorgehen, um ein Telco-Netz von Null richtig zu strukturieren: von der Topologie- und Scope-Definition über Prefix-Container und Summaries bis zu Access-Pools, Interconnects, Services, IPAM und Versionierung.

Greenfield bedeutet nicht „klein anfangen und später ordnen“

Ein verbreiteter Fehler ist, in der Anfangsphase „einfach erstmal irgendwas“ zu adressieren und die Struktur später nachzuziehen. In Telco-Netzen funktioniert das selten, weil frühe Entscheidungen sofort in Konfigurationen, Kundenprodukte, Monitoring, Dokumentation und Verträge wandern. Je früher Ihre Struktur klar ist, desto weniger Betriebsschuld bauen Sie auf.

• Frühe Entscheidungen sind klebrig: BNG-Pools, VRF-Namen, Loopback-Schemata, VLAN-Standards werden später nur teuer geändert.
• Skalierung kommt früher als gedacht: neue PoPs, neue Ringe, neue Partner, neue Serviceklassen.
• Automation braucht stabile Daten: ohne klare Container/Tags wird IPAM zur Excel-Ansammlung.

Schritt 1: Topologie und Failure Domains definieren

Adressplanung ist immer eine Abbildung der Topologie. Bevor Sie Prefixe verteilen, definieren Sie die Failure Domains, die später auch Summaries, Routing-Scopes und Betriebszuständigkeiten bestimmen. In Telcos hat sich eine Hierarchie bewährt:

• Region: geografische Grobdomäne (z. B. Nord/Süd oder Ländercluster).
• Metro/Area: Stadtcluster oder Metro-Ring als typische Failure Domain.
• PoP: konkreter Standort (Core/Edge/Aggregation-Funktion).
• Access-Cluster: BNG/BRAS- oder Aggregationsdomäne, an der Subscriber-Pools geshardet werden.

Diese Ebenen sind nicht „Bürokratie“, sondern ein Werkzeug: Sie verhindern, dass lokale Netze global werden, und sie machen uRPF, Filter und Troubleshooting einfacher.

Schritt 2: Rollenblöcke festlegen, bevor Sie Subnetze vergeben

Der wichtigste Greenfield-Entscheid ist die Trennung nach Rollen. Rollenblöcke sind Prefix-Container mit klarer Semantik. Sie sind die Grundlage für Policies („exportiere nur Public-Container“) und für Automatisierung („jedes neue PoP bekommt dieselben Rollencontainer“).

• Infrastructure: Loopbacks, P2P-Links, Core/Metro-Transport.
• Interconnect: Peering/Transit/IXP-Links, externe Übergabenetze.
• MGMT: Out-of-Band, Admin-Zugriffe, Geräte-Management.
• OAM: Telemetry, Syslog, NetFlow/IPFIX, Monitoring-Collector.
• Services: DNS/NTP/AAA, DMZ/Plattformdienste, Anycast-Endpunkte.
• Subscriber/Customer: Residential/Business/Wholesale Pools, VRF-spezifisch.
• Platform: MEC/Kubernetes Pod/Service CIDRs, VIP/LB Pools (falls relevant).

Schritt 3: Standardpräfixe definieren, die überall gelten

Standards sind in Greenfield-Projekten Gold wert, weil sie spätere Drift verhindern. Im Provider-Umfeld haben sich folgende Längen in vielen Designs bewährt:

• Loopbacks: IPv4 /32, IPv6 /128
• Punkt-zu-Punkt Links: IPv4 /31 (Default), IPv6 /127
• IPv6 Segmente: /64 pro L2/L3-Segment
• Access-VLANs IPv4: nach Bedarf, häufig /24-/26 im Access; Infrastruktur kleiner, aber konsistent

Das Ziel ist nicht „eine einzig wahre Größe“, sondern eine Regel, die zu 95% passt und Ausnahmen sichtbar macht.

Schritt 4: Aggregation Design – Summaries von Anfang an einplanen

Ein Telco-Netz scheitert nicht an „zu wenigen Adressen“, sondern an „zu vielen Routen“. Deshalb muss Summarisierung in der Struktur eingebaut sein. Summaries sollten entlang echter Containergrenzen möglich sein: Region → Metro → PoP. Wenn Sie Prefixe quer verteilen („hier ein /24 aus Region A, dort ein /24 aus Region B“), verlieren Sie Aggregation dauerhaft.

• Region-Summaries: ermöglichen einfache BGP-Policies und kleine Filterlisten.
• Metro-Summaries: halten IGP/BGP stabil, wenn viele PoPs wachsen.
• PoP-Container: sorgen dafür, dass lokale Änderungen lokal bleiben.
• Null-Route bewusst: Summaries können mit Null-Routes abgesichert werden, aber nur mit konsistenter Detailverteilung.

Schritt 5: Access-Pools von Anfang an sharden

In Greenfield-Netzen ist der größte langfristige Hebel die Access-Pool-Strategie: Subscriber-Pools dürfen nicht global „frei fließen“, sondern müssen an Access-Cluster/BNG-Cluster gebunden sein. Das reduziert Blast Radius, vereinfacht uRPF/Anti-Spoofing, macht Kapazitätsplanung planbar und hilft beim Troubleshooting.

• IPv4 Subscriber: Pools pro BNG-Cluster, mit Growth- und Failure-Reserve.
• IPv6 PD: Delegationspools pro Cluster/Region, aggregierbar und filterbar.
• Produktklassen: RES/BIZ/WHSL getrennt (Policies, QoS, Security).
• Migrationreserve: Puffer für Parallelbetrieb, Reconnect-Wellen und Rollbacks.

Schritt 6: VRFs und Multi-Tenant-Design früh entscheiden

Telco-Netze betreiben fast immer mehrere Mandantenkontexte: Kunden-VPNs, Wholesale, Management-VRF, Service-VRFs, ggf. 5G-Core oder MEC. Greenfield ist der ideale Zeitpunkt, VRF-Naming, VRF-Adressräume und Leak-Standards festzulegen. Besonders wichtig: Overlapping RFC1918 ist normal – aber nur, wenn IPAM und Policies VRF-aware sind.

• VRF-Taxonomie: klare Namen und Zweck (MGMT, OAM, SVC, RES, BIZ, WHSL).
• Prefix-Container pro VRF: verhindert „unsichtbare“ Overlaps und erleichtert Filter/Exports.
• Leak-Allow-Lists: nur definierte Shared Services leaken, keine großen Summaries wie 10/8.
• Policy-Punkte: Inter-VRF-Kommunikation über definierte Firewalls/Gateways, wo nötig.

Schritt 7: Interconnect-Adressierung als eigenes Modul

Peering, Transit und IXPs sind eigene Trust-Domänen. Deshalb sollte Interconnect-Adressierung strikt getrennt sein – sowohl im IP-Plan als auch in Naming, ACLs und Dokumentation. Für P2P-Interconnects sind /31 (IPv4) und /127 (IPv6) bewährte Standards. IXP-LANs folgen meist IXP-Vorgaben.

• Dedizierte Pools: IC-P2P-V4, IC-P2P-V6 getrennt von Core-P2P.
• IXP-LAN getrennt: IXP-Adressen sind keine „normalen“ Linknetze; Security-Defaults sind restriktiver.
• Dokupflicht: Partner/ASN, Link-ID, Standort, Policy-Gruppe, MTU, Owner.

Schritt 8: Services, Anycast und zentrale Infrastruktur einplanen

Viele Greenfield-Pläne vergessen zentrale Dienste: DNS/NTP/AAA, PKI, Logging, Telemetry, Bastion, Repository, ggf. Anycast-Resolver. Ohne eigene Service-Container werden diese später „irgendwo“ platziert – oft im falschen Kontext (Security und Betrieb leiden).

• Service-VRF oder Zone: SVC getrennt von Customer und MGMT.
• Anycast bewusst: Anycast-IP-Pools getrennt und dokumentiert, damit Monitoring und Policies konsistent bleiben.
• OAM separat: Telemetry/Logging in OAM-Containern, nicht im Service- oder Customer-Adressraum.

Schritt 9: IPv6 als First-Class Citizen – nicht als „Add-on“

Greenfield ist die beste Gelegenheit, IPv6 sauber zu integrieren. Das bedeutet: parallele Containerhierarchie zu IPv4, konsistente Standards (/64-/127-/128) und Prefix-Filter von Anfang an. Besonders wichtig im Access: PD-Strategie (/56 vs. /48) und Anti-Spoofing (uRPF/ACLs/Source Validation) müssen zum Adressplan passen.

• Parallele Hierarchie: Region/Metro/PoP/Rolle auch für IPv6.
• PD-Pools sharden: pro Cluster/Region, damit Aggregation und uRPF funktionieren.
• Filterbarkeit: Public vs. internal strikt getrennt; Export default-deny.

Schritt 10: IPAM/Source of Truth und Versionierung von Tag 1

In einem neuen Telco-Netz sollten Sie IPAM nicht „später“ einführen. Ein Source-of-Truth-System ist der Ort, an dem Prefixe, Rollen, VRFs, VLANs, Links und Ownership zusammenkommen. Das ist Grundlage für Automatisierung (Templates), Audits (Nachvollziehbarkeit) und schnelle Incident-Diagnose.

• Templates: „Neuer PoP“ erzeugt automatisch Rollencontainer (LB, P2P, MGMT, OAM, SVC, SUB).
• Pflichtfelder: Scope (Region/Metro/PoP), Rolle, VRF, Owner, Status, Change-Referenz.
• Versionierung: Änderungen an Summaries, Pools und Leaks nachvollziehbar; Snapshots für große Umbauten.
• Drift Detection: regelmäßiger Abgleich Config↔SoT, damit die Wahrheit nicht auseinanderläuft.

Konkretes Beispielschema: Wie Sie von oben nach unten planen

Ein praktikabler Weg ist „Top-down in Containern“: Sie planen zuerst die Grobblöcke, dann teilen Sie sie entlang der Hierarchie und Rollen. Ein generisches, übertragbares Schema:

• REG-<R>: Region-Aggregat (IPv4 und IPv6), enthält alle Metro-Aggregate.
• MET-<M>: Metro-Aggregat, enthält PoP-Container.
• POP-<P>: PoP-Container, enthält Rollenblöcke LB/P2P/MGMT/OAM/SVC/IC.
• ACC-<C>: Access-Cluster-Container, enthält Subscriber-Pools pro Produktklasse und PD-Pools.

Diese Struktur ermöglicht Summaries pro Region/Metro, klare Zuständigkeiten und wiederholbare Rollouts.

Security by Design: Warum ein guter IP-Plan Leaks und Spoofing reduziert

Ein Greenfield-Plan sollte Security nicht als „Firewall-Thema“ betrachten. IP-Design kann und sollte Security einfacher machen:

• Prefix-Filter: Export default-deny, nur Public-Container nach außen.
• Route-Leak-Schutz: Kundennetze und Management sind in getrennten Containern; Policies können containerbasiert arbeiten.
• uRPF-freundliche Scopes: Subscriber-Pools pro Cluster/Region, Rückwege eindeutig.
• VRF-leaks minimal: Allow-Lists für Shared Services, keine großen RFC1918-Leaks.

Typische Greenfield-Fallen und wie Sie sie vermeiden

• „Wir nehmen einfach 10/8 für alles“: ohne Rollencontainer entstehen später unwartbare Filter und Overlaps.
• Keine Reserven: Growth und Failure Reserve fehlen; Pools laufen bei Ausfällen oder Migrationen voll.
• Kein Sharding im Access: globaler Pool erschwert uRPF, Troubleshooting und begrenzt Failover.
• IPv6 später: führt zu parallelen Sonderlösungen und inkonsistenter Segmentierung.
• IPAM „irgendwann“: Excel-Divergenz, fehlende Nachvollziehbarkeit, hohe Betriebskosten.
• Zu viele Ausnahmen: Standards verlieren Wirkung; Drift entsteht früh.

Praxis-Checkliste: Neues Telco-Netz von Null richtig strukturieren

• Topologie definieren: Region, Metro, PoP, Access-Cluster als Failure Domains festlegen.
• Rollencontainer festlegen: Infra (LB/P2P), Interconnect, MGMT, OAM, Services, Subscriber/Customer, Platform.
• Standards setzen: /32-/128 Loopbacks, /31-/127 P2P, /64 Segmente, klare Ausnahmen mit Begründung.
• Aggregation planen: Summaries pro Region/Metro/PoP möglich machen, keine Cross-Region-Prefix-Entnahmen.
• Access sharden: Pools pro BNG/Cluster und Produktklasse, inkl. Growth/Failure/Migration-Reserve.
• VRFs standardisieren: Taxonomie, Container pro VRF, Leak-Allow-Lists nach Servicekatalog.
• Interconnects trennen: eigene Pools und Security-Defaults für Peering/Transit/IXP.
• IPv6 integrieren: parallele Hierarchie, PD-Strategie, Prefix-Filter, Anti-Spoofing früh definieren.
• IPAM/SoT von Tag 1: Templates, Pflichtfelder, Versionierung, Drift Detection und Runbooks etablieren.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.