Das deckt sich auch mit meinen Praxis-Erfahrungen. Solange man einen Bogen um die teure rote Telefonanlage macht, läuft der Kram eigentlich.
Konnte ich jetzt aus Erfahrungen des ex AG nicht bestätigen. Abseits der 2.4GHz WLAN Problematik liefen alle 7530(AX)/7590(AX) an L2- und L3BSA sowie an eigenen DSLAMs immer hervorragend. Als Modem wurde zuerst das Zyxel VMG1312-B30A eingesetzt (bis max. VDSL100 Profil17a), und später auf das Draytek Vigor2765 gewechselt.
Meh, auch heute noch bekommst Du Router mit alten 1-2 core MIPS CPUs die sich schon fuer weniger als SQM/Traffic-Shaping strecken muessen (die machen PPPoE+NAT+Firewall+WLAN nicht annaehernd nahe Wirespeed,
Nicht so schnell, ein QCA9558 ist mit einem (!) 700MHz-MIPS Core schnell genug, um Header mit Gigabit Wirespeed umzuschreiben: also WAN-Ethernet<->LAN-Ethernet (IP-Adresse+Port umschreiben + Checksumming). Natürlich haben alle OEM-Firmware-Nutzer dafür den effizienten netfilter/iptables aus dem Linux-Kernel verwendet.
Von PPPoE-Wirespeed (!) war dabei nie die Rede, aber das ein Problem, das man nur in komischen Märkten mit Speziallocken hat. 
Deshalb braucht hier auch keiner von 8 Gbit/s PPPoE über XGS-PON träumen. Gibt keine Hardware, die das kann.
Konnte ich jetzt aus Erfahrungen des ex AG nicht bestätigen. Abseits der 2.4GHz WLAN Problematik liefen alle 7530(AX)/7590(AX) an L2- und L3BSA sowie an eigenen DSLAMs immer hervorragend. Als Modem wurde zuerst das Zyxel VMG1312-B30A eingesetzt (bis max. VDSL100 Profil17a), und später auf das Draytek Vigor2765 gewechselt.
Die Rede war von der Verwendung des eingebauten Modems.
Nicht so schnell, ein QCA9558 ist mit einem (!) 700MHz-MIPS Core schnell genug, um Header mit Gigabit Wirespeed umzuschreiben: also WAN-Ethernet<->LAN-Ethernet (IP-Adresse+Port umschreiben + Checksummin, 9.28 g). Natürlich haben alle OEM-Firmware-Nutzer dafür den effizienten netfilter/iptables aus dem Linux-Kernel verwendet.
Von PPPoE-Wirespeed (!) war dabei nie die Rede, aber das ein Problem, das man nur in komischen Märkten mit Speziallocken hat.
Deshalb braucht hier auch keiner von 8 Gbit/s PPPoE über XGS-PON träumen. Gibt keine Hardware, die das kann.
hmpf ja, es soll z.B. auch der Bpi-R3 bei PPPoE nur so für ca. 900–1000 Mbps reichen, beim bpi-r4 soll es bspw. die volle 1gbits erreichen (aber da gibts momentan noch en bug, mit irqBalance soll man aber wohl etwas Abhilfe schaffen können). aufjedenfall soll mit fertiger LRO implementation openwrt auf dem Bpi-R4 bei PPPoE mit über 1Gbits ermöglichen, 9.28 Gbits/sec soll es jetzt schon erreichen
Von PPPoE-Wirespeed (!) war dabei nie die Rede, aber das ein Problem, das man nur in komischen Märkten mit Speziallocken hat.
Ah, OK, Du hatte vergessen, dass das Dein Steckenpferd ist (AVM-Bashing und PPPOE-Ablehnung, beides Dir zustehende Meinungen).
Deshalb braucht hier auch keiner von 8 Gbit/s PPPoE über XGS-PON träumen. Gibt keine Hardware, die das kann.
Wuerde mich wundern wenn das nicht mit z.B. einer ueber-Atom-Klasse x86_64 CPU erreichbar waere...
Ein MSAN wird per E-Tree auf mehrere PPPoE AC/BNGs geschaltet, Endgerät sucht sich den passenden BNG aus (hart gewählt oder derjenige, der am Schnellsten antwortet), und baut einen eindeutigen Tunnel auf. Keine Probleme bei Wartungsarbeiten im Netz durch DHCP Timer, die vorher angefasst und hinterher wieder angefasst werden müssen, denn Tunnel weg -> Routen weg.
Da die DTAG hier dieselben BNGs eingesetzt hat, wie der ISP für den ich gearbeitet hab, würde mich das sehr wundern, wenn es dabei zu Problemen gekommen wäre.
Sehr interessant, weiß eigentlich jemand, ob die Telekom bei Standard-Anschlüssen auch Failover zu anderen BNGs betreibt? Bei MPLS wird einiger Aufwand betrieben (Failover zu benachbartem BNG, Vermeidung von Brücken usw.), aber bei "einfachen" Anschlüssen, so mein Eindruck, ist die prähistorische Zuteilung über den Vorwahlbereich heilig.
Dafür spräche allerdings, dass hier mal Einblasarbeiten stattgefunden haben und eine Nachbarin die ausführende Firma (in der Hoffnung auf besseres Internet) befragt hatte: Es wurde ein "LWL-Querkabel" gelegt, und zwar von Vermittlungsstelle A in den benachbarten Ort mit Vermittlungsstelle B, welche grundsätzlich aber an einen anderen BNG angeschlossen ist.
Mmmh, ich hatte das eher interpretiert als: BNGs am selben BNG-Standort?
hmpf ja, es soll z.B. auch der Bpi-R3 bei PPPoE nur so für ca. 900–1000 Mbps reichen,
Der PPPoE Client in OpenWrt ist single-threaded und nicht hardware-beschleunigt und daher etwas CPU-hungrig, braucht es entsprechend leistungsfaehige System (CPUs und Speicher und IP-Bandbreite).
Der PPPoE Client in OpenWrt ist single-threaded und nicht hardware-beschleunigt und daher etwas CPU-hungrig, braucht es entsprechend leistungsfaehige System (CPUs und Speicher und IP-Bandbreite).
ja, deswegen schrieb ich ja Bpi-R4 ist sehr wahrscheinlich dazu fähig. mal sehen was für Werte kommen wenn LRO im Upstream ist
Wenn ich auf dem bpi4-r4 NAT-Offloading via HW aktiviere, habe ich bei 500 Mbps Last keine messbare CPU-Last, sie verbleibt bei 99% idle.
Ich kann mir nicht vorstellen, dass der PPPoE-Client derart gut optimiert ist. Wenn ja, ist der für mehrere Dutzend Gbps gut.
Edit: Ich sehe gerade, dass der auf dem bpi4-r4 eingesetzte MediaTek Filogic einer der wenigen Chips ist, die PPPoE in HW beschleunigen. Das erklärt, weshalb ich nur CPU-Last beim NATting sehe.
Ich kann mir nicht vorstellen, dass der PPPoE-Client derart gut optimiert ist. Wenn ja, ist der für mehrere Dutzend Gbps gut.
ja, das ist halt die Frage!
ich hatte bisher nur den Bpi-R3 eingesetzt
Edit: Ich sehe gerade, dass der auf dem bpi4-r4 eingesetzte MediaTek Filogic einer der wenigen Chips ist, die PPPoE in HW beschleunigen. Das erklärt, weshalb ich nur CPU-Last beim NATting sehe.
Genau das schränkt dann die Hardware-Auswahl wieder auf wenige SoCs ein und dementsprechend übel sieht dann auch das Router-Angebot auf dem deutschen Hardware-Markt aus (und alles aus dem Ausland ist inkompatibel).
Und dann wundert man sich, warum >95% irgendwelche OEM-Büchsen von zwei Herstellern sind und der Tarif einfach nur möglichst billig sein muss.
Und natürlich darf man auch mit Hardware-Beschleunigung immer Angst vor sowas haben:
Nur mit proprietärem Mediatek-SDK auf dem Stand von 2021 gibt es die volle PPPoE-Geschwindigkeit (und gratis viele schöne Sicherheitslücken). Also nichts geht mit Magenta Fiber 2000. Das Ding routet natürlich ohne Probleme 2.5G-Ethernet-NAT-Wirespeed.
mal sehen was für Werte kommen wenn LRO im Upstream ist
Unklar was LRO da bringen soll, das funktioniert i.d.R. nicht mit PPPoE Verkapselung...
Edit: Ich sehe gerade, dass der auf dem bpi4-r4 eingesetzte MediaTek Filogic einer der wenigen Chips ist, die PPPoE in HW beschleunigen. Das erklärt, weshalb ich nur CPU-Last beim NATting sehe.
Ja, das ist etwas anderes als uebliches LRO...
Genau das schränkt dann die Hardware-Auswahl wieder auf wenige SoCs ein und dementsprechend übel sieht dann auch das Router-Angebot auf dem deutschen Hardware-Markt aus (und alles aus dem Ausland ist inkompatibel).
Ausser dass die BananaPis um die es hier geht aus dem Ausland kommen und gar nicht speziell fuer den deutschen Markt entwickelt wurden*. Und das sie Auswahl an Router-SoCs recht begrenzt ist ist auch nichts neues, haengt halt auch davon ab, dass es gar nicht so viele Herstellen von WiFi Chipsaetzen fuer APs gibt.
Und dann wundert man sich, warum >95% irgendwelche OEM-Büchsen von zwei Herstellern sind und der Tarif einfach nur möglichst billig sein muss.
Meh, sind schon ein paar mehr als 2 (die Provider-CPE kommen von mehr als 2 Fertigern), aber die Anzahl der echten Hersteller der Hardware ist auch nicht unendlich
*) Und Mediatek sitzt in Taiwan und hieten es anscheinend fuer ausreichend wichtig PPPoE Offload zu implementieren, entweder ist der deutsche Markt wichtiger als Du meinst, oder aber (mein Verdacht) ist PPPoE gar keine komplett deutsche Sonderlocke.
Ja, das ist etwas anderes als uebliches LRO...
also jetzt alles klar?
Genau das schränkt dann die Hardware-Auswahl wieder auf wenige SoCs ein und dementsprechend übel sieht dann auch das Router-Angebot auf dem deutschen Hardware-Markt aus (und alles aus dem Ausland ist inkompatibel).
warum ist alles aus dem Ausland inkompatibel?
ja, das ist halt die Frage!
ich hatte bisher nur den Bpi-R3 eingesetzt
Auch der SoC unterstützt HW-Beschleunigung bei PPPoE.
Mediatek sitzt in Taiwan und hieten es anscheinend fuer ausreichend wichtig PPPoE Offload zu implementieren
Einem SoC-Lieferanten geht's da nicht um "wichtig", für das Feature wird irgendein OEM 2021 schlicht bezahlt haben. Deshalb ist es proprietär. Und für 8G XGS-PON gibt es dann immer noch nichts.
LRO steht i.d.R. fuer Large Receive Offload und da "klebt" die Netzkarte/deren Treiber TCP Segmente eines 5-tupels direct aneinander und kann dadurch statt 10 einzelner 1500 Byte Segmente ein einzigen ca. 15000 Byte TCP Packet an den Kernel schicken und das muss dann nur einmal anfasst werden statt 10 mal. Aber damit das funktioniert muessen:
a) ausreichend viele aufeinanderfolgende Segmente eines TCP-Flows zeitnah bei der NIC eintreffen
b) diese muessen direkt lesbar sein, was bei PPPoE halt nur gegeben ist, wenn die NIC das kann.
c) Funktioniert nur mit TCP und z.B. nicht mit QUIC
Linux GSO (die Software Variante von LRO) kann wohl auch durch PPPoE hindurch agieren, aber das ist halt GRO nicht LRO.
Einem SoC-Lieferanten geht's da nicht um "wichtig", für das Feature wird irgendein OEM 2021 schlicht bezahlt haben. Deshalb ist es proprietär. Und für 8G XGS-PON gibt es dann immer noch nichts.
Warum sollte der bpi4-r4 damit ein Problem haben?
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
