cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
679
Views
0
Helpful
1
Replies

ASR9006

Leo Monge
Level 1
Level 1

Hi Fellows;

Anybody Knows what´s the meaning of the next log error: 

%IP-IP_NTP-5-ALL_CONN_LOST : All NTP peer connections failed.
RP/0/RSP0/CPU0:May 19 19:47:32.868 : ntpd[261]: %IP-IP_NTP-5-LP_CONN_RECOVERED : At least a low priority NTP peer connection was recovered - Stratum 15->4.
RP/0/RSP0/CPU0:May 20 09:44:57.434 : ntpd[261]: %IP-IP_NTP-5-SYNC_LOSS : Synchronization lost : 10.192.0.14 : The clock was stepped and needs to be resynced

It is critical??

equipment ASR9006

image: disk0:asr9k-os-mbi-4.3.1/0x100305/mbiasr9k-rsp3.vm,1;

 

Thanks in advance!!

 

1 Accepted Solution

Accepted Solutions

xthuijs
Cisco Employee
Cisco Employee

hi there,

this is not that critical, what it means is that the 9006 lost its connection with the NTP server and needed to resync. The clock (date/time) will be running on its own internal system clock and is not synced to the time source required. the internal clock is very accurate already, but there may be a msec/usec skew.

what happened was that the update from the ntp server was out of the boundaries for the xr ntp implementation to resync on that update received and instead dropped the sync completely and restarted from scratch to get the sync back going.

If this situation happens frequently, it may mean that ntp packets in between are getting dropped or the time server is updating its time with too much variation.

I know we made some enahcenemtns in NTP in XR to deal with this more gracefully, but that in itself is not a necessity to upgrade.

if you like more detail, the show ntp trace may hold some extra info you want to know to help mitigate thi if this continues on.

regards

xander

View solution in original post

1 Reply 1

xthuijs
Cisco Employee
Cisco Employee

hi there,

this is not that critical, what it means is that the 9006 lost its connection with the NTP server and needed to resync. The clock (date/time) will be running on its own internal system clock and is not synced to the time source required. the internal clock is very accurate already, but there may be a msec/usec skew.

what happened was that the update from the ntp server was out of the boundaries for the xr ntp implementation to resync on that update received and instead dropped the sync completely and restarted from scratch to get the sync back going.

If this situation happens frequently, it may mean that ntp packets in between are getting dropped or the time server is updating its time with too much variation.

I know we made some enahcenemtns in NTP in XR to deal with this more gracefully, but that in itself is not a necessity to upgrade.

if you like more detail, the show ntp trace may hold some extra info you want to know to help mitigate thi if this continues on.

regards

xander

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: