Site icon bintorosoft.com

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

Red Snapper

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.

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:

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:

Pool= Baseline×PeakFactor ×GrowthFactor +FailureReserve +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.

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?

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.

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.

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.

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.

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.

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.

Typische Planungsfehler und wie Sie sie vermeiden

Praxis-Checkliste: Wie viele Adressen braucht welcher Service?

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:

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

Exit mobile version