Site icon bintorosoft.com

FTTH Aggregation Topology: OLT, Aggregation, BNG/BRAS Design

Red Snapper

Eine saubere FTTH Aggregation Topology ist für Glasfaseranbieter der entscheidende Faktor, ob ein FTTH-Netz wirtschaftlich skaliert, stabil betrieben werden kann und Kunden die erwartete Performance bekommen. FTTH (Fiber to the Home) ist nicht nur ein Bauprojekt im Feld, sondern vor allem eine Transport- und Servicearchitektur: Am Rand steht die OLT (Optical Line Terminal) als PON-Zugangsebene, dahinter folgt die Aggregation (Layer-2/Layer-3, je nach Design), und am Service-Ende steht der BNG/BRAS als Subscriber-Edge, der Sessions terminiert, IP-Adressen vergibt, Policies durchsetzt und den Verkehr in Richtung Internet, Peering und Services führt. Genau an diesen Übergängen entstehen die meisten Probleme, wenn Topologie und Rollen nicht sauber definiert sind: Broadcast-/ARP-Last, VLAN-Sprawl, unklare Failure Domains, zu große L2-Domänen, instabile PPPoE-Sessions, DHCP-Engpässe, CGNAT-Hairpins oder OPEX-Explosion durch zu viele Sonderfälle. Ein professionelles FTTH-Design arbeitet daher mit wiederverwendbaren Blueprints: klare OLT-Uplinks, definierte Aggregationshubs, standardisierte VLAN-/EVPN-/VRF-Modelle, redundante BNG/BRAS-Clusters, kontrollierte QoS-Profile und Telemetry, die Subscriber- und Linkverhalten messbar macht. Dieser Artikel erklärt die Designprinzipien von OLT über Aggregation bis BNG/BRAS – mit Blick auf Skalierung, Resilienz, Betriebskosten und saubere Security-/Management-Grenzen.

FTTH Transportkette verstehen: Von der Faser bis zur Session

FTTH unterscheidet sich von vielen anderen Access-Technologien dadurch, dass die physische Zugangsstruktur (PON) sehr stark auf Aggregation und Oversubscription ausgelegt ist. Das ist wirtschaftlich sinnvoll, stellt aber besondere Anforderungen an die Transporttopologie und an die Subscriber-Termination. In einem typischen FTTH-Design ist die OLT das Aggregationsgerät für viele ONTs/ONTUs (Kundenanschlüsse), während BNG/BRAS die logische „Einwahl“ in das Provider-Netz abbildet. Zwischen beiden liegt die Aggregationsebene, die Kapazität bündelt, Failure Domains strukturiert und Transport zum Service-Edge bereitstellt.

Leitprinzip: Access ist „viele kleine“, BNG ist „wenige große“

OLT und Access sind breit verteilt und wachsen in der Fläche. BNG/BRAS ist konzentrierter und wächst in Kapazität und Session-Zahl. Die Topologie muss daher so gestaltet sein, dass Access-Wachstum nicht direkt zu Servicekomplexität im Kern führt.

OLT-Rolle und Uplink-Design: Bandbreite, Redundanz und Domänengrenzen

Die OLT ist nicht nur ein optischer Terminator, sondern ein wichtiger Topologiepunkt: Hier beginnen L2- und VLAN-Strukturen, hier entstehen erste Failure Domains, und hier entscheidet sich, wie sauber sich der Access später aggregieren lässt. OLT-Uplinks sollten in FTTH-Designs nicht „irgendwie“ in die Aggregation gehen, sondern über standardisierte Patterns: definierte Uplink-Bundles, klare LAG-/ECMP-Regeln, konsistente MTU-Profile und feste Service-VLAN-/QinQ-Schemata.

OLT-Failure Domain bewusst definieren

Eine OLT ist oft ein natürlicher Failure-Domain-Knoten: Fällt sie aus, sind viele Anschlüsse betroffen. Das ist nicht immer vermeidbar, aber es ist gestaltbar: Kleine OLT-Domänen, klare regionale Verteilung, robuste Strom- und Klima-Infrastruktur und ein Standard-Plan für Wartung und Austausch reduzieren Risiko und MTTR.

Aggregationsebene: Warum sie mehr ist als „ein Switch“

FTTH-Aggregation entscheidet über Skalierbarkeit und Betriebskosten. Hier werden tausende OLT-Uplinks zusammengeführt, und hier entscheidet sich, ob Sie ein beherrschbares L2-Design fahren oder ob Sie in VLAN-Sprawl, Broadcast-Last und unklaren Fehlerbildern untergehen. In modernen Designs ist Aggregation oft mehrstufig: Access Aggregation (nah am Feld) und Metro Aggregation (regionaler Hub), bevor der BNG/BRAS erreicht wird.

Designentscheidung: L2-Aggregation bis BNG oder L3 früher?

Ein Kerntrade-off im FTTH-Design ist, wie weit Sie L2 führen. L2 bis zum BNG kann einfach wirken, erhöht aber Broadcast-/ARP-Last und die Größe der Fehlerdomänen. Früheres L3 (z. B. IP-Backhaul bis zum BNG) kann Skalierung und Stabilität verbessern, erfordert aber klare VRF- und Routing-Blueprints. In der Praxis sind Hybridmodelle verbreitet: L2 für die unmittelbare Subscriber-Zuordnung, L3 für Transportsegmente und klare Domänengrenzen.

VLAN-/QinQ-Modelle: Service-VLAN, Subscriber-VLAN und Skalierungsfallen

FTTH-Netze nutzen häufig VLAN-basierte Modelle, um Subscriber zu trennen und Produkte abzubilden. Dabei gibt es mehrere typische Schemata: pro OLT ein Service-VLAN, pro PON ein VLAN, oder QinQ mit Outer VLAN (S-VLAN) und Inner VLAN (C-VLAN). Die Wahl beeinflusst Tabellenlimits, Broadcast-Domänen, Provisioning-Komplexität und die Fähigkeit, Wholesale/Bitstream abzubilden.

Blueprint-Regel: VLAN-Strategie ist ein Control-Plane-Parameter

VLAN-Entscheidungen beeinflussen MAC-Tabellen, ARP/ND-State, CPU-Last und Fehlersuche. Eine „schnelle“ VLAN-Lösung wird später oft teuer. Deshalb sollten VLAN/QinQ-Modelle als standardisierte, dokumentierte Blueprints existieren.

BNG/BRAS: Subscriber-Termination als Herzstück des FTTH-Service

Der BNG/BRAS ist die logische Servicekante: Hier wird entschieden, wer online ist, welche IP er bekommt, welches Produktprofil gilt und wie Traffic ins Netz darf. Der BNG ist damit nicht nur ein Router, sondern eine Policy- und State-Plattform: Session-States, DHCP-Leases oder PPPoE-Sessions, QoS-Profile, Accounting, ggf. LI-Integration und oft auch Steering zu CGNAT oder Security Services. Topologisch muss der BNG hochverfügbar und skalierbar sein, weil er zentrale Betriebsauswirkungen hat.

BNG ist eine Failure Domain – und muss bewusst klein gehalten werden

Ein „einziger großer BNG“ wirkt effizient, ist aber riskant: Wartung und Fehler betreffen sofort große Kundenmengen. Regionale BNG-Cluster mit klaren Domains reduzieren Blast Radius und verbessern Wartbarkeit.

PPPoE vs. IPoE (DHCP): Auswirkungen auf Topologie und Betrieb

Ob Sie PPPoE oder IPoE nutzen, beeinflusst BNG-Design, Aggregation und Troubleshooting. PPPoE bringt eine explizite Session-Logik mit, ist im Betrieb gut nachvollziehbar, erzeugt aber zusätzlichen Overhead und kann bei großen Scale-Szenarien anspruchsvoll sein. IPoE (meist DHCP) ist oft „leichter“ im Datenpfad, erfordert aber saubere DHCP-Architektur, Relay-Design und Sicherheitsmechanismen gegen Spoofing.

Entscheidungskriterium: Betriebsmodell und Tooling

Die „beste“ Wahl hängt stark davon ab, welche Betriebs- und Automationsprozesse Sie haben. Wichtig ist weniger das Protokoll, sondern dass das Gesamtsystem (BNG, AAA, IPAM, Telemetry) konsistent und auditierbar funktioniert.

Aggregation bis zum BNG: L2-Scale, ARP/ND und Blackhole Prevention

Wenn Access-Aggregation große L2-Domänen bildet, steigt die Gefahr von ARP/ND-Stürmen, MAC-Table-Pressure und schwer erklärbaren Blackholes. Zudem werden Failoverpfade oft anders geroutet und können MTU- oder VLAN-Inkonsistenzen offenlegen. Ein robustes Design begrenzt L2-Scopes, nutzt klare Domänengrenzen und plant MTU end-to-end.

Ein klassischer Fehler: MTU nur im Normalpfad geprüft

Im Failover laufen Pakete oft über andere Aggregationslinks oder andere VLAN-Trunks. Wenn diese eine kleinere MTU oder andere Tagging-Profile haben, entstehen Drops, die wie „BNG-Probleme“ wirken, aber reine Transportinkonsistenzen sind.

BNG-Clusterdesign: Anycast Gateway, Redundanz und Session-Continuity

BNG-Redundanz ist mehr als „zwei Geräte“. Sie muss definieren, wie Kunden im Failover weiterarbeiten: Dürfen Sessions kurz neu aufbauen oder muss State erhalten bleiben? In vielen FTTH-Umgebungen ist ein kurzer Neuaufbau akzeptabel, solange er selten ist und keine große Churn-Welle erzeugt. Für Premium-/Business-Produkte können strengere Anforderungen gelten.

Designregel: Failover muss „boring“ sein

Ein gutes BNG-Design sorgt dafür, dass Ausfälle und Wartungen nicht zu massiven Reauth-/DHCP-Stürmen führen. Dazu gehören Headroom, gestaffelte Rollouts, klare Timings und Telemetry, die Churn sichtbar macht.

QoS-Topologie im FTTH: Wo Shaping und Policing hingehört

FTTH ist stark oversubscribed. Ohne QoS wird in Peakzeiten nicht nur „langsamer“, sondern unberechenbar. Ein sauberes QoS-Design ist topologisch: Marking am Ingress (wo Produktprofil bekannt ist), Shaping/Queuing an Engpässen (OLT-Uplinks, Aggregation-Uplinks, BNG-Uplinks) und Policing dort, wo Verträge durchgesetzt werden. Viele Provider implementieren Subscriber-Shaping am BNG, um Produkte sauber zu garantieren und Congestion kontrolliert zu machen.

QoS ist ein Produktmerkmal

Wenn Sie Tarife verkaufen, verkaufen Sie implizit QoS-Verhalten in Engpässen. Ein Blueprint muss daher definieren, wie Produkte in Shaping/Queuing abgebildet werden und wie das im Störfall aussieht.

CGNAT und Internet Edge: Topologisch sinnvoll koppeln

In IPv4-dominierten Consumer-FTTH-Netzen ist CGNAT oft Teil des Standardpfads. Das wirkt auf die Topologie: CGNAT ist stateful und will Symmetrie; Internet-Exits (Peering/Transit) sollen regional sein, um Latenz und Kosten zu optimieren. Ein häufiges Anti-Pattern ist zentraler CGNAT bei regionalen Exits: Das erzeugt Hairpinning und unklare Pfade. Besser ist eine regionale Kopplung von BNG, CGNAT und Internet Edge oder klare, kontrollierte Transportpfade zwischen diesen Rollen.

Designregel: Internetpfad ist Teil des Access-Produkts

FTTH-Kunden bewerten das Netz über Internet-Erlebnis. Deshalb sollten CGNAT/Peering/Transit nicht als getrennte Silos geplant werden, sondern als Ende-zu-Ende-Pfad vom BNG bis zum Interconnect.

Management und Security: OOB/In-Band, Jump-Zones und Domain-Trennung

FTTH-Access ist verteilt und damit anfällig für Betriebs- und Security-Risiken: Viele Standorte, viele Geräte, viele Zugänge. Ein professionelles Design trennt Management als eigene Domain (Management-VRF oder OOB), nutzt Jump-Zones mit MFA und Audit, und begrenzt die Angriffsfläche durch minimal notwendige Routen und strikte Policies.

Access-Security ist Betriebsfähigkeit

Wenn Security-Kontrollen den Betrieb blockieren, entstehen Workarounds. Gute FTTH-Designs machen Security praktikabel: klare Rollen, klare Domains, klare Tools und saubere Telemetry.

Observability und Kapazitätsplanung: Was in FTTH wirklich gemessen werden muss

FTTH-Netze kippen selten „langsam“. Häufig sind es Peaks, Microbursts, Member-Hotspots oder Session-Churn-Ereignisse. Deshalb braucht es Telemetry auf den richtigen Ebenen: OLT-Uplink-Auslastung, Aggregations-Queue-Drops, BNG-Session- und CPU/Memory-Headroom, DHCP/PPPoE-Eventraten, CGNAT-State und Interconnect-Qualität.

Evidence-by-Design: Wachstum planbar machen

Wenn Sie Growth-Trends für Sessions, Peak-Throughput und Queue-Drops historisieren, können Sie Upgrade-Trigger definieren, bevor Kunden betroffen sind. Das reduziert Notfallprojekte und erhöht Servicequalität.

Blueprint-Leitlinien: OLT, Aggregation und BNG/BRAS als skalierbares FTTH-Design

Exit mobile version