PPPoE-Session-Flaps: Diagnose von Access bis Core

Das Hauptkeyword „PPPoE-Session-Flaps: Diagnose von Access bis Core“ beschreibt ein klassisches, aber operativ anspruchsvolles Störungsbild in Provider-Netzen: PPPoE-Sessions bauen sich scheinbar zufällig auf und ab, Kunden melden kurze Unterbrechungen, und im NOC entstehen viele einzelne Tickets, obwohl die eigentliche Ursache oft zentral ist. Ein „Session-Flap“ kann dabei von Sekundenbruchteilen (kurzer Link-Drop) bis zu Minuten (Reauth-Loop, Control-Plane-Störung) reichen. Die Herausforderung liegt weniger im Protokoll selbst als in der End-to-End-Kette: vom CPE/ONT über DSLAM/OLT, Aggregation (BNG/BRAS), AAA/RADIUS, IP-Core bis hin zu Überwachungs- und Policy-Systemen. Wer PPPoE-Flaps nur auf einem Gerät betrachtet, übersieht häufig das Muster – und verliert wertvolle Zeit. Eine saubere Diagnose folgt daher einer Methode: klare Abgrenzung des Symptoms (wer, wann, wie oft), korrelierte Telemetrie (L1/L2 vs. PPP vs. AAA), reproduzierbare Tests und ein strukturierter „Narrowing“-Prozess, der die Fault Domain schnell eingrenzt. In diesem Artikel erhalten Sie eine praxisorientierte Checkliste, wie Sie PPPoE-Session-Flaps im großen Maßstab untersuchen – vom Access bis zum Core – und wie Sie typische Ursachen (Line Instability, VLAN/QinQ-Probleme, BNG-Überlast, RADIUS-Latenz, MTU/MRU-Mismatches, Interim-Accounting-Fehler oder Policy-Änderungen) sicher voneinander unterscheiden.

PPPoE-Session-Flaps verstehen: Was flapt eigentlich?

„PPPoE“ ist nicht gleich „Internet“. Eine Session umfasst mehrere Phasen und Abhängigkeiten: Discovery (PADI/PADO/PADR/PADS), PPP-Session (LCP, Authentifizierung via PAP/CHAP/EAP), IP-Parameter (IPCP/IPv6CP) und die Anbindung an AAA/Policy/Accounting. Ein Flap kann in jeder Phase entstehen – und die Gegenmaßnahme hängt davon ab, ob es sich um ein physisches Problem, ein Layer-2-Problem, ein Control-Plane-Problem oder ein Policy-/AAA-Problem handelt.

• Discovery-Flaps: Session kommt gar nicht zustande oder bricht in der Discovery-Phase ab (häufig L2/VLAN/Access).
• LCP-Flaps: PPP startet, fällt aber durch LCP-Rejects, LCP-Timeouts oder Keepalive-Probleme auseinander.
• Auth/AAA-Flaps: PPP steht kurz, dann Abbruch durch Auth-Failure, RADIUS-Timeout oder Policy-Reject.
• IPCP/IPv6CP-Flaps: Auth ok, aber IP-Phase scheitert (Adresspool, Optionen, MTU/MRU, Dual-Stack-Interaktion).
• Session-Reset bei Laufzeit: Session steht, bricht aber periodisch ab (Line Drops, BNG-Resets, AAA-Interims, CoA, Reauth).

Symptom sauber definieren: Ohne Messrahmen keine Diagnose

Bevor Sie Geräte-Logs wälzen, definieren Sie die Flap-Signatur. Ein einzelner Kunde kann immer „lokal“ sein. Ein Massenereignis ist fast nie lokal. Entscheidend sind Umfang, Periodik und Korrelation.

• Scope: betrifft es einzelne Anschlüsse, ein Access-Segment, einen BNG, eine Region, einen Wholesale-Partner?
• Periodik: exakt alle X Minuten (Interim-Accounting, Reauth-Timer, DHCPv6-PD-Renew, Policy-Jobs) vs. zufällig (L1/EMI, Kontaktprobleme).
• Dauer: Sekunden (L1 Blips) vs. 30–120 Sekunden (PPP-LCP/AAA Retries) vs. Minuten (Backoff, Reauth-Loops).
• Begleitmetriken: CRC/LOS, Ethernet-Errors, BNG CPU, RADIUS RTT, Drops, Queueing.

Flap-Rate als operative Kennzahl

Für Priorisierung und Trendanalyse hilft eine einfache Flap-Rate pro Anschlussgruppe oder BNG. Das ist keine perfekte Wissenschaft, aber ein belastbarer Vergleichswert.

