Capacity Planning für Cisco-Router: Throughput, CPU/Memory und Growth Projection

Capacity Planning für Cisco-Router sorgt dafür, dass Bandbreiten-Upgrades, neue Security-Features (VPN, QoS, ACLs) und Wachstum (mehr Standorte, mehr Nutzer, mehr SaaS) nicht zu Performance-Problemen führen. Im Enterprise ist „Throughput“ allein nicht ausreichend: Entscheidend sind CPU-/Memory-Headroom, Forwarding-Pfade (Hardware vs. CPU), Feature-Overhead (Crypto, NetFlow, CoPP) und realistische Growth-Projektionen. Ein professioneller Ansatz kombiniert Messwerte aus dem Betrieb (95. Perzentil), Sicherheitsreserven und klare Upgrade-Trigger. Dieser Leitfaden zeigt, wie Sie Throughput, CPU/Memory und Wachstum strukturiert planen und mit CLI-Evidence belegen.

Zielbild: Was Capacity Planning im Enterprise liefern muss

Capacity Planning ist ein Prozess, kein einmaliges Spreadsheet. Ziel ist eine belastbare Aussage: „Wie viel Traffic und Features sind heute sicher möglich und wann müssen wir skalieren?“

• Baseline: aktuelle Nutzung und Headroom (Peak/95p)
• Feature-Impact: VPN/QoS/ACL/Telemetry/NetFlow (Overhead)
• Growth: Nutzer, Standorte, Bandbreiten, Applikationsmix
• Triggers: klare Schwellen, ab wann Upgrade/Refactoring nötig ist

Throughput-Realität: Datenblatt vs. echte Feature-Last

Router-Datenblätter geben oft idealisierte Throughput-Werte an. In realen Enterprise-Setups sinkt effektiver Durchsatz durch Verschlüsselung, QoS, NetFlow/Telemetry, ACLs und Fragmentierung. Deshalb müssen Sie „Feature-Throughput“ planen, nicht nur „Port-Speed“.

• Unverschlüsselt vs. IPsec: Crypto kann der dominante Faktor werden
• QoS/Shaping: beeinflusst Queueing und CPU (je Plattform)
• ACLs/Policy: zusätzliche Verarbeitung pro Paket/Flow
• Telemetry/NetFlow: zusätzliche Export-Last und Speicherbedarf

Messmodell: 95. Perzentil statt Durchschnitt

Für Kapazität ist der Durchschnitt nahezu wertlos. Nutzen Sie das 95. Perzentil (oder 99p für kritische Umgebungen) und planen Sie Headroom für Ausreißer, Failover und Wartungsfenster.

• Baseline: 95p Utilization pro WAN-Link (Up und Down getrennt)
• Spikes: Peak-Events (Backups, Patchdays, Quartalsabschluss)
• Failover: bei Dual-ISP muss ein Link die Last tragen können

Kapazitätsformel (vereinfacht)

$\mathrm{Erforderliche}\mathrm{Kapazität}=\mathrm{95p}\times (1+\mathrm{Growth})\times (1+\mathrm{FeatureOverhead})+\mathrm{FailoverReserve}$

CPU/Memory: Die wichtigsten Headroom-KPIs

CPU und Memory sind die häufigsten „unsichtbaren“ Engpässe. Hohe CPU führt zu Routing/VPN-Flaps und Managementverlust. Memory-Pressure kann zu Instabilität, Drops und unerwarteten Reloads führen.

• CPU: Dauerlast vs. Peaks (SPF/Updates, Crypto, QoS, Control-Plane Noise)
• Memory: freie Reserven, Fragmentierung, Trend über Wochen
• Indikatoren: CPU-Spikes korrelieren mit Flaps/Logs?

CLI: CPU/Memory Evidence

show processes cpu sorted
show processes cpu history
show processes memory sorted
show processes memory

Feature-Overhead: Was Ihre Kapazität am stärksten beeinflusst

Im Enterprise ist Feature-Overhead planbar, wenn Sie ihn explizit erfassen. Besonders relevant sind VPN/Crypto, QoS, Routing-Skalierung und Export/Logging.

