Glasfaser GPON Modul / DEC 750 SFP-Ports / Leistung & Link Speed

[genfai]

Hallo zusammen,

vor ein paar Tagen hatte ich schon mal im englischsprachigen Hardware and Performance Subforum geschrieben, konnte mich dort aber glaube nicht ganz verständlich machen. Das deutschsprachige Forum hatte ich glatt übersehen.

Folgendes Szenario:

Vodafone Glasfaser mit PPPoE Einwahl und 1000/500 Bandbreite. Vodafone stellt einen einfachen ONT von Huawei mit einem einzelnen 1 GBit Port bereit. Offiziellen Support für eigene Geräte gibt es nicht. Schließt man den ONT regulär per LAN an der DEC 750, erhält man 940/510, also das Gigabit Ethernet Limit im Downstream.

Getestet werden soll, ob man auf den ONT verzichten und durch Direktanschluss der Glasfaser die gebuchte Bandbreite erreichen kann.

Dafür habe ich zwei GPON Module (Lancom und Zyxel) jeweils mit den Daten des ONT konfiguriert, in einen der SFP-Ports der DEC 750 gesteckt und die Glasfaser verbunden. Die Konfiguration funktioniert grundsätzlich und man bekommt stabiles Internet ohne Übertragungsfehler.

Beide Module verbinden sich auf der SFP-Seite allerdings nur mit 1 GBit SGMII und die messbare Bandbreite fällt konstant auf 780/480.

Zumindest das Zyxel Modul unterstützt auch 2,5 GBit HGSMII auf der SFP-Seite. Die SFP-Ports unterstützen das aber wohl nicht? Ich habe in den FreeBSD Treiber Commits verweise auf 2,5 GBit gefunden, verstehe das aber leider nicht weiter. Egal, was ich im Menü von OPNsense auswähle, die Verbindung wird immer nur als 1 GBit SGMII angezeigt. Ich nehme an, die Ports oder Treiber unterstützen schlicht nur 1 GBit und 10 GBit?

Was ich habe gar nicht verstehe, ist die verschlechterte Bandbreite von 780/480. Hier sollte ja zumindest das gleiche wie beim Anschluss des ONT per LAN herauskommen. Gibt es da eine Idee zu? Die Verbindung des Moduls wird im OPNsense Dashboard mit 1 GBit SGMII sowie rxpause und txpause aktiviert angezeigt. Wenn ich das an anderer Stelle richtig verstanden habe, sollte das deaktiviert werden und könnte die Ursache sein? Allerdings habe ich keinen Weg gefunden, das in OPNsense für die SFP-Ports der DEC 750 abzuschalten.

In einem getesteten Unify-Gerät lässt sich für das Zyxel-Modul 2,5 GBit erzwingen und man erhält messbar 1040/510, sprich alles inkl. Overprovisioning von Vodafone.

[meyergru]

Im SFP+ Slot kann ich auch für 10 GbE-Module, die auch 2.5 und 5 GBit/s unterstützen, diese Geschwindigkeiten nicht manuell auswählen. Offenbar wird als Signalisierung nur 1 und 10 GBit/s unterstützt.

Wenn also 2.5 GBit/s z.B. per Auto-Negotiation genutzt werden, wird trotzdem 10 GBit/s angezeigt. Das Verhalten kenne ich auch von Cisco-Switches.

Ich weiß nicht einmal, ob es standardisiertes Signaling bzw. Auswahl der echten Geschwindigkeit für andere Raten als 1 und 10 GBit/s gibt oder ob die Module bzw. das Gerät das jeweils auch können.

Ich hatte übrigens das selbe vor wie Du, bin aber schon bei der Herstellung der Verbindung als solches gescheitert und verwende jetzt den Huawei-ONT.

[genfai]

Die Verbindung selbst war erstaunlicherweise kein Problem. Der ONT wurde mit Standardzugang geliefert und das Passwort/PLOAM ließ sich damit auslesen. Das zusammen mit der Seriennummer in den GPON-Modulen gesetzt und in das DEC 750 gesteckt. Die wurden direkt erkannt und ließen sich normal konfigurieren. Ich hatte das auch über ein Wochenende laufen und gehofft, dass zumindest die auf 780/480 verringerte Bandbreite ggü. dem per Ethernet angeschlossenen ONT nur netzseitige Überlastung war. Nach dem Rückbau zum ONT waren aber sofort wieder die 940/510 verfügbar.

