Capacity & Congestion: Bottleneck in L1, L3 oder L7 bestimmen

Capacity & Congestion gehören zu den häufigsten Ursachen für Performance-Probleme in Provider- und Enterprise-Netzen – und gleichzeitig zu den am häufigsten falsch diagnostizierten. Der Grund ist simpel: Ein Bottleneck zeigt sich selten dort, wo er entsteht. Ein überbuchter Uplink kann wie ein DNS-Problem aussehen, ein fehlerhafter Optik-Link wie eine „Application Timeout“-Welle, und ein überlasteter Reverse-Proxy kann Paketverlust imitieren, obwohl das Backbone sauber ist. Genau deshalb ist „Capacity & Congestion: Bottleneck in L1, L3 oder L7 bestimmen“ mehr als ein Monitoring-Thema – es ist eine Methode zur Beweisführung. Ziel ist, Engpässe entlang des End-to-End-Pfads messbar zu lokalisieren: Ist die Ursache physikalisch (Layer 1), routing-/pfadbasiert (Layer 3) oder in der Anwendungsschicht bzw. den Plattformkomponenten (Layer 7)? In diesem Artikel lernen Sie, wie Sie Capacity- und Congestion-Symptome systematisch trennen, welche Telemetrie pro Layer belastbar ist und wie Sie aus Messdaten eine klare, nachvollziehbare Entscheidung ableiten. Das Ergebnis: schnellere MTTR, weniger Eskalationsschleifen und ein „Bottleneck-Fingerpointing“, das durch Fakten ersetzt wird.

Warum Bottlenecks so oft am falschen Layer vermutet werden

Congestion ist ein emergentes Phänomen: Es entsteht aus Verkehrsmustern, Queue-Verhalten, Pfadwahl, Protokoll-Reaktionen und Applikationslogik. Dadurch wandern Symptome. Ein Engpass an einem Backbone-Link (L1/L2) führt zu Queueing und Drops, was TCP-Retransmits (L4) erhöht und in Anwendungen als „Timeout“ oder „500er“ (L7) auftaucht. Umgekehrt kann ein L7-Engpass (z. B. erschöpfte Worker oder Connection Pools) zu Retry-Stürmen führen, die wiederum Traffic-Spitzen erzeugen und echte Netzcongestion auslösen. Wer nur auf ein Dashboard schaut, riskiert einen klassischen Denkfehler: Symptome werden mit Ursachen verwechselt.

• Layer-Verschiebung: L1/L3-Probleme äußern sich in L7-Metriken (Fehlerquoten, Latenzen), L7-Probleme äußern sich in Netzmetriken (Traffic-Spikes, neue Flows, SYN-Retries).
• Asymmetrie: In vielen Netzen sind Hin- und Rückweg unterschiedlich. Ein Engpass auf dem Rückweg kann nur bestimmte Transaktionen treffen (z. B. große Antworten).
• Lastabhängigkeit: Viele Engpässe sind erst bei Peak sichtbar. Nachts „alles grün“, zur Primetime kippt es.

Begriffe sauber trennen: Capacity, Congestion, Bottleneck

Eine präzise Sprache macht Diagnose schneller. Capacity ist die theoretische oder konfigurierte Maximalleistung eines Links, Geräts oder Dienstes. Congestion ist der Zustand, in dem Nachfrage die nutzbare Kapazität übersteigt und dadurch Queueing, Drops oder Verzögerungen entstehen. Der Bottleneck ist der engste Abschnitt im End-to-End-Pfad, der das Gesamtsystem begrenzt.

$\mathrm{Utilization}=\frac{\mathrm{Traffic}}{\mathrm{Capacity}}$

Hohe Auslastung ist nicht automatisch Congestion. Ein Link kann dauerhaft bei 80–90% laufen und trotzdem stabil sein, wenn Queueing kontrolliert ist und Burst-Charakteristika passen. Congestion erkennen Sie erst über die Nebenwirkungen: steigende Queue-Latenz, Drops, ECN-Markierungen, Retransmits oder Applikations-Timeouts.

