Glasfaser Eigenes Modem an FTTH-Anschluss via SFP GPON Modul

Mixus schrieb:
Hast du nur den hal -> "sn SERIENNUMMER" Befehl genutzt? Der speichert die Seriennummer nicht permanent.
Dazu musst du den hal -> "set sn SERIENNUMMER" Befehl nutzen.
Ja top, das wars. Danke! Jetzt kann ich munter zwischen Zyxel und Huawei sowie dem alten ONT wechseln. Schick!
 
  • Gefällt mir
Reaktionen: KernelMaker und Mettwurscht
Könnte mal jemand das ändern der Seriennummer beim Zyxel SFP Modul bisschen ausführlicher erklären bitte? Geht das über die Linus Shell oder über das Menü vorher wenn man sich mit Tera term auf das Modul verbindet?
 
Besten dank. Da konnte ich die letzte Info finden. Man muß in den Punkt "Hal" rein bevor man die Seriennummer setzten kann. :daumen:
 
Wäre nett wenn nochmal jemand die Länge des dem Zyxel Moduls beiliegenden Glasfaserkabels messen könnte. Danke!
 
  • Gefällt mir
Reaktionen: Mettwurscht, shavenne und Mixus
KernelMaker schrieb:
An die Mikrotik-Fraktion
Es gibt nun scheinbar eine Beta-Firmware mit HSGMII-Support.
https://forum.mikrotik.com/viewtopic.php?t=166000#p926988
Danke an @shavenne für die Info

Sehr gut, gerade mit dem Zyxel Modul auf einem CRS326-24G-2S+ mit der 7.3beta34 getestet und das Modul kommt tatsächlich mit 2.5G hoch.

Achtung: Die nachfolgende Anleitung ist AUSDRÜCKLICH auf eigene Gefahr! Wenn es aus irgendeinem Grund mit eurem Mikrotik Modell nicht klappen sollte, habt ihr ein semi-gebricktes SFP Modul, da sich die Speed Settings nicht nach einem Neustart auf autonegotiation resetten!
Die Speed Settings lassen sich dann nur noch in einem funktionierenden 2.5G Slot, oder via Serieller Konsole (erfordert Löten bei diesem Modul) auf dem Modul anpassen!

Schritte zur Umsetzung:
1. Auf dem Zyxel Modul per SSH einloggen
2. hal Modus ("hal" in die Konsole eintippen)
3. set speed 2.5g mode full
4. Auf dem Mikrotik via Winbox, CLI, oder Webinterface einloggen
5. Teminal öffnen
6. folgende Befehle eingeben:
Code:
/interface/ethernet/
set auto-negotiation=no *SFP SLOT*
set speed=2.5Gbps *SFP SLOT*

Danach kommt das Modul mit 2.5G wieder hoch.
 
  • Gefällt mir
Reaktionen: Mettwurscht, shavenne und KernelMaker
Speedtest bitte ;)
 
  • Gefällt mir
Reaktionen: Mettwurscht
Hab aktuell nur 1G Ethernet zwischen Router und dem Switch wo das Modul drinsteckt, mehr als ~945M sind aktuell somit eh nicht drin :)
Aber immerhin lohnt es sich nun ein Upgrade auf 10G zumindest zwischen den Kernkomponenten anzustreben ;)
 
Ah ok, schade. Bin sehr auf @shavenne gespannt. Er wird es dann wohl für uns testen, wenn das Modul ankommt.
 
Frage, wenn man den ONT direkt in einen managed Switch einbaut, wie sichert man das dann ab, damit ueber die WAN Seite kein Schindluder mit der Switch-Konfiguration gemacht werden kann? Ist das überhaupt eine relevantes Threat-Model oder ist es unwahrscheinlich genug*, dass man das ignorieren kann?


*) Es muesst ja jemand von aussen die richtige interne IP-adresse verwenden, was bei ge-NATetem IPv4 schwer sein duerfte, aber bei IPv6 kann der Switch halt auch eine global erreichbare Adresse bekommen, oder?
 
Die "Konfigurationsschnittstelle" vom Switch in einem eigenem VLAN bzw. in einem Management VLAN laufen lassen. Strenggenommen hats Management vom Switch ja im Default VLAN generell eigentlich gar nix zu suchen (auch wenn ich das im Heimbereich auch eher nicht so eng sehe)

Oder hab ich dich jetzt irgendwie missverstanden? :D


Leider kommt DHL mal gerade so gar nicht aus dem Quark. Modul kommt erst morgen :(
 
  • Gefällt mir
Reaktionen: pufferueberlauf
pufferueberlauf schrieb:
Frage, wenn man den ONT direkt in einen managed Switch einbaut, wie sichert man das dann ab, damit ueber die WAN Seite kein Schindluder mit der Switch-Konfiguration gemacht werden kann? Ist das überhaupt eine relevantes Threat-Model oder ist es unwahrscheinlich genug*, dass man das ignorieren kann?


*) Es muesst ja jemand von aussen die richtige interne IP-adresse verwenden, was bei ge-NATetem IPv4 schwer sein duerfte, aber bei IPv6 kann der Switch halt auch eine global erreichbare Adresse bekommen, oder?

Der Traffic von außen kommt ja nur über die PPPoE Session rein. Und die baut der Router auf, nicht der managed Switch, daher auch keine Absicherung nach außen hin nötig.

