So haben wir unseren BNG-Core auf MikroTik aufgebaut

Wenn ein Kundenrouter eine PPPoE-Verbindung aufbaut, sieht das von außen aus wie eine simple Benutzeranmeldung. Tatsächlich passiert in diesen wenigen Sekunden deutlich mehr.

Aus einer zunächst anonymen Layer-2-Verbindung wird eine vollständig definierte Teilnehmer-Session:

• Der Anschluss wird identifiziert.
• Die Zugangsdaten werden geprüft.
• Ein Produktprofil wird zugewiesen.
• Eine private oder öffentliche IP-Adresse wird vergeben.
• Die Session landet in der passenden Routingdomäne.
• Bandbreitenklasse und Queueing werden aktiviert.
• Die Erreichbarkeit wird dynamisch im Netz verteilt.
• Accounting und Monitoring beginnen.

Der technische Übergabepunkt für all diese Funktionen ist unser Broadband Network Gateway, kurz BNG.

Innerhalb von AS204197 betreiben wir dafür zwei BNG-Systeme auf Basis von MikroTik CCR2216 und RouterOS 7. Ein BNG steht in Frankfurt, der zweite in Alsbach. Beide Systeme sind aktive Serviceknoten und vollständig in unser MPLS-Backbone integriert.

Dabei ging es mir nicht darum, einen möglichst großen PPPoE-Server zu bauen.

Unser Ziel war ein BNG-Core, bei dem Access, Authentifizierung, Teilnehmer-Policy, Routing, Queueing und Internet-Edge sauber voneinander getrennt bleiben.

Die folgenden Konfigurationsbeispiele zeigen ausschließlich die technischen Prinzipien. Namen, Adressen, Bandbreiten, Kennungen und Policies wurden abstrahiert. Es handelt sich nicht um Ausschnitte aus unserer produktiven Konfiguration und ausdrücklich nicht um eine vollständige Copy-and-paste-Konfiguration.

Vereinfacht sieht unser Aufbau so aus:

Die Rollen sind bewusst getrennt.

Der Access-Layer transportiert die Teilnehmerverbindung bis zu uns.

Der BNG terminiert die PPP-Session und setzt die Teilnehmer-Policy um.

RADIUS entscheidet, welcher Teilnehmer welches Produkt und welche Adressierung erhält.

MPLS und MP-BGP transportieren die verschiedenen Routingdomänen durch unser Netz.

Die Border-Router übernehmen die vollständige Internet-Routingtabelle und wählen den passenden Weg über Transit, Private Network Interconnects und Internet Exchanges.

Der BNG muss deshalb weder das eigentliche Carrier-Grade NAT durchführen noch sämtliche Internetpfade kennen. Seine Kernaufgabe besteht darin, aus einer Teilnehmerverbindung einen definierten IP-Service zu machen.

Unsere Architektur unterstützt derzeit zwei grundsätzliche Übergabearten:

1. direkte PPPoE-Terminierung über einen Layer-2-Service,
2. PPP-Übergabe aus einem Wholesale- oder BSA-Netz über L2TP.

Der Begriff „direkt“ bedeutet dabei nicht zwingend, dass der Kundenrouter physisch an einem Port des BNG angeschlossen ist.

Entscheidend ist vielmehr, dass die PPPoE-Frames durchgängig auf Layer 2 bis zu einem unserer BNGs transportiert und dort terminiert werden. Zwischen Accessanschluss und BNG befindet sich in diesem Modell kein externer L2TP Access Concentrator.

Nach der Terminierung greifen für beide Übergabearten dieselben Prozesse:

Damit bleibt das eigentliche Produkt weitgehend unabhängig davon, über welchen Accessweg der Kunde unser Netz erreicht.

Bei der direkten PPPoE-Terminierung transportieren wir die Ethernet- und PPPoE-Frames des Kunden bis zu einem unserer BNGs.

Dafür kommen unterschiedliche Accessmodelle infrage.

Bei FTTH-Anschlüssen kann ein regionaler oder überregionaler Netzbetreiber mehrere Teilnehmeranschlüsse aggregieren und uns diese über eine Layer-2-Netzkopplung übergeben.

Je nach Modell erfolgt die Übergabe beispielsweise über:

• dedizierte Service-VLANs,
• QinQ beziehungsweise gestapelte VLANs,
• eine Ethernet-NNI,
• einen Carrier-Ethernet-Service,
• eine direkte Layer-2-Anbindung an einen unserer Backbone-Standorte.

Der FTTH-Netzbetreiber stellt dabei im Wesentlichen den physischen und logischen Access bereit. Die eigentliche PPPoE-Session endet nicht beim FTTH-Anbieter, sondern auf einem unserer BNGs.

Dadurch behalten wir die Kontrolle über:

• Authentifizierung,
• IP-Adressvergabe,
• Bandbreitenklasse,
• Routingdomäne,
• Accounting,
• Session-Limits,
• Internet- und MPLS-Services.

Der FTTH-Zugang wird damit zu einem Transportweg in unseren BNG-Core und nicht zu einer isolierten Produktplattform.

Auch komplette Accessnetze oder Kundenstandorte können über eine Layer-2-Verbindung direkt an unseren Backbone angebunden werden.

