Wanted to follow up on this thread (a year later) because I am having HUGE issues with COMWARE 5.20 and is inability to use NTP4. Rather NTP3 is has high as it goes and has caused no end of problems on our network as the default for the bulk of our equipment is NTP4.
We have two A7500 core switches in our network along with two MSR30-20 and two A6604 routers. The two routers are set up as VRRP routers for failover and we made them our "central" NTP servers for our overall domain. Our problems started when we realized that none of our CentOS6 machines were connecting to the ntp servers within our network. We have thousands of servers so its a non-trivial process to point them all to public resources (and quite honestly, no one that does scale builds would ever do that anyway).
After a bunch of research, we finally figured out that none of our HP gear spoke NTP4. Unfortunately we ended up adding a few Cisco routers for no other reason than to do some "make work" and be our internal NTP servers (ie, Cisco does do NTP4 whereas COMWARE does not).
Again, its easy to "say" just change all your servers to do "ntpdate -o3 ntp1.domainname.com" or something like that, but if you look at the effort to push changes like that to a data center full of machines as well as keep it up to date for new machines, its just more overhead on a staff that already doesn't have time for these kinds of problems.
As a short review, we are running on all our JC105A's (A5800 H3C switches) Comware Software, Version 5.20.105, Release 1808P02. We are using the statements:
ntp-service unicast-server 172.24.192.2
ntp-service unicast-server 172.24.192.3
Which just works as NTP3 clients....
<SC9-A07-SW>display ntp sessions
source reference stra reach poll now offset delay disper
********************************************************************************
[12345]172.24.192.2 38.229.71.1 3 255 1024 36 5.2 13.7 14.8
[245]172.24.192.3 38.229.71.1 3 255 1024 898 7.5 10.1 14.8
note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured
Total associations : 2
On our core switches (A7506 H3Cs) Comware Software, Version 5.20, Release 6616P05 we do basically the same thing.
One of the routers that we were TRYING to get to work was an A-MSR30-20 (JF284A) router that was running
Comware Software, Version 5.20, Release 2207P41, Standard
ntp-service source-interface GigabitEthernet0/0
ntp-service unicast-server 192.114.71.34
ntp-service unicast-server 74.122.204.5
ntp-service unicast-server 72.26.198.240
ntp-service unicast-server 38.229.71.1
In this case we got the following:
<TW-RTR1>display ntp sessions
source reference stra reach poll now offset delay disper
********************************************************************************
[25]192.114.71.34 193.67.79.202 2 0 64 9d 0.0 0.0 0.0
[12345]38.229.71.1 172.16.32.4 2 255 64 32 0.1 57.0 0.9
[245]74.122.204.5 199.101.96.57 3 255 64 10 -6.1 54.4 1.2
[245]72.26.198.240 108.61.73.244 3 255 64 9 3.1 72.4 0.9
note: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured
Total associations : 6
----
no matter how we configured any client (unix based), pointing to any of the three devices all yielded "blank connections" unless we forced an NTP3 query (which you have to set to accomplish).
For ntpdate, we used "ntpdate -o3 ntp1.domainname.com"
For ntpd we had to specify in the /etc/ntp.conf file:
server ntp1.domainname.com version 3
server ntp2.domainname.com version 3
Which then give us the following on our CentOS 6 server:
ntpdc> peers
remote local st poll reach delay offset disp
=======================================================================
=172.24.192.2 172.24.192.160 3 64 1 0.00063 8.320428 2.81735
=172.24.192.3 172.24.192.160 3 64 1 0.00056 8.320468 2.81735
Without specifying version 3, you get basically "st 16" with all zeros for times.
I've googled all over and have yet to find definitive reasons why NTP4 does not work on COMWARE devices. But as of June 2013, apparently NTP4 still is not available to COMWARE devices and you have to configure NTP3 throughout your network if you want to use your network devices as common sources.
Note that the above configurations are all you need for these devices to "service" the NTP3 requests. The caviat is that they will ONLY service NTP3 requests. NTP4 requests will just "disappear" in the ether and you'll be left scratching your head for some time as to what you configured wrong, etc. Nothing wrong, your just making the wrong request (too modern) to a device that only supports the older, non-default standard.
---
I sure hope this gets cached in google and someone else benefits from our struggles. Its been a long process to debug this as every other device "just works" out of the box for NTP4. We never even suspected this problem while searching and other than one other post out there, have not ran into anyone else that has bothered to type up their results.
