February 21, 2026

BNG/BRAS Session Issues: Warum Mass-Reauth passiert und Mitigation

BNG/BRAS Session Issues gehören zu den kritischsten Störungsbildern in Access-Netzen, weil sie nicht „nur“ einzelne Kunden betreffen, sondern sehr schnell in eine Mass-Reauth-Situation kippen können: Tausende bis Millionen Teilnehmer verlieren gleichzeitig ihre Session, starten eine Neuautorisierung (PPPoE/PPP oder IPoE/DHCP), und erzeugen dadurch eine Lastwelle, die BNG, RADIUS/AAA, DHCP, Aggregation und sogar das Backbone unter Druck setzt. Für Kunden sieht das wie ein großflächiger Internet-Ausfall aus, oft begleitet von kurzen Wiederkehrern („es geht wieder, dann wieder weg“), hoher Latenz und massiven Paketverlusten. Operativ ist Mass-Reauth besonders gefährlich, weil es einen selbstverstärkenden Effekt erzeugt: Je mehr Sessions neu aufgebaut werden, desto mehr steigt die Signalisierungslast; je höher die Last, desto mehr Timeouts und Retries treten auf; je mehr Retries, desto mehr Sessions fallen erneut. Wer BNG/BRAS betreibt, muss deshalb verstehen, warum Mass-Reauth passiert, wie man die Ursachen sauber trennt (Control Plane, AAA, Access, State/Chassis, Timing) und welche Mitigation-Mechanismen zuverlässig funktionieren. Dieser Artikel erklärt die häufigsten Auslöser von Mass-Reauth, typische Symptome und eine praxistaugliche Mitigation- und Diagnose-Checkliste, mit der NOC-Teams schneller stabilisieren, den „Second Outage“ verhindern und langfristig die Widerstandsfähigkeit des Access-Stacks erhöhen.

Table of Contents

BNG/BRAS und „Session“: Wovon wir operativ sprechen

BNG (Broadband Network Gateway) bzw. BRAS (Broadband Remote Access Server) ist der zentrale Session-Anker im Breitbandzugang. Abhängig von der Access-Architektur entstehen Sessions typischerweise über:

PPPoE/PPP: PPPoE Discovery + PPP LCP/NCP, anschließend AAA-Autorisierung (häufig RADIUS) und Accounting.
IPoE (DHCP-basiert): DHCPv4/DHCPv6 (ggf. Prefix Delegation), oft kombiniert mit RADIUS oder DHCP-Optionen für Policy und Accounting.

Gemeinsam ist beiden Varianten: Eine Session ist nicht nur eine IP-Adresse, sondern ein Bündel aus Zustand (State) und Policy: Benutzeridentität, Serviceprofil (Speed, QoS, ACL), Accounting, ggf. CGNAT-Zuordnung und Bindung an Access-Port/VLAN/Line-ID. Wenn dieser Zustand verloren geht oder ungültig wird, folgt Reauth/Recreate.

Was „Mass-Reauth“ genau ist

Von Mass-Reauth spricht man, wenn innerhalb kurzer Zeit ein großer Anteil der aktiven Sessions neu autorisiert oder neu aufgebaut wird. Das kann bewusst passieren (geplante Wartung, Policy-Rollout), tritt aber in Störungen oft ungewollt auf. Operativ relevant ist die Differenzierung:

Mass-Reauth (kontrolliert): Sessions werden schrittweise reauthentifiziert, mit Rate-Limits und stabiler AAA-Kapazität.
Mass-Reauth (unkontrolliert): Session-Reset- oder Timeout-Welle erzeugt Lastspitzen, Retries und Kaskadeneffekte.

Typische Symptome: Wie Mass-Reauth im NOC aussieht

Session Counter „sägezahnartig“: aktive Sessions fallen abrupt, steigen dann wieder, ggf. in Wellen.
AAA-Latenz steigt: RADIUS-Response-Zeiten gehen hoch, Timeouts nehmen zu.
Access-Signalisierung explodiert: PPPoE Discovery, DHCP Discover/Request, DHCPv6 Solicit/Request steigen stark.
CPU/Control Plane Spikes: BNG CPU, CoPP/Policer Drops, Prozess-Watchdogs, Control-Plane-Queues füllen sich.
Kundensicht: kurze Disconnects, neue IPs, wiederholte PPPoE Reconnects, VoIP bricht, IPTV freeze, Gaming Disconnects.

Warum Mass-Reauth passiert: Die häufigsten Ursachenklassen

Die meisten Mass-Reauth-Events lassen sich in wenige Ursachenklassen einordnen. Das hilft, im Incident nicht „alles gleichzeitig“ zu debuggen.

Ursachenklasse 1: AAA/RADIUS-Probleme (Timeouts, Overload, Policy-Fehler)

AAA ist oft der Engpass. Wenn RADIUS nicht schnell genug antwortet, laufen Timer ab, und Sessions werden abgewiesen oder fallen zurück in Retry-Schleifen. RADIUS-Grundlagen sind in RFC 2865 (Authentication) und RFC 2866 (Accounting) beschrieben.

RADIUS-Latenz/Timeout: Datenbank-Latenz, Overload, Netzwerkprobleme, Paketverlust, zu aggressive Retransmits.
Policy-Change-Fehler: neue Attribute/Profiles führen zu Rejects oder zu unerwarteten Session-Terminations.
Accounting-Backpressure: wenn Accounting-Records nicht verarbeitet werden, blockieren manche Implementierungen Ressourcen.
Shared Secret/Port/ACL-Fehler: nach Change sind Requests „still“ geblockt, die Session-Engine läuft in Timeouts.

Ursachenklasse 2: Session-State-Verlust am BNG (Reload, Linecard, HA-Failover)

BNGs sind stateful Systeme. Ein Chassis-Reload, Prozess-Crash, Linecard-Reset oder fehlerhaftes HA-Failover kann Session-State verlieren. Je nach Design (In-Service Software Upgrade, Stateful Switchover, Redundancy Group) ist das normal oder kritisch.

Plötzlicher Drop vieler Sessions: klassisch bei Control-Plane-Event oder HA-Switchover ohne vollständigen State-Sync.
Teilweiser State-Verlust: nur Sessions auf bestimmten Linecards/Interfaces/VRFs betroffen.
Stale State und Doppelzustände: BNG glaubt, Sessions existieren, Kunden reconnecten aber; führt zu Konflikten („duplicate session“, „stuck sessions“).

Ursachenklasse 3: Access-/Aggregation-Ereignisse (OLT/DSLAM/BNG Uplink, VLAN/QinQ)

Ein Access-Event kann wie ein BNG-Problem aussehen. Wenn VLANs flappen, LAG-Members Fehler haben oder QinQ/Tagging falsch ist, gehen Discovery/Keepalives verloren, und Sessions werden neu aufgebaut.

PPPoE PADI/PADO Storms: typischer bei Layer-2-Instabilität oder falschem Forwarding im Aggregationsnetz.
DHCP Retries: DHCP Discover/Request Wiederholungen steigen, weil Replies nicht zurückkommen.
MAC-Learning-/Storm-Control: falsche Thresholds können legitime Session-Signalisierung drosseln.

Ursachenklasse 4: Timer- und Keepalive-Fehlkonfiguration (PPPoE, PPP, DHCP)

Zu aggressive Timer sind ein klassischer Auslöser für „flappy sessions“. Beispiele:

PPPoE/PPP: LCP Echo-Interval/Echo-Failure zu niedrig → kurzfristige Loss-Spikes werden als Link-Down interpretiert.
DHCP: kurze Lease Times plus Ausfälle bei Renew-Replies → Mass-Renew- und Rebind-Wellen.
Interaktion mit FRR/ECMP: kurzzeitige Konvergenz-/Rehash-Transienten können Timer triggern.

Für DHCPv4 ist RFC 2131 eine Referenz, für DHCPv6 RFC 3315. PPPoE wird in RFC 2516 beschrieben.

Ursachenklasse 5: IP-Address-Management und Pools (IPoE/DHCP, CGNAT, PD)

Wenn IP-Pools knapp werden oder Prefix Delegation inkonsistent ist, kann das Reauth-Wellen verstärken: Kunden reconnecten, bekommen keine Adresse, retryen aggressiv. Bei CGNAT kann zusätzlich Port-Allocation-Pressure entstehen.

Pool Exhaustion: DHCP vergibt keine Leases mehr oder BNG kann keine Address Bindings anlegen.
PD-Probleme: IPv6 Prefix Delegation ändert sich, CPEs reagieren mit Neustarts oder langen Recovery-Zeiten.
Stale Leases: Address-Release/Accounting hängt, Pools „sehen leer aus“, sind aber blockiert.