Der Übergabepunkt kann sich dabei in einem Rechenzentrum, einem regionalen PoP oder an einer Carrier-NNI befinden.

Der Layer-2-Service wird anschließend innerhalb unseres Backbones bis zum BNG transportiert. Die physische Anbindung muss damit nicht am selben Standort enden wie die PPPoE-Session.

Diese Entkopplung ist wichtig.

Wir können einen Accesspartner an einem geeigneten Backbone-Standort übernehmen, ohne dort zwingend einen eigenen BNG betreiben zu müssen. Das MPLS-Netz übernimmt den Transport zum vorgesehenen Terminationspunkt.

Auch Richtfunk- und Wireless-DSL-Netze können als Ethernet-Access für PPPoE verwendet werden.

Dabei aggregiert ein lokaler Access Node oder Funkstandort die Teilnehmeranschlüsse. Die Kundenrouter bauen ihre PPPoE-Sessions anschließend über das Funknetz bis zu unserem BNG auf.

Das Funknetz muss dabei keine öffentlichen Teilnehmeradressen verwalten und keine eigene Internet-Routinglogik bereitstellen.

Es stellt den Layer-2-Transport bereit.

Damit lässt sich ein regionales Wireless-Access-Netz in dieselbe AAA-, Routing- und Servicearchitektur integrieren wie ein FTTH-Anschluss.

Ein weiterer Anwendungsfall sind transparente Ethernet-Verbindungen wie beispielsweise EtherConnect.

Ein entfernter Kundenstandort oder Accessknoten erhält dabei eine Layer-2-Verbindung bis in unseren Backbone. Der dort eingesetzte Router kann seine PPPoE-Session direkt zu einem unserer BNGs aufbauen.

Aus Sicht des Kundenrouters befindet sich der PPPoE Access Concentrator logisch im selben Ethernet-Service – auch wenn zwischen beiden Standorten ein Carrier-Netz und unser MPLS-Backbone liegen.

Das kann beispielsweise für folgende Szenarien genutzt werden:

• direkte Geschäftskundenanschlüsse,
• verwaltete Internetzugänge,
• temporäre oder projektbezogene Accessstandorte,
• kleinere regionale Aggregationspunkte,
• Zugänge, bei denen IP-Service und Transport bewusst getrennt beschafft werden.

Der Ethernet-Service transportiert den Access. Unser BNG stellt das eigentliche IP-Produkt bereit.

Innerhalb unseres Netzes transportieren wir solche PPPoE-Services über definierte VPLS-Pseudowires bis zum BNG.

Das Underlay bleibt dabei vollständig geroutet. Darauf laufen OSPF, MPLS und LDP. Erst oberhalb dieser Transportebene entsteht der eigentliche Layer-2-Service.

Der VPLS-Pseudowire landet auf dem BNG in einer dedizierten PPPoE-Bridge.

Split-Horizon verhindert, dass unterschiedliche Accesssegmente innerhalb dieser Bridge unbeabsichtigt direkt miteinander kommunizieren. Die Bridge dient ausschließlich als kontrollierte Übergabe zum PPPoE-Server.

Ein stark abstrahiertes RouterOS-Beispiel:

Das Beispiel zeigt bewusst nur das Prinzip:

• Der Access wird als eigener Layer-2-Service transportiert.
• Der Service endet auf einer dedizierten PPPoE-Bridge.
• Die Teilnehmer-Sessions werden erst auf dem BNG terminiert.
• Der Transportweg bleibt vom eigentlichen IP-Produkt getrennt.

Bei Bitstream- beziehungsweise BSA-Anschlüssen endet die Accessstrecke zunächst bei einem L2TP Access Concentrator des Vorleisters.

Der LAC übernimmt die Accessseite der Verbindung und übergibt die eigentliche PPP-Session über L2TP an einen unserer BNGs. Der BNG arbeitet dabei als L2TP Network Server, kurz LNS.

Der physische DSL-Anschluss und die PPP-Terminierung können dadurch in unterschiedlichen Netzen liegen.

Der Wholesale-Partner stellt die Teilnehmerverbindung bis zum LAC bereit. Authentifizierung, IP-Adressierung, Queueing, Accounting und Routing erfolgen anschließend in unserer eigenen BNG-Infrastruktur.

Beide BNG-Standorte verfügen über einen eigenen LNS-Serviceendpunkt. Der Wholesale-Partner kann Sessions daher an mehr als einen Standort übergeben.

Für die reguläre L2TP-Übergabe verwenden wir einen dedizierten CrossConnect zum BSA-Partner.

Über diesen CrossConnect besteht eine direkte BGP-Verbindung. Die jeweilige LNS-Serviceadresse wird dort als spezifische /32-Route angekündigt.

Gleichzeitig befindet sich die LNS-Adresse innerhalb eines von uns regulär im Internet angekündigten /24-Netzes.

Dadurch entstehen zwei mögliche Wege zum selben LNS-Endpunkt:

Technisch nutzen wir dabei das <strong>Longest Prefix Match</strong>.

Auch wenn häufig von einem BGP-Prinzip gesprochen wird, fällt die eigentliche Entscheidung in der Forwarding-Tabelle des Routers:

