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.

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 = session_resets time_window

Wellen-Indikator: Anteil gleichzeitig betroffener Sessions (MathML)

WaveShare = 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

• RFC 2516 (PPPoE)
• RFC 2865 (RADIUS Authentication)
• RFC 2866 (RADIUS Accounting)
• RFC 5080 (RADIUS Security Issues and Best Practices)
• RFC 1661 (PPP: The Point-to-Point Protocol, LCP/NCP Grundlagen)
• RFC 5880 (BFD: Failure Detection, relevant für Transienten)

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.