Kapazitätsplanung ist in Telco- und Provider-Netzen der Unterschied zwischen stabiler Servicequalität und wiederkehrenden Krisenprojekten. Während Topologie und Routing oft „richtig“ aussehen, scheitern viele Netze an einer simplen Realität: Traffic wächst nicht linear, er ist spiky, regional unterschiedlich, stark von Content-Events abhängig und im Störfall muss das Netz N-1 weiter funktionieren. Ohne systematische Wachstumsmodelle und klare Headroom-Strategien passiert typischerweise Folgendes: Links sind im Durchschnitt „nur“ zu 40% ausgelastet, aber in Peak-Minuten droppen Queues; ein IXP-Port ist im Normalbetrieb ok, aber beim Transit-Failover kollabiert er; ein BNG/CGNAT ist throughputseitig entspannt, aber CPS/Sessions und Logging-Pipeline laufen in Peaks an die Wand. Professionelle Kapazitätsplanung betrachtet daher nicht nur Bandbreite, sondern die gesamte Servicekette: Access->Metro->Core->Edge, inklusive Interconnect, Service Chains (CGNAT, Firewalls, DDoS) und Control Plane (BGP/IGP, Session-State). Der Kern ist ein wiederholbarer Prozess: messen, modellieren, Trigger definieren, rechtzeitig investieren – und dabei Headroom so zu planen, dass Wartungen und Störungen ohne SLA-Bruch überstanden werden. Dieser Artikel zeigt praxisnah, wie Sie Wachstumsmodelle aufbauen, welche Headroom-Strategien sich bewährt haben und wie Sie Upgrade-Entscheidungen mit Telemetry und SLOs belastbar machen.
Warum Kapazitätsplanung in Telco-Netzen schwierig ist
Kapazität ist mehr als „Gigabit“. Provider-Netze haben viele Engpassarten, die sich gegenseitig beeinflussen. Außerdem ist Traffic nicht gleichmäßig: Abendspitzen, Sports-Streams, Spiele-Updates, Cloud-Backups und DDoS-Ereignisse erzeugen Peaks, die in Durchschnittsmetriken verschwinden. Und weil Netze redundant sind, muss Kapazität auch im Ausfallfall reichen.
- Spikiness: Microbursts und kurze Congestion-Spitzen sind oft das eigentliche Problem, nicht der Tagesdurchschnitt.
- Geografie: Regionen wachsen unterschiedlich; ein PoP kann „explodieren“, während andere stabil bleiben.
- Serviceketten: CGNAT, Firewalls, Scrubbing und Proxies haben eigene Limits (State, PPS, Logging).
- N-1 Realität: Wartung oder Ausfall reduziert Pfadvielfalt; Restpfade müssen kritische Last tragen.
- Policy-Effekte: Peering/Transit-Policies oder TE-Änderungen verschieben Traffic plötzlich.
Leitprinzip: Kapazität ist ein End-to-End Budget
Sie planen nicht nur Links, sondern Servicepfade. Ein Upgrade am Core hilft wenig, wenn der Engpass am IXP-Port oder im BNG-Queueing liegt.
Die Kapazitätsdimensionen: Throughput, PPS, CPS, State und Speicher
Ein belastbares Modell betrachtet mehrere Achsen. Bandbreite (Throughput) ist sichtbar und wird deshalb oft überbetont. In der Praxis limitieren häufig andere Größen: Pakete pro Sekunde (PPS), neue Verbindungen pro Sekunde (CPS), Tabellen-/State-Limits (Sessions, NAT, BGP/EVPN), sowie Speicher/Collector-Kapazität für Telemetry und Logging.
- Throughput (bps): Klassische Linkauslastung, relevant für Upgrades, aber nicht allein entscheidend.
- PPS: Kleine Pakete, DDoS, Telemetry-Overhead oder Control-Plane-Last können PPS limitieren.
- CPS: Besonders relevant für CGNAT, Firewalls, Proxies und bei Reconnect-Wellen.
- Session-/State-Counts: BNG Sessions, NAT-State, EVPN MAC/IP-State, FIB/TCAM-Pressure.
- Telemetry/Logging: Flow-Records, gNMI Streams, NAT-Logs; oft der versteckte Engpass.
Ein vereinfachtes Engpassmodell
Die kleinste Achse entscheidet. Deshalb muss Kapazitätsplanung multidimensional sein.
Messgrundlage: Welche Telemetry Sie für Kapazitätsplanung brauchen
Gute Modelle beruhen auf guten Daten. In Telco-Topologien sollten Sie nicht nur 5-Minuten-Interface-Averages speichern, sondern auch Peaks, Queue-Drops, Member-Visibility bei LAG/ECMP und Service-spezifische KPIs. Wichtig ist außerdem: Daten müssen topologisch labelbar sein (Region, PoP, Linkklasse, Serviceklasse), sonst sind Forecasts schwer nutzbar.
- Interface/Port: p95/p99 Auslastung, Peak-Minuten, Errors, Optical Degradation.
- Queues: Drops pro Klasse, Buffer-Indikatoren, Microburst-Signale an Engpässen.
- ECMP/LAG: Member-Auslastung und Imbalance, nicht nur Gesamtbundle.
- Routing: Prefix-Counts, BGP-Update-Raten, FRR-Aktivierungen als Indikatoren für Pfadverschiebungen.
- Services: BNG Sessions/Churn, CGNAT State/CPS/Port-Pool-Pressure, Firewall-Throughput/PPS.
Designregel: Messen an Choke Points
Kapazitätsplanung braucht höchste Granularität dort, wo Engpässe real sind: Interconnect-Ports, DCI-Links, Hub-Uplinks, BNG/CGNAT-Edges. Im Core reichen oft Trends.
Wachstumsmodelle: Linear, exponentiell, stufenweise und eventgetrieben
Trafficwachstum ist nicht immer linear. In Telco-Realität gibt es mehrere Muster, die je nach Region, Produkt und Partner unterschiedlich auftreten. Ein gutes Modell erkennt diese Muster und verwendet passende Forecast-Methoden statt „eine Gerade durch alles“.
- Linear: Stabiler Zuwachs pro Monat; typisch für reife Regionen ohne große Produktänderungen.
- Exponentiell: Frühe Ausbauphasen (FTTH Rollout), starker Kundenzuwachs oder neue Content-Partnerschaften.
- Stufenweise: Große Kunden- oder Wholesale-Onboardings, neue Mobile-Sites, neue PoPs; Wachstum springt.
- Eventgetrieben: Sportevents, Release-Tage, DDoS; kurzfristige Peaks definieren Headroom-Needs.
- Policygetrieben: Peering/Transit-Änderungen verschieben Traffic, ohne dass Gesamttraffic wächst.
Praktischer Ansatz: Trend + Saison + Peak-Faktor
Viele Betreiber modellieren Wachstum als Kombination aus langfristigem Trend, saisonalen Mustern (Wochentag/Abendspitze) und einem Peak-Faktor für Events. Das ist oft realistischer als komplexe Statistik ohne Topologiekontext.
Forecasting pro Topologieebene: Access, Metro, Core, Edge
Kapazitätsplanung muss hierarchisch sein, weil Engpässe je Ebene anders entstehen. Access skaliert mit Anschlüssen und Oversubscription, Metro mit Aggregationspunkten, Core mit regionaler Lastverteilung und Edge mit Interconnect-Partnern und Internet-Exit-Strategien.
- Access: PON/Last-Mile Oversubscription, OLT-Uplinks, Cluster-Wachstum nach Ausbaugebiet.
- Metro: Aggregationshubs, Ring- und Mesh-Reserven, N-1 bei Ringbruch oder Hubwartung.
- Core: DCI/Backbone-Pfade, TE-Strategien, Summarization von Wachstum über Regionen.
- Edge/Interconnect: IXP/PNI/Transit-Portklassen, Traffic-Mix nach ASN, Exit-Regionalisierung.
Designregel: Edge-Kapazität folgt Traffic-Mix, nicht nur Gesamttraffic
Ein neuer PNI kann Transit drastisch senken, ein IXP-Fabric-Problem kann Transit kurzzeitig erhöhen. Edge-Forecasts sollten deshalb immer die Verteilung PNI/IXP/Transit modellieren.
Headroom-Strategien: N-1, N-2 und „Failure-Aware Capacity“
Headroom ist die bewusst eingeplante Reserve, damit ein Service trotz Ausfall oder Wartung weiter funktioniert. In Telco-Netzen ist Headroom kein Luxus, sondern Voraussetzung für planbare Wartung, stabile Failoverpfade und SLO-Einhaltung. Die Frage ist nicht „ob“, sondern „wie viel und wo“.
- N-1 Headroom: Ausfall eines Links/Nodes darf keine Congestion in kritischen Klassen erzeugen.
- N-2 Headroom: Für besonders kritische Domains (z. B. zentrale Edges, DCI) kann N-2 sinnvoll sein.
- Serviceklasse-Headroom: Nicht jede Klasse muss N-1 voll tragen; Priorisierung über QoS kann Headroom effizienter machen.
- Regionaler Headroom: Regionen mit häufigen Wartungen oder höherem Risiko brauchen mehr Reserve.
Headroom ist ein SLO-Parameter
Wenn Ihr SLO Latenz/Loss in Peakzeiten fordert, müssen Sie Headroom auf Engpässen so planen, dass Queue-Drops im N-1 nicht regelmäßig auftreten.
Kapazitätsplanung an Engpässen: Interconnect, DCI, Hub-Uplinks
Die meisten spürbaren Incidents entstehen an wenigen Stellen. Deshalb lohnt es sich, für diese Zonen klare Port- und Upgrade-Strategien zu definieren: Portklassen, Schwellenwerte, Upgrade-Trigger und Failover-Simulationen. Besonders wichtig sind Interconnects (IXP/PNI/Transit), DCI-Links und Hub-Uplinks in Metro-Aggregationen.
- Interconnect-Portklassen: Definierte Zielauslastungen (z. B. p95 < X%), Upgrade bei wiederkehrenden Drops oder Peak-Überschreitung.
- DCI: Cross-Region-SLOs erfordern Reserve; DCI-Congestion hat großen Blast Radius.
- Hub-Uplinks: Aggregationshubs müssen N-1 tragen; LAG-Member-Imbalance kann trotz freier Gesamtbandbreite droppen.
- Queue-First Thinking: Nicht nur bps, sondern Drops pro Klasse sind der Frühindikator.
Ein praktischer Upgrade-Trigger
Wenn ein Engpass regelmäßig Queue-Drops in priorisierten Klassen zeigt oder p99-Latenz in einer Region ansteigt, ist das oft ein stärkerer Trigger als „80% durchschnittliche Auslastung“.
Servicekapazität: BNG, CGNAT, Firewalls und Logging-Pipelines
In modernen Netzen sind viele Engpässe stateful. BNG/BRAS skaliert über Sessions, CGNAT über State/CPS/Port-Pools, Firewalls über PPS/Session-Table, und Logging/Telemetry über ingest/speicher. Kapazitätsplanung muss diese Plattformen genauso behandeln wie Links – mit Headroom, N-1 und Upgrade-Triggern.
- BNG: Active Sessions, Setup-Raten, Reauth/Churn, CPU/Memory, Policy-Instanzen, N-1 Clusterreserve.
- CGNAT: Concurrent State, CPS Peaks, Port-Pool-Pressure, Drop-Reasons, Logging-Backpressure.
- Firewalls: PPS/Session-Table, Inspection-Features, asymmetrische Pfade, HA-Failover unter Last.
- Telemetry/Logging: gNMI/Flow/NAT-Logs: Collector-Headroom, Buffering, Retention, Query-Last.
Designregel: Plattformen brauchen eigene SLOs
Wenn CGNAT-Logging backpressured, oder BNG bei Churn kollabiert, ist das ein Kapazitätsproblem – auch wenn die Links „grün“ sind. Definieren Sie Plattform-SLOs und Upgradetrigger.
Konservativ vs. effizient: Headroom durch QoS und Traffic-Klassen
Headroom lässt sich nicht nur durch „mehr Bandbreite“ erreichen. Ein gängiger Ansatz ist serviceklassenbasierte Planung: Kritische Klassen (Voice, Timing, Control, Enterprise) werden im N-1 geschützt, Bulk-Traffic darf degradiert werden. Das senkt Kosten, muss aber transparent geplant und getestet sein.
- Priorisierte Klassen: Schutz gegen Drops, definierte minimale Bandbreite im N-1.
- Best Effort/Bulk: Darf im Störfall degradiert werden, aber mit klaren Grenzen (keine Komplettkollapse).
- Admission Control: Policing/Shaping an Vertragsgrenzen verhindert, dass einzelne Kunden Headroom „auffressen“.
- Testbarkeit: QoS-Profile müssen im Failover getestet werden, sonst ist die Reserve nur theoretisch.
Anti-Pattern: QoS als Ersatz für fehlende Kapazität
QoS kann Headroom effizienter nutzen, aber keine dauerhaft fehlende Kapazität kompensieren. Wenn Bulk dauerhaft die Prioritätsklassen verdrängt, braucht es Upgrades, nicht nur neue Queue-Profile.
Upgrade-Entscheidungen: Trigger, Lead Times und „Time to Exhaust“
Kapazitätsplanung wird operativ, wenn sie in klare Trigger übersetzt wird. Dazu gehört die Prognose: Wann erreicht ein Link/Cluster die Grenze? Und wie lange dauert ein Upgrade (Lead Time)? Die Differenz ist Ihr Handlungsspielraum. Ohne diese Logik entstehen Notfall-Upgrades.
- Time to Exhaust: Prognose, wann p95/p99 oder Drops die definierten Grenzen erreichen.
- Lead Time: Beschaffung, Cross-Connect, IXP-Port, Linecard, Change-Fenster – realistisch einplanen.
- Upgrade-Trigger: Kombination aus Peak-Auslastung, Drop-Raten, SLO-Verletzungen, Trend.
- Wellenstrategie: Regionale Upgrades in Wellen, um Risiko zu minimieren und Lerneffekte zu nutzen.
Eine einfache Entscheidungsformel
Wenn Sie voraussichtlich vor Abschluss der Maßnahme an die Grenze laufen, ist es bereits zu spät. Safety Margin ist besonders wichtig in spiky Umgebungen.
Kapazitätsplanung und Policy: Traffic kann durch Regeln „wachsen“
Ein häufiger Überraschungseffekt ist policybedingtes Wachstum: Peering-Änderungen, Traffic Engineering, neue Communities oder veränderte Inbound-Steuerung verschieben Traffic. Die Kapazitätsplanung muss daher Policy-Änderungen als Kapazitätsereignisse betrachten – mit Vorher/Nachher-Messung und Rollback-Regeln.
- Peering vs. Transit: Ein PNI kann Transit entlasten, ein IXP-Ausfall kann Transit kurzfristig stark belasten.
- Regionale Exits: Exit-Regionalisierung reduziert Hairpinning, kann aber einzelne PoPs stärker belasten.
- TE/SR Policies: Verschieben Last im Backbone; Member-Imbalance kann Engpässe erzeugen.
- Change-Awareness: Kapazitätsdashboards müssen Change-Labels enthalten, sonst sind Analysen unscharf.
Designregel: Jede Policy-Änderung braucht Kapazitäts-Checks
Vor dem Rollout sollten Sie simulieren oder zumindest messen, welche Links/Ports stärker belastet werden. Nach dem Rollout sind Vorher/Nachher-Vergleiche Pflicht.
Typische Fehlerbilder und wie man sie vermeidet
- Nur Durchschnittswerte: Lösung: Peak-Minuten, p95/p99, Microburst-Indikatoren und Queue-Drops messen.
- Headroom nur auf Links: Lösung: Plattformkapazität (BNG/CGNAT/Firewall/Telemetry) gleichwertig planen.
- N-1 ignoriert: Lösung: N-1 Tests und Störfallsimulationen, Headroom-Definition pro Linkklasse.
- Keine Topologie-Labels: Lösung: Region/PoP/Linkklasse/Serviceklasse als Pflichtlabels, automatisiert.
- Notfall-Upgrades: Lösung: Time-to-Exhaust vs. Lead Time, klare Trigger und Safety Margin.
- Policy-Shift überrascht: Lösung: Change-Awareness, Traffic-Mix-Analysen (Flows) und Rollback-Kriterien.
Praktische Leitlinien: Wachstumsmodelle und Headroom-Strategien
- Mehrdimensional planen: Throughput, PPS, CPS, State, Queue-Budgets und Telemetry/Logging als gemeinsame Limits betrachten.
- Topologiehierarchie nutzen: Forecasts pro Region/PoP/Linkklasse/Serviceklasse statt globaler Zahlen.
- Choke Points priorisieren: Interconnect, DCI, Hub-Uplinks, Service-Edges mit hoher Granularität überwachen.
- Headroom definieren: N-1 als Standard, N-2 für kritische Domains; Headroom pro Serviceklasse über QoS ergänzen.
- Upgrade-Trigger festlegen: p95/p99, Queue-Drops, SLO-Verletzungen und Trend kombinieren, nicht nur „80% Auslastung“.
- Lead Times realistisch: Beschaffung, Cross-Connects, Change-Fenster und Testaufwand in die Planung integrieren.
- Policy-Änderungen einbeziehen: Peering/Transit/TE-Änderungen als Kapazitätsereignis behandeln, Vorher/Nachher messen.
- Regelmäßig testen: Failover unter Last, N-1 Verhalten, QoS-Wirkung und MTU/Blackhole-Risiken validieren.
- Governance etablieren: Kapazitätsreviews, Error Budgets, Investment-Backlog und Evidence-by-Design als kontinuierlichen Prozess führen.
