Capacity Planning für IP-Pools: Wie viele Adressen braucht welcher Service?

Capacity Planning für IP-Pools ist im Telco- und Provider-Umfeld eine der wichtigsten Disziplinen, weil IP-Adressen nicht nur eine technische Ressource sind, sondern ein begrenztes Betriebsmittel – insbesondere bei IPv4. Die zentrale Frage lautet nicht „Wie groß ist ein Pool?“, sondern „Wie viele Adressen braucht welcher Service – heute, morgen und unter Stressbedingungen?“ Denn Adressbedarf entsteht nicht nur durch Endkunden. Er entsteht durch DHCP-Leases, IPv6 Prefix Delegation, CGNAT-Design, Management- und OAM-Netze, Edge-Services (DNS/NTP/AAA), Plattformen (Kubernetes, MEC), Interconnects, Anycast, VRFs, Sicherheitszonen und durch Reserven für Wachstum, Failover und Migrationen. Häufig werden IP-Pools zu knapp geplant, weil man nur die aktuellen Kunden zählt und den Rest ignoriert: Peak-Concurrency, Gerätedichte pro Haushalt, Lease-Zeiten, Dual-Stack-Strategie, BNG-Cluster-Redundanz, Wartungsfenster, Rollbacks und die Tatsache, dass Adressräume in großen Netzen geshardet werden müssen, um Scope und Fehlerdomänen zu beherrschen. Ein zu großer Pool ist hingegen auch nicht „gratis“: Er kann Summarisierung verschlechtern, Filterlisten aufblähen, uRPF erschweren und IPv4-Ressourcen unnötig binden. Ein gutes Capacity Planning findet die Balance: ausreichend Reserve für Wachstum und Ausfälle, aber so strukturiert, dass Aggregation, Policies und Betrieb stabil bleiben. Dieser Artikel zeigt praxisnah, wie Sie IP-Pools für unterschiedliche Serviceklassen dimensionieren, welche Kennzahlen und Formeln sich bewährt haben, welche typischen Denkfehler auftreten und wie Sie Ihre Planung so aufbauen, dass sie auditierbar, automatisierbar und langfristig belastbar ist.

IP-Pool ist nicht gleich IP-Pool: Serviceklassen sauber trennen

Der größte Fehler im Capacity Planning ist, alle Adressen „in einen Topf“ zu werfen. In Telco-Netzen sollten Pools nach Funktion und Failure Domain getrennt werden. Damit wird der Bedarf pro Service überhaupt erst messbar und planbar.

• Subscriber IPv4 (DHCPv4 oder statisch): Endkunden-IPv4 für Internetzugang oder CPE-WAN.
• Subscriber IPv6 (Prefix Delegation): delegierte Prefixe pro Kunde (z. B. /56) plus interne /64-Segmente.
• CGNAT Public Pools: öffentliche IPv4-Egress-Adressen, die viele Kunden teilen.
• Infrastructure Pools: Loopbacks, P2P-Links, Core/Metro-Transport, Interconnects.
• Management/OAM Pools: OOB, NMS, Telemetry, Syslog, NetFlow, Collector-Netze.
• Service/DMZ Pools: DNS, NTP, AAA, Load Balancer, Anycast, Bastion, Plattformdienste.
• Plattform-/Cloud-native Pools: Kubernetes Pod/Service CIDRs, MEC-Cluster, EVPN/VXLAN VTEPs.

Die drei Dimensionen des Bedarfs: Bestand, Peak und Reserve

IP-Planung scheitert selten am „aktuellen Bestand“, sondern an Peak- und Reserve-Annahmen. Ein professionelles Capacity Planning betrachtet drei Dimensionen:

• Bestand (Baseline): wie viele aktive Nutzer/Devices/Services existieren im Normalbetrieb?
• Peak (Worst Case): wie viele gleichzeitige Sessions/Leases treten in Stoßzeiten auf (Abendpeak, Events, Störungen)?
• Reserve (Growth & Failure): wie viel Puffer benötigen Sie für Wachstum, Redundanz (N+1), Wartungen und Migrationen?

