Cisco Bug: CSCsz22456 - 3.9 GSR PRP-2 lost NTP peer connection from time to time
Mar 09, 2018
- Cisco 12000 Series Routers
Known Affected Releases
Symptom: After route processor fail over, the new active route processor may keep repeating NTP synchronization and un-synchronization, e.g. RP/0/0/CPU0:Apr 21 14:12:30.326 : ntpd: %IP-IP_NTP-5-HP_CONN_RECOVERED : High priority NTP peer connection recovered - Stratum 15->2. RP/0/1/CPU0:Apr 21 14:17:54.236 : ntpd: %IP-IP_NTP-5-SYNC_LOSS : Synchronization lost : DLRSC node : Peer unreachable or clock selection failed RP/0/0/CPU0:Apr 21 14:29:42.126 : ntpd: %IP-IP_NTP-5-SYNC_LOSS : Synchronization lost : <ip add> : The clock was stepped and needs to be resynced RP/0/0/CPU0:Apr 21 14:29:42.126 : ntpd: %IP-IP_NTP-5-HP_CONN_LOST : High priority NTP peer connection lost - Stratum 2->15. RP/0/0/CPU0:Apr 21 14:29:42.127 : ntpd: %IP-IP_NTP-5-ALL_CONN_LOST : All NTP peer connections failed. RP/0/0/CPU0:BISCUIT-BR#RP/0/0/CPU0:Apr 21 14:35:03.210 : ntpd: %IP-IP_NTP-5-HP_CONN_RECOVERED : High priority NTP peer connection recovered - Stratum 15->2. Conditions: At the time of route processor failover, there is a case where the route processor is still standby and is in the middle of learning the clock frequency from the previous active route processor, i.e., adjusting its clock frequency to the correct one. The route processor failover may disrupt the frequency adjustment process and results in transient/inaccurate clock frequency. If there is a large frequency difference between the transient one and the external NTP server's one, the new active route processor encounters repetitive NTP synchronization and un-synchronization.
Related Community Discussions
Bug details contain sensitive information and therefore require a Cisco.com account to be viewed.
Bug Details Include
- Full Description (including symptoms, conditions and workarounds)
- Known Fixed Releases
- Related Community Discussions
- Number of Related Support Cases