Der Kaskadeneffekt: Warum Mass-Reauth sich selbst verstärkt

Mass-Reauth eskaliert oft durch Rückkopplung. Drei Mechanismen sind besonders typisch:

Retry-Backoff zu aggressiv: CPEs und BNGs senden Retries zu schnell, statt sich zu beruhigen.
AAA wird zum Bottleneck: erhöhte RADIUS-Last erhöht Latenz, was mehr Timeouts auslöst.
Control Plane Saturation: BNG CPU/CoPP drosselt Control-Traffic, wodurch noch mehr Protokoll-Timeouts entstehen.

Einfaches Kapazitätsmodell für Reauth-Rate-Limit (MathML)

$ReauthRate \leq \frac{AAA_capacity}{Requests_per_session}$

Die Idee ist pragmatisch: Wenn Ihre AAA-Infrastruktur pro Sekunde nur eine bestimmte Anzahl Requests zuverlässig beantworten kann, müssen Sie die maximale Reauth-Rate darunter halten. Andernfalls produziert das System durch Timeouts und Retries mehr Last als es verarbeiten kann.

Diagnose-Runbook: „Mass-Reauth“ in Minuten klassifizieren

Ein praxistaugliches Runbook trennt zuerst „BNG vs. AAA vs. Access“ und priorisiert Stabilisierung vor Detailanalyse.

Schritt: Scope und Zeitfenster

Wie viele Sessions? Anteil betroffen, über welche BNGs/PoPs/Linecards?
PPPoE oder IPoE? Unterscheidung der Protokollsignale (PADI/PADO vs. DHCP Discover/Solicit).
Startzeit vs. Change: Korrelation mit Maintenance, Policy-Deploy, AAA-Update, Backbone-Event.

Schritt: AAA-Signale prüfen

RADIUS RTT/Timeouts: steigen Response-Zeiten? nimmt Timeout-Rate zu?
Reject-Rate: nehmen Access-Rejects zu (Policy/Profilfehler) oder nur Timeouts?
Queue/Worker Saturation: sind AAA-Worker ausgelastet, DB-Backends langsam?

Schritt: BNG-Control-Plane prüfen

CPU/Memory: Spikes, GC/Process-Reset, Control-Plane Queue Drops.
HA Events: Switchover, Linecard Reset, Prozess-Restarts im Zeitfenster.
Session Errors: „duplicate session“, „stale session“, „no resources“.

Schritt: Access-/Aggregation-Indizien prüfen

Uplink Errors/Flaps: LAG-Member, CRC/FEC, Discards, Storm-Control Events.
VLAN/QinQ Events: Tagging-Änderungen, MAC-Flaps, Broadcast-Storm-Indizien.
Regionale Häufung: nur bestimmte OLTs/DSLAMs/Access-Ringe betroffen?

Mitigation: Wie Sie Mass-Reauth schnell stabilisieren

Die erste Priorität im Incident ist nicht „perfekte RCA“, sondern das Stoppen der Lastwelle. Bewährte Mitigation-Maßnahmen sind:

Mitigation 1: Rate-Limiting und Backoff erzwingen

Session Admission Control: begrenzen, wie viele neue Sessions pro Sekunde am BNG angenommen werden.
AAA Request Rate: RADIUS-Requests pro NAS/Realm drosseln, um AAA nicht zu überfahren.
Retry-Backoff erhöhen: Timer so anpassen, dass Retries nicht in Sekundenbruchteilen eskalieren.

Wichtig: Rate-Limiting ist eine Notbremse. Es verlängert die Recovery, verhindert aber, dass das System durch Selbstüberlastung kollabiert.

Mitigation 2: AAA entlasten (Sharding, Fallback, Priorisierung)

Traffic Shaping für AAA: kritische Realms/Services priorisieren (z. B. Business-Kunden vor Best-Effort).
Read-only Mode / Cache: falls vorhanden, temporär mit gecachten Policies arbeiten, um DB-Abhängigkeiten zu reduzieren.
RADIUS Path Redundanz: alternative AAA-Knoten aktivieren, Health-Checks prüfen, Load balancen.

Mitigation 3: Graceful Recovery statt „Alles wieder an“

Nach einer Stabilisierung ist der häufigste Fehler, die Drosselung abrupt zu entfernen. Das erzeugt den Second Outage. Besser ist ein kontrolliertes Hochfahren:

Stufenweise Re-Enable: Rate-Limits schrittweise erhöhen und nach jeder Stufe Stabilität prüfen.
Regional staffeln: PoP für PoP oder Access-Domain für Access-Domain, statt global.
KPIs als Stop-Kriterium: wenn AAA RTT oder Timeout-Rate wieder steigt, Stufe halten oder zurückrollen.

Mitigation 4: Timer-Korrektur und Schutz vor falschen Flaps

BFD/Keepalive-Tuning: bei flappy Access-Strecken Parameter weniger aggressiv setzen, um kurze Transienten zu tolerieren.
DHCP Lease Strategy: zu kurze Leases vermeiden, Renew/Retry-Strategie prüfen.
CoPP/ACL prüfen: Control-Plane darf für PPPoE/DHCP/RADIUS nicht unbeabsichtigt gedrosselt werden.

Mitigation 5: Session-State und HA gezielt absichern

Stateful Failover testen: regelmäßige Drills, um zu sehen, wie viele Sessions beim Switchover wirklich bleiben.
Session Sync Health: Monitoring für State-Sync-Latenz und Fehler, nicht nur „HA up“.
Rolling Changes: Upgrades und Linecard-Resets in kleinen Batches, nicht als Big Bang.

Messbarkeit und E-E-A-T: Welche Metriken Sie dauerhaft brauchen

Damit Mass-Reauth nicht erst über Kundentickets auffällt, braucht es dauerhafte Metriken und Baselines. Wichtig ist die Trennung nach PPPoE vs. IPoE und nach Region/BNG.

Sessions: active sessions, session create rate, session drop rate, duplicate/stale counters.
AAA: RADIUS RTT (p50/p95/p99), timeout rate, reject rate, requests/sec, retransmits.
DHCP: discover/offer/request/ack rates, lease allocation failures, PD failures (v6).
Access: PPPoE PADI/PADO rates, VLAN/MAC anomalies, storm-control hits.
Control Plane: CPU, CoPP drops, control-plane queue occupancy, process restarts.

Häufige Root-Causes in der Praxis und passende Gegenmaßnahmen

Die folgenden Root-Cause-Muster sind in Provider-Umgebungen besonders häufig und sollten als „Playbooks“ vorbereitet sein.

Muster: AAA langsam, Sessions flappen in Wellen

Ursache: Datenbank-/Backend-Latenz, AAA-Overload, RADIUS-Transportprobleme.
Gegenmaßnahme: Rate-Limit, AAA-Kapazität erhöhen/umleiten, Caching/Fail-open-Strategie (wo vertretbar), Retransmits reduzieren.

Muster: Nach Policy-Deploy massenhaft Rejects

Ursache: fehlerhafte Profile, fehlende Attribute, inkompatible Vendor-Attribute, falsche Realm-Mappings.
Gegenmaßnahme: Rollback der Policy, Canary-Rollouts, Validierung per Test-Realms, Reject-Alarmierung.

Muster: Nach BNG-HA-Event viele „stale sessions“ und Wiederanmeldungen

Ursache: State-Sync unvollständig, HA-Failover nicht stateful, Linecard-Scope größer als geplant.
Gegenmaßnahme: HA-Design prüfen, Session-Drain vor Maintenance, Recovery staffeln, State-Sync Monitoring.

Muster: Regionale Mass-Reauth nach Aggregation-Event

Ursache: L2-Instabilität, QinQ-Fehler, LAG-Member degradiert, MAC-/Storm-Control Limits.
Gegenmaßnahme: per-member Telemetrie, Storm-Control Thresholds realistisch setzen, Access-Change-Validation, gezieltes Isolieren der Fault Domain.

Evidence Pack: Pflichtdaten für Vendor-/Field-/Carrier-Eskalation

Zeitlinie (UTC): Start, Peak, erste Mitigation, Stabilisierung, Recovery-Ende.
Scope: betroffene BNGs/Linecards/PoPs, PPPoE vs. IPoE, v4/v6 getrennt.
AAA Daten: RTT/Timeout/Reject, Requests/sec, Backend-Latenzen, Retransmits.
Session Daten: create/drop rates, error counters (duplicate/stale/no resources).
Access Daten: PADI/PADO oder DHCP rates, VLAN/MAC Events, LAG member health.
Control Plane: CPU/CoPP drops, process restarts, HA events.

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.