Gerade in Telco-Netzen ist „Failure Reserve“ zentral: Wenn ein BNG-Cluster ausfällt, müssen andere Cluster temporär mehr Kunden aufnehmen. Ihr Pooling und Sharding muss das aushalten.

Grundformel für IP-Pool-Dimensionierung

Eine einfache, in der Praxis gut nutzbare Grundformel lautet:

$\mathrm{Pool}=\mathrm{Baseline}\times \mathrm{PeakFactor}\times \mathrm{GrowthFactor}+\mathrm{FailureReserve}+\mathrm{OperationalReserve}$

Diese Formel ist bewusst generisch. Entscheidend ist, dass Sie jeden Faktor mit messbaren Annahmen hinterlegen: Telemetrie, DHCP-Logs, BNG-Sessionzahlen, CGNAT-Statistiken, Plattformmetriken und Growth-Prognosen.

Subscriber IPv4 Pools: DHCP-Leases, CPE-Verhalten und Cluster-Sharding

Wenn Kunden echte IPv4-Adressen bekommen (ohne CGNAT oder ergänzend), ist der Bedarf zunächst scheinbar einfach: „ein Kunde = eine IPv4“. In der Praxis muss man aber mit mehreren Effekten rechnen: Mehrfachgeräte/Mehrfachsessions, Lease-Churn, CPE-Reboots und parallele Leases während Migrationen.

• Concurrent Leases: nicht jeder registrierte Kunde ist gleichzeitig online, aber viele sind es. Planen Sie mit Concurrent-Faktoren statt mit Gesamtbestand.
• Lease-Dauer: kurze Leases erhöhen Churn und können Peak-Bedarf treiben (z. B. bei Mass-Reconnect).
• Dual-WAN/Redundanz: Business-Kunden haben häufiger Backup-Links oder mehrere CPEs.
• BNG-Sharding: Pools pro BNG/BNG-Cluster, nicht ein globaler Pool – sonst werden Scope und Troubleshooting schwierig.
• Migration/Parallelbetrieb: bei Umbauten kann ein Kunde temporär zwei Leases haben (alt/neu).

Praxisregel: Subscriber-IPv4-Pools brauchen fast immer einen expliziten „Churn-/Migration“-Puffer, sonst laufen sie in Wartungsfenstern voll.

IPv6 Prefix Delegation: Wie viele Prefixe braucht ein Kunde wirklich?

Bei IPv6 ist das Engpassproblem selten die Anzahl der Adressen, sondern die Struktur: Delegationsgrößen (/56, /48), Aggregation und Policy-Fähigkeit. Dennoch gibt es Kapazitätsfragen: Wie viele Prefixe gleichzeitig sind aktiv, wie werden sie geshardet, und wie groß sind die Pool-Container pro Region/BNG?

• Ein Kunde, ein Prefix: in den meisten Designs bekommt ein Anschluss genau ein delegiertes Prefix (z. B. /56).
• Prefix-Wechsel (Renumbering): bei Reconnect kann sich PD ändern; parallele Gültigkeit kann temporär entstehen.
• Multiple Delegations: Sonderfälle (Business, Multi-Site, statische PD) erhöhen Bedarf.
• Sharding: PD-Pools pro BNG/Cluster und Region bindet Failure Domains und vereinfacht uRPF/Anti-Spoofing.

Kapazität bei IPv6 wird deshalb eher über „wie viele /56 brauche ich im Pool?“ gerechnet. Ein /48 enthält 256 /56, ein /40 enthält 65.536 /56. Entscheidend ist, wie Sie diese Container nach Regionen und Clustern strukturieren, damit Aggregation erhalten bleibt.

CGNAT Pools: IPv4-Egress kapazitiv planen (ohne Port-Kollaps)