Das Zyxel Modul kann man per Shell auf 2.5 GBit zwingen. Der getestete Unify-Router hat damit eine "unbekannte Verbindung" angezeigt, aber ansonsten hat es funktioniert. In den SFP-Ports des DEC 750 wird das Modul dann gar nicht erkannt. Ich bin leichtfertig davon ausgegangen, dass wenn 2.5 und 5 GBit unterstützt werden, jenes auch für die SFP-Seite gilt. Aber hier wird dann vermutlich immer mit 10 GBit verbunden, egal was auf der Ethernet/Fiber-Seite ausgehandelt wird. Das können die GPON-Module nicht und deshalb Fallback auf 1 GBit. Wobei ich nirgendwo die genauen Spezifikationen der AMD SFP-Ports des Ryzen 1500 im DEC 750 finden konnte und ob das nun nur eine Treiberfrage oder eine Limitation der Hardware ist.

Das ist so aber zumindest nachvollziehbar. Warum die Bandbreite mit den GPON Modulen allerdings jeweils auf 780/480 fällt, ist mir nach wir vor nicht ganz klar. Verwendet man das Lancom Modul in einem Lancom Router, gibt es wieder die volle Bandbreite am Ethernet Limit mit 940/510. Es liegt also nicht am Modul oder dem Zusammenspiel mit dem OLT bei Vodafone.

[meyergru]

Eventuell irgendein internes Buffering was dann Ethernet Flow Control benötigt. Hast Du das mal angeschaltet?

Müsste etwas in dev.ax.0.rx_pause oder tx_pause sein. Eventuell lassen sich mit sysctl auch die Probleme sehen (Statistik). Um hohe Geschwindigkeiten zu erreichen, sollte man auch RSS einschalten, da gibt es ein paar Threads dazu.

Ich stoße aktuell nicht an die Barriere, weil ich bei M-Net einen Tarif mit 600 MBit/s habe, der aber tatsächlich 680 bringt. Der Preis-Uplift auf 1000 skaliert somit nicht - schon gar nicht, wenn dann nur 950 (oder noch weniger) geht.

[genfai]

dev.ax.<x>.rss_enabled
Ist per Standard vorhanden und aktiviert. Deaktivieren hatte keinen messbaren Effekt.

dev.ax.<x>.rx_pause
dev.ax.<x>.tx_pause
Das habe ich jeweils aktiviert als auch deaktiviert getestet. Ich hatte im Netz gelesen, dass man es ggf. deaktivieren sollte. Sofern das Dashboard nichts Falsches anzeigt, wird Deaktivieren allerdings nicht umgesetzt, es bleibt immer eingeschaltet.

dev.ax.<x>.link_workaround
dev.ax.<x>.sph_enable
Damit hatte ich auch noch experimentiert. (Zugegeben aber nur weil "sysctl -a | grep dev.ax" das als Schalter ausgeworfen hat und ohne zu verstehen, was das genau bewirkt.)

Statistikdaten habe ich leider nicht gespeichert. Muss ich nachts, wenn niemand hier sonst gestört wird, noch mal umstecken. Es gab zumindest keinen packet loss. Latenz war ggü. Anschluss des ONT per Ethernet minimal besser. Rund eine halbe Millisekunde, sofern man das nicht als Messtoleranz bezeichnen will. Die CPU war nicht ausgelastet.

Im Code für den Treiber wird übrigens 2.5G erwähnt inkl. "gmii_2500".
https://reviews.freebsd.org/D25793

Den Code verstehe ich aber nur sehr eingeschränkt und habe auch unter opnsense nirgendwo gefunden, welche Treiberversion überhaupt verwendet wird. Per grep bekommt man nur AMD 10 GBit Ethernet ausgeworfen.

Den GBit Tarif gab es hier das erste Jahr zum Preis des kleinsten. Aber das geht hier ohnehin durch zwei Parteien, so dass das auch später human bleibt.