Die OSI-orientierte Diagnose: Ein Entscheidungsbaum statt Bauchgefühl

Der schnellste Weg zum richtigen Layer ist ein reproduzierbarer Ablauf. Denken Sie in drei Schritten: (1) End-to-End-Symptome objektivieren, (2) Layer-spezifische Beweise sammeln, (3) Engpass-Layer isolieren und verifizieren.

• Schritt 1 – Symptomprofil: Ist es Latenz, Loss, Jitter, Durchsatz, Errors oder nur bestimmte Anwendungen?
• Schritt 2 – Pfad und Scope: Welche Kundensegmente, Regionen, POPs, Services sind betroffen? Gibt es ein Zeitmuster?
• Schritt 3 – Layer-Beweise: L1: physische Fehler/Signalqualität; L3: Pfadwahl/ECMP/Policy; L7: Sättigung von Proxies, DNS, CDN, APIs.

Layer 1: Bottlenecks und „Congestion-Symptome“, die eigentlich Physik sind

Layer 1 wird häufig übersehen, weil „Link up“ als ausreichend gilt. In der Praxis kann ein physischer Pfad jedoch degradieren, Fehler korrigieren (FEC) oder sporadisch droppen, und das wirkt wie Congestion. Besonders tückisch: FEC kann Fehler lange kaschieren, bis Uncorrectables auftreten oder die Latenz (durch Korrekturen) messbar steigt.

Typische L1-Indikatoren für einen Engpass oder eine Degradation

• Fehlerzähler: CRC/Symbol Errors, PCS/PMD-Fehler, steigende Error-Rate korreliert mit Peaks.
• FEC-Statistiken: Hohe Corrected-Counts oder Uncorrectables sind ein starkes Warnsignal.
• DOM/DDM-Werte: Rx-Power driftet, Temperaturgrenzen, asymmetrische Optikwerte zwischen Enden.
• Flaps/Microflaps: Sehr kurze Carrier-Drops, die in manchen Systemen nur als Counter sichtbar sind.

So unterscheiden Sie L1-Degradation von echter Congestion

• Congestion: Queueing/Drops steigen mit Traffic, Fehlerzähler bleiben sauber.
• L1-Problem: Fehlerzähler/FEC steigen unabhängig vom Traffic oder überproportional; Drops können auch bei moderater Last auftreten.
• Test: Kontrollierte Lastreduktion: Sinkt Loss sofort, ohne dass Fehlerzähler sich ändern? Dann eher Congestion. Bleiben Fehlerzähler aktiv, dann L1/L2.

Layer 3: Wenn Pfadwahl, ECMP oder Policy den Engpass erzeugt

Layer 3 ist der Ort, an dem „Kapazität vorhanden“ und „Kapazität genutzt“ auseinanderlaufen. Ein klassischer Fall: Gesamtkapazität im Backbone ist ausreichend, aber Routing/TE lenkt zu viel Traffic über wenige Links. Dann entsteht Congestion lokal, obwohl andere Pfade leer sind. Ebenso können ECMP-Hashing oder Anycast-Entscheidungen einzelne Links oder POPs überlasten.

Layer-3-Signale, die auf einen Pfad-basierten Bottleneck hinweisen

• Uneven Utilization: Parallelpfade mit stark unterschiedlicher Auslastung bei gleichem Zielset.
• Hotspot-Links: Einzelne Interfaces erreichen regelmäßig hohe Auslastung, während Nachbarlinks frei bleiben.
• Route Changes/Churn: Häufige Best-Path-Wechsel oder IGP-Metrikänderungen, die Traffic „hin und her“ schieben.
• Asymmetrie: Hinweg sauber, Rückweg congested (oder umgekehrt) – sichtbar über Traces und Flow-Daten.

ECMP-Hashing als „versteckter Capacity-Killer“

ECMP verteilt Flows nicht gleichmäßig in Bits pro Sekunde, sondern typischerweise in Flow-Gruppen. Wenige „Elephant Flows“ können daher einen Link saturieren, während andere Links ungenutzt bleiben. Besonders anfällig: Video-Streaming, Backup-Jobs, CDN-Fills, große Enterprise-Tunnel.

• Beweisführung: Flow-Top-N (Quelle/Ziel/Port) und Anteil am Interface-Traffic zeigen, ob einzelne Flows dominieren.
• Mitigation-Ansätze: Hash-Key erweitern, LAG/ECMP-Größe erhöhen, TE/SR-Policies nutzen, Traffic Engineering für Elephants.

Policy- und TE-Fehlerbilder

• Lokale Präferenz/Communities: Unabsichtlich verschobener Egress zu einem weniger kapazitätsstarken Transit.
• IGP-Metriken: Ein Metrik-Change zieht unerwartet „fremden“ Traffic an.
• SR-TE/MPLS-TE: Policy-Scope zu breit oder Schutzpfad aktiviert sich dauerhaft und läuft in Congestion.

Wenn Sie Standards als Referenz brauchen: Für BGP-Grundlagen ist BGP-4 (RFC 4271) hilfreich; für MPLS-Kontext MPLS Architecture (RFC 3031).

Layer 7: Wenn die Plattform der Engpass ist – und das Netz „unschuldig“

Layer 7 ist in Provider-Umgebungen längst kein Randthema mehr: DNS, CDN, Proxy/SASE, WAF, API-Gateways, Load Balancer und Auth-Systeme sind kritische Pfadkomponenten. Ein L7-Bottleneck führt häufig zu Timeouts, 5xx-Spikes, Retries und Verbindungsaufbau-Stürmen. Das sieht für das NOC oft nach Netzcongestion aus – ist aber in Wahrheit eine Ressourcen- oder Konfigurationsgrenze der Plattform.

Typische L7-Bottleneck-Indikatoren

• Queueing in der Anwendung: Request-Queue wächst, Worker/Thread-Pools sind voll, steigende „Time to First Byte“.
• Connection Pool Exhaustion: Upstream-Pools (DB, Origin, Auth) sind am Limit, Backpressure entsteht.
• Rate Limiting/WAF: False Positives oder zu aggressive Limits erzeugen Drops/Resets, die wie Loss wirken.
• Cache-Miss-Storms: CDN/Proxy zieht plötzlich viel Origin-Traffic, der Backbone-Links und Origin überlastet.

So grenzen Sie L7 von L1/L3 ab

• Netzmetriken stabil: Keine Interface-Drops, keine Queue-Drops, keine ungewöhnlichen Retransmits im Backbone.
• Fehler sind service-spezifisch: Nur bestimmte Hostnames/Services betroffen, andere Anwendungen laufen normal.
• Serverseitige Signale: CPU, Memory, GC-Pausen, Thread-Pool-Sättigung, 5xx/429-Raten steigen.
• Synthetische Probes: ICMP/UDP-Ping ok, aber HTTP/TLS-Requests steigen in Latenz oder failen selektiv.

Für HTTP-Statuscodes als Diagnosehilfe ist die Referenz HTTP Semantics (RFC 9110) nützlich, um 5xx/4xx sauber einzuordnen.

Messstrategie: Welche Daten pro Layer den Bottleneck beweisen

Die zentrale Frage lautet: Welche Messung ist „gerichtsfest“ genug, um den Layer zuzuweisen? Ein guter Ansatz kombiniert drei Perspektiven: (1) Infrastruktur (Interfaces/Queues), (2) Pfad (Routing/Flows), (3) Service (Requests/Sessions). Erst in Kombination entsteht ein belastbares Bild.

Layer 1 – Messdaten