CGNAT ist der typische Hebel gegen IPv4-Knappheit, aber er verschiebt die Kapazitätsfrage von „Wie viele IPs?“ zu „Wie viele Ports/Sessions pro IP?“ und „Wie viel Logging/State kann ich tragen?“. Für IP-Pool-Planung heißt das: Sie dimensionieren öffentliche IPv4-Egress-Adressen anhand von Concurrent Subscribers, Port-Bedarf pro Nutzer und Sicherheits-/Logging-Anforderungen.

• Portbudget pro Public IP: pro IPv4 gibt es einen Portbereich; effektiv verfügbar ist weniger als 65.535 wegen Reserven und Systemverhalten.
• Port-Shares: wie viele Kunden teilen sich eine Public IP? Das hängt vom Trafficprofil ab (Gaming, Video, P2P, IoT).
• Session-Table Capacity: State ist oft der limitierende Faktor, nicht nur IPs.
• Logging-Aufwand: je nach Anforderungen (Zeit/IP:Port) beeinflusst Logging, wie aggressiv Sie sharen können.
• Geografisches Sharding: CGNAT-Pools pro Region/Cluster verbessern Resilienz und reduzieren Blast Radius.

Ein guter CGNAT-IP-Pool ist daher nicht „so groß wie möglich“, sondern so groß, dass Port-Auslastung, Session-Limits und Logging im Peak stabil bleiben – plus Reserve für Failover.

Management- und OAM-Pools: klein, aber kritisch

MGMT- und OAM-Netze verbrauchen oft weniger Adressen als Subscriber-Pools, aber sie sind betriebsentscheidend. Zu knapp geplante OAM-Netze führen dazu, dass Monitoring/Telemetry „nachträglich irgendwo“ untergebracht wird – ein typischer Wildwuchs-Auslöser.

• MGMT/OOB: IPs für Switches, Router, Firewalls, BMCs, Jump Hosts, Admin-Tools.
• OAM/Telemetry: Collector-Netze, Exporter-IPs, Syslog-Relays, NetFlow/IPFIX, Tracing.
• Separater Container: MGMT und OAM getrennt vom Service- und Customer-Adressraum (Security und Audit).
• Reserve für neue Tools: Observability wächst oft schneller als erwartet (mehr Agents, mehr Collector-Cluster).

Infrastructure Pools: Loopbacks und P2P-Links richtig kalkulieren

Infrastructure-Pools wachsen linear mit Geräten und Links. Hier ist die Planung vergleichsweise deterministisch, aber oft unterschätzt, wenn MEC/Edge-Ausbau viele neue Knoten bringt.

• Loopbacks: pro Router/Firewall/Service-Node eine /32 (IPv4) und /128 (IPv6); plus Rollenbereiche (RR, PE, P, BNG, VTEP).
• P2P-Links: IPv4 /31 und IPv6 /127 pro Link; Linkwachstum folgt Topologie (Ringe, Mesh, Spines).
• Interconnects: Peerings, Transit, IXPs haben eigene Pools; nicht mit Core-P2P mischen.
• Reserve für Rebuilds: bei Umbauten existieren temporär parallele Links; dafür braucht es Puffer.

Plattform- und MEC-Pools: Warum „Cloud-native“ eigene Kapazitätslogik hat

Wenn Sie MEC oder 5G Core Plattformen cloud-native betreiben, entstehen IP-Bedarfe in Form von CIDRs: Pod-Netze, Service-Netze, VIP-Pools, Underlay-Hostnetze. Diese Netze müssen so dimensioniert sein, dass Skalierung nicht an IPs scheitert.

• Pod CIDR: richtet sich nach maximaler Podzahl pro Cluster plus Reserve für Burst-Scaling.
• Service CIDR: richtet sich nach Anzahl der Services und internen VIPs; oft kleiner als Pod-CIDR, aber nicht trivial.
• VIP/LB Pools: pro Zone/Serviceklasse; wichtig für SBA-Endpunkte, Anycast-Resolver, APIs.
• Edge-Sites multiplizieren: kleine Fehler in der CIDR-Dimensionierung werden bei 100+ MEC-Sites teuer.

