SFP ont module geeft geen link op Intel X520

[Robbiedobbie]

Ik heb een mini pctje bedoeld als router (De R86s - N305) welke 2 SFP+ poorten heeft. De aansturing hierbij is de Intel 82599ES. Recent heb ik ook glasvezel internet gekregen (welke via gpon werkt) en dacht ik dat het een leuke challenge zou zijn om de glasvezel zonder los ONT direct aan te sluiten op dit routertje.

Hiervoor heb ik de LEOX LXT-010S-H SFP ont module gekocht, omdat deze ook in 1GbE mode kan draaien.

Om deze te configureren, moet ik direct naar de module een telnet verbinding leggen. Daarom heb ik de glasvezel nog niet omgeplugd (Want ik wil niet dat ie het foute serienummer naar de OLT gaat communiceren). Echter lukt het me met geen mogelijkheid om de interface up te krijgen, niet in OPNsense die ik normaal draai, maar ook niet via een arch linux live usb om even met de tooling te werken waar ik zelf het meest bekend mee ben.

De module lijkt wel herkend te worden (ik zie ook geen unsupported device meldingen in de logging), maar ik krijg met geen mogelijkheid de link up. Als ik met eththool de 2 sfp poorten bekijk, dan geeft de lege poort aan dat 10GbE supported is, en de volle poort geeft 1GbE aan als supported link. Ook de module wordt netjes weergegeven bij queries. Echter geeft ethtool bij speed en duplex 'Unknown!' aan als value, en is link detected: no.

Heb ik hier pech en werkt die module gewoon niet samen met de intel kaart, of komt dit doordat ik de glasvezel nog niet erin heb zitten?

[FatalError]

Je moet er inderdaad wel een vezel in prikken voor de link up. Nu kan dat bij PON iets anders werken dan ik gewend ben, maar reguliere SFPs "kopieren" de glasvezel linkstatus naar de SFP interface status

[Robbiedobbie]

Dus ik kan de module dan niet configureren voordat ik er een vezel inprik? Kan het geen kwaad dat de ONT nog niet de juiste config heeft als ik de vezel inprik dan?

Ik ging er eigenlijk vanuit dat de link status of up zo komen door de interne interface, of dat de link pas up zou komen als ie ook volledig connectie gelegd heeft met de OLT

[ik222]

Robbiedobbie schreef op woensdag 8 november 2023 @ 11:22:
Dus ik kan de module dan niet configureren voordat ik er een vezel inprik? Kan het geen kwaad dat de ONT nog niet de juiste config heeft als ik de vezel inprik dan?

Ik ging er eigenlijk vanuit dat de link status of up zo komen door de interne interface, of dat de link pas up zou komen als ie ook volledig connectie gelegd heeft met de OLT

Link status gaat over de verbinding met de OLT, die zal pas up komen als je de vezel erin stop en de module ook met het juiste serienummer geconfigureerd is zodat de ONT zich ook succesvol aanmeldt.

Om zo’n module te configureren hoeft de link status niet up te zijn. Je zou er naar moeten kunnen telnetten als je een andere poort bridged met de SFP poort en daar een device aan hangt met een IP adres in de juiste range.

Overigens kan een niet geconfigureerde GPON SFP aansluiten op zich geen kwaad. Alleen werken zal het ook niet. Wat je niet moet doen is een AON SFP op een GPON netwerk aansluiten, dan veroorzaak je tegenlicht en wordt in het slechtste geval de patch naar jou aansluiting fysiek verwijderd.

[ Voor 8% gewijzigd door ik222 op 08-11-2023 20:12 ]

[nelizmastr]

Volgens de documentatie heeft het ding een eigen IP om te configureren, 192.168.100.1, maar dan moet je er wel even zelf een glasvezelkabel aan knopen zodat je een link hebt om erbij te komen. Wellicht is dat het beste idee?

Dus het liefst tussen een laptop/pc en de SFP module een kabel hangen en dan configureren over die link.

[ Voor 19% gewijzigd door nelizmastr op 08-11-2023 21:42 ]

[Robbiedobbie]

ik222 schreef op woensdag 8 november 2023 @ 20:11:
[...]

Link status gaat over de verbinding met de OLT, die zal pas up komen als je de vezel erin stop en de module ook met het juiste serienummer geconfigureerd is zodat de ONT zich ook succesvol aanmeldt.

Om zo’n module te configureren hoeft de link status niet up te zijn. Je zou er naar moeten kunnen telnetten als je een andere poort bridged met de SFP poort en daar een device aan hangt met een IP adres in de juiste range.

Overigens kan een niet geconfigureerde GPON SFP aansluiten op zich geen kwaad. Alleen werken zal het ook niet. Wat je niet moet doen is een AON SFP op een GPON netwerk aansluiten, dan veroorzaak je tegenlicht en wordt in het slechtste geval de patch naar jou aansluiting fysiek verwijderd.