$\mathrm{FlapRate}=\frac{\mathrm{SessionDrops}}{\mathrm{ObservedTime}}$

Ergänzend ist die „Mean Time Between Flaps“ (MTBF) hilfreich, um periodische Muster zu erkennen.

$\mathrm{MTBF}=\frac{\mathrm{ObservedTime}}{\mathrm{SessionDrops}}$

Access-Diagnose: L1/L2 zuerst, bevor Sie PPP „beschuldigen“

Ein großer Teil der PPPoE-Flaps entsteht durch instabile physische oder Layer-2-Bedingungen im Access: DSL/Vectoring-Störungen, fehlerhafte ONT/Optik, defekte Patchkabel, sporadische Stromversorgung, aber auch VLAN- oder QinQ-Fehler in Aggregationspfaden. Der wichtigste Grundsatz: Wenn L1/L2 wackelt, wird PPP nur die Folge sein.

• DSL: SNR-Margin, FEC/CRC, Retrains, SES/ES, Vectoring-Fehlerbilder.
• FTTH: Optische Pegel, LOS/LOF, Rx/Tx-Drift, Temperaturkorrelation, PON-Events.
• Ethernet (CPE/ONT-Uplink): Link flaps, Duplex/Speed-Mismatch, FCS/Alignment Errors.
• VLAN/QinQ: falsche Outer/Inner VLANs, Tag-Stripping, MTU für PPPoE nicht berücksichtigt.

PPPoE-over-Ethernet und MTU/MRU: Der „stille“ Flap-Auslöser

PPPoE hat Overhead. Wenn im Pfad eine zu kleine MTU oder ein inkonsistenter MRU-Wert wirkt, können bestimmte Pakete fragmentiert oder verworfen werden. Das führt nicht immer zu Total-Ausfall, aber zu LCP-Timeouts, Retries und scheinbar „zufälligen“ Abbrüchen – besonders bei Last oder bestimmten Anwendungen. Für Grundlagen zu PPP ist RFC 1661 relevant; PPPoE selbst ist in RFC 2516 beschrieben.

• Indikatoren: Abbrüche unter Last, Probleme bei bestimmten Services, wiederkehrende LCP Echo Failures.
• Mitigation: MTU im Access/Aggregation konsistent planen, MSS-Clamping nur gezielt und nachvollziehbar einsetzen.

Aggregation und BNG/BRAS: Control Plane ist oft der Engpass

Wenn viele PPPoE-Sessions gleichzeitig flappen oder Reconnects in Wellen auftreten, ist der BNG/BRAS ein zentraler Verdächtiger – nicht zwingend als Ursache, aber als Verstärker. Control-Plane-Überlast, Memory-Pressure, Prozess-Restarts, Linecard-Probleme oder Queueing zwischen Linecards und Control-Plane können Flaps auslösen oder verlängern. Auch häufige AAA-Anfragen und Accounting können die Plattform kippen, wenn Peaks nicht abgefedert werden.

• BNG-CPU/Memory: Spikes bei Session-Rebuild, Garbage Collection, Prozess-Resets.
• Session-Scale Limits: harte Limits (Sessions/Subscriber), Soft Limits (Lookup-Latenz), Lizenzgrenzen.
• Linecard/DP-Errors: Drops, Buffer-Exhaustion, Microbursts.
• Keepalive/Timers: aggressive LCP Echo-Settings können bei transienten Störungen Flaps erzeugen.

Wellenförmige Flaps: „Kaskade“ statt Einzelproblem

Ein häufiges Muster sind „Reconnect-Stürme“: Ein kurzer Access- oder Core-Event trennt viele Sessions; der anschließende gleichzeitige Reconnect überlastet BNG und AAA; daraus wird ein längeres Incident. Das ist operativ wichtig, weil die Gegenmaßnahme nicht „mehr Debugging“, sondern Lastglättung ist.

• Mitigation: Reconnect-Backoff/Randomisierung, Session-Rate-Limits, stabile AAA-Kapazität, Headroom im BNG.
• Nachweis: zeitliche Korrelation: erst Link/IGP-Event, dann AAA-Spike, dann Session-Rejects.

AAA/RADIUS: Latenz und Timeouts als Flap-Treiber