Es könnte höchstens jemand über das Telekom-interne VLAN 7 auf den Switch kommen, aber dafür müsste schon das Netz der Telekom in irgendeinerweise kompromitiert werden. Hier müsste man dann aber zusätzlich noch einen Weg finden aus dem VLAN 7 ins Management VLAN des Switches, oder des ONT SFPs zu kommen.
Das halte ich aber für ein außreichend unwahrscheinliches Szenario ...
 
  • Gefällt mir
Reaktionen: pufferueberlauf
PPPoE ist ja nicht immer der Fall. Bei Deutsche Glasfaser z.B. haben wir kein PPPoE o.ä., der zieht sich einfach per DHCP seine IPs.
 
  • Gefällt mir
Reaktionen: pufferueberlauf
Wichtig ist halt, dass man auch nur das ISP VLAN durchlässt. Sonst könnte der ISP einfach ein ONT Profil mit dem Management VLAN hochfahren und wäre dann drin.

pufferueberlauf schrieb:
Frage, wenn man den ONT direkt in einen managed Switch einbaut, wie sichert man das dann ab, damit ueber die WAN Seite kein Schindluder mit der Switch-Konfiguration gemacht werden kann? Ist das überhaupt eine relevantes Threat-Model oder ist es unwahrscheinlich genug*, dass man das ignorieren kann?


*) Es muesst ja jemand von aussen die richtige interne IP-adresse verwenden, was bei ge-NATetem IPv4 schwer sein duerfte, aber bei IPv6 kann der Switch halt auch eine global erreichbare Adresse bekommen, oder?
Oder meinst du in dem Fall Managed Switch = Router, sodass der Switch das Tor zum Internet wird?
 
  • Gefällt mir
Reaktionen: pufferueberlauf
Mixus schrieb:
Der Traffic von außen kommt ja nur über die PPPoE Session rein. Und die baut der Router auf, nicht der managed Switch, daher auch keine Absicherung nach außen hin nötig.
D.h. Du verlaesst Dich darauf, dass der ISP potentiell problematische Pakete nicht durchlaesst... wahrscheinlich gut genug...

shavenne schrieb:
Die "Konfigurationsschnittstelle" vom Switch in einem eigenem VLAN bzw. in einem Management VLAN laufen lassen.
Ja, das klingt vernünftig, ist das der Default (z.B. Konfiguration im Auslieferungszustand nur ueber VLANX und/oder Port Y moeglich) oder muss man das als Nutzer selber so einrichten?

shavenne schrieb:
Strenggenommen hats Management vom Switch ja im Default VLAN generell eigentlich gar nix zu suchen (auch wenn ich das im Heimbereich auch eher nicht so eng sehe)
Da bin ich bei4 Dir, aber gerade im Heimbereich ist dann wichtig wie der Switch vom Hersteller konfiguriert war... Das gilt nicht fuer die Profis hier im Thread mir geht es darum ob man Laien empfehlen kann/soll einen managed Switch auf der WAN Seite zu verweenden oder ob man da zusaetzliche Ausfuehrung zu den Einstellungen geben muss... (Z.B. raspberry Pi4B mit seinem einen Ethernet interface als Router on a Stick mit managed Switch um WAN und LAN zu trennen).

KernelMaker schrieb:
Oder meinst du in dem Fall Managed Switch = Router, sodass der Switch das Tor zum Internet wird?
Nein, ich meinte etwas wie ONT -> SwitchWANPort -> Router -> Switch LAN Ports
Weil wenn man dann den Switch umkonfigurieren kann potentiell die Moeglichkeit besteht LAN Traffic zu belauschen...

Ich weiss das ist kein sonderlich wahrscheinliches Szenario, aber die Frage ist halt wie laesst sich das zuverlaessig unterbinden (ohne auf die Netzhygiene z.B. vom ISP angewiesen zu sein)?
 
Ich würde behaupten, für die meisten stellt sich das Problem nicht da viele ISPs VLANs nutzen.
also selbst wenn das Management auf dem default VLAN ist, wird das wohl kaum auf dem ISP VLAN sein.

Und für Laien sollte klar sein, dass man ohne korrekte Konfiguration sein WAN auf den Switch lässt. Das könnte man umgehen indem jeweils ein Switch für beide Netze genutzt wird. So wird es ja auch bei Business gemacht. Der ISP stellt dann einen Switch bzw. Direkt einen Router bereit.
 
Zuletzt bearbeitet:
KernelMaker schrieb:
Oder meinst du in dem Fall Managed Switch = Router, sodass der Switch das Tor zum Internet wird?
Wird schwierig, da die allermeisten Switche, außer evtl. Whitebox-Hardware mit eigenem NOS, kein NAT beherrschen. Könnte man evtl. für IPv6 only in Erwägung ziehen, aber auch da haben sehr viele Switche keine vollständige Implementierung für funktionierende RAs oder DHCPv6.
 
  • Gefällt mir
Reaktionen: KernelMaker
kingpin42 schrieb:
Wird schwierig, da die allermeisten Switche, außer evtl. Whitebox-Hardware mit eigenem NOS, kein NAT beherrschen. Könnte man evtl. für IPv6 only in Erwägung ziehen, aber auch da haben sehr viele Switche keine vollständige Implementierung für funktionierende RAs oder DHCPv6.
Klar, sinnvoll ist das für zuhause sicherlich nicht. Aber in der Theorie ginge ein Switch auch für simples Routing
 
Zurück
Oben