Reservestrategien: Growth, Failover, Migration und Quarantäne

Capacity Planning ist nicht vollständig ohne definierte Reservestrategie. Provider, die stabil wachsen, planen Reserven bewusst – und dokumentieren sie als „nicht vergebbar“ bis zum Bedarf. Das verhindert, dass Reserven stillschweigend „aufgebraucht“ werden.

• Growth Reserve: Puffer für planbares Wachstum (z. B. 12–24 Monate).
• Failure Reserve: N+1 Reserve, damit bei Cluster-Ausfall andere Pools Kunden übernehmen können.
• Migration Reserve: temporäre Doppelbelegung bei Umzügen, Renumbering, Plattformwechseln.
• Quarantäne: auslaufende Pools/Prefixe werden nicht sofort recycelt, um Konflikte und „Zombie-Routen“ zu verhindern.

Messdaten und KPIs: Womit Sie Bedarf wirklich belegen

Gute IP-Pool-Planung basiert nicht auf Bauchgefühl. Im Telco-Betrieb stehen typischerweise genügend Daten zur Verfügung, wenn man sie konsequent nutzt und in einer Kapazitätslogik zusammenführt.

• DHCP: aktive Leases, Churn Rate, Peak-Leases, Renew/Release-Verhalten, Lease-Dauer-Korrelation.
• BNG/BRAS: aktive Sessions, Peak concurrency, Reconnect-Wellen, HA-Failover Events.
• CGNAT: aktive Sessions, Ports pro Subscriber, Port Exhaustion Events, Logging-Volumen.
• IPAM: Utilization pro Container, Wachstum pro Region/PoP, „Free Space“ vs. reserviert.
• Monitoring/OAM: Anzahl Exporter/Collector, Wachstumstrends, neue Toolchains.

Typische Planungsfehler und wie Sie sie vermeiden

• Nur Gesamtbestand statt Concurrency: führt zu Über- oder Unterdimensionierung; Peak concurrency ist entscheidend.
• Keine Failure Reserve: Pools laufen bei Ausfall eines Clusters voll.
• Kein Sharding: globaler Pool ohne Scope-Disziplin erschwert uRPF, Troubleshooting und Policies.
• CGNAT nur nach IPs geplant: Ports/Sessions/Logging werden unterschätzt; IP-Pool wirkt „groß“, kollabiert aber operativ.
• Keine Quarantäne: Recycling zu früh verursacht Konflikte, besonders bei Summaries und alten CPEs.
• Fehlende Versionierung: Änderungen am Pool sind nicht nachvollziehbar; Incidents dauern länger.

Praxis-Checkliste: Wie viele Adressen braucht welcher Service?

• Subscriber IPv4: concurrency-basierte Planung, Lease-Churn-Puffer, Pools pro BNG/Cluster, Migrationreserve.
• IPv6 PD: Anzahl delegierter Prefixe (meist 1 pro Kunde) plus Sonderfälle; Pools pro Cluster/Region; Aggregation erhalten.
• CGNAT Public IPv4: IPs nach Port-/Sessionbedarf dimensionieren, Logging/State einrechnen, N+1 Reserve pro Region.
• MGMT/OAM: separate Container, Reserve für neue Tools/Exporter/Collector, strikte Trennung von Customer-Netzen.
• Infrastructure: Loopbacks pro Node, /31-/127-P2P pro Link, Reserve für Umbauten und neue Rings/Pods.
• Plattform/MEC: Pod/Service CIDRs und VIP-Pools pro Cluster, Skalierungsreserve und Site-Multiplikation berücksichtigen.
• Reservestrategie: Growth + Failure + Migration + Quarantäne als explizite, geschützte Bereiche im IPAM.
• Messbarkeit: DHCP/BNG/CGNAT/IPAM-KPIs regelmäßig auswerten, Forecasts versionieren, Schwellenwerte für „Planungsalarm“ definieren.

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.