Sun Network 10GbE Switch 72p: x2129a 1G-module in SFP+-poort blijft down terwijl 10G-buren prima werken
Ik heb een Sun Network 10GbE Switch 72p geërfd met een paar legacy dozen eraan die nooit meer dan een gigabit zullen doen. Het plan was om een 1G-geschikte module in een van de SFP+-cages te zetten en er vanaf te zijn.
- Sun Network 10GbE Switch 72p, SEFOS CLI via de seriële console
- x2129a dual-rate 10G/1G multimode module
- OM3 duplex LC naar een 1G-poort op een oudere accessswitch
- 10G-links op hetzelfde chassis staan up en verwerken verkeer normaal
De poort met die module komt nooit op. Geen alarmen, geen fouten in het log, gewoon een poort die down blijft terwijl zijn 10G-buren prima werken, en het verre eind ziet ook niets.
Al geprobeerd:
- module opnieuw geplaatst en de patchkabel gewisseld
- naar een tweede cage verplaatst
- de poort aan het verre eind gecontroleerd, die staat up en wacht op een partner
Wordt een 1G-link in deze poorten überhaupt ondersteund, en zo ja, wat mis ik aan de switchkant?
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 5
Beide helften moeten kloppen en geen van beide gebeurt vanzelf.
Switchkant: op dit platform zijn alleen poorten 65-72 dual speed, dus poort 71 is prima. De x2129a is het gekwalificeerde dual-rate 10G/1G multimode onderdeel voor precies deze klus, en de x2123a is de RJ45-variant als je ooit 1G koper uit die cages nodig hebt. Maar de poort valt niet vanzelf terug, je stelt de snelheid handmatig in via SEFOS:
Zet de poort down voor je de snelheid wijzigt en breng hem daarna weer up. Dat overslaan is meestal de reden waarom mensen melden dat de instelling niet beklijft. En
write startup-config, anders is het weg bij de volgende reload.Verre eind: schakel autonegotiation uit en forceer die poort naar 1000 full duplex. In 1Gbps-modus doen deze poorten niet aan autonegotiation, dus een partner die op autoneg blijft staan is verreweg de meest voorkomende reden dat de link nooit tot stand komt, en dat past precies bij jouw symptomen: 10G-buren blij, deze ene stil in beide richtingen.
Doe beide, en kijk dan opnieuw naar de poort. Blijft hij down met het verre eind geforceerd, dan is dat een andere fout en de moeite waard om de vezel goed te bekijken.
In welk poortnummer zit hij? Dat maakt hier uit, want niet elke SFP+-cage op dit chassis is dual speed, alleen een blok van acht aan het eind doet iets anders dan 10G. Zit je module in een van de andere, dan kun je stoppen met zoeken naar een configuratiefout, daar gaat het nooit werken.
Tweede vraag: wat zit er aan het verre eind en staat autonegotiation op die poort nog aan? Dat is de andere helft van het antwoord, en "nooit aangeraakt" betekent vrijwel altijd dat hij aan staat.
Poort 71, dus die zit in het laatste blok. Het verre eind is een 1G multimode poort op een oudere accessswitch, autonegotiation aan, fabrieksinstelling, nooit aangeraakt.
Aan de Sun-kant heb ik ook niets geforceerd, de poort staat op wat er standaard uitkomt. Als beide kanten gewijzigd moeten worden, kan ik die link zonder iemand te vragen een paar minuten down halen, er loopt nog niets belangrijks over.
1G in een 10G-cage is nooit plug-and-play, en de regels verschillen per platform, zelfs binnen één vendor. Op Extreme VOSS wil de VSP 4450 dat autonegotiation aan blijft staan als het verre eind een switch van een ander merk is, terwijl de VSP 7254XSQ autonegotiation helemaal niet ondersteunt, dus daar moet het externe apparaat het uit hebben voor er een 1G-link tot stand komt. Tegengesteld advies, zelfde vendor, twee dozen. Voor hun 1000BASE-T SFP, AA1419043-E6, ook vermeld als 10070H, is aangepaste autoneg op de externe koperpoort de aanbevolen aanpak.
MikroTik heeft hier zijn eigen variant van met multi-rate optiek. Een XS+31LC10D in een gewone SFP+-poort moet geforceerd worden in plaats van autonegotiated, met de rate-select-pin laag getrokken, anders kan data tijdens de transmissie corrupt raken:
Andere snelheden, hetzelfde soort probleem: de cage kan meer dan één snelheid aan en iets moet hem vertellen welke je bedoelde.
Waardeer trouwens dat je überhaupt een snelheidsknop hebt. Bij QNAP's managed QSW-switches, QSW-M5216-1T, QSW-M2116P-2T2S en de rest van die lijn, is de datamodus van de SFP+-poorten niet aan te passen in QSS, alleen de RJ45-poorten kunnen beperkt worden. Dus een 1G SFP wordt door de poortfirmware ofwel automatisch herkend, ofwel hij linkt niet, en er is geen configuratie om op terug te vallen. Mensen eindigen met zoeken naar een module die de poort toevallig wel lust, of zetten er in plaats daarvan een DAC in.
Dat is ook waarom je berichten ziet waarin 10G-naar-10G prima opkomt in dezelfde cage terwijl een 1G-module donker blijft. Op jouw doos is het een handmatige instelling, één keer vervelend en dan voorgoed opgelost.