Joe,
Could you check/post the output of "utils ntp status" from the CUPS server console? In regards to the firewall list on the CUCM, there should be a line for udp port 123. If you have a Linux or Mac host, you could check to see if you can reach NTP on the CUCM server by using the ntpq command.
For example:
sh-3.2# ntpq -c peers 10.3.4.20
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.3.2.1 204.9.54.119 2 u 45 64 377 2.341 -81.569 29.076
In the example above, 10.3.4.20 is my CUCM publisher node.
If you only have a Windows PC/server then you can probably find a NTPQ windows binary on the internet. The older CallManager servers had a NTP package called XNTP, which I used on my Windows boxes in the lab.
If you can successfully run a NTP query (ntpq) on the CUCM from a remote station, then the CUCM firewall is not blocking you.
You could also try to troubleshoot this using the network capture facility on the CUCM and CUPS servers. For example:
admin:utils network capture port 123 count 1000 size 128 host ip 192.168.1.4
Executing command with options:
size=128 count=1000 interface=eth0
src= dest= port=123
ip=192.168.1.4
In this example, I am running the capture on my CUCM and the 192.168.1.4 address is my macbook running the ntpq command. However, you could set this up on both the CUCM-BE and CUPS server.
On CUCM:
admin:utils network capture file ntpcheckFromCUCM count 100000 size all port 123
On CUPS:
admin:utils network capture file ntpcheckFromCUPS count 100000 size all port 123
You could also filter by IP addresses if you wanted to see other information (like an ICMP port unreachable?). In this latter case, I would recommend filtering by IP address on the CUPS server (host ip ) and by port on the CUCM server. Mmm, well maybe if you did an ip filter in both it wouldn't be too bad. You may need to check to see if there is too much info in the trace.
Anyway, after you execute the command on both servers. You may want to open up a NEW SSH session to the CUPS server and execute a NTP restart (utils ntp restart) or start (utils ntp start). After a minute, you will want to enter Ctrl-C on the CUCM-BE and CUPS SSH sessions where you initiatied the capture.
You can then download the capture files:
On CUCM:
admin: file get activelog platform/cli/ntpcheckFromCUCM.cap
On CUPS:
admin: file get activelog platform/cli/ntpcheckFromCUPS.cap
You can then use Wireshark or some other protocol analyzer to review the sniffer traces.
Now, you don't necessarily have to capture the output for processing off box, if you go back to the example where I was capturing traffic on port 123 to/from host 192.168.1.4 (above) then you could at least determine packets were being exchanged. In our example, I ran a ntpq -c peers command from 192.168.1.4 right after setting up the capture on the CUCM host. Here is the output:
admin:utils network capture port 123 count 1000 size 128 host ip 192.168.1.4
Executing command with options:
size=128 count=1000 interface=eth0
src= dest= port=123
ip=192.168.1.4
19:44:52.953623 IP 192.168.1.4.61591 > iecucm01.cnclab.com.ntp: NTPv2, Reserved, length 12
19:44:52.954080 IP iecucm01.cnclab.com.ntp > 192.168.1.4.61591: NTPv2, Reserved, length 16
19:44:52.957733 IP 192.168.1.4.61591 > iecucm01.cnclab.com.ntp: NTPv2, Reserved, length 12
19:44:52.957910 IP iecucm01.cnclab.com.ntp > 192.168.1.4.61591: NTPv2, Reserved, length 480
19:44:52.957975 IP iecucm01.cnclab.com.ntp > 192.168.1.4.61591: NTPv2, Reserved, length 144
You can tell two things from this output. First, the NTP packets from 192.168.1.4 successfully reached the CUCM server. This definitively tells us the network isn't blocking. Second, you can see that the CUCM server (iecucm01) responds on the NTP port. This definitevely tells us that the CUCM firewall isn't blocking anything. Of course, I suspect that if the host firewall was blocking NTP we may even find that the first NTP packet is not seen. I would have to test that but the result is not important.
At this point, you should have enough data to determine where the communication is breaking.
Note, that if you needed to test the host based firewall (i.e. remove it from the equation), then you could try to disable the firewall (utils firewall disable). I haven't done this myself, so read up on this command before you start your testing.
HTH.
Regards,
Bill
Please rate helpful posts.
