Q+DA0001 40G DAC between CRS326-24S+2Q+RM and Huawei S6720: both ends read the cable, link stays down
Rebuilding aggregation at one of our sites: a CRS326-24S+2Q+RM takes the custmer SFP+ ports and uplinks over 40G into a Huawei S6720. Short run inside the same rack, so a passive DAC rather than optics.
- MikroTik CRS326-24S+2Q+RM, QSFP+ port qsfpplus1-1
- Huawei S6720-54C-EI-48S-AC, plain 40GE port
- MikroTik Q+DA0001 passive 40G QSFP+ DAC
Both boxes read the cable correctly, the MikroTik shows it as its own Q+DA0001 and the Huawei lists a 40G copper cable in the port info. And then nothing happens:
MikroTik: qsfpplus1-1 no-link
Huawei: 40GE... current state : DOWNWhat has been done already:
- looped the same cable between the two QSFP+ ports of the CRS326: links immediately
- looped it between two 40GE ports on the Huawei: also links
- swapped ends, moved to the other QSFP+ port, reseated everything
- verified neither side is administratively down
So the cable is good and each switch is happy with it on its own, only the cross-vendor pair refuses. Has anyone actually got a Q+DA0001 up between a CRS326 and an S6720, and what did you have to change on either side to get the port to come up?
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
That default-to-default pairing is your problem, and so is switching both ends off together. What worked here on the same combination is asymmetric, which feels wrong when you write it down, but there it is: the Huawei 40GE port with auto-negotiation disabled, while qsfpplus1-1 on the MikroTik keeps its own autoneg enabled.
On the Huawei, inside the interface:
On the MikroTik, leave it alone or set it explicitly so nobody "fixes" it later:
The 40G link came up right after that on my CRS326 to S6720 pair and has been stable since. I would not sell this as a fix so much as a workaround: the two implementations clearly do not agree about what a 40G DAC link should negotiate, and the asymmetric setting is simply the corner where both are content. Do it in a maintenance window rather than on a live uplink, and if it does not take, check whether your Huawei image lets you disable autoneg on that port at all, because that part is not universal.
Cross-vendor 40G where both ends see the cable but neither brings it up almost always comes down to what the two ports are trying to negotiate.
Post the autoneg state from both sides: the 40GE port config on the Huawei and the auto-negotiation value for qsfpplus1-1 on the MikroTik, and say whether you have changed either from the default. Also say whether you have already tried switching it off - on both ends at once, or on one end only, because those are two different experiments.
The loop tests only prove the cable is good. They tell you nothing about the two ends agreeing on the same negotiation behaviour, which is the interesting part heer.
Both sides are at their defaults: auto-negotiation=yes on qsfpplus1-1 and negotiation auto on the Huawei 40GE port, and I have not touched either config beyond bringing the interfaces up. I did try switching it off on both ends at the same time, which changed nothing at all; the one-sided variant never occurred to me.
Link state stays no-link on the MikroTik and DOWN on the Huawei, and the counters do not move at all, so it never gets far enough to log an error on either box.
That last caveat deserves more than a footnote, because it is excatly where I got stuck. On an S6320-54C-EI, with RouterOS 7.12 on the MikroTik side, the 40G port does not let you turn auto-negotiation off at all, so the asymmetric trick has nowhere to land.
Symptoms otherwise identical: both ends read the cable, port stays down, no errors anywhere. So the workaround above is real but platform-specific, and the underlying incompatibility between these two 40G implementations is still open as far as I can tell.
For anyone landing here who cannot make a cross-vendor DAC behave at all: at some point it is cheaper to stop fighting it.
I had an Alta Route 10 against a CRS309-1G-8S+ where the Route 10 recognised both a 10Gtek and an FS SFP+ DAC, reported as SFP-H10GB-CU2M, while the CRS309 showed no link partner advertising and the pair would only link when forced down to 1G. Forcing 10gbase_r in /cfg/sfpX.txt did nothing, and whatever module sat in the cage, ethtool on the Route 10 kept listing baseT modes. Swapped both ends to FS SFP-10GSR-85 optics and had a 10G link instantly.
Different speed and different boxes, same lesson: when the cable is proven good and the two ends still wll not agree, a pair of optics costs less than another week of tuning.