PPPoE-Umgebungen hängen für Authentifizierung, Autorisierung und Accounting häufig an RADIUS. Schon moderate Latenzspitzen können in der Praxis Flaps auslösen, wenn Timeouts knapp sind oder Retry-Mechanismen gleichzeitig auf vielen BNGs greifen. Typisch ist auch: Die Auth klappt noch, aber Accounting oder Interim-Updates führen zu unerwarteten Disconnects, wenn Policies „Accounting required“ erzwingen oder wenn CoA/Disconnect-Requests falsch getriggert werden. Eine gute Grundlage zu RADIUS ist RFC 2865 (Authentication) und RFC 2866 (Accounting).

• RADIUS RTT: p95/p99 statt Durchschnitt beobachten; Burst-Latenzen sind entscheidend.
• Timeout/Retry: zu kurze Timeouts erzeugen unnötige Retries; zu lange verschleppen Session-Establishment.
• Interim Accounting: periodische Peaks können exakt periodische Flaps erzeugen, wenn Systeme überlasten.
• CoA/Disconnect: Fehlkonfigurationen in Policy-Systemen können massenhaft Sessions trennen.

Periodische Flaps: Interim-Accounting und Reauth als Fingerabdruck

Wenn Flaps bei vielen Kunden in nahezu identischen Intervallen auftreten (z. B. alle 5, 10, 15 oder 30 Minuten), ist das ein starker Hinweis auf Timer-getriebene Mechanismen: Interim-Accounting, Reauthorization, Quota-Checks oder externe Policy-Jobs. In solchen Fällen ist die schnellste Diagnose nicht „Access messen“, sondern die Timer-Kette zwischen BNG und AAA/PCRF/Policy-Systemen zu prüfen.

IP-Core und Transport: Wenn PPPoE „Opfer“ von Routing-Events wird

PPPoE selbst läuft über L2-Transport bis zum BNG. Dennoch kann das Core-Netz indirekt Flaps auslösen: IGP-Konvergenz, BFD-Settings, ECMP-Umschaltungen, MPLS-Transportprobleme oder Control-Plane-Protection, die Management- oder AAA-Traffic beeinträchtigt. Der Klassiker: PPP bleibt technisch stabil, aber AAA wird unerreichbar, Logging/Accounting staut sich, und Policies triggern Disconnects.

• IGP/BFD-Events: kurze Loss-Spikes, die LCP Echo als „Down“ interpretiert.
• QoS/CoPP: AAA/Control-Traffic wird gedrosselt, wenn Schutzprofile zu aggressiv sind.
• Path-Asymmetry: besonders relevant, wenn AAA oder Management über separate VRFs/Paths läuft.
• Transport-MTU: MTU-Inkonsistenzen in MPLS/Metro können PPPoE-Overhead indirekt treffen.

Diagnose-Workflow: Von Access bis Core in klaren Schritten

Ein wiederholbarer Workflow reduziert MTTR und verbessert Ticketqualität. Wichtig ist, dass Sie die Reihenfolge einhalten: erst Scope und Muster, dann Layer-Checks, dann tiefe Protokolldetails. So vermeiden Sie, sich in Einzelfällen zu verlieren.

• Schritt 1 – Scope bestimmen: Welche BNGs, Access-Segmente, Regionen, Wholesale-Partner sind betroffen?
• Schritt 2 – Zeitliche Korrelation: Flaps im gleichen Zeitfenster? Gibt es Peaks bei AAA oder BNG CPU?
• Schritt 3 – L1/L2 prüfen: Link-Flaps, Optik/DSL-Fehler, VLAN/QinQ-Anomalien, Error Counter.
• Schritt 4 – PPP-Phase lokalisieren: Discovery vs. LCP vs. Auth vs. IPCP/IPv6CP.
• Schritt 5 – AAA validieren: RADIUS RTT, Timeouts, Reject-Gründe, CoA/Disconnect-Spuren.
• Schritt 6 – Core/Policy prüfen: Routing-Events, CoPP, QoS, Reachability AAA/Policy-Cluster.
• Schritt 7 – Mitigation priorisieren: Stop-the-bleed (Stabilität) vor Root Cause (dauerhafte Fixes).

PPPoE-Discovery-Probleme: Wenn PADI/PADO im Nirvana verschwinden

Discovery-Probleme sind häufig L2-getrieben: VLAN-Mapping, QinQ-Translation, MAC-Learning, L2-Loops, Storm-Control oder falsch konfigurierte Access-Ports. In großen Access-Netzen sind flächige Discovery-Ausfälle oft Indikatoren für eine einzelne Fehlkonfiguration in Aggregation oder ein L2-Loop-Ereignis, das MAC-Tabellen und Flooding-Verhalten verändert.