Toen ik je reactie zag dacht ik, d'oh, waarom heb ik daar niet aan gedacht. Ik heb zojuist even een bridge gelegd binnen opnsense tussen de sfp poorten (Om uit te sluiten dat ik de verkeerde poort heb) en 1 ethernet poort. Ook heb ik voor de zekerheid even een floating firewall rule ingesteld die allow all deed (Hangt toch nog niet aan het internet). De interfaces heb ik niet met een ip geconfigureerd, en ik heb mijn laptop direct aan de ethernet poort gehangen met kabel. Daarna heb ik mijn laptop een fixed ip 192.168.100.2/24 gegeven, en ben gaan proberen te telnetten.

Ik zie met wireshark (ook met package capture op de bridge binnen opnsense) ARP requests voorbij komen om 192.168.100.1 te zoeken. Echter komt hier nooit response op. De telnet komt logischerwijze ook niet tot stand

Ik vermoed dat opnsense het verkeer op de bridge alsnog niet doorstuurt naar een module die DOWN is met een NO-CARRIER flag. Zijn hier nog settings waar ik iets aan kan veranderen? Of heb ik pech en moet ik een ander apparaat gaan zoeken met een sfp poort (Mediaconverter aanschaffen puur voor de configuratie?).

Ik zal straks nog eens testen maar dan met de glasvezel is ingeprikt. Logica zegt mij dat ik dan alsnog een interface die down is zal hebben, en nog steeds geen carrier, maar het is ondertussen het proberen waard.

[Kabouterplop01]

Als je 2 SFP ports hebt, én 2 sfp's dan duw je die erin en steek je er een vezel tussen, lijkt mij dat je dan link moet krijgen, deden we vroeger met switches al om de GBIC/sfp te testen.

[Robbiedobbie]

Ok, ik heb nog even dit weekend zitten experimenteren met het bereiken van de interne interface (192.168.100.1) van de sfp module.

Wat ik geprobeerd heb:
1. In opnsense een bridge maken tussen een ethernet poort en de sfp poort, dan een pc op de ethernet inpluggen en die een static ip geven op 192.168.100.2
2. Hetzelfde als stap 1, maar dan de bridge zelf een ip geven en vanaf de opnsense box zelf proberen te connecten via die interface
3. In linux (arch live boot) een bridge maken tussen een ethernet poort en de sfp poort, dan een pc op de ethernet inpluggen en die een static ip geven op 192.168.100.2
4. Hetzelfde als stap 3, maar dan de bridge zelf een ip geven en vanaf de opnsense box zelf proberen te connecten via die interface

Ook heb ik geprobeerd de module alvast op de glasvezel in te pluggen, maar dan geeft deze ook "no carrier" en krijg ik alsnog nergens een connectie. Ik heb bovenstaande stappen allemaal nog een keer geprobeerd terwijl de glasvezel verbonden was, maar dat mocht niet baten.

Kabouterplop01 schreef op donderdag 9 november 2023 @ 08:32:
Als je 2 SFP ports hebt, én 2 sfp's dan duw je die erin en steek je er een vezel tussen, lijkt mij dat je dan link moet krijgen, deden we vroeger met switches al om de GBIC/sfp te testen.

Helaas betreft het een GPON ONT die dus alleen connectie zou maken met een OLT, hetgeen ik natuurlijk niet in bezig heb en een duur geintje is om aan te schaffen.

Zou het een poging waard zijn om een TP-link MC220L mediaconverter aan te schaffen om op die manier de sfp module te configureren, of zou daarna alsnog de module niet werken op die intel x520 sfp slots?

[Kabouterplop01]

Dan moet je rekening houden dat je de andere kant ook up moet krijgen.
Oftewel je moet er en een SFP (dus jouw sfp + vezel + een 2e sfp in de converter) in duwen en een utp met link tussen laptop en converter.
schema:

[pfsense]<sfp>====fiber==<sfp>[converter]<utp>----------[laptop]

[MasterL]

Je zei dat je Arch linux live usb hebt geprobeerd, waar loop je dan precies tegen aan?
Ik snap het "bridge" verhaal niet zo goed. Je zou toch zeggen dat je "gewoon" een IP-adres (192.168.100.2) op de interface kunt configureren en zo (direct) 192.168.100.1 kan bereiken?
Gebruikt Arch netplan? Probeer anders eens zoiets:

code:

    eth0:
        ignore-carrier: true
        addresses:
        - 192.168.100.2/24

eth0 natuurlijk vervangen voor de port/nic waar de optic in zit, het gaat vooral over het stukje
"ignore-carrier: true". Dit zou toch te doen moeten zijn lijkt mij tenzij de X520 heel erg picky is betreft compatable optics, dit probleem heb ik wel eens gehad met Esxi en een X520 maar toen was dit duidelijk leesbaar in de logs.

[Robbiedobbie]

