Supermicro E300-9A auf pfSense Plus 22.05: ix2 und ix3 bleiben bei no carrier, obwohl ein DAC an einem USW-Aggregation problemlos linkt
Meine Firewall ist ein Supermicro E300-9A mit pfSense Plus 22.05, und beide 10G-SFP+-Ports weigern sich hochzukommen. Weder ix2 noch ix3 zeigt jemals carrier, egal was ich in den Käfig stecke.
Hardware:
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M und ein passives 10Gtek-Twinax-Kabel
- Supermicro AXS85-192-M3 Glasfasermodule als Alternative
- Ubiquiti USW-Aggregation auf der Switch-Seite
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 sieht genauso aus.
Bisher versucht:
- beide Kabel funktionieren am USW-Aggregation zwischen anderen Geräten, sind also nicht tot
- Kupfer gegen die AXS85-192-M3-Glasfasermodule getauscht, gleiches no carrier an beiden Ports
- die Appliance mehrfach neu gestartet, auch mit Modul-Einstecken im laufenden Betrieb
Steckt in dieser Box etwas, das erst angestoßen werden muss, bevor die Käfige funktionieren, oder habe ich es mit zwei toten Ports zu tun?
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
Warme Neustarts bringen dich nirgendwohin - diese Ports frieren einen Medienstatus ein und tasten bei einem Restart nie neu ab. Fahr die Appliance ordentlich runter, zieh das Netzteil für ein paar Minuten raus, dann starte sie mit bereits eingestecktem Modul neu. Das hat hier beide Ports zurückgebracht, und jemand anders hat identisches Verhalten an einem Intel-X552-Port beschrieben, weshalb ich das für einen veralteten Medienstatus halte und nicht für ein pfSense-Problem.
Wenn du ein Modul im laufenden Betrieb einsteckst, stoß das Interface an, statt neu zu starten:
Das bringt den Treiber dazu, den Käfig erneut anzuschauen. Das ist für nichts eine dauerhafte Lösung, spart dir aber einen Reboot, wenn du auf der Werkbank Module tauschst. Prüf das Ergebnis mit
ifconfig -astatt mit der Frontblende.Mach zuerst die vollständige Stromtrennung und bestätige beide Käfige mit einem DAC, bevor du die Switch-Seite anfasst. Hier zählt es, ein Ding nach dem anderen zu debuggen, denn "no carrier bei jedem Modul" und "Link kommt mit falscher Geschwindigkeit hoch" sind meistens zwei getrennte Fehler, die zufällig in derselben Kabelstrecke stecken.
Die vollständige Stromtrennung hat's gebracht. Runtergefahren, Netzteil raus, ein paar Minuten gewartet, wieder eingeschaltet - beide Ports kamen hoch. Einen DAC zwischen ix2 und ix3 geschleift und einen sauberen 10G-Link bekommen, und das AXS85-192-M3-Paar macht zwischen den beiden Ports ebenfalls 10G, die Käfige und die Module sind also in Ordnung.
Die Switch-Seite ist eine andere Geschichte. Richtung USW-Aggregation handelt der Link nur je 1G aus, und wenn ich an einem der beiden Enden 10G erzwinge, geht er runter und bleibt unten. Die eine Hälfte des Problems ist also weg, die nervige Hälfte ist noch da.
Die 1G-Fallback-Hälfte kommt mir sehr bekannt vor. Ich bin demselben Symptom auf einem TL-SG3428X und einem TL-SX3008F hinterhergejagt: Einen an einem dieser SFP+-Ports hängenden Server neu starten, und er kam mit 1G ausgehandelt zurück, egal worauf der Switch-Port konfiguriert war. Intel X520-DA2, Mellanox- und HP-Adapter, Intel-E10GSFPSR- und 10GTek-Optik, Firmware-Updates, mehrere Treiberversionen unter Linux und Windows, Port-Profile - nichts davon hat irgendetwas geändert. Ein Switch-Reboot oder das Umschalten der Port-Geschwindigkeit weg von 10G und wieder zurück hat den 10G-Link bis zum nächsten Host-Reset wiederhergestellt.
Was das Ganze tatsächlich behoben hat, war der Wechsel der Optik statt irgendetwas am Host: TP-Link-SM5110-SR-Module am Switch-Ende, und der Link kam jedes Mal mit 10G zurück. Jemand anders hat dasselbe an einer SG3428XMPP bestätigt. Die Lesart war, dass der Switch mit manchen Drittanbieter-Modulen nach einem Link-Reset auf der Host-Seite falsch aushandelt.
Anderer Hersteller bei dir, aber die Form passt. Bevor du irgendetwas im Satz kaufst, leih dir ein einzelnes Ubiquiti-Modul und teste einen Port am Aggregation-Switch.
Zum Erzwingen von 10G: Das nur an einem Ende zu tun macht es schlechter, nicht besser. Die Gegenseite versucht weiter auszuhandeln, und eine feste Einstellung gibt ihr nichts, wogegen sie aushandeln kann, der Link bleibt also einfach unten - genau das Verhalten, das du beschreibst. Geschwindigkeit und Duplex an beiden Enden fixieren, oder an keinem.
Zwei verwandte Fälle aus der MikroTik-Welt, falls sie dir etwas sagen. An einem RB4011 wurde ein Finisar FTLF8524P2BNV-BR erkannt, sfp-rx-loss und sfp-tx-fault standen beide auf no, und das Interface sagte trotzdem no-link, weil ein 1G-SFP in einem SFP+-Käfig festgenagelt statt ausgehandelt werden muss:
und, auch hier, an beiden Enden. Der zweite Fall war eine CCR1072, bei der auto-negotiation nach einem Link-Verlust auf DONE stehen blieb und der Treiber es nie neu startete; Autoneg zu deaktivieren und die Geschwindigkeit zu fixieren brachte den Link zurück, um den Preis einer sauberen Link-down-Erkennung.