CodingBox Q&A Ask question

Open tooling voor transceiver-EEPROM's naast ethtool -m: sfppi, sfpdoctor, py-sfp-eeprom, oom

Asked Active Viewed 30 AI translation from English
0

Een groot deel van mijn werk bestaat uit de optiek van het ene bedrijf in de switch van een ander bedrijf stoppen, dus ik breng veel tijd door met een module vragen wat hij denkt te zijn. Mijn gereedschapskist daarvoor is op dit moment één commando diep, en ik wil graag weten wat er verder de moeite waard is om op de testbankmachine te zetten.

  • Linux-machines met SFP+- en QSFP28-poorten voor testbankwerk, plus een Raspberry Pi die niets nuttigs doet
  • een labswitch met SONiC, en welke vendor-CLI de klantapparatuur toevallig heeft
  • een lade modules van SFP tot en met QSFP-DD, de meeste gecodeerd voor iemand anders

Wat ik nu gebruik:

ethtool -m enp3s0f0
ethtool -e enp3s0f0
sfputil show eeprom

Aan de vendorkant is het wat de box toevallig biedt - show idprom, show interfaces diagnostics optics, display transceiver, /interface ethernet monitor. Dat alles leest. Niets ervan schrijft, en niets ervan vertelt me of een checksum echt fout is of gewoon ongebruikelijk.

Wat ik gevonden maar nog niet in scherpe praktijk gebruikt heb:

  • sfppi, een I2C-programmer voor de Raspberry Pi die ook checksums repareert
  • sfpdoctor en py-sfp-eeprom om SFF-8472-pagina's te lezen en te modelleren
  • OCP oom, de open optical monitoring library gericht op switches, en de optoe-driver waar sfputil op draait

De commerciële coderdozen zijn een aparte beslissing en niet degene waar ik naar vraag. Wat ik eerst wil weten is welke van de open tools mensen daadwerkelijk op een testbank houden: wat leest een pagina betrouwbaar uit over alle vormfactoren heen, wat is veilig om mee te schrijven, en waar ligt de grens tussen de SFF-8472-onderdelen en de CMIS-onderdelen in dezelfde lade.

Heeft iemand hier een werkende routine van gemaakt, of is het nog steeds één tool per taak?

Comments 0

No comments yet.

Log in to comment. Log in