[meyergru]

Ich habe mir das Telekom / Zyxel jetzt mal bestellt, dann kann ich den Huawei ONT dekommissionieren.

Aber zu Deinem Geschwindigkeits-Problem: Es scheint doch eine Limitation des SFP-Moduls zu sein, denn hier werden auch limitierte Werte gemeldet - aber an einem Mikrotik-Switch:

https://www.computerbase.de/forum/threads/eigenes-modem-an-ftth-anschluss-via-sfp-gpon-modul.2061989/page-13#post-26834775

Soweit ich es verstanden habe, verwendet sowohl das Huawei MA5671A als auch das ZyXEL PMG3000-D20B intern LANCOM-Chips. Das würde auch erklären, wieso Du mit beiden Modulen die gleichen Werte bekommst.

Das scheint also nicht an der DEC750 bzw. dem axgbe-Treiber zu hängen?

Ich hätte zwar einen Unifi-Switch zum Vergleich, aber ich werde bei meiner Line-Rate ja das Limit sowieso nicht erreichen.

[genfai]

Das Lancom SFP-GPON-1 bzw. eigentlich SPS-34-24T-HP-TDFO, wie ich im Lancom-Forum gelernt habe, war der erste Versuch, weil ich den passenden Lancom Router hatte, um SN/PLOAM damit einfach zu schreiben. Das Zyxel PMG3000-D20B war dann der zweite Test. Konfiguration hatte ich nach folgenden Anleitungen gemacht:

https://github.com/xvzf/zyxel-gpon-sfp
https://blog.jaseg.de/posts/telekom-gpon-sfp/

War so problemlos mit dem DEC 750 und opnsense möglich. Nur daran denken, dass die Shell nur erreichbar ist, wenn die Glasfaser angeschlossen ist, sonst baut der SFP-Link nicht auf.

Interessant bei Deinem Setup wird, ob die rund 740/480 irgendein oberes Limit in der Konstellation sind oder die Konfiguration für irgendeine grundsätzlich Degradierung der Leistung sorgt. Etwas seltsam ist ja ansonsten, dass auch der Upstream bei mir von 510 auf 480 fällt, also nicht die absolute Bandbreite das Problem ist.

Den Computerbase-Thread habe ich gelesen. Dort hatte ich auch die Info her, das/wie man 2.5G beim Zyxel erzwingen kann und den Hinweis auf Flow Control. Wobei sich letzteres im Netz unabhängig der Glasfaser öfter zu opnsense findet. Allerdings hatte ich kein Glück, an den Einstellungen etwas zu ändern. opnsense, der SFP-Port und/oder das Modul ignorieren das anscheinend einfach.

Das MA5671A habe ich nicht, nur noch ein GPON-ONU-34-20BI von FS. Aber alle haben anscheinend als Chipsatz einen Lantiq/Intel PEF98035. Das wusste ich bisher nicht. Muss ich mal schauen, ob ich ein konfigurierbares Modul mit einem anderen Chipsatz zum Testen finde.

Am Modul selbst kann es im Grunde nicht liegen, weil es im Lancom rund die erwartete Bandbreite bringt. Sind dort nur rund 900 MBit, was aber am Prozessor Geräts liegen dürfte. Im Lancom-Forum habe ich allerdings gelernt, dass das Modul dort nicht mit SGM-II verbinden würde, sondern 1000BASE-X. Ich weiß nicht, ob das solche Auswirkungen haben kann. Auswählen konnte ich 1000BASE-X bei opnsense, wurde aber nicht übernommen.

Tendenziell vermute ich tatsächlich, dass es primär ein Treiberproblem ist. In der Liste der unterstützten Hardware von Deciso erscheint kein GPON-Modul. Wurde vermutlich nie getestet. Mehr oder weniger gesichert via 2.5G Link Speed funktioniert es anscheinend nur mit einigen Unify Geräten und einer bestimmten Broadcom Karte.

[meyergru]

War so problemlos mit dem DEC 750 und opnsense möglich. Nur daran denken, dass die Shell nur erreichbar ist, wenn die Glasfaser angeschlossen ist, sonst baut der SFP-Link nicht auf.

