I've run into this problem now for the second time in two weeks. The Sunday before last I was called because the MX64 at that location was taking an extended amount of time to check into the Dashboard. Multiple reboots and resets were attempted to no avail. It was using a 4G gateway as it's WAN link and a laptop directly connected to that gateway worked without issue. A call to Meraki led to an RMA being processed for the MX however when I got to work on Monday morning the MX had checked in. We decided to proceed with the replacement to be safe.
No outbound traffic is blocked so the rules detailed in the MX Help>Firewall menu shouldn't come into play because access to those IPs on those ports is allowed.
Today I was trying to provision a couple of full stacks and ran into the same issue. The connection was attempted using three different MXes and 4 different network links including two different 4G gateways. Again a connected laptop worked without issue. Currently I have the MX connected on an access port normally used for my test set. When I watch traffic on that port I see a trickle (4-7 packets per second). This is on a 100Mb connection so speed shouldn't be an issue.
In all cases, I'm getting the rainbow of lights as the device attempts to register. My plan is to leave the MX running overnight and hope it has checked in by the morning. I'm wondering if anyone else has run into this because we provision our gear before shipping but at this rate I better start on my January networks now.
This particular hardware is being re-used (it's not new out of the box) but was removed from the old network which was then deleted returning it to inventory from where it was then added to the new destination network. Pings to the LAN facing IP address of the MX, even sourced from the gateway address fail despite being arp'ed, the port being up and it passing the small amount of traffic it is.
When a device has been joined to a network one of the first things it does is change its software version to what that network is using. It does this before reporting that it has checked into the dashboard.
If you have a slow link this can take a while. Sometimes a device also has trouble changing its software version and can get stuck. Note that the dashboard only reports the version of software the device should be running - not what it actually is running. Support can check the actual software version a device is running.
Rarely a device can get into a software upgrade/downgrade loop. The local status page usually reflects this by telling you it is upgrading.
A brand new out of the box switch can easily take 40 minutes to complete its software upgrade. We usually plug them in at least 24 hours before we want to use them to make sure that part is out of the way.
Our experience is similar to @PhilipDAth. The other thing we do for new warm spare units and is the secondary goes into it's own network temporarily until it gets it code. After that we move it over to the primary's network.
Depending how long your MX64 has been sitting on the shelf that may help. When we received our first batch of MX100s a few years ago the base code didn't support warm spare until after the initial code upgrade.
So here's an update. As expected, it finally checked in shortly after I left for the day.
We tried something seen elsewhere, un-claiming, resetting, re-claiming then adding the MX to the desired network. It came online within a few minutes.
While I understand and agree with the replies regarding the need to upgrade code, these MXes haven't been offline that long (no more than a week or so) so they shouldn't be badly out of date and it doesn't explain the trickle of data I see on a link that otherwise runs at expected speeds.
I'm not convinced that there isn't something else going on.