Q+DA0001 40G-DAC tussen CRS326-24S+2Q+RM en Huawei S6720: beide kanten lezen de kabel, de link blijft down
Ik bouw de aggregatie op een van onze locaties opnieuw op: een CRS326-24S+2Q+RM neemt de klant-SFP+-poorten en uplinkt over 40G naar een Huawei S6720. Kort traject binnen hetzelfde rack, dus een passieve DAC in plaats van optiek.
- MikroTik CRS326-24S+2Q+RM, QSFP+-poort qsfpplus1-1
- Huawei S6720-54C-EI-48S-AC, gewone 40GE-poort
- MikroTik Q+DA0001 passieve 40G QSFP+-DAC
Beide boxen lezen de kabel correct, de MikroTik toont hem als zijn eigen Q+DA0001 en de Huawei vermeldt een 40G koperen kabel in de poortinfo. En dan gebeurt er niets:
MikroTik: qsfpplus1-1 no-link
Huawei: 40GE... current state : DOWNWat er al gedaan is:
- dezelfde kabel geloopt tussen de twee QSFP+-poorten van de CRS326: linkt meteen
- geloopt tussen twee 40GE-poorten op de Huawei: linkt ook
- uiteinden omgewisseld, verplaatst naar de andere QSFP+-poort, alles opnieuw geplaatst
- geverifieerd dat geen van beide kanten administratief down staat
Dus de kabel is goed en elke switch is er op zichzelf tevreden mee, alleen het cross-vendor paar weigert. Heeft iemand daadwerkelijk een Q+DA0001 tussen een CRS326 en een S6720 omhoog gekregen, en wat moest je aan een van beide kanten veranderen om de poort op te laten komen?
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
Die default-tegen-default-koppeling is je probleem, en dat geldt ook voor beide kanten samen uitschakelen. Wat hier bij dezelfde combinatie werkte is asymmetrisch, wat vreemd aanvoelt zodra je het opschrijft, maar daar is het: de Huawei 40GE-poort met auto-negotiation uitgeschakeld, terwijl qsfpplus1-1 op de MikroTik zijn eigen autoneg ingeschakeld houdt.
Op de Huawei, binnen de interface:
Op de MikroTik laat je het met rust, of je zet het expliciet zodat niemand het later "repareert":
De 40G-link kwam daarna meteen op bij mijn CRS326-naar-S6720-paar en is sindsdien stabiel. Ik zou dit niet verkopen als een fix maar eerder als een workaround: de twee implementaties zijn het duidelijk oneens over wat een 40G-DAC-link zou moeten onderhandelen, en de asymmetrische instelling is gewoon de hoek waar beide tevreden zijn. Doe het in een onderhoudsvenster in plaats van op een levende uplink, en als het niet aanslaat, controleer dan of je Huawei-image autoneg op die poort überhaupt kan uitschakelen, want dat onderdeel is niet universeel.
Cross-vendor 40G waarbij beide kanten de kabel zien maar geen van beide hem omhoog krijgt, komt bijna altijd neer op wat de twee poorten proberen te onderhandelen.
Post de autoneg-status van beide kanten: de 40GE-poortconfig op de Huawei en de auto-negotiation-waarde voor qsfpplus1-1 op de MikroTik, en zeg of je een van beide van de standaard hebt afgebracht. Zeg ook of je het al hebt geprobeerd uit te schakelen - aan beide kanten tegelijk, of aan slechts één kant, want dat zijn twee verschillende experimenten.
De looptests bewijzen alleen dat de kabel goed is. Ze vertellen je niets over of de twee uiteinden het eens worden over hetzelfde onderhandelingsgedrag, en dat is nu net het interessante deel.
Beide kanten staan op hun standaardwaarde: auto-negotiation=yes op qsfpplus1-1 en negotiation auto op de Huawei 40GE-poort, en ik heb geen van beide configs aangeraakt behalve de interfaces omhoog brengen. Ik heb wel geprobeerd het aan beide kanten tegelijk uit te schakelen, wat helemaal niets veranderde; de eenzijdige variant is nooit bij me opgekomen.
De linkstatus blijft no-link op de MikroTik en DOWN op de Huawei, en de tellers bewegen helemaal niet, dus het komt op geen van beide boxen ooit ver genoeg om een fout te loggen.
Die laatste kanttekening verdient meer dan een voetnoot, want precies daar liep ik vast. Op een S6320-54C-EI, met RouterOS 7.12 aan de MikroTik-kant, laat de 40G-poort je auto-negotiation helemaal niet uitschakelen, dus de asymmetrische truc heeft nergens om te landen.
Verder identieke symptomen: beide kanten lezen de kabel, de poort blijft down, nergens fouten. Dus de workaround hierboven is echt maar platformspecifiek, en de onderliggende incompatibiliteit tussen deze twee 40G-implementaties staat voor zover ik kan zien nog steeds open.
Voor iedereen die hier terechtkomt en een cross-vendor DAC helemaal niet aan de praat krijgt: op een gegeven moment is het goedkoper om te stoppen met vechten.
Ik had een Alta Route 10 tegenover een CRS309-1G-8S+ waarbij de Route 10 zowel een 10Gtek- als een FS SFP+-DAC herkende, gemeld als SFP-H10GB-CU2M, terwijl de CRS309 geen link partner advertising toonde en het paar alleen linkte als het teruggedwongen werd naar 1G. 10gbase_r forceren in /cfg/sfpX.txt deed niets, en welke module er ook in de cage zat, ethtool op de Route 10 bleef baseT-modi tonen. Beide kanten omgewisseld naar FS SFP-10GSR-85-optiek en meteen een 10G-link.
Andere snelheid en andere boxen, zelfde les: als bewezen is dat de kabel goed is en de twee uiteinden het nog steeds niet eens worden, kost een paar optiek minder dan nog een week afstemmen.