Das habe ich jetzt schon mehrfach gelesen - was sieht man dann im Status? Kein Link? Oder nur keine IP?

Ich frage, weil mein MA5671A keinen Link zeigt - weder am Unifi noch am DEC750, ich habe es aber nicht an die Glasfaser angeschlossen. Ich dachte schon, es sei defekt, aber eventuell liegt es nur da dran.

Als ich damals damit herumprobiert habe, ging es prinzipiell, aber ich bekam keine Verbindung zum OLT - inzwischen habe ich in dem Computerbase-Thread eine Info gefunden, die sich mit meinem Verdacht deckt: https://www.computerbase.de/forum/threads/eigenes-modem-an-ftth-anschluss-via-sfp-gpon-modul.2061989/page-2#post-26571921

Ich hatte damals notiert:

Es gibt da noch ein paar subtile Unterschiede, z.B. die OMCC-Version, die im HG8012H höher ist, nämlich 0xb0 statt 0xa0, was bedeutet, dass das extended message set unterstützt wird. Kann also gut sein, dass sich OLT und ONU schon nicht verstehen. Auch der Vendor Code unterscheidet sich (0x45 statt 0xcc, das entspricht wohl dem Präfix der Product ID).

Meine Hoffnung ist ja zunächst, dass das ZyXEL / Telekom einfach mal läuft... dann kommt die Speed-Optimierung. Ich kann mir aber nicht vorstellen, dass das der Treiber ist. Dann dürfte 10 GBit noch viel weniger gehen. Ich tippe da eher auf etwas in Richtung MTU.

[meyergru]

So, habe das MA5671A nochmal reingesteckt. Mit Glasfaser gesteckt ist es online. SSH ging erstmal nicht, weil die Key-Algorithmen nicht passten, aber über die Weboberfläche kam ich in die LuCi-Oberfläche. Mein PLOAM-Status ist 5, aber danach gibt es keinen Verbindungsaufbau per PPPoE.

Mal sehen, wie es mit dem ZyXEL klappt, das scheint ja eine neuere Firmware zu haben, wenn SSH da ohne weiteres geht. Meine Hoffnung ist, dass die OMCC-Version dann auch neuer ist und es dann mit M-Net geht. Sonst habe ich zwei unbrauchbare GPON-Module...

[genfai]

Status O5 sollte eigentlich signalisieren, dass alles erfolgreich erledigt ist.

https://forum.huawei.com/enterprise/en/the-process-for-an-onu-to-go-online-gpon-technical-posts-12/thread/462895-100181

Was die PPPoE-Einwahl betrifft: Hast Du an das passende VLAN gedacht?

https://ubiquiti-networks-forum.de/board/thread/2259-vlan-ids-bei-ftth-dsl/

Bei M-Net soll das VLAN 40 sein. Wenn ich das VLAN 7 bei Vodafone nicht setze, tut sich da auch nichts.

SSH ist bei dem Zyxel ohne Mods oder Basteleien direkt möglich.

Noch zu den Treibern der AMD 10G SFP-Ports. Ich nehme an, dass nicht der Treiber oder die Ports ein Problem mit dem Durchsatz an und für sich haben, sondern SGM-II nicht richtig oder vollständig implementiert ist. Vielleicht wird bei den GPON-Modulen auch grundsätzlich etwas falsch erkannt. Es ist schon recht seltsam, dass die Schalter komplett ignoriert werden. Irgendwo hatte ich einen Post gelesen, in dem jemand die Bandbreite von lokalem 10G gemessen hatte. Das war nahe am Maximum. Grundsätzlich können die Ports und auch die Leistung des DEC 750 das.

Wenn Du Dein Modul zum Laufen bekommst, wäre ich sehr daran interessiert, ob die volle erwartete Bandbreite durchkommt.

[meyergru]

Noch geht nichts, M-Net scheint da irgendwas Spezielles zu machen... siehe https://forum.m-net.de/viewtopic.php?f=23&t=14923 Das ZyXEL verhält sich da genauso wie das Huawei, auch bezogen auf "Interface up nur mit anliegender Glasfaser".

