cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1762
Views
5
Helpful
3
Replies

Call Manager Subscriber cannot connect to Publisher NTP

tcmckay
Level 1
Level 1

I am running 11.5 and recently without any changes in our environment the Subscriber is spitting out the following error every 2 min:

Primary node NTP server, cuc-pub, is currently inaccessible or down. Verify the network between the primary and secondary nodes.  Check the status of NTP on both the primary and secondary nodes via CLI 'utils ntp status'.  If the network is fine, try restarting NTP using CLI 'utils ntp restart'.

 

I have logged into the Pub and Sub cli and run this command

utils ntp status

Pub

:utils ntp status
ntpd (pid 22582 22450) is running...

remote refid st t when poll reach delay offset jitter
==============================================================================
10.10.1.10 .LOCL. 1 u 63 64 377 0.146 -116.19 17.419


unsynchronised
polling server every 8 s

 

Sub

ntp status
ntpd (pid 8546) is running...

remote refid st t when poll reach delay offset jitter
==============================================================================
10.8.16.34 .INIT. 16 u 599 1024 0 0.000 0.000 0.000


unsynchronised
polling server every 8 s

 

When I run utils network ping both hosts can reach each other.

 

The Pub looks at a local DC for time and the Sub looks at the Pub.  I have also restart NTP on both nodes several times but this did not resolve the issue.

 

Any suggestions are appreciated before I involve TAC.

1 Accepted Solution

Accepted Solutions

In order to get this resolved I added the Call Manager Publisher as the NTP server on the CUC-Publisher and made sure the CUC-Sub looked at the CUC-Pub for NTP. Once I added the Call Manager as NTP the previous NTP started working and the new NTP worked. I am not sure why it stopped or why I had to add another NTP to get the original running but it all works now.

View solution in original post

3 Replies 3

Mike_Brezicky
Cisco Employee
Cisco Employee
Ive had this happen on CUCM clusters that were regionally separate and on the edge of the latency distance.
You can try rebooting the cluster, but TAC would be your next best option because root access would likely be needed to clear any potential problems in NTP.

Kaloyan
Cisco Employee
Cisco Employee

Hello,

Have you tried taking packet captures from the subscriber to determine if there's NTP connectivity with the publisher? In most cases this is a network related issue. I suggest running a simultaneous packet captures from the publisher and the subscriber to determine if there's any NTP communication between them.

1. From the CLI of the pub type "utils network capture eth0 port 123 file PCAP_pub count 100000 size all host ip <SUBSCRIBER IP address>"
2. From the CLI of the sub type "utils network capture eth0 port 123 file CiscoTAC PCAP_sub 100000 size all host ip <PUBLISHER IP address>"
3. Restart the NTP on the subscriber with "utils ntp restart"
4. Let the captures run about a minute and stop them by pressing CTRL + C
5. Collect via RTMT > Trace & Log Central > Collect Files > Packet capture logs
6. Analyze them using Wireshark to see if you see bidirectional NTP communication between the servers (who sends what, who receives what etc).

Refer to this article for more NTP troubleshooting information (it is for CUCM but it is pretty much the same) https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118718-technote-cucm-00.html.




In order to get this resolved I added the Call Manager Publisher as the NTP server on the CUC-Publisher and made sure the CUC-Sub looked at the CUC-Pub for NTP. Once I added the Call Manager as NTP the previous NTP started working and the new NTP worked. I am not sure why it stopped or why I had to add another NTP to get the original running but it all works now.