February 21, 2026

PPPoE Session Flaps: Diagnose von Access bis Core

PPPoE Session Flaps sind im Provider-Betrieb eines der teuersten Störungsbilder, weil sie gleichzeitig technische und operative Konsequenzen haben: Kunden verlieren wiederholt die Verbindung, Anwendungen brechen, VoIP/Video friert ein, und im NOC entsteht schnell ein „Mass-Reconnect“-Effekt mit erhöhter Signalisierungslast auf BNG/BRAS, AAA/RADIUS und Aggregation. Der schwierigste Teil ist, dass PPPoE Flaps selten nur eine Ursache haben. Häufig treffen mehrere Faktoren zusammen: ein degradiertes Access-Segment mit Mikroverlusten, zu aggressive LCP Echo-Parameter, ein L2-Problem in der Aggregation (VLAN/QinQ, LAG-Member), sporadische BNG-Control-Plane-Überlast oder RADIUS-Latenzspitzen, die Sessions instabil machen. Deshalb ist eine Diagnose von Access bis Core zwingend: Sie müssen das Problem entlang der Kette CPE ↔ Access ↔ Aggregation ↔ BNG/BRAS ↔ AAA ↔ Core systematisch eingrenzen, statt in der Mitte zu raten. Dieser Artikel liefert eine praxistaugliche Vorgehensweise, um PPPoE Session Flaps sauber zu diagnostizieren: typische Failure Modes, die wichtigsten Signale pro Layer, konkrete Checks, Messlogik für Flap-Rate und Stabilitätsfenster sowie eine Mitigation-Checkliste, um zuerst zu stabilisieren und dann die Root Cause belastbar zu beweisen.

Table of Contents

PPPoE in 60 Sekunden: Warum Sessions flappen können

PPPoE (PPP over Ethernet) besteht aus einer Discovery-Phase (PADI/PADO/PADR/PADS) und der PPP-Session (LCP, ggf. CHAP/PAP, anschließend NCP wie IPCP/IPv6CP). Sobald die PPP-Session steht, werden Keepalives (LCP Echo) und Session-Timer relevant. Jede Störung entlang des Pfades, die Discovery oder LCP beeinträchtigt, kann einen Flap auslösen. PPPoE ist in RFC 2516 beschrieben, RADIUS (für Auth/Accounting) in RFC 2865 und RFC 2866.

Was genau ist ein „Session Flap“?

Operativ ist ein PPPoE Session Flap ein wiederholtes Ab- und Wiederaufbauen der PPPoE/PPP-Session innerhalb eines kurzen Zeitfensters. Wichtig ist die Trennung:

Hard Flap: Session fällt komplett weg (PADS verloren, LCP down), danach vollständiger Neuaufbau.
Soft Instability: Session bleibt „up“, aber LCP Retries, hohe Retransmits, Auth-Delays oder kurze Micro-Outages treten auf (für Kunden ähnlich schlimm).
Regional Flap: viele Kunden in einer Access-Domain (z. B. OLT/DSLAM/Ring) flappen gleichzeitig.
BNG Flap: viele Sessions auf einem BNG/Linecard flappen gleichzeitig (Control-Plane/HA/Resource-Thema).

Die häufigsten Ursachenklassen – von Access bis Core

Um PPPoE Session Flaps schnell zu diagnostizieren, lohnt sich eine grobe Klassifizierung. Sie reduziert den Suchraum und hilft, die richtigen Teams einzubinden.

Ursachenklasse 1: Access/CPE und Last-Mile Instabilität

Physische Störungen: DSL-SNR-Schwankungen, FTTx-Optik-Degradation, Mikroaussetzer, die LCP Echo verlieren lassen.
CPE Verhalten: aggressive Reconnect-Logik, Firmware-Bugs, NAT/Firewall-Interaktion mit PPP.
Power Events: kurze Stromausfälle beim Kunden oder in Street Cabinets führen zu „Flap-Wellen“.

Indiz: Flaps sind stark regional oder sogar straßenzugspezifisch; BNG und AAA wirken gesund, aber viele PADI/PADR kommen aus demselben Access-Segment.

Ursachenklasse 2: Layer-2 Aggregation (VLAN/QinQ, LAG, Storm-Control)

VLAN/QinQ-Mismatch: PPPoE Frames werden falsch getaggt oder verworfen.
LAG/Member Degradation: ein Port-Channel ist up, aber ein Member hat Errors/Drops – selektive Flaps entstehen durch Hashing.
Storm-Control / Policer: zu enge Limits drosseln PPPoE Discovery (PADI Storms) oder PPP Control Frames.
MAC Learning/Flaps: L2-Loops oder MAC-Flapping führen zu transienten Forwarding-Lücken.

Indiz: Flaps korrelieren mit Interface Errors/Discards oder Storm-Control Countern; einzelne Aggregationsknoten oder Ringe zeigen auffällige Ereignisse.

Ursachenklasse 3: BNG/BRAS Control Plane und Ressourcen

CPU/CoPP Saturation: PPP Control Frames werden gedrosselt, LCP Echos verlieren, Sessions resetten.
Session State Limits: Ressourcen knapp (Memory, TCAM/ACL slots, session table), was zu Drops oder fehlerhaften Terminations führt.
HA/Switchovers: Stateful Failover nicht vollständig → viele Sessions verlieren State und reconnecten.
Linecard/Process Events: Teilflaps: nur Sessions auf bestimmten Slots/Interfaces betroffen.

Indiz: Flaps sind BNG-spezifisch (ein Gerät/Chassis/Slot), oft gekoppelt mit CPU-Spikes, Prozess-Restarts oder Control-Plane Drops.

Ursachenklasse 4: AAA/RADIUS Latenz, Timeouts, Rejects

AAA-Probleme verursachen nicht nur „kein Login“, sondern können auch Flaps triggern, wenn Reauth/Accounting/Interim-Updates scheitern oder wenn neue Sessions nicht schnell genug autorisiert werden. RADIUS-Sicherheits- und Betriebsaspekte sind in RFC 5080 beschrieben.

RADIUS RTT hoch: BNG wartet, Timeouts treten auf, CPE reconnectet.
Reject-Spikes: Policy-/Profil-Fehler, Realm-Mapping, Vendor-Attribute-Probleme.
Accounting Backpressure: Ressourcen werden gebunden, wenn Accounting nicht bestätigt wird (implementierungsabhängig).

Indiz: RADIUS timeouts/retransmits steigen zeitgleich mit PPPoE reconnect rate; Flaps sind oft breit verteilt, nicht nur regional.

Ursachenklasse 5: Core/Backbone Ereignisse (indirekter Trigger)

Der Core verursacht PPPoE Flaps selten direkt, kann aber indirekt Trigger setzen: FRR/IGP-Konvergenz erzeugt Mikroverlust/Jitter-Spikes; TE-Änderungen verschieben Traffic; Congestion auf Uplinks führt zu Control-Plane-Loss, der LCP-Echos trifft.

FRR/Convergence Transienten: kurze Loss-Spikes, die aggressive LCP-Parameter auslösen.
Congestion: Queue Drops treffen Control Traffic (wenn QoS falsch ist).
Path Drift: neue Pfade mit anderer MTU oder anderer Qualität führen zu sporadischen Control Drops.

Indiz: Flaps korrelieren mit Backbone-Events (Link fails, TE shifts) und mit Queue Drops auf Uplinks.

Messlogik: Flaps quantifizieren, bevor Sie handeln

Eine gute Diagnose beginnt damit, das Phänomen messbar zu machen. Zwei Kennzahlen sind besonders hilfreich: Flap-Rate und gleichzeitige Reconnect-Wellen.

Flap-Rate (MathML)

$FlapRate = \frac{session_resets}{time_window}$

Wellen-Indikator: Anteil gleichzeitig betroffener Sessions (MathML)

$WaveShare = \frac{sessions_flapped_in_window}{sessions_active}$

Ein hoher WaveShare spricht eher für ein Infrastrukturereignis (Aggregation/BNG/AAA/Core) als für individuelle CPE-Probleme.

Runbook: Diagnose von Access bis Core

Dieses Runbook ist so aufgebaut, dass Sie in der Incident-Triage schnell zur richtigen Ursacheklasse kommen. Es ist bewusst vendorneutral, fokussiert aber auf die Reihenfolge der Nachweise.

Schritt 1: Scope bestimmen (regional, BNG-spezifisch, global)

Nach Region/Access-Domain gruppieren: sind Flaps in einem Ring/OLT/DSLAM-Cluster konzentriert?
Nach BNG/Slot gruppieren: treffen Flaps primär ein Chassis oder bestimmte Linecards?
Nach Access-Typ: PPPoE über DSL vs. FTTx kann unterschiedliche Fehlerbilder haben.

Schritt 2: PPPoE Discovery und PPP Control als Signalquelle nutzen

PADI/PADO Rate: PADI-Spike ohne passende PADO kann auf L2-Forwarding/Filter hindeuten.
PADR/PADS Rate: wenn PADS ausbleibt, ist der Session-Establish blockiert (BNG/AAA/L2).
LCP Events: LCP Echo Failure/Timeouts deuten auf Paketverlust/Jitter oder CoPP hin.

Schritt 3: Access/Aggregation prüfen

Interface Health: CRC/FEC, Discards, Queue Drops auf Access-Uplinks und Aggregation.
LAG per-member: einzelne Member mit Errors? Hash-bedingte selektive Flaps möglich.
Storm-Control Counters: Hits während Flap-Wellen? Thresholds zu niedrig?
MAC Flaps: L2-Loop-Indizien, ungewöhnliche MAC-Moves.

Schritt 4: BNG/BRAS Ressourcen und Control Plane

CPU und CoPP: steigen Drops/Policer Hits für PPPoE/PPP Control?
Session Table Health: Ressourcenlimits, Fehlermeldungen wie „no resources“ oder „stale session“.
HA/Process Events: Switchover, Prozess-Restarts, Linecard-Resets im Zeitfenster.

Schritt 5: AAA/RADIUS Korrelation

RADIUS RTT (p95/p99): steigen Response-Zeiten parallel zu Reconnects?
Timeout/Reject Rate: Timeouts deuten auf Overload/Netzprobleme, Rejects auf Policy/Profil.
Retransmits: steigende Retransmits sind ein Warnsignal für bevorstehende Mass-Reauth.

Schritt 6: Core-Events als Trigger prüfen

FRR/IGP Events: gab es Link-Fails oder Convergence-Spikes im Zeitfenster?
Uplink Congestion: Queue Drops auf BNG-Uplinks können PPP Control Traffic treffen (QoS prüfen).
TE Shifts: Traffic Engineering Änderungen können Pfadqualität kurzfristig verschlechtern.

Mitigation: PPPoE Flaps schnell stabilisieren

Im Incident gilt: erst stabilisieren, dann optimieren. Folgende Maßnahmen sind praxiserprobt, müssen aber im eigenen Netz als Runbook vorbereitet sein.

Mitigation 1: Mass-Reconnect verhindern (Rate-Limits, Backoff)

Session Admission Control: begrenzen, wie viele neue PPPoE Sessions pro Sekunde angenommen werden.
PPPoE Discovery Rate Control: PADI-Storms eindämmen, ohne legitimen Traffic zu blocken.
AAA schützen: RADIUS Requests drosseln/queueing, damit AAA nicht kollabiert.

Mitigation 2: LCP Echo Parameter realistisch wählen

Zu aggressive LCP Echo Settings sind eine häufige Ursache für Flaps bei kurzen Transienten. Ziel ist, kurze Mikroverlust- oder FRR-Events zu tolerieren, ohne echte Ausfälle zu verschleiern.

Praxisregel: Echo-Interval und Failure-Threshold so wählen, dass Failover-Transienten nicht sofort als Session-Down interpretiert werden.
Wichtig: Parameter müssen mit FRR/Convergence-Zielen und Access-Qualität harmonieren.

Mitigation 3: QoS/CoPP für PPPoE/PPP/RADIUS sicherstellen

Control Traffic priorisieren: PPPoE/PPP Control Frames und RADIUS dürfen nicht in Default-Queues ersticken.
CoPP gezielt: nicht „alles ICMP/UDP“ pauschal drosseln, wenn PPPoE/RADIUS betroffen sind.

Mitigation 4: Defekte Teilpfade isolieren

LAG-Member entfernen: wenn ein Member degradiert ist, gezielt herausnehmen.
Access Fault Domain trennen: betroffene Ringe/Nodes isolieren, um globale Wellen zu vermeiden.
Storm-Control Thresholds anpassen: legitime PPPoE Peaks während Recovery müssen berücksichtigt werden.

Evidence Pack: Pflichtdaten für RCA und Eskalation

Zeitlinie (UTC): Start, Peak, Mitigation, Stabilisierung, Recovery-Ende.
Scope: betroffene Regionen/Access-Domains, betroffene BNGs/Slots, Anteil der Sessions.
PPPoE/PPP Signale: PADI/PADO/PADR/PADS Raten, LCP Echo Failures, Termination Reasons.
BNG Ressourcen: CPU, CoPP drops, session table errors, HA/Process Events.
AAA Daten: RADIUS RTT p95/p99, timeout/reject rate, requests/sec, retransmits.
Aggregation/Access Telemetrie: per-link/per-member Errors/Drops, storm-control hits, MAC flaps.
Core Korrelation: FRR/IGP Events, uplink congestion, TE changes.

Outbound-Ressourcen

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.