I don't know where to begin here. Basically I have an autoprovisioned VCF setup with 2 spines and 9 leaf devices. I have the spines supposedly in full adjacency, but the backup spine keeps flapping VCP link for 1 device, and for 2 of the leaf devices the auto-convert for the VCP ports just doesn't seem to happen. So out of 9 leafs - all configured the exact same way - only 6 are behaving like they should. I can't reach out to JTAC because we're in a limbo of reseller hell for about 2 months now where registration and licensing is all kinds of messed up. I got 2 VCF licenses from a Juniper employee, but when I install them it doesn't recognize the feature sets. I don't think licensing is the issue, but who knows? I can't find any documentation about what happens you get a license in versus when you don't. I got nothing to go on. I wouldn't even know the one member was flapping if syslog wasn't telling me so. I know it's a tall order but uh... anybody have insights?
Edit - and to make it clear - all VCP links are just fine on the master spine device. Nothing happening there at all.
Have you build VCF before uploading license? without licenses you may encounter an unpredicatable behaviours.
Pl note following link which states license required for VCF.
Pl upload a correct licenses.
You may re-build your VCF post uploading licenses as follows.
In place of auto provisioned mode, you may try pre-provisioned mode which will give you fair idea of fault isolation.
VCF pre-provision KB
Mark it as an accpeted solution if it resolved your issue.
Something is always going to be 'unpredictable' when it's not working. If you can expound on the technicals for why licensing would cause this behavior (I've not found anything) I'll consider marking it as the 'solution'. I may have to review the original post, but I may have forgot to mention I was supplied 2 licenses which I attempted to put on to the spine devices. They install, but come back as "unknown" for the feature set. The Juniper employed engineer didn't think the licensing would be an issue during build out anyway.
Thanks for the attempt though.
So coming back to this - the issue was third party optics which purchasing thought was officially Juniper, but in reality they were not. I believe the third party optics had some sort of issue with multiplexing on OM3. Official Juniper QSFPs stopped the port flapping. Configurations were all correct, it was definitely a hardware problem.
We have had issues with a couple Juniper QSFPs being dead on arrival, but that was relatively easy to suss out using:
request virtual-chassis vc-port diagnostics optics member # (effected member here) vcp-#/#/# (where this is the vcp port)
So for vcp-255/2/53 on member 4 it'd be like so:
request virtual-chassis vc-port diagnostics optics member 4 vcp-255/2/53
Then the following displays results:
show virtual-chassis vc-port diagnostics optics member 4 vcp-255/2/53
Key things I've found to look at are TX and RX signal levels and power. These are indicative of either a cabling problem, or if the cable is good it's likely a hardware issue if the signal and power is out of range.
Hope that helps anybody else beating their face on their desk about this.
It is always recommended to go ahead with the Juniper Optics; rather than any third party optics.
Somewhat related, asking here as I can't find any info in the docs&forum so far:
Did you find the diagnostics request command disruptive on the link?
I have a core QFX stack acting up a bit and I don't really want to run a diag request if it disrupts the link during the day.