Die spezifischste passende Route gewinnt.

Solange die /32-Route über den dedizierten CrossConnect vorhanden ist, wird sie gegenüber der übergeordneten /24-Route bevorzugt.

Die /32 ist spezifischer als die /24 und wird daher für genau diese Serviceadresse verwendet.

Fällt der CrossConnect oder die zugehörige BGP-Session aus, wird die /32-Route zurückgezogen. Die übergeordnete /24-Route bleibt jedoch über unsere regulären externen BGP-Anbindungen erreichbar.

Der Wholesale-Partner erreicht anschließend weiterhin dieselbe LNS-IP-Adresse – nur über einen anderen Netzpfad, beispielsweise über einen gemeinsamen Internet Exchange.

Für die Umschaltung sind weder DNS-Änderungen noch neue Tunnelziele oder manuelle Eingriffe notwendig.

Die Zieladresse bleibt identisch. Lediglich die Route zu dieser Adresse ändert sich.

Das Modell verbindet einen deterministischen Primärpfad mit der Reichweite unseres gesamten externen BGP-Setups:

• Im Normalbetrieb läuft die L2TP-Übergabe direkt über den CrossConnect.
• Bei einem Ausfall bleibt der LNS-Endpunkt über das aggregierte Präfix erreichbar.
• Die alternative Übergabe kann über einen IX, ein direktes Peering oder Transit erfolgen.
• Die Backup-Erreichbarkeit benötigt keine separate Service-IP.

Damit wird nicht der CrossConnect selbst redundant. Redundant ist die IP-Erreichbarkeit des Dienstes.

Sobald eine PPPoE- oder L2TP-Session am BNG eintrifft, beginnt die eigentliche Service-Provisionierung.

Der BNG übermittelt die Teilnehmerdaten an unser RADIUS-System.

Neben Benutzername und BNG-Identität können dabei – sofern vom Accessnetz geliefert – auch Informationen wie Circuit-ID oder Anschlusskennung in die Anfrage einfließen.

Wir verwenden die Circuit-ID als Bestandteil der NAS-Port-Identifikation. Dadurch lässt sich eine Session nicht nur einem Benutzernamen, sondern auch einem konkreten Accessanschluss zuordnen.

RADIUS entscheidet anschließend unter anderem:

• ob die Anmeldung zulässig ist,
• welches PPP-Profil verwendet wird,
• ob eine dynamische oder statische IP-Adresse vergeben wird,
• aus welchem Adresspool die Session bedient wird,
• ob nur eine oder mehrere parallele Sessions zulässig sind,
• welchem Produkt der Teilnehmer zugeordnet ist,
• ob zusätzliche Routen oder Serviceparameter erforderlich sind.

Ein vereinfachtes RADIUS-Ergebnis könnte beispielsweise so aussehen:

Oder bei einer dynamischen Adressvergabe:

RADIUS wählt damit das Produktprofil und die Adressierung aus.

Die eigentliche Zuordnung zur Queue-Klasse erfolgt anschließend über das auf dem BNG hinterlegte PPP-Profil.

Unsere PPP-Profile übernehmen zwei besonders wichtige Aufgaben:

1. Sie ordnen die dynamische PPP-Schnittstelle einer Interface-Liste zu.
2. Sie tragen die vergebene Teilnehmer-IP dynamisch in eine Address List ein.

Beide Informationen werden anschließend unabhängig voneinander verwendet.

Die Interface-Liste bestimmt den Routingkontext beziehungsweise die VRF.

Die Address List bestimmt die Bandbreiten- und Queue-Klasse.

Ein abstrahiertes Beispiel:

Beide Profile verwenden dieselbe Queue-Klasse RATE-CLASS-A, landen aber in unterschiedlichen Routingdomänen.

Damit werden zwei voneinander unabhängige Produkteigenschaften getrennt modelliert:

Ein öffentlicher Internetzugang und ein CGNAT-Zugang können somit dieselbe Bandbreitenklasse verwenden, ohne im selben Routingkontext zu landen.

Sobald die Session aufgebaut wird, erzeugt RouterOS eine dynamische PPP-Schnittstelle.

Diese Schnittstelle wird automatisch:

• der passenden Interface-Liste,
• der zugehörigen VRF,
• und über ihre IP-Adresse der passenden Queue-Klasse

zugeordnet.

Beim Abbau der Session verschwinden die dynamischen Zuordnungen wieder.

Die Session erzeugt die für Routing und Queueing benötigten Zustände selbst – und entfernt sie beim Abbau automatisch.

Aktuell unterscheiden wir auf den BNGs drei grundsätzliche Servicearten.

Teilnehmer im CGNAT-Produkt erhalten eine Adresse aus einem standortspezifischen Shared-Address-Pool.

Die dynamische PPP-Schnittstelle landet in einer eigenen CGNAT-VRF. Von dort wird der Verkehr über unser MPLS-Netz zu einer separaten CGNAT-Schicht transportiert.

Der BNG selbst führt kein Carrier-Grade NAT durch.

Dadurch können wir Session-Terminierung und NAT-Kapazität unabhängig voneinander skalieren.

Der BNG verwaltet die Teilnehmer-Session. Die CGNAT-Systeme übernehmen die zustandsbehaftete Adressumsetzung.

