Geh ich langsam davon aus, das doch meine Module defekt sind! Weil die was anzeigen, wenn kein Kabel drin ist.
Wäre jetzt nicht meine erste Vermutung. Wenn der Switch ein neues SFP-CO10 so wie das alte anspricht, könnte so etwas aber passieren.
Eben ist mein Exemplar vom FlyPro angekommen. Ich muss zugeben, da hat der Hersteller sich schon bei der Verpackung Mühe gegeben. Die Blechschachtel ist auch prima als Behältnis für Fisherman's Friend zu gebrauchen (siehe Anhang)...vielleicht kommt sie ja aus der der gleichen Quelle
Und tatsächlich, es liefert Monitoring-Infos, und zumindest die Temperatur ist plausibel. Direkt aus der Verpackung genommen, waren es 14 Grad, jetzt nach ein paar Minuten ohne Link auf der Kupfer-Seite:
Code: Alles auswählen
Port INFO: ETH-9
Status INFO: OK
Connector INFO: LC
Medium INFO: 10GBASE-SR
Wavelength INFO: 0
Monitoring INFO: Yes
Temperature INFO: 19
Supply-Voltage INFO: 3299
Tx-Bias INFO: 6
Tx-Power INFO: 500
Rx-Power INFO: 0
Vendor INFO: FLYPRO
Part-No INFO: SFP-10GT-CS-30M
Revision INFO:
Serial-No INFO: 231123CI0015
Date INFO: 2023-11-23
Mit einer 1 Gbit-Gegenstelle wechselt die 'Rx-Power' auf 400, dabei bleibt's auch, wenn ich einen 10GBASE-T Link damit mache.
Was nicht schön ist (aber marktüblich...): Das Modul behauptet von sich selber, ein Fasermodul mit LC-Konnektor zu sein. Das ist gängige Praxis, um Kupfer-SFP-Module z.B. in Linux-basierten Appliances zum Laufen zu bekommen, wo SFP+-Ports z. B. vom ixgbe-Treiber bedient werden - der weigert sich schlicht zu starten, wenn er etwas anderes als ein DAC oder ein optisches Modul findet.
Der Nebeneffekt von so einem 'Geflunker' ist nur halt, dass man als Verbindung auch nie etwas anderes als 10GBASE-F angezeigt bekommt. Im Vergleich hier ein ISG-8000 mit dem FlyPro-Modul in ETH-9 und einem SFP-CO10MG in ETH-10,
die beide mit einer 1 GBit-Gegenstelle verbunden sind und auch so einen Link aufbauen:
Code: Alles auswählen
Port Assignment Private-Mode Queue-Packets Link-Active Connector Auto-Negotiation Flow-Control MDI-Mode Remote-Fault Downshift Clock-Role Power-Saving MAC-Address Temperature ifIndex
===========-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ETH-9 LAN-9 Yes 0 Yes FD10GB-F Disabled No Not-Applicable No No None No 00900b9987e8 9
ETH-10 LAN-10 Yes 0 Yes FD1000B-TX Completed Yes MDI No No Master No 00900b9987e9 10
Beim SFP-CO10 'weiß' der Treiber im LCOS, dass ein Kupfer-PHY im Modul steckt, und fragt selbigen nach der echten Geschwindigkeit auf dem Kupfer-Medium.
Fazit: Man lernt immer was dazu. Hier scheint der Entwickler der Firmware im Mikrocontroller sich ein wenig Extra-Mühe gegeben zu haben. In SFP+-Kupfer-Modulen sitzt immer ein kleiner Mikrocontroller, der I2C auf MDIO für den Registerzugriff auf den Kupfer-PHY umsetzt. Der kann natürlich auf der I2C-Seite noch ein paar Register mehr implementieren, A/D-Wandler für die Betriebsspannung haben auch viele einfache Mikrocontroller heute implementiert und die Temperaturangabe holt der sich u.U. auch von dem Kupfer-PHY. Laut Werbung ist ein Marvell-PHY verbaut, der hätte einen on-Chip-Sensor, ist also eigentlich alles nur Software
Ob's wirklich ein Marvell-PHY ist, wird vermutlich offen bleiben. Im Datenblatt wird zwar von Zugriff per I2C auf die PHY-Register gesprochen, aber nicht dokumentiert wie. Und das macht bei SFP+-Modulen leider jeder Hersteller anders
Bevor jemand fragt: Nein, aufgrund so einer Erkenntnis wird hier niemand den Lieferanten fürs SFP-CO10 wechseln. Monitoring-Info ist 'nice to have', da haben andere Kriterien wie Verfügbarkeit (und Einkaufspreis...) höhere Prio.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.