Supermicro E300-9A op pfSense Plus 22.05: ix2 en ix3 blijven op no carrier staan met een DAC die prima linkt op een USW-Aggregation
Mijn firewall is een Supermicro E300-9A met pfSense Plus 22.05, en beide 10G SFP+-poorten weigeren op te komen. Noch ix2 noch ix3 toont ooit carrier, wat ik ook in de cage stop.
Hardware:
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M en een 10Gtek passieve twinax-kabel
- Supermicro AXS85-192-M3-fibermodules als alternatief
- Ubiquiti USW-Aggregation aan de switchkant
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 ziet er hetzelfde uit.
Tot nu toe geprobeerd:
- beide kabels werken op de USW-Aggregation tussen andere apparaten, dus ze zijn niet dood
- koper vervangen door de AXS85-192-M3-fibermodules, zelfde no carrier op beide poorten
- de appliance meerdere keren herstart, inclusief een module plaatsen terwijl hij draaide
Zit er iets in deze box dat een zetje moet krijgen voordat de cages gaan werken, of kijk ik naar twee dode poorten?
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 4
Met warme herstarts kom je nergens - die poorten onthouden een mediastatus en probe nooit opnieuw bij een restart. Sluit de appliance netjes af, trek de voedingsadapter er een paar minuten uit, en start hem dan weer op met de module er al in. Dat bracht hier beide poorten terug, en iemand anders beschreef identiek gedrag op een Intel X552-poort, en daarom denk ik dat het een verouderde mediastatus is en geen pfSense-probleem.
Als je een module plaatst terwijl het systeem al draait, bounce dan de interface in plaats van te herstarten:
Daardoor kijkt de driver opnieuw naar de cage. Het is voor niets een permanente oplossing, maar het scheelt een reboot als je op de werkbank modules aan het wisselen bent. Controleer het resultaat met
ifconfig -ain plaats van met het frontpaneel.Doe eerst de volledige stroomverwijdering en bevestig beide cages met een DAC voordat je de switchkant aanraakt. Eén ding tegelijk debuggen is hier belangrijk, want "no carrier bij elke module" en "link komt op met de verkeerde snelheid" zijn meestal twee aparte fouten die toevallig in hetzelfde kabeltraject zitten.
Volledige stroomverwijdering heeft het gedaan. Afgesloten, adapter eruit, een paar minuten gewacht, weer aangezet - beide poorten kwamen op. Een DAC geloopt tussen ix2 en ix3 en een schone 10G-link gekregen, en het AXS85-192-M3-paar doet ook 10G tussen de twee poorten, dus de cages en de modules zijn in orde.
De switchkant is een ander verhaal. Richting de USW-Aggregation onderhandelt de link altijd maar op 1G, en als ik aan een van beide kanten 10G forceer, gaat hij plat en blijft plat. Dus de helft van het probleem is weg en de vervelende helft is er nog steeds.
Die 1G-fallback-helft komt me heel bekend voor. Ik heb hetzelfde symptoom gejaagd op een TL-SG3428X en een TL-SX3008F: herstart een server die aan een van die SFP+-poorten hangt en hij kwam terug onderhandeld op 1G, ongeacht waarop de switchpoort was geconfigureerd. Intel X520-DA2, Mellanox- en HP-adapters, Intel E10GSFPSR- en 10GTek-optiek, firmware-updates, meerdere driverversies op Linux en Windows, poortprofielen - niets daarvan veranderde iets. Een switch-herstart, of de poortsnelheid van 10G af en weer terug zetten, herstelde de 10G-link tot aan de volgende hostreset.
Wat het echt oploste was het veranderen van de optiek in plaats van iets aan de hostkant: TP-Link SM5110-SR-modules aan de switchkant en de link kwam elke keer terug op 10G. Iemand anders bevestigde hetzelfde op een SG3428XMPP. De lezing was dat de switch met sommige modules van derden verkeerd onderhandelt na een linkreset aan de hostkant.
Andere vendor aan jouw kant, maar de vorm klopt. Voordat je een setje van wat dan ook koopt: leen één Ubiquiti-merkmodule en test één poort op de aggregation-switch.
Over het forceren van 10G: dat aan slechts één kant doen maakt het erger, niet beter. De peer probeert nog steeds te onderhandelen en een vaste instelling geeft hem niets om tegen te onderhandelen, dus de link blijft gewoon plat liggen - precies het gedrag dat je beschrijft. Zet snelheid en duplex aan beide kanten vast, of aan geen van beide.
Twee vergelijkbare gevallen uit de MikroTik-wereld, voor het geval ze een belletje doen rinkelen. Op een RB4011 werd een Finisar FTLF8524P2BNV-BR gedetecteerd met sfp-rx-loss en sfp-tx-fault die beide no toonden, en de interface zei nog steeds no-link, omdat een 1G SFP in een SFP+-cage vastgezet moet worden in plaats van onderhandeld:
en, nogmaals, aan beide kanten. Het tweede geval was een CCR1072 waar auto-negotiation na een linkverlies op DONE bleef staan en de driver het nooit herstartte; autoneg uitschakelen en de snelheid vastzetten bracht de link terug, tegen de prijs van correcte detectie van link-down.