• IPsec/IKEv2: Rekey/DPD + Verschlüsselung, besonders bei vielen Tunneln
• BGP Full Routes: Prefix-Counts erhöhen CPU/Memory und Convergence
• OSPF große LSDB: SPF-Last, Flap-Sensitivität
• QoS: Queueing/Policing, besonders am WAN-Engpass
• NetFlow/Telemetry: Export-Rate, Collector-Last, Buffer
• CoPP: schützt CPU, erfordert aber Tuning und Monitoring

Interface-Health: Errors/Drops als Kapazitätsindikator

Selbst bei „genügend Bandbreite“ können Errors und Drops die Nutzererfahrung ruinieren. CRC und Output Drops sind frühe Warnsignale für Layer1/2-Probleme oder Congestion.

• CRC/Input Errors: Kabel/SFP/Provider-CPE
• Output Drops/Queue Drops: Congestion/QoS fehlend oder falsch
• Planung: Drops sind ein Trigger für QoS/Upgrade, nicht nur „Bandbreite voll“

CLI: Interface Errors/Drops

show interfaces counters errors
show interfaces | include output drops|queue
show policy-map interface

Growth Projection: Wie Sie Wachstum realistisch modellieren

Wachstum kommt selten linear. Berücksichtigen Sie Nutzerwachstum, Standortwachstum, SaaS-Verlagerung und Security-Features, die nachträglich „dazukommen“. Planen Sie mit Szenarien.

• Szenario A: +20% Nutzer, SaaS stabil
• Szenario B: +10 Standorte, mehr VPN-Tunnel, mehr Routing-Adjacencies
• Szenario C: Bandbreitenupgrade 100 → 500 Mbit/s + QoS + Telemetrie
• Szenario D: Dual-ISP aktiv, Failover-Reserve erforderlich

Failover-Reserve: Dual-ISP und HA als Kapazitätsfaktor

Bei Dual-ISP/HA ist Kapazität nicht „Summe beider Links“, sondern „was passiert im Worst Case“. Wenn ISP1 ausfällt, muss ISP2 die kritische Last tragen, mindestens für ein definiertes Zeitfenster.

• Active/Standby: Backup-Link muss kritische 95p-Last tragen können
• Active/Active: jeder Link muss „wichtige Klassen“ tragen können (VoIP/Video)
• VPN: Failover muss Tunnel und Traffic stabil halten (Crypto-Headroom)

Upgrade-Trigger: Wann Sie skalieren müssen

Definieren Sie Trigger, die automatisch zu einer Kapazitätsmaßnahme führen. Damit vermeiden Sie, dass Upgrades erst nach einem Incident passieren.

• WAN Utilization: 95p dauerhaft > Zielschwelle (z. B. „nahe am Shaping“)
• Queue Drops: wiederkehrend oder steigend (Echtzeit betroffen)
• CPU: Dauerlast hoch oder Peaks korrelieren mit Flaps
• Memory: Trend sinkt, Low-Memory Events oder Instabilität
• Routing: Prefix-Counts/LSDB wachsen über Designgrenzen

Capacity Review: Standard-Checkliste für monatliche NOC-Reviews

Planen Sie Capacity Reviews als regelmäßigen Prozess (monatlich/quarterly). So erkennen Sie Trends, bevor sie zu Outages werden.

• WAN 95p/Peak, Drops/Errors, QoS Counter
• CPU/Memory Trends, Top-Prozesse
• Routing/VPN Stabilität (Flaps, Rekey/DPD Fehler)
• Change-/Incident-Korrelation: was hat Kapazität beeinflusst?

CLI: Capacity Snapshot (Copy/Paste)

show ip interface brief
show interfaces counters errors
show interfaces | include output drops|queue
show policy-map interface
show processes cpu sorted
show processes cpu history
show processes memory sorted
show ip route summary
show bgp summary
show crypto ikev2 sa
show crypto ipsec sa
show logging | last 50

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.