• Interface-Errors, FEC (corrected/uncorrected), Flap-Counter
• Optikwerte (Rx/Tx, Temperatur), Alarm-/Threshold-Events
• Vergleich mit Baseline (vor Peak / vor Change)

Layer 3 – Messdaten

• Utilization pro Parallelpfad (ECMP/LAG), Top-N-Links nach Auslastung
• Routing-Änderungen (Best Path, IGP-SPF, TE-Policy-Events)
• Flow-Daten (IPFIX/NetFlow): Elephants, neue Flow-Rate, AS/Prefix-Verteilung

Layer 7 – Messdaten

• Request-Raten, Error-Raten (5xx/4xx), Latenzverteilung (p50/p95/p99)
• Queue-Längen, Worker-Auslastung, Connection Pools, Upstream-Health
• Retry-Raten und Timeouts (Client und Server), Circuit-Breaker-Events

Praktischer Ablauf: Bottleneck-Lokalisierung in 15 Minuten

In Incidents zählt Geschwindigkeit. Der folgende Ablauf ist bewusst pragmatisch: erst grob klassifizieren, dann gezielt verifizieren.

• Minute 0–3: Scope klären: Welche Regionen/Services? Zeitlicher Beginn? Nur Peak oder dauerhaft?
• Minute 3–6: L1-Sanity: Errors/FEC/Flaps/Dom auf den Top-Links im betroffenen Pfad.
• Minute 6–10: Congestion-Beweis: Interface Utilization + Queue-Drops/ECN + Latenzanstieg korrelieren.
• Minute 10–12: L3-Pfadcheck: ECMP-Verteilung, ungewöhnliche Traffic-Shifts, Policy-Events.
• Minute 12–15: L7-Abgleich: Sind 5xx/Timeouts service-spezifisch? Gibt es Plattform-Sättigung oder Retry-Storm?

Typische Fallkonstellationen und wie Sie sie entwirren

Fall 1: „Backbone congested“ – aber nur ein einzelner Link ist voll

• Hinweis: Ein Hotspot-Link bei gleichzeitig freien Parallelpfaden.
• Wahrscheinlicher Layer: L3 (ECMP/TE/Policy).
• Beweis: Flow-Top-N zeigt Elephants; Routing/TE zeigt Pfadpräferenz.

Fall 2: „Packet Loss“ – aber Error-Zähler steigen

• Hinweis: CRC/FEC Uncorrectables korrelieren mit Loss.
• Wahrscheinlicher Layer: L1.
• Beweis: Fehler treten auch bei moderater Auslastung auf; DOM-Werte auffällig.

Fall 3: „Timeouts“ – Netzmetriken sind sauber

• Hinweis: Keine Queue-Drops, keine Retransmit-Spikes im Backbone, aber HTTP-Fehler und Latenz steigen.
• Wahrscheinlicher Layer: L7.
• Beweis: Plattformmetriken zeigen Sättigung (Worker/Queue/Pools), 5xx/429 steigen.

Fall 4: „Alles langsam“ – nur zur Primetime

• Hinweis: Zeitmuster, Peak-abhängig, häufig mit Video/Streaming korreliert.
• Wahrscheinlicher Layer: L3 oder L7, seltener L1.
• Beweis: Link/Queueing steigt synchron mit Traffic; ggf. Cache-Miss-Storm oder Content-Shift.

Outbound-Links: Vertiefung für Standards und Diagnose-Grundlagen

• BGP-4 (RFC 4271) – Policy und Routing-Entscheidungen als Congestion-Ursache
• MPLS Architecture (RFC 3031) – Pfade, Labels und Traffic Engineering Kontext
• HTTP Semantics (RFC 9110) – Interpretation von 5xx/4xx als L7-Signal
• IEEE 802.3 – Ethernet-Grundlagen (Link-Physik und Fehlerbilder)
• Architectural Principles of the Internet (RFC 1958) – Denkmodell für End-to-End-Fehlerursachen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.