Ich glaube mittlerweile, dass Passwort und S/N 100% korrekt sind, weil der Link-Status mit fehlerhaften Daten anders ist - allerdings: Nur der Link-Status, nicht der ONT-Status, der war immer O5.

Natürlich habe ich an das VLAN 40 gedacht. Konkret ist es ja so, dass ich nur das pppoe0 von igb0_vlan40 (externes ONT) auf ax1_vlan40 (GPON) umschalte, d.h. ich kann mich auch nicht bei den Zugangsdaten vertippen...

Das mit der vollen Bandbreite werde ich nicht testen können, da mein Anschluss nur 600 MBit/s hat.

[genfai]

Der Link zum M-Net Forum führt für mich leider auf eine Login-Seite. Gibt es den noch anders?

Im Lancom-Forum hat jemand Dein beschriebenes Problem mit Deutsche Glasfaser. Auch O5, aber keine Einwahl möglich. Ist jetzt nicht besonders hilfreich. Aber vielleicht mal im Auge behalten, falls sich dort eine Lösung findet:

https://www.lancom-forum.de/viewtopic.php?t=19599&start=15

Jemand hat dort noch auf die Möglichkeit von DS-Lite hingewiesen, falls erforderlich. Wobei das bei Dir ähnlich dem VLAN natürlich nur Sinn machen würde, wenn es ansonsten im ONT geschieht und Du es nicht sowieso schon eingerichtet hast.

Ansonsten vielleicht auf dem WAN-Interface auch noch mal die MAC des ONT spoofen?

Mit der vollen Bandbreite meinte ich tatsächlich die volle Bandbreite Deines Tarifs, in dem Fall also die 600 MBit. Bei mir fällt ja auch der Upstream mit den GPON-Modulen von 510 auf 480. Würde bei Dir im Downstream die Bandbreite ebenfalls sinken, wäre das ein weiteres Indiz für ein Treiberproblem.

[meyergru]

Oh, stimmt, das geht nur mit Anmeldung. Ich hatte dort im Wesentlichen das geschrieben, was ich hier berichtet habe. Einer der M-Net Admins hat aber gesagt, dass außer S/N und Passwort nichts benötigt wird - ich hatte dort schon den Verdacht geäußert, dass es weiterer Dinge bedarf, z.B. OMCC-Version oder MAC. Ich hatte ja bereits ein externes Huawei-ONT mit S/N und Passwort geklont.

Er meinte, dass seiner Erfahrung nach die S/N selten netto übertragen wird und vermutete das Problem dort.

Wiewohl das für das Huawei-Modul ja noch möglich gewesen wäre, ist es beim Telekom-Modul sehr unwahrscheinlich, zudem man die graduelle Änderung bei korrekter S/N sehen konnte:

Code: [Select]

#######################################################
#                                                     #
# Please login to CLI mode. Then You can do commands. #
#                                                     #
#######################################################

Entering character mode
Escape character is '^]'.


Login: admin
Password:
ZYXEL# hal
Hal# show
  ont         show ont parameter
  link        show pon link
  ploam       show ploam
  tcont       show tcont
  gemport     show gemport
  counter     show pon counter
  softfeature show softfeature
  tod1pps     show tod1pps
  speed       show speed
  stream      show stream
  unit        UNI port
  dhcp        dhcp
  pppoe       pppoe
  packet
  extvlan     vlan
  access-list access list
  mac-bind    bind mac address
  mac-filter  filter mac address
  monitor     gemport
  mac         mac
  storm       show storm
  rstp        show rstp
  port        show port
  multicast   show multicast
  i2c         show i2c
  sfp         sfp hardversion
Hal# show ont
Hal# -----------------ONT Info-----------------
OMCC state   : Ready
ONU ID       : 101
SN           : ZYWNc0e734b4
Password     : 474F56454B4F48455650
Power Level  : 1
Ont State    : O5 OPERATION
Ranging State: UNKNOWN
Admin state  : UNLOCK


Hal# show link
Hal# Link State: O3 SERIAL_NUMBER


Hal# set sn HWTC1cb0cd20
Hal# .set sn success!
unknow speed mode parameter!
unknow speed mode parameter!


Hal# show link
Hal# Link State: O5 OPERATION

Hal# SF_SetFeature: Set feature(10) to 1
SF_SetFeature: Set feature(10) to 1
SF_SetFeature: Set feature(10) to 1


Nächste Woche will der Admin das live mit mir testen, indem er am OLT schaut, was schiefgeht.

Andere Dinge, wie VLAN, DS-Lite usw. kann ich eigentlich ausschließen, weil der Anschluss mit dem externen Modem ja funktioniert.

Nach meiner Vermutung muss das irgendein subtiles Problem auf GPON/OMCI-Ebene sein. Ich habe aber nur begrenzte Kenntnisse, wie man das Problem debuggen kann, da kommt mir die Unterstützung des Experten sehr recht.

[genfai]

Was meinst Du mit netto übertragen?

Ich habe das bei dem Zyxel tatsächlich nur gemacht wie Du, set sn und sn password. Danach hat es abseits der beschriebenen Probleme grundsätzlich funktioniert.

Dass jemand von M-Net diesbezüglich Support leistet ist aber wirklich edel. Die meisten Anbieter wehren sich ja nach Leibeskräften auch nur zuzugeben, dass der Anschluss eigener Hardware nicht sofort das Ende des Universums zur Folge hat.

Gerne so detailliert wie möglich davon berichten!

[meyergru]

Ja, ich werde berichten.

Und zum Thema "netto" siehe https://de.wikipedia.org/wiki/Netto - der Admin meinte, die Boxen übertragen teilweise nicht die Eingabe, sondern noch mehr. Angesichts des Aufbaus der S/N kann ich mir das vorstellen.

Die Notationen unterscheiden sich da ziemlich (hex, dez, mit Hersteller-Präfix). Ich "glaube", dass die Variante vier Zeichen Hersteller und Rest hexadezimal korrekt ist.

Allerdings möchte M-Net bei Fremdgeräten normalerweise folgende Angaben:

-Hersteller
-Seriennummer
-MAC-Adresse
-Modem-ID

Ich will das natürlich nicht, weil dann das M-Net Original-ONT nicht mehr als Fallback ginge.

Was eine "Modem-ID" sein soll, weiß ich nicht, vermutlich ist die Seriennummer in GPON-Notation gemeint ("Seriennummer" kann ja auch eine rein herstellerspezifische Nummer sein, die nicht übertragen wird).

Es sind aber zwei weitere Angaben genannt, nämlich MAC und Hersteller. Die MAC kann eigentlich nicht relevant sein (1. wegen Aussage des Admin und 2. weil ich schon den ONT erfolgreich durch einen mit einer anderen MAC ersetzt hatte).

Es bleibt noch der Hersteller - tatsächlich glaube ich, dass der PLOAM-Level O.K. ist und es dann in der OMCI-Schicht zu Problemen kommt (https://www.youtube.com/watch?v=iyEc0ja8ugk). Das kann die Software-Version oder die Hersteller-Kennung sein (trotz Änderung der S/N ist der Vendor ja immer noch ZxXEL).

Es gibt ein Posting, dass das zu bestätigen scheint: https://www.computerbase.de/forum/threads/eigenes-modem-an-ftth-anschluss-via-sfp-gpon-modul.2061989/page-2#post-26571921

Wenn man nachsieht, was die "Managed Entity class id = 332" ist, findet man in https://www.itu.int/rec/dologin_pub.asp?lang=s&id=T-REC-G.988-201711-I!!PDF-E&type=items in Section 9.13.11 Enhanced Security Control dazu Verschlüsselungsvarianten, das PLOAM Passwort kommt dort auch vor.

Es kann also sein, dass die GPON-Module aufgrund ihrer älteren OMCC-Version diese Angabe nicht unterstützen und nur ein Standardverfahren implementieren.

Interessanterweise bin ich mir aber gar nicht sicher, dass das Passwort tatsächlich benötigt wird. Im Original-Huawei-ONT war es gesetzt, aber in den o.a. Angaben kommt keins vor. Eventuell müsste man das Passwort einfach leer lassen und dann wird die Angabe, wie es verschlüsselt wird, nicht mehr notwendig?

Keine Ahnung - nächste Woche werden wir sehen.