MasterL schreef op maandag 13 november 2023 @ 11:23:
Je zei dat je Arch linux live usb hebt geprobeerd, waar loop je dan precies tegen aan?
Ik snap het "bridge" verhaal niet zo goed. Je zou toch zeggen dat je "gewoon" een IP-adres (192.168.100.2) op de interface kunt configureren en zo (direct) 192.168.100.1 kan bereiken?
Gebruikt Arch netplan? Probeer anders eens zoiets:

code:

    eth0:
        ignore-carrier: true
        addresses:
        - 192.168.100.2/24

eth0 natuurlijk vervangen voor de port/nic waar de optic in zit, het gaat vooral over het stukje
"ignore-carrier: true". Dit zou toch te doen moeten zijn lijkt mij tenzij de X520 heel erg picky is betreft compatable optics, dit probleem heb ik wel eens gehad met Esxi en een X520 maar toen was dit duidelijk leesbaar in de logs.

Het bridge verhaal was naar aanleiding van de tip van ik222 eerder in het topic.

Ik heb puur voor de zekerheid net nog een keer geprobeerd in arch linux usb boot (Deze gebruikt systemd-networkd dus hetgeen netplan op de achtergrond ook gebruikt AFAIK). Hierbij heb ik de volgende configuratie gebruikt:

code:

[Match]
Name=enp4s0f1

[Link]
RequiredForOnline=no
ActivationPolicy=always-up

[Network]
ConfigureWithoutCarrier=true
IgnoreCarrierLoss=true
Address=192.168.100.2/24

Als ik vervolgens networkd restart en dan ga kijken hoe de interfaces geconfigureerd worden dan krijg ik het volgende met 'ip a':

code:

...
6: enp4s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:f0:cb:fe:c1:b2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.2/24 brd 192.168.100.255 scope global enp4s0f1
        valid_lft forever preferred_lft forever
...

Alle andere interfaces heb ik ook down gehouden, en hebben allemaal geen ip configured, dus dat kan ook niet in de weg zitten. Pingen naar 192.168.100.1 wil niet lukken, maar dat klinkt mij (als semi netwerk noob) vrij logisch als de interface als DOWN wordt beschouwd.

Ik heb veel op internet gelezen over dat modules als "unsupported" gemeld worden in de log, maar bij mij is de logging (ook met debug log aan) vrij summier. Ik krijg alleen dit wanneer ik de module hotplug:

ixgbe 0000:04:00.1 enp4s0f1: detected SFP+: 14

[Kabouterplop01]

Wat is het risico en gevolg eigenlijk als je het foutieve serienummer tijdelijk doorgeeft?

[ik222]

Kabouterplop01 schreef op maandag 13 november 2023 @ 19:30:
Wat is het risico en gevolg eigenlijk als je het foutieve serienummer tijdelijk doorgeeft?

Niets, op de OLT zal dan een onbekende ONT in de autofind komen maar dat gebeurt zo vaak (bijvoorbeeld tijdens migraties of als een lijn al gepatched is maar de ONT nog niet provisioned). Kwaad kan dat totaal niet en ze gaan je daarvoor dus ook zeker niet afsluiten of iets dergelijks

[Robbiedobbie]

Nou, ik ben een stap verder, maar snap er nu nog minder van

Afgelopen week uiteindelijk maar eens een mediaconvertertje (de bekende MC220L) aangeschaft om te kijken of ik op die manier de module wel aan de gang kon krijgen. Die detecteerde de module direct, en daar heb ik netjes alles mee kunnen configureren. Na het configureren heb ik ook een internet verbinding weten op te zetten, dus ik weet dat de configuratie nu klopt.

Daarna voor de zekerheid toch nog eens de module in m'n routertje met de Intel X520 gestoken, en opeens wordt de module direct gedetecteerd in opnsense (Wel met snelheid 'Unknown, txpause, rxpause"). Ook kan ik opeens verbinding maken met de configuratie pagina van de module.
Steek ik echter de glasvezel in, dan valt de module uit. Na zo'n 30 seconden (De opstarttijd van de module) komt ie weer up, om een paar seconden later weer down te gaan.

Eigenlijk komt het er op neer, dat als ik snel ben en de configuratie pagina kan bereiken, dat de module UP lijkt zolang de ONU status O1, O2 of O3 is, maar verder zie ik hem niet komen (Dan is ie down). Als ik in de mediaconverter de module heb hangen zie ik de status wel netjes doorkomen tot O6 (Dus tot de verbinding helemaal tot stand is gekomen)

Nu is het mij dus een raadsel wat het probleem is. Als de module niet compatible zou zijn met de X520, zou ik verwachten dat ik nooit op de configuratie pagina zou kunnen komen (Waarom dat nu na configuratie via de mediaconverter wel lukt weet ik echter niet). Als er iets met de module zou zijn, dan zou ik verwachten dat ik ook geen connectie zou krijgen als die in de mediaconverter steekt.

Iemand enig idee waar dit aan kan liggen?