• Indikatoren: viele „kein PADO“/„no service-name“/„timeout waiting for PADS“ Meldungen, gleichzeitig erhöhte Broadcast/Unknown-Unicast.
• Mitigation: L2-Loop-Containment, Storm-Control sauber tunen, VLAN-Übersetzungen standardisieren.

LCP Echo, Keepalives und False Positives: Wenn „zu aggressiv“ wie „instabil“ aussieht

Viele Betreiber setzen LCP Echo-Mechanismen ein, um Dead Sessions schnell zu erkennen. Das ist sinnvoll, kann aber bei transientem Loss oder CPU-Spikes zu False Positives führen: Die Session wird getrennt, obwohl der Pfad nach kurzer Zeit wieder stabil ist. Das Ergebnis sind Flaps, die wie Access-Probleme aussehen, aber durch Timer-Policy verursacht sind.

• Indikatoren: Abbrüche ohne L1/L2-Fehler, korrelieren mit CPU-Spikes oder Core-Microbursts.
• Mitigation: Echo-Intervalle/Retry-Count an reale Loss-Profile anpassen, nicht „maximal aggressiv“ konfigurieren.

Dual-Stack-Realitäten: IPv6CP, Prefix Delegation und „Hidden Flaps“

In Dual-Stack-Umgebungen kann die PPPoE-Session formal stehen, aber IPv6 bricht weg (oder umgekehrt). Kunden melden dann „Internet instabil“, obwohl die IPv4-Session ok ist. Ursache sind oft inkonsistente IPv6CP-Optionen, Prefix Delegation-Prozesse, AAA-Attribute oder Interaktionen mit CPE-Firmware.

• Indikatoren: IPv6-only Apps betroffen, IPv4-Tests ok; häufige PD-Renews oder RA/ND-Anomalien hinter dem CPE.
• Mitigation: IPv4/IPv6 getrennt instrumentieren, AAA-Attribute konsistent halten, CPE-Interoperabilität testen.

Mass-Mitigation im Incident: Stabilität herstellen, ohne neue Probleme zu erzeugen

Wenn Flaps massenhaft auftreten, zählt zuerst Stabilisierung. Die Kunst ist, kurzfristige Maßnahmen so zu wählen, dass sie nicht die Root-Cause-Analyse zerstören oder Folgeschäden verursachen (z. B. noch größere Reconnect-Stürme). Typische Sofortmaßnahmen adressieren Rate, Headroom und die kritischsten Abhängigkeiten.

• Reconnect-Rate dämpfen: Session-Rate-Limits oder Backoff, um BNG/AAA zu entlasten.
• AAA priorisieren: QoS/CoPP so anpassen, dass RADIUS/Policy-Traffic nicht im Schutzprofil untergeht.
• BNG Headroom sichern: nichtkritische Prozesse/Telemetry reduzieren, wenn Plattform am Limit ist (kontrolliert und dokumentiert).
• Access-Fault Domain isolieren: betroffene Segmente gezielt identifizieren und eingrenzen, statt „alles“ zu resetten.

RCA-fähige Beweise sammeln: Was in Tickets und Postmortems stehen muss

Ein sauberes Incident-Write-up zu PPPoE-Session-Flaps ist mehr als „Sessions droppten“. Für nachhaltige Fixes brauchen Sie Beweise, die eine eindeutige Ursache stützen und Wiederholungen verhindern: Zeitlinie, betroffene Domains, Korrelationen und klare „Why“-Kette.

• Zeitlinie: erster Drop, Peak, Stabilisierung, vollständige Erholung.
• Fault Domain: Access (DSL/FTTH), Aggregation (VLAN/QinQ), BNG (Control Plane), AAA (RADIUS), Core (IGP/QoS).
• Korrelation: Session-Drops vs. L1/L2-Errors, BNG CPU, RADIUS RTT, Routing-Events.
• Konkreter Trigger: Config Change, Software-Bug, Kapazitätslimit, Fiber Event, Policy-Job, Timer-Mismatch.
• Mitigation & Follow-ups: kurzfristige Maßnahmen, dauerhafte Fixes, Monitoring-Verbesserungen.

Outbound-Links zu relevanten Standards und Referenzen

• RFC 2516: A Method for Transmitting PPP Over Ethernet (PPPoE)
• RFC 1661: The Point-to-Point Protocol (PPP)
• RFC 2865: Remote Authentication Dial In User Service (RADIUS)
• RFC 2866: RADIUS Accounting
• Broadband Forum TR-101: Migration to Ethernet-Based DSL Aggregation

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.