ConnectX-4 MCX456A-ECAT linkt niet met een Cisco NCS op 100GBASE-LR4 terwijl loopback aan beide kanten slaagt
We beheren een paar racks die overdragen aan een carrier-facing Cisco NCS, en een van de 100G-serveruplinks is sinds de opbouw nooit opgekomen. Zelfde resultaat na het verplaatsen van de server naar een ander rack met een ander patchpaneel, dus ik behandel het niet meer als een eenmalig geval.
- Supermicro-server, NVIDIA/Mellanox ConnectX-4 MCX456A-ECAT, beide poorten vrij
- generieke 100GBASE-LR4 QSFP28, singlemode, 10 km bereik, één aan elk uiteinde
- Cisco NCS aan de andere kant, dark fibre tussen de twee ruimtes
Het deel waar ik op vastloop: elke module doorstaat een loopback op zijn eigen apparaat. Met de vezel rechtstreeks teruggelust in dezelfde QSFP28 meldt de NIC een schone 100G-link, en de NCS doet hetzelfde aan zijn kant. Zet de echte trace ertussen en er is niets.
# module looped back on the NIC itself
Speed: 100000Mb/s
Link detected: yes
# same module, real span to the NCS
Speed: Unknown!
Link detected: noWat we al geprobeerd hebben:
- beide modules vervangen door reserve-exemplaren uit dezelfde batch, geen verandering
- de server verplaatst en herpatcht via een ander paneel
- een case geopend bij de NIC-leverancier, en het antwoord was een verwijzing naar de gevalideerde transceiverlijst in de firmware release notes, wat niet verklaart waarom loopback werkt
Is er iets met LR4 op de ConnectX-4 waardoor hij lokaal kan linken maar nooit over een echte trace, of jaag ik het verkeerde eind hiervan na?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Dit leest als een vuil pad, geen compatibiliteitsprobleem.
Alles wat je tot nu toe vervangen hebt, zit aan de kant die al goed testte, en dat is waarom er niets veranderde - de trace zelf is het enige dat nog onaangeroerd is. Werk dus het pad af:
De gevalideerde transceiverlijst waar je naartoe verwezen werd, is een blik waard, maar een module die netjes opkomt in loopback wordt al correct aangestuurd door de NIC. Compatibiliteitslijsten verklaren modules die botweg geweigerd worden, niet modules die lokaal linken en het over een trace begeven.
Als reinigen het niet doet, is de volgende stap een lichtbron en vermogensmeter op de dark fibre, of een OTDR als je er een kunt lenen, voordat je nog een NIC of nog een paar optiek koopt.
Een loopback bewijst alleen dat één poort zichzelf kan horen - laser, ontvanger, snelheidsinstellingen. Het zegt niets over het glas tussen je twee ruimtes, en dat is nu net het ene stuk dat je niet getest hebt. Dus voordat de NIC opnieuw de schuld krijgt: haal cijfers op van beide kanten met de echte trace aangesloten: wat is het Rx-vermogen op de NCS-poort, en wat is het op de NIC? Rx die onder de Low Warn-drempel zit met de trace erin, wijst klassiek naar de andere kant of naar het pad, niet naar de lokale poort. Aan de Linux-kant zou
ethtool -mdezelfde uitlezing moeten geven, en als die terugkomt metCannot get module EEPROM information: Input/output error, lees dat dan niet als een dode module - op mlx5 is dat meestal firmware-side moduletoegang, enmst start,mst cable adden danmlxcablesgeven je de waarden alsnog.Reinigen was het antwoord. We hebben een scope op de eindvlakken gezet en zowel beide modules als beide patchkabels waren vervuild; de kabel die door het paneel tussen de ruimtes liep was de ergste van de twee. Alles in het pad gereinigd, opnieuw geplaatst, en de 100G-link naar de NCS kwam bij de eerste poging op en is sindsdien blijven staan.
Lichtjes geïrriteerd op mezelf omdat ik zo lang op het compatibiliteitsspoor zat terwijl het loopback-resultaat me de hele tijd al vertelde dat de modules in orde waren en het pad niet. Voor wie hier later terechtkomt: loopback bewijst de poort, niet de vezel.