Can people please edit their posts to include ROS version and if BGP, NTP server etc was running?
I have 28 tile devices running NTP (and no routing protocols), versions are between 6.22 and 6.29.1. All crashed, though 25 of them rebooted themselves via watchdog timer. 3 needed power cycling.
Have three CCRs, and they all crashed. They were each running a different version (6.26, 6.28, and 6.29)
Have a customer that has a CCR that didn’t lockup, but don’t know if it is poling ntp. It could also be that the others caused it to not be able to update it’s clock, so it didn’t get the time 23:59:60.
I just got back from the trip around my network nodes (it took about 2 hours by car. Fortunately I disabled in time the NTP server on most of the routers, I have more than 60 installed and some are very far)…
My routers have 6.26, 6.27, 6.28, 6.29, 6.29.1 and they all crashed. All kinds of CCR (1009, 1016, 1032 on various flavors).
They have all BGP routing protocol, only a few have the full routing table, while most of them have only my internal routes.
They have all the clock synchronized through NTP.
It happened both to routers with and without NTP package, at 00:00 UTC (02:00 local time).
The funny thing is that by chance it happened for the first time on the 1st of April and other forum users thought that it was an april fool’s joke.
Mikrotik didn’t take the ticket seriously because it said it happened only to me. (As I stated it was by chance, due to a driver bug on public italian NTP services, and it hasn’t been easy to find out!).
20+ CCRs all dead.
Time to replace all my mikrotiks.
I have two CCR with NTP package installed. Both crashed today.
No NTP package - no crash.
All our CCR’s locked up right at 7pm CDT. 3 x86 units did not, MT493 units did not.
This is very strange.
Same here, almost all CCR down, and the only way was to power reboot. NTP, BGP, OSPF, var 6.29.1, OSPF 3,
does setting up watchdog helps ?
all CCR down here as well, until manual power cycle. 6.29, no BGP, static routing, NTP as client from 192.53.103.104/192.53.103.108.
i got 4 ccr1036 v6.27, 4 of them crashed. the others ccr is safe, among them using v6.29. and v6.19.
OK, first of all sorry about previous joke poster, cause looks like i had similar problem, but only on few CCRs.
Am i right to say that only CCRs with NTP package installed and configured was affected?
2 CCR crashed, i hope the bug will get fixed soon.
More details:
-
- CCR1036-12G-4S
-
- version 6.27
-
- NTP package installed. NTP client configured to a public server
yes, it seems so, i got v6.27 which NTP package installed and the CCR was crashed.
but the others which have v6.27 without NTP package installed, they are normal.
but some of my CCR using v6.19 with NTP package installed are not crashed.
And all were synchronized (configured) to public server?
Now, tell me I did not warn you.
Most of my CCRs don’t have the NTP package installed, and they all crashed badly.
I have one ccr (ccr1036-8g-2s+) running BGP, OSPF, OSPF3 on v6.19 (uptime 200+ days)
Yesterday, I saw this thread while searching for possible issues with the upcoming leap second,
disabled the ntp client on time.
It did not crash.
Maybe the time on the router is not that important,
maybe, we could let it disabled?
Could a time drift cause any problems for example BGP?
you can also use “IP Cloud” automatic time. It will not be as precise, within 1-2 seconds usually.
Having the time synchronized is a must, because otherwise it’s difficult (if not impossible) compare logs of multiple devices, and in a complex network it helps debug troubles quickly.
Normis ip cloud time synchronization is not an option for many reasons, and it’s not always applicable.
of course. but better than no NTP at all