In investigating, the alarms are showing an ntp problem:
# show alarms
=========== ======================================
ID Time Severity Source Category Message
==================== ===================== ==========
SSR-router 2025-01-14 02:32:36 MAJOR SYSTEM No active NTP server
# show ntp
Tue 2025-04-08 19:06:37 UTC
Retrieving NTP information...
================ ================ ======== ========= ========= ====== ====== ====== ======= ======= ======== ========
Node Time Source Status Ref. ID Stratum Type When Poll Reach Delay Offset Jitter Tally Code
SSR-router <time server1> active .INIT. 16 u -1024 0 0.000 0.000 0.000 reject
SSR-router <time server2> active .INIT. 16 u -1024 0 0.000 0.000 0.000 reject
SSR-router <time server3> active .INIT. 16 u -1024 0 0.000 0.000 0.000 reject
SSR-router <time server4> active .INIT. 16 u -1024 0 0.000 0.000 0.000 reject
SSR-router <time server5> active .INIT. 16 u - 1024 0 0.000 0.000 0.000 reject
The reject Tally Code and 0 value for Poll indicates the ntp servers are not reachable and/or responding.
Time is not syncing in the deployment
Incorrect peer path status and authentication errors
Bandwidth metrics and site reports say there are no issues with WAN connectivity
ISP carrier for the area checked and there were no issues found.
The sites are all experiencing slowness according to local IT
To confirm, drop to the shell and try the following:
# ntpdate -u time.google.com
Then at pcli run the following again:
Wed 2025-04-09 14:24:13 UTC
✔ Retrieving NTP information...
================ ================ ======== ========= ========= ====== ====== ====== ======= ========
SSR-Router <time server1> active .STEP. 16 u -64 0 0.000 0.000 0.000 reject
SSR-Router <time server2> active .STEP. 16 u -64 0 0.000 0.000 0.000 reject
SSR-Router <time server3> active .STEP. 16 u -64 0 0.000 0.000 0.000 reject
SSR-Router <time server4> active .STEP. 16 u -64 0 0.000 0.000 0.000 reject
SSR-Router <time server5> active .STEP. 16 u -64 0 0.000 0.000 0.000 reject
SSR-Router *216.239.35.0 active .GOOG. 1 u 2 64 1 34.286 2.396 2.027 syspeer
This confirms there is no problem with SSR itself and connectivity to the time servers should be troubleshot.