Site icon bintorosoft.com

BNG/BRAS Placement: Topologie, Policy und Scale (Subscriber Sessions)

Red Snapper

BNG/BRAS Placement ist eine der wichtigsten Architekturentscheidungen in FTTH-, HFC- und DSL-Provider-Netzen, weil hier Transporttopologie, Service-Policy und Skalierung von Subscriber Sessions zusammenlaufen. Der Broadband Network Gateway (BNG) – oft historisch als BRAS bezeichnet – ist nicht „nur ein Router“, sondern die zentrale Servicekante für Zugangsdienste: Er terminiert PPPoE- oder IPoE/DHCP-Sessions, vergibt IP-Adressen (direkt oder über DHCP/AAA), setzt Produktprofile und QoS um, stellt Accounting/Logging bereit und lenkt Verkehr zu Internet-Exits, CGNAT, Security-Services und Wholesale-Übergaben. Genau deshalb ist die Frage „Wo steht der BNG?“ nicht trivial. Ein zentraler BNG-Cluster vereinfacht Betrieb und Tooling, kann aber Hairpinning, große Failure Domains und hohe Transportlast erzeugen. Regionale BNGs reduzieren Latenz, begrenzen Blast Radius und verbessern Störfallverhalten, erhöhen jedoch Anforderungen an Standardisierung, Automatisierung und Kapazitätsplanung. Zusätzlich wirkt Placement direkt auf Scale: Session-Counts, Control-Plane-Last, Tabellenlimits, DHCP/PPPoE-Eventraten und die Fähigkeit, DDoS, Prefix-Changes oder Maintenance ohne Kundenimpact zu verkraften. Dieser Artikel zeigt praxisnah, wie Telcos BNG/BRAS topologisch platzieren, welche Policy- und Routingmuster sich bewährt haben und wie man Subscriber-Scale (Sessions) so plant, dass Wachstum nicht zur Komplexitäts-Explosion wird.

BNG/BRAS Rolle im Provider-Netz: Warum Placement eine Kernentscheidung ist

Der BNG ist die Schnittstelle zwischen Access-Aggregation und dem Service-/Core-Netz. Er ist „Subscriber-aware“: Er kennt Kundenidentität, Produktprofil, Zugriffstechnologie, ggf. Wholesale-Attribute und er ist meist der Ort, an dem Rate-Limits, Serviceklassen, Walled Garden/Captive Portal, IPv4/IPv6-Strategien, Multicast-Policies und Security-Mechanismen gebündelt werden. Damit ist er automatisch eine Failure Domain. Placement entscheidet, wie groß diese Failure Domain ist und wie stark sie mit Transport- und Interconnect-Topologien gekoppelt ist.

Leitprinzip: BNG ist eine Service-Edge, nicht Teil des Transit-Cores

Ein stabiler Provider-Core bleibt möglichst frei von kundenspezifischem State. Subscriber-State gehört an definierte BNG-Edges. Das macht Changes kontrollierbar und reduziert Risiko, dass Access-Wachstum direkt den Core destabilisiert.

BNG Placement Modelle: Zentral, regional, distributed

In der Praxis lassen sich die meisten BNG-Architekturen in drei Muster einordnen. Oft existieren Mischformen, aber als Blueprint-Denken sind diese drei Modelle hilfreich, um Trade-offs strukturiert zu bewerten.

Praxisbeobachtung: Regional ist oft der Sweet Spot

Viele Betreiber landen bei regionalen Clustern, weil sie den besten Kompromiss liefern: kontrollierte Failure Domains, gute Nutzererfahrung, und zugleich noch eine überschaubare Anzahl von Standorten, die sich mit Templates automatisieren lässt.

Topologie-Kriterien: Latenz, Hairpinning und Transportkosten

BNG Placement beeinflusst direkt Pfadlängen. Wenn Access-Aggregation weit vom BNG entfernt ist, müssen Control- und User-Plane-Verkehre durch zusätzliche Aggregations- und Core-Segmente. Das erhöht Latenz, erzeugt potenziell Jitter und kostet Backbone-Kapazität. Besonders spürbar wird das, wenn CGNAT oder Security-Services an anderen Orten sitzen als der BNG: Dann entstehen Hairpins (Traffic läuft unnötig durch zentrale Knoten).

Ein Anti-Pattern: Zentraler BNG bei regionalen Internet-Exits

Wenn der BNG zentral ist, Exits aber regional, entsteht unnötiges Hairpinning: Traffic muss zum BNG, dann wieder raus in eine Region – oder umgekehrt. Das erhöht Kosten und erschwert Troubleshooting. Besser ist, BNG-Placement und Exit-Strategie gemeinsam zu planen.

Failure Domains und Resilienz: Was darf ein Ausfall kosten?

BNG-Ausfälle sind hochwirksam, weil sie viele Sessions gleichzeitig betreffen können. Die wichtigste Designfrage lautet daher: Wie groß darf die Impact-Zone sein? Diese Frage muss technisch und geschäftlich beantwortet werden. Zentralisierung ist effizient, aber riskant. Regionalisierung reduziert Risiko, erhöht aber Betriebsaufwand. Entscheidend ist, Failover planbar zu machen: im Datenpfad, in AAA-Abhängigkeiten, in IPAM/DHCP und in der Policy-Steuerung.

Failover ist nicht nur Routing – es ist Session-Engineering

Bei BNG-Failover geht es oft nicht um „Route ist da“, sondern um die Frage, wie viele Sessions neu aufgebaut werden müssen, wie schnell AAA/DHCP reagieren, und ob die Control Plane unter Burst-Last stabil bleibt.

Scale-Faktoren: Was BNGs in der Praxis limitiert

Subscriber-Scale ist mehrdimensional. Ein BNG kann durch reine Session-Anzahl limitiert sein, durch PPS/Throughput, durch Policy-Komplexität, durch Tabellenlimits oder durch Control-Plane-Ereignisse (Churn). Besonders kritisch sind Peaks: „Abendspitze“ kombiniert mit einem Link-Flap oder einem AAA-Problem kann die Plattform an die Grenze bringen, auch wenn Durchschnittswerte harmlos aussehen.

Ein praktisches Scale-Gesetz: Komplexität multipliziert Sessions

State≈Sessions×Service_Varianten×Protokolle

Wenn Sie pro Tarif neue Policies, neue QoS-Klassen und neue Sonderregeln einführen, wächst State schneller als die Subscriberzahl. Standardisierung ist daher ein Skalierungswerkzeug.

PPPoE vs. IPoE: Auswirkungen auf Placement und Scale

Die Wahl von PPPoE oder IPoE/DHCP wirkt direkt auf Control-Plane-Last und Betriebsmodelle. PPPoE hat explizite Sessions und ist bei Störungen gut nachvollziehbar, erzeugt aber zusätzlichen Overhead und kann bei hohen Sessionzahlen anspruchsvoll sein. IPoE/DHCP ist oft effizienter im Datenpfad, verlagert aber Komplexität in DHCP-Infrastruktur, Relays und Security gegen Spoofing. Placement beeinflusst hier die Latenz zu AAA/DHCP und die Größe potenzieller „Renew Storms“.

Entscheidungskriterium: Welche Stürme können Sie besser beherrschen?

In großen FTTH-Netzen sind Storms real: PPPoE Reauth-Wellen oder DHCP Renew-Wellen. Die Wahl sollte daran gekoppelt sein, welche Art von Lastspitzen Ihre Plattformen, Tools und Prozesse besser handhaben.

Policy und Routing: Wie Placement die effektive Topologie definiert

BNG Placement wirkt nur dann wie geplant, wenn Routing- und Policy-Design es unterstützt. Sie brauchen ein konsistentes Modell für: Subscriber-Adressräume, VRF-Strukturen, Route-Leaks zu Shared Services, Traffic Steering zu CGNAT/Firewall, und regionale Exit-Strategien. Ohne dieses Modell wird Placement zu „Hardware an einem Ort“ ohne topologischen Nutzen.

Blueprint-Regel: BNG-Domain = Routing-Domain

Wenn Sie BNGs regionalisieren, sollten Sie auch Routing und Adressierung regionalisieren. Sonst bleibt Hairpinning bestehen, und Failover wird unkontrolliert.

BNG und Access-Aggregation: L2-Scope, VLAN/QinQ und OPEX

Die Aggregation zwischen OLT/Access und BNG bestimmt, ob das Netz L2-lastig oder L3-lastig ist. Große L2-Scopes erhöhen ARP/ND, MAC-Table-Pressure und Fehlersuche-Aufwand. Zu stark fragmentierte L2-Strukturen erhöhen hingegen Provisioning-Komplexität. Placement beeinflusst diesen Trade-off: Je weiter BNG weg ist, desto stärker steigt der Druck, L3 früher zu machen oder L2-Domänen bewusst zu begrenzen.

Ein OPEX-Hebel: Wenige Aggregationsprofile

Wenn jede Region ein anderes VLAN/QinQ- oder L2/L3-Modell fährt, explodiert Betriebskomplexität. Besser sind wenige, wiederholbare Profile, die überall gleich funktionieren.

BNG und Security/Management: Domains sauber trennen

BNGs sind hochkritische Systeme: Sie sehen Kundentraffic und halten Policy/State. Deshalb müssen Managementzugriffe strikt getrennt sein (Management-VRF/OOB), Jump-Zones mit MFA und Audit genutzt werden, und Control-Plane-Schutz muss Standard sein. Placement beeinflusst auch Security: regionale BNGs benötigen regionale Management- und Tooling-Pfade (AAA/PKI/DNS/NTP/Logging), sonst wird Betrieb fragil.

Security Domains sind auch Stabilitätsdomänen

Wenn Management und Tooling sauber segmentiert sind, wird ein Incident eher lokal begrenzt. Wenn alles „flach“ ist, ist auch der Blast Radius groß – sowohl bei Security als auch bei Betriebsfehlern.

Observability: Placement-Entscheidungen messbar machen

BNG Placement sollte nicht nach Gefühl entschieden werden, sondern anhand von Kennzahlen und Zielwerten: Latenz zu wichtigen Zielen, Session-Churn, Reauth-/DHCP-Eventraten, CPU/Memory-Headroom, Queue-Drops auf Aggregationslinks und Failover-Verhalten. Wichtig ist dabei, Peaks zu messen, nicht nur Durchschnittswerte.

Evidence-by-Design: Cluster- und Regionsentscheidungen rechtfertigen

Wenn Sie zeigen können, dass regionale BNGs Hairpinning reduzieren, Failover-Impact begrenzen und Churn kontrollierbar halten, wird Placement eine belastbare Architekturentscheidung – und nicht ein politischer Kompromiss.

Praktische Entscheidungslogik: So wählen Sie ein BNG/BRAS Placement Pattern

Blueprint-Leitlinien: Topologie, Policy und Scale für BNG/BRAS

Exit mobile version