Bei einem Zugang mit öffentlicher IPv4-Adresse liefert RADIUS die jeweilige Teilnehmeradresse.

Da PPP eine Punkt-zu-Punkt-Verbindung erzeugt, erscheint die Teilnehmeradresse auf dem BNG als dynamisch erreichbare Hostroute über die PPP-Schnittstelle.

Diese Hostroute wird aus der Public-VRF über MP-BGP als VPNv4-Route in unser MPLS-Netz exportiert.

Die Border-Router und die übrigen relevanten Provider-Edge-Systeme lernen dadurch automatisch, auf welchem BNG die betreffende Teilnehmeradresse aktuell terminiert.

Wird die Session beendet, verschwindet die dynamische Route wieder.

Damit benötigen wir keine statischen Hostrouten für einzelne PPP-Kunden und keine manuelle Umschaltung zwischen den beiden BNGs.

Ein Teilnehmer kann statt eines normalen Internetzugangs auch in einer privaten Kunden-VRF landen.

Die Session-Terminierung bleibt identisch. Lediglich das von RADIUS ausgewählte PPP-Profil und damit die Interface-Liste ändern sich.

Über denselben Accessmechanismus können wir dadurch unterschiedliche Services bereitstellen:

• normaler Internetzugang,
• Internetzugang über CGNAT,
• öffentliche IP-Adresse,
• privater MPLS-Zugang,
• verwalteter Standortzugang,
• Zugriff auf eine zentrale Unternehmens-VRF.

Der Accessweg definiert somit nicht automatisch das Produkt.

Ein FTTH-, Richtfunk-, EtherConnect- oder BSA-Anschluss kann abhängig vom zugewiesenen Profil in vollständig unterschiedliche Routingdomänen führen.

Unsere BNGs sind nicht nur PPP-Terminatoren. Sie sind zugleich Provider-Edge-Router innerhalb unseres MPLS-Netzes.

Das Underlay basiert auf einem dynamischen IGP. LDP verteilt die MPLS-Labels. Als Transportadressen verwenden wir stabile Loopback-Adressen, damit die Label- und BGP-Sessions nicht direkt von einzelnen physischen Interface-Adressen abhängig sind.

Jeder BNG unterhält MP-BGP-Sessions zu redundanten Route Reflectors.

Darüber werden unter anderem VPNv4-Routen ausgetauscht:

Die BNGs exportieren dabei nur die für ihre Routingdomänen relevanten Informationen:

• dynamische Teilnehmer-Hostrouten,
• standortspezifische Adresspools,
• definierte Servicepräfixe,
• statische Kundenrouten,
• private MPLS-Routen.

Die vollständige globale Internet-Routingtabelle bleibt auf den Border-Routern.

Ein BNG kann grundsätzlich eine vollständige Internet-Routingtabelle lernen.

In unserer Architektur wäre das jedoch unnötig.

Der BNG muss nicht entscheiden, ob ein Ziel über einen bestimmten Transit, einen Internet Exchange oder ein PNI erreicht wird. Diese Entscheidung gehört an den Internet-Edge.

In seiner Internet-VRF benötigt der BNG im Wesentlichen eine gültige Default Route.

Die Default Routes werden von den Border-Routern über das MPLS-VPN verteilt und mit einer Standortinformation versehen.

Auf jedem BNG bevorzugen wir den lokalen Internetausstieg. Die Default Route des jeweils anderen Standorts bleibt als Fallback verfügbar.

Schematisch:

Solange der lokale Border-Router einen funktionsfähigen Internetpfad bereitstellt, verlässt der Teilnehmerverkehr das Netz am selben Standort.

Fällt dieser Pfad weg, wird automatisch die Default Route des zweiten Standorts aktiv.

Damit erreichen wir lokales Egress-Routing, ohne die BNGs mit der vollständigen Internet-Control-Plane zu belasten.

Das Queueing ist einer der technisch interessantesten Teile unserer BNG-Architektur.

Ein Bandbreitenwert allein beschreibt noch keine funktionierende Dienstgüte.

Ein Anschluss kann im Speedtest die erwartete Datenrate erreichen und sich unter Last trotzdem schlecht verhalten:

• stark ansteigende Latenz,
• hohe Jitter-Werte,
• abgehackte VoIP-Verbindungen,
• verzögerte DNS-Anfragen,
• instabile Videokonferenzen,
• langsame interaktive SSH- oder RDP-Sessions.

Das Problem ist häufig nicht die verfügbare Bandbreite, sondern die Position und das Verhalten der Warteschlange.

Unser Queue-Modell besteht deshalb aus mehreren Schritten:

Wir verwenden Mikrotik-Rate-Limit nicht als zentrales Element unserer Bandbreitensteuerung.

In unserem Aufbau ließ sich damit die gewünschte Kombination aus:

• getrennten Upload- und Download-Klassen,
• CAKE als Queue Discipline,
• gemeinsamen Bandbreitenklassen für verschiedene VRFs,
• dynamischer Teilnehmerzuordnung,
• und hierarchischen Queue Trees

nicht sauber und reproduzierbar abbilden.

RADIUS wählt deshalb das passende PPP-Profil aus.

Das PPP-Profil trägt die Teilnehmeradresse dynamisch in eine definierte Address List ein. Diese Address List bildet anschließend die eigentliche Tarif- beziehungsweise Bandbreitenklasse.

Solange die Session aktiv ist, befindet sich ihre IP-Adresse in RATE-CLASS-A.

Wird die Session beendet, entfernt RouterOS den dynamischen Eintrag automatisch.

Damit ist die Queue-Konfiguration nicht an wechselnde PPP-Interface-Namen oder einzelne Benutzernamen gebunden.

Bei einem asymmetrischen Zugangsprodukt müssen Upload und Download unabhängig voneinander behandelt werden.

Im Upload sehen wir die Teilnehmeradresse als Quelladresse.

Im Download ist die Teilnehmeradresse das Ziel.

Deshalb verwenden wir zwei unterschiedliche Mangle-Regeln:

Das Ergebnis sind zwei unabhängige Packet Marks:

Dadurch kann jede Richtung mit einer eigenen Queue und einem eigenen Limit behandelt werden.

Die Queue-Logik muss dabei nicht wissen:

• welcher Benutzer angemeldet ist,
• auf welchem Accessweg die Session ankommt,
• ob der Teilnehmer eine öffentliche oder private Adresse verwendet,
• auf welchem BNG die Session terminiert.

Sie benötigt ausschließlich die dynamische Zuordnung der Teilnehmer-IP zur jeweiligen Bandbreitenklasse.

Auf dem BNG verwenden wir getrennte Parent-Queues für Upload und Download.

Darunter befinden sich die Leafs der einzelnen Bandbreitenklassen.

Die eigentlichen Tarifklassen werden darunter angeordnet:

Die Parent-Queues definieren den insgesamt verfügbaren Rahmen.

Die Child-Queues bilden die einzelnen Service- und Bandbreitenklassen ab.

Dadurch bleibt die Struktur übersichtlich:

Neue Produktklassen können ergänzt werden, ohne die grundlegende Paketklassifizierung neu aufzubauen.

Als Queue Discipline innerhalb der Leaf-Queues verwenden wir CAKE.

CAKE verbindet mehrere Funktionen:

• Active Queue Management,
• Flow-Isolation,
• kontrollierte Warteschlangen,
• Schutz vor einzelnen dominierenden Datenströmen,
• bessere Latenz unter Last.

Eine klassische FIFO-Queue verarbeitet Pakete im Wesentlichen in der Reihenfolge ihres Eingangs.

Ein einzelner großer Download oder Upload kann dadurch eine lange Warteschlange erzeugen. Kleine, latenzkritische Pakete müssen anschließend hinter großen Datenmengen warten.

CAKE versucht, diese Situation zu vermeiden.

Typische parallele Datenströme sind beispielsweise:

• Cloud-Backups,
• Software-Downloads,
• Videostreaming,
• VoIP,
• Videokonferenzen,
• DNS,
• SSH,
• RDP,
• HTTP/3 und QUIC.

Ohne Active Queue Management kann ein Anschluss weiterhin einen hohen Durchsatz erreichen, während sich die Latenz gleichzeitig vervielfacht.

CAKE hält die Warteschlange kontrolliert und verhindert, dass ein einzelner Flow die komplette Queue dauerhaft belegt.

Ein abstrahierter Queue-Type:

Die Bandbreitenhülle wird durch den Queue Tree vorgegeben. CAKE übernimmt innerhalb der jeweiligen Queue das eigentliche Warteschlangenmanagement.

Die technische Queue-Grenze entspricht nicht zwingend exakt der vermarkteten Datenrate.

Ein als „100 Mbit/s“ beschriebenes Produkt kann sich je nach Messpunkt auf unterschiedliche Ebenen beziehen:

• IP-Nutzdaten,
• PPPoE-Payload,
• Ethernet-Frames,
• DSL-PTM,
• Carrier-Handoff,
• physische Leitungskapazität.

Wird die Queue exakt auf den nominellen Produktwert gesetzt, kann die beim Kunden messbare Nutzdatenrate durch Protokoll- und Encapsulation-Overhead unterhalb des Produkts liegen.

Deshalb erhalten unsere Queue-Klassen einen kontrollierten technischen Headroom.

Dieser Headroom wird nicht geraten, sondern anhand realer Messungen geprüft:

• TCP-Durchsatz,
• UDP-Durchsatz,
• Paketverluste,
• Latenz unter Last,
• unterschiedliche Paketgrößen,
• parallele Flows,
• Upload und Download,
• verschiedene Accessarten.

Zu viel Headroom wäre ebenfalls falsch.

Dann würde sich die eigentliche Warteschlange nicht mehr kontrolliert auf dem BNG, sondern in einem nachgelagerten System bilden – beispielsweise im Accessnetz, im Modem oder an einem Carrier-Handoff.

Das Ziel ist deshalb nicht der größtmögliche Wert.

Das Ziel ist, die relevante Warteschlange an einer Stelle zu halten, an der wir sie kontrollieren können.

CAKE kann nur die Warteschlange beeinflussen, die sich tatsächlich auf dem BNG befindet.

Im Download ist das vergleichsweise gut steuerbar.

Der BNG sieht die Pakete, bevor sie in Richtung Accessnetz gesendet werden. Liegt das konfigurierte Limit knapp unterhalb des tatsächlichen Engpasses, entsteht die Warteschlange kontrolliert auf dem BNG.

Im Upload ist die Situation anders.

Wenn der Kundenrouter bereits mehr Daten in eine langsame DSL- oder Funkstrecke sendet, als diese übertragen kann, entsteht die Warteschlange möglicherweise schon:

• im Kundenrouter,
• im Modem,
• am Funkinterface,
• im Access Node,
• oder im DSLAM.

Bis das Paket unseren BNG erreicht, hat es diesen Engpass bereits passiert.

Der BNG kann den eingehenden Datenstrom anschließend klassifizieren, begrenzen und zwischen Flows fairer verteilen. Er kann aber keine Warteschlange rückwirkend beseitigen, die bereits im Accessnetz entstanden ist.

Active Queue Management wirkt nur vollständig, wenn die kontrollierte Queue am tatsächlichen Engpass sitzt.

Für eine vollständig kontrollierte Upload-Latenz kann daher zusätzlich ein passendes Queueing auf dem Kundenrouter oder innerhalb des Accessnetzes erforderlich sein.

Damit Mangle, Queue Tree, Firewall und Accounting die Teilnehmerpakete sehen, müssen diese Pakete den normalen RouterOS-Paketpfad durchlaufen.

Schematisch gehören dazu Einstellungen wie:

Das erhöht die CPU-Last.

Für einen reinen Transitrouter wäre es sinnvoll, möglichst viele Pakete über FastPath oder Hardware-Offloading zu verarbeiten.

Ein BNG hat jedoch eine andere Aufgabe.

Er muss:

• PPPoE-Sessions terminieren,
• Pakete klassifizieren,
• Queue-Regeln anwenden,
• Firewall-Policies ausführen,
• dynamische Routingzustände erzeugen,
• Accounting-Daten erfassen.

Ein Paket, das diese Verarbeitungsschritte umgeht, ist aus Sicht des BNGs nicht schneller verarbeitet, sondern an der vorgesehenen Service-Policy vorbeigelaufen.

Deshalb planen wir die Plattformkapazität nicht anhand eines einzelnen maximalen Herstellerwerts.

Relevant sind Messungen unter realistischen Bedingungen:

• aktives PPPoE,
• aktive Mangle-Regeln,
• aktive Queue Trees,
• CAKE,
• RADIUS-Accounting,
• viele parallele Sessions,
• kleine Pakete,
• viele gleichzeitige Flows,
• Session-Auf- und -Abbau.

Ein Speedtest mit einer einzelnen PPPoE-Session ist kein BNG-Benchmark.

Bei unserer direkten PPPoE-Architektur treffen mehrere Encapsulation Layer aufeinander:

Bei Wholesale-Verbindungen kommt zusätzlich L2TP als Transportebene hinzu.

Wir betrachten deshalb nicht nur die MTU eines einzelnen Interfaces, sondern die vollständige Encapsulation Chain.

• Core-Transport – Spielraum für MPLS-Labels und Transport-Header
• VPLS-Service – Transport vollständiger Ethernet-Serviceframes
• PPPoE – Teilnehmer-MTU und MRU
• L2TP – Transport der PPP-Session über das IP-Netz
• TCP – MSS-Anpassung als Schutz vor PMTUD-Problemen

Die PPPoE-Teilnehmer-MTU liegt typischerweise unter der normalen Ethernet-MTU.

Zusätzlich verwenden wir TCP-MSS-Anpassungen auf den relevanten Servicepfaden.

Ein schematisches Beispiel:

Es gibt dabei keinen universellen MSS-Wert, der für jedes Netz richtig ist.

Der korrekte Wert hängt vom vollständigen Transportweg ab:

• native Ethernet-Verbindung,
• VPLS,
• MPLS-Label-Stack,
• GRE,
• IPsec,
• L2TP,
• zusätzliche Carrier-Encapsulation.

Wir prüfen deshalb nicht nur einfache ICMP-Erreichbarkeit, sondern unter anderem:

• ICMP mit gesetztem DF-Bit,
• unterschiedliche Paketgrößen,
• TCP-MSS während des Handshakes,
• TLS-Verbindungen,
• HTTP/2,
• QUIC und HTTP/3,
• lokale und redundante Transportpfade.

Ein erfolgreicher Ping mit 64 Byte beweist lediglich, dass kleine ICMP-Pakete funktionieren.

Unsere Redundanz besteht nicht aus einer einzelnen Funktion.

Sie setzt sich aus mehreren unabhängigen Ebenen zusammen:

1. Redundanz der BNG-Standorte,
2. Redundanz der BSA-Erreichbarkeit,
3. Redundanz der Access- und Transportwege,
4. Redundanz des MPLS- und Internet-Cores.

Beide BNGs sind aktive Serviceknoten.

Sie verfügen über:

• eigene LNS-Serviceendpunkte,
• eigene Teilnehmerpools,
• eigene Verbindungen in das MPLS-Core,
• MP-BGP-Sessions zu redundanten Route Reflectors,
• Zugriff auf dieselben zentralen AAA-Dienste,
• lokale und entfernte Internet-Default-Routen.

Was wir nicht haben, ist eine vollständige zustandsbehaftete Synchronisation aller laufenden PPP-Sessions zwischen beiden BNGs.

Eine aktive PPP-Session enthält unter anderem:

• Authentifizierungsstatus,
• Session-ID,
• lokale und entfernte Adresse,
• dynamische Routinginformationen,
• Accounting-Zustand,
• Queue-Zuordnung,
• Paket- und Bytezähler.

Fällt der terminierende BNG vollständig aus, muss die Session daher neu aufgebaut werden.

Der CPE oder der Wholesale-LAC verbindet sich anschließend mit einem erreichbaren BNG. RADIUS authentifiziert den Teilnehmer erneut, das Produktprofil wird wieder angewendet und die notwendigen Routen werden erneut erzeugt.

Das ist kein hitless Session-Failover.

Es ist ein kontrollierter und automatisierter Wiederaufbau des Dienstes.

Die BSA-Erreichbarkeit wird durch die Kombination aus spezifischer /32-Route und übergeordneter /24-Route abgesichert.

Der dedizierte CrossConnect ist der bevorzugte Weg.

Fällt dieser aus, bleibt der LNS-Serviceendpunkt über unsere regulären BGP-Anbindungen erreichbar.

Damit hängt die BSA-Übergabe nicht ausschließlich von einem einzelnen physischen CrossConnect ab.

An Standorten mit erhöhten Verfügbarkeitsanforderungen setzen wir bereits auf zwei unabhängige Transportwege in unseren Backbone.

Dabei kann es sich beispielsweise um unterschiedliche:

• Carrier,
• Trassen,
• Übergabepunkte,
• physische Medien,
• Funk- und Leitungswege

handeln.

Der Standort wird damit nicht nur auf BNG- oder Core-Ebene redundant ausgelegt, sondern bereits auf der Accessseite.

Je nach technischer Ausprägung kann der Layer-2-Service über beide Wege bereitgestellt oder bei einem Ausfall über den alternativen Transportpfad neu aufgebaut werden.

Damit schützen wir nicht nur gegen den Ausfall eines BNGs, sondern auch gegen deutlich häufigere Fehlerbilder:

• Carrier-Störung,
• beschädigte Glasfaser,
• ausgefallener Richtfunkpfad,
• gestörter Übergabeport,
• Fehler an einem einzelnen Access-PoP,
• Ausfall einer Transportkomponente.

Die BNG-Redundanz wird dadurch um eine echte Redundanz am Kundenstandort ergänzt.

Ein BNG ist ein exponierter Serviceknoten.

Entsprechend restriktiv behandeln wir seine Management- und Accessflächen.

Zu den Betriebsmaßnahmen gehören unter anderem:

• zentrale Logs für PPP, PPPoE, L2TP und RADIUS,
• regelmäßiges RADIUS-Interim-Accounting,
• SNMP-Monitoring,
• zentrale Zeitversorgung,
• automatisierte Off-Device-Konfigurationssicherungen,
• beschränkter Managementzugriff,
• deaktivierte nicht benötigte Dienste,
• deaktivierter MAC-basierter Administrationszugriff,
• explizite Allowlisting-Regeln für Wholesale-LACs,
• Routingfilter auf externen Service-Peerings,
• Überwachung der BGP-, LDP- und OSPF-Nachbarschaften.

Ein privater Carrier-Link wird dabei nicht automatisch als vertrauenswürdiges internes Netz behandelt.

Auch ein dedizierter BSA-CrossConnect bleibt ein externer Serviceübergang.

Zulässige Gegenstellen und Protokolle werden explizit freigegeben. Andere Zugriffe werden verworfen beziehungsweise protokolliert.

Im Fehlerfall müssen wir nachvollziehen können:

• auf welchem BNG die Session terminiert war,
• über welchen Accesspfad sie angekommen ist,
• welche Circuit-ID übergeben wurde,
• welches Profil RADIUS geliefert hat,
• welche IP-Adresse verwendet wurde,
• welcher VRF die Session zugeordnet war,
• welche Queue-Klasse gegriffen hat,
• wann die Session aufgebaut und beendet wurde,
• warum sie gegebenenfalls getrennt wurde,
• welcher Internet- oder MPLS-Pfad aktiv war.

Erst dann lässt sich ein Fehler zwischen CPE, Accessnetz, LAC, L2TP, PPP, RADIUS, Queueing, MPLS, CGNAT und Internet-Edge systematisch eingrenzen.

RouterOS stellt die wesentlichen Komponenten unseres BNG-Cores auf einer einheitlichen Plattform bereit:

• PPPoE und L2TP,
• RADIUS AAA und Accounting,
• dynamische PPP-Profile,
• Interface- und Address Lists,
• VRFs,
• OSPF,
• MPLS und LDP,
• MP-BGP und VPNv4,
• VPLS,
• Firewall und Mangle,
• Queue Tree und CAKE.
• Dadurch können wir eine Teilnehmer-Session von der Accessübergabe bis zur MPLS-VRF auf demselben Serviceknoten verarbeiten.

Die Stärke liegt dabei nicht in einer einzelnen Funktion.

Sie liegt im Zusammenspiel:

Das bedeutet allerdings nicht, dass ein MikroTik-Router automatisch für jede beliebige BNG-Größe geeignet ist.

PPPoE, Firewalling, Mangle, Queue Tree und AQM benötigen CPU-Ressourcen. Wer FastPath bewusst deaktiviert, muss die daraus resultierende Last realistisch einplanen.

Auch die Anzahl dynamischer Sessions, Routen, Address-List-Einträge und paralleler Flows muss unter realen Bedingungen getestet werden.

Unsere Skalierungsstrategie besteht deshalb nicht darin, einen einzelnen Router immer weiter aufzurüsten.

Wir setzen auf:

• klar definierte BNG-Knoten,
• mehrere Standorte,
• standortspezifische Teilnehmerpools,
• redundante Access- und Routingpfade,
• eine zentrale AAA- und Policy-Ebene,
• die Möglichkeit, weitere Terminationspunkte hinzuzufügen.

Der Accessweg definiert nicht das Produkt

Ob FTTH, Richtfunk, Wireless DSL, EtherConnect oder BSA über L2TP – alle Wege landen im selben BNG-Core. Was der Teilnehmer bekommt, entscheiden RADIUS und das PPP-Profil, nicht der Anschluss.

Routing-Service und Bandbreitenklasse werden getrennt modelliert

Die Interface-Liste bestimmt die VRF, die Address List die Queue-Klasse. Ein öffentlicher und ein CGNAT-Zugang können dieselbe Bandbreitenklasse verwenden, ohne im selben Routingkontext zu landen.

Die Session erzeugt ihre eigenen Zustände

Beim Aufbau trägt sich die dynamische PPP-Schnittstelle selbst in Interface-Liste und Address List ein, beim Abbau verschwinden die Zuordnungen wieder. Es gibt keine statischen Hostrouten pro Kunde und keine manuelle Umschaltung zwischen den BNGs.

Der BNG braucht keine vollständige Internettabelle

Eine standortbezogene Default Route reicht. Die globale Routingentscheidung gehört an den Internet-Edge, nicht auf den Serviceknoten.

Queueing entscheidet über die gefühlte Qualität, nicht die reine Bandbreite

Queue Tree und CAKE halten die Warteschlange an einer Stelle, die wir kontrollieren. Der technische Headroom wird gemessen, nicht geraten – zu viel ist genauso falsch wie zu wenig.

Active Queue Management wirkt nur am tatsächlichen Engpass

Im Download gut steuerbar. Im Upload endet unsere Kontrolle dort, wo die Warteschlange bereits im Kundenrouter, im Modem oder im Accessnetz entsteht.

FastPath ist nicht das Ziel

Ein Paket, das Mangle, Queue Tree und Accounting umgeht, ist nicht schneller verarbeitet – es ist an der Service-Policy vorbeigelaufen. Kapazität planen wir deshalb mit realen Messungen, nicht mit einem Herstellermaximum.

Redundanz ist mehrschichtig – aber kein hitless Failover

Zwei aktive BNG-Standorte, /32-plus-/24-Erreichbarkeit der BSA-Endpunkte und doppelte Transportwege sichern den Dienst. Fällt der terminierende BNG aus, wird die Session neu aufgebaut – kontrolliert, aber nicht unterbrechungsfrei.

MTU ist eine Eigenschaft des gesamten Pfades

Nicht die eines einzelnen Interfaces. Ethernet, MPLS, VPLS, PPPoE, teils L2TP – die vollständige Encapsulation Chain zählt. Ein erfolgreicher 64-Byte-Ping beweist gar nichts.

Unser BNG-Core ist kein isolierter PPPoE-Server.

Er ist die Verbindung zwischen Access, AAA, Queueing, Routing und den eigentlichen IP-Services innerhalb von AS204197.

Die zentrale Verarbeitungskette sieht dabei so aus:

Der Accessweg kann dabei unterschiedlich aussehen:

• aggregierte FTTH-Anschlüsse,
• direkte Layer-2-NNIs,
• Richtfunk- und Wireless-DSL-Netze,
• EtherConnect-Verbindungen,
• Wholesale- und BSA-Anschlüsse über L2TP.

Das dahinterliegende Produkt bleibt trotzdem nach denselben Regeln definiert.

Auch die Erreichbarkeit der Serviceendpunkte hängt nicht ausschließlich an einer einzelnen Verbindung. Der dedizierte BSA-CrossConnect wird durch die globale Erreichbarkeit des übergeordneten Präfixes ergänzt. Ausgewählte Kundenstandorte erhalten zusätzlich zwei unabhängige Transportwege in unseren Backbone.

MikroTik ist dabei die technische Plattform.

Der eigentliche BNG-Core entsteht jedoch erst durch das Zusammenspiel aus:

• PPP,
• RADIUS,
• dynamischen Profilen,
• Address Lists,
• Queue Tree und CAKE,
• VRFs,
• MPLS,
• MP-BGP,
• Routing Policies,
• Monitoring,
• und einem nachvollziehbaren Redundanzmodell.

Genau diese Kombination macht aus einer einfachen Teilnehmerverbindung einen kontrollierten und reproduzierbaren IP-Service.