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.
- Access (PON/OLT): Viele Kundenports werden optisch gebündelt; Uplinks zur Aggregation sind häufig stark oversubscribed.
- Aggregation: Bündelt OLT-Uplinks, trennt Domänen, setzt ggf. L2/L3-Policies und stellt Redundanz bereit.
- BNG/BRAS: Terminiert PPPoE oder IPoE (DHCP), setzt Subscriber-Policies, QoS, Accounting und leitet Traffic weiter.
- Core/Edge: Internet-Exits, Peering, CGNAT, Security Services, ggf. Wholesale/Bitstream.
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.
- Uplink-Kapazität: Aus PON-Oversubscription folgt: Uplink-Reserve ist wichtiger als „theoretische PON-Rate“.
- Redundanz: Dual-Uplink zu zwei Aggregationsknoten, idealerweise mit Facility-/Trassen-Diversität.
- LAG/ECMP-Disziplin: Member-Visibility und Hashing-Entropie sind wichtig, um Hotspots zu vermeiden.
- MTU-Profile: QinQ/Encapsulation-Overhead muss end-to-end passen, sonst entstehen Blackholes.
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.
- Access Aggregation: Nah an OLTs; Fokus auf kosteneffizienter Bündelung und klarer Uplinkstruktur.
- Metro Aggregation: Regionale Hubs mit höherer Redundanz, QoS- und ggf. L3-Funktionalität.
- Failure Domain Kontrolle: Ein Aggregationsknoten darf nicht unkontrolliert zu „Single Hub für alles“ wachsen.
- OPEX-Hebel: Standardisierte Blueprints reduzieren Varianten und beschleunigen Entstörung.
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.
- Per-OLT VLAN: Einfacher Überblick, aber kann bei sehr vielen OLTs zu vielen VLANs führen.
- Per-PON VLAN: Granularer, kann Fehlersuche erleichtern, erhöht aber VLAN-Zahl stark.
- QinQ: Gute Skalierung für Wholesale/Mehrmandantenmodelle, erfordert konsequente MTU- und Tagging-Disziplin.
- Broadcast-Last: Große L2-Domänen erhöhen ARP/ND und unbekannten Unicast – häufig unterschätzt.
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.
- Session-Skalierung: Millionen Sessions erfordern CPU/Memory-Planung, Tabellenlimits und klare Upgrade-Trigger.
- Redundanz: N+1 BNG-Cluster pro Region, diverse Standorte, kontrolliertes Failover.
- Policy Enforcement: Produktprofile, Rate Limits, QoS-Klassen, ggf. walled garden oder captive portal.
- Service Integration: Steering zu CGNAT, Firewalls, DDoS-Services oder Wholesale-Übergaben.
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.
- PPPoE: Klare Sessions, gute Accounting-Modelle, aber zusätzliche Encapsulation und Session-Handling.
- IPoE/DHCP: Weniger Overhead, oft gut für moderne CPEs, aber DHCP-Scale und Security (DHCP Snooping/Optionen) müssen sauber geplant werden.
- Dual-Stack: IPv4/IPv6 Parallelbetrieb beeinflusst Adressierung, Policies, CGNAT-Strategien und MTU/MSS-Details.
- Provisioning: Auth/AAA-Integration (RADIUS/DIAMETER) als kritische Abhängigkeit, die redundant sein muss.
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.
- L2-Scopes begrenzen: Kleine Broadcast-Domänen pro Aggregationscluster, statt „alles L2 bis zum Core“.
- ARP/ND-Management: Rate-Limits, Security Controls und Telemetry, um Storms früh zu erkennen.
- MTU-Disziplin: QinQ/PPPoE/Encapsulation-Overhead budgetieren; Failoverpfade mitprüfen.
- Störfalltests: Link-/Hub-Ausfall testen, ob Sessions stabil bleiben und ob keine Blackholes entstehen.
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.
- Active/Active vs. Active/Standby: Trade-off zwischen Effizienz und Einfachheit; entscheidend ist Predictability im Failover.
- Regionalisierung: BNGs nahe an Aggregationshubs reduzieren Hairpinning und verbessern Latenz.
- Session-Policy: Definieren, ob Failover Session-Reset auslösen darf; entsprechend Provisioning und Kundenerwartung steuern.
- OPEX: Standardisierte Cluster-Blueprints reduzieren Wartungsrisiken und verkürzen Changes.
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.
- Subscriber-Shaping: Häufig am BNG, weil dort pro Kunde/Profil gesteuert werden kann.
- Queuing an Uplinks: Aggregationslinks brauchen konsistente Queue-Profile, um Microbursts zu beherrschen.
- Bulk vs. Realtime: Hintergrundlast degradieren, Echtzeit-/Control stabil halten.
- Telemetry: Drops pro Queue/Klasse, Member-Link-Sicht bei LAGs, Peak-Analyse statt Durchschnitt.
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.
- Regionaler Exit: Peering/Transit nahe an Kundenschwerpunkten reduziert Backbone-Last und verbessert Performance.
- Stateful Symmetrie: CGNAT-Pfade müssen stabil sein; ECMP/Hashing bewusst planen.
- DDoS/Security: Edge-Services als eigene Domain; klare Steering-Mechanismen und Telemetry.
- Observability: NAT-State, Port-Pool-Pressure, Session-Resets und Drops müssen sichtbar sein.
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.
- Management-VRF/OOB: Separater Zugriffspfad für OLTs, Aggregation und BNGs; nicht über Kundennetze.
- Jump-Zones: Verbindlicher Admin-Zugangspunkt, Session Recording und rollenbasierte Rechte.
- Critical Dependencies: AAA/PKI/DNS/NTP/Logging redundant und regional erreichbar.
- Control-Plane Schutz: Rate-Limits, CoPP, Guardrails gegen Storms und Fehlkonfigurationen.
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.
- OLT KPIs: Uplink-Auslastung, Drops, Fehlerzähler, eventbasierte Peaks.
- Aggregation KPIs: Queue-Drops pro Klasse, LAG-Member-Auslastung, Microburst-Indikatoren.
- BNG KPIs: Session-Counts, Reauth-/DHCP-Raten, RIB/FIB-Pressure, CPU/Memory, Policy-Hit-Rates.
- Service KPIs: Latenz/Loss zu wichtigen Zielen, Interconnect-Health, DDoS-Events, MTU-Blackhole-Indikatoren.
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
- OLT-Uplinks standardisieren: Dual-Uplink, klare LAG/ECMP-Profile, konsistente MTU und Tagging-Regeln.
- Aggregation hierarchisch bauen: Access Aggregation → Metro Hub, mit klaren Failure Domains und begrenzten L2-Scopes.
- VLAN/QinQ bewusst wählen: Skalierung, Wholesale-Anforderungen und Tabellenlimits berücksichtigen; wenige Profile statt Sonderfälle.
- BNG regionalisieren: N+1-Cluster, diverse Standorte, definierte Failover- und Session-Continuity-Politik.
- PPPoE/IPoE konsequent: Protokollwahl an Betriebsmodell koppeln; AAA/DHCP skalieren und absichern.
- QoS als Produktmodell: Subscriber-Shaping am BNG, Queuing an Engpässen, Störfallfähigkeit (N-1).
- CGNAT/Internet Edge koppeln: Stateful Pfade symmetrisch halten, Hairpins vermeiden, Interconnect-Policies standardisieren.
- Management & Security trennen: Management-VRF/OOB, Jump-Zones, Guardrails und auditierbare Changes.
- Telemetry verpflichtend: OLT/Aggregation/BNG/CGNAT/Interconnect-KPIs, Peaks und Churn sichtbar machen.
