Comware

I am running into a few issues trying to figure out how to configure NTP. I haven't done it before. I believe I understand the principals of NTP with stratums and time servers however, I can't seem to make heads or tails on how to configure my A5800 core to be my network NTP server. I would ideally like to hook up to two pools: 0.pool.ntp.org and 1.pool.ntp.org. I've attempted to go about using both the CLI and the WebUI to no avail. Does anyone have some protips on configuring NTP? 

 

Thanks in advance everyone!

#configuration
#NTP
#server

Its something you require any internet based NTP server ip and access to that which will sync your device with and then you can use that time as time sync.

Yep, I understand the principals behind NTP. I am more or less having issues with the syntax on creating the NTP configuration. I have a source IP address I would like to use (my vlan 2 interface) and I would like to use 0.pool.ntp.org and 1.pool.ntp.org as my source addresses. I believe the command I want to use looks like :

 

ntp-service unicast-server 0.pool.ntp.org source-interface vlan-interface 2

 Is this correct? If it is how do I set the stratum? Is that done with the priority option? What about authentication-keyid? What is that option for?

 

Thanks in advance!

I'd use 3.country.pool.ntp.org, and only updates once a week or more (or else you risk your subnet being banned)

I keep getting NTP: Unknown host.

is dns resolving configured?

You know what? I don't think I have it setup right. I don't have my config in front of me but, I vaguely remember testing it out after I configured it and it didn't work. 

 

dns domain company.com
dns resolve
dns server 8.8.8.8
dns server 8.8.4.4

 Am I missing something?

---

@Justin_Goldberg wrote:

I'd use 3.country.pool.ntp.org, and only updates once a week or more (or else you risk your subnet being banned)

---

That's probably about the most inaccurate statement possible.

 

NTP syncing once a week? A ban on a whole subnet? Unlikely.

 

The NTP pool uses DNS to load-balance between public NTP servers which are run by various orginisations.

 

The only way you'd be looked at would be if you were to start throwing several hundred/thousand requests a second at a single NTP server.

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.

 

 

 

#comware
#MSR30-20
#A7500
#A5800
#NTP3
#NTP4

I just copied your entire post and saved it to my notes section. Someone definitely read this and appreciated it.

---

@MDella wrote:

...

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.

...

 

---

Hi MDella,

 

I know this is probably not helpful to your situation, but if you have a data centre full of machines, you probably should have two other important things:

1. A standard installation process which includes the necessary notes about using NTPv3 only.
2. A configuration management system like Puppet, Chef, or cfengine, which allows you to make bulk changes to configurations like this one.

I agree that it's not good that NTPv4 is not supported, though.

I get what you are saying with this Paul, but if these are really supposed to be datacenter/core grade switches competitive with the rest of the market my expectation is that they do what the rest of their competitors do at minimum. I've never had to go back with my Juniper or Cisco gear and had to sus out why NTP isn't working as expected...

All platforms have their quirks, but i agree this isn't something we should have to struggle with.

 

All i can think is that HP/H3C/3Com never intended for these switches to be used as NTP servers.

---

@paulgear wrote:

 

I know this is probably not helpful to your situation, but if you have a data centre full of machines, you probably should have two other important things:

1. A standard installation process which includes the necessary notes about using NTPv3 only.
2. A configuration management system like Puppet, Chef, or cfengine, which allows you to make bulk changes to configurations like this one.

---

So just to set the record straight on this... We use a multi-phased approach to build, launch, deploy, etc machines.  When you are dealing with numbers from 1000-20,000 machines, you have a process.  Since deployments are automated, there are LOTS of things that are thought of, dealt with, etc that service the basic functions of these machines.  Where do logs go, how are disks of varying sizes partitioned and deployed, what auditing and automated reporting systems are in place, etc.

 

When building a machine from "raw metal", you have many steps to overcome.  One of the most basic are getting time correct in your overall infrastructure.

 

For us, we start from raw metal booting the iLO of our machines off of DHCP servers.  This of course uses the SNTP function of iLO as distributed by DHCP.  Some interesting facts however... The iLO system uses GMT as its base system and does not necessarly have the "brains" to deal with DHCP 112 to allow for the changing of timezones.  Weither you knew this or not, GMT is *not* the same as UTC or (more currently) Etc/UTC timezones.  Modern OSs have to deal with ever changing politics of time and whatnot, but somehow time has to be universal.

 

Fortunately SNTP is v3 based. So we get the time.  iLO then puts the time in the RTC for you (nothing you can do about it) during a reboot of the machine (a bug that was reported and later fixed. They now put it in the RTC upon physical power cycle, not on reboots).  Why is this distinction important?!?  Because it turns out the default European/London time zone is 3600 seconds off for half the year.

 

When iLO populates the RTC, half the year it puts the wrong time in for Etc/UTC.  When the machine boots, the first thing that happens (time wise) is that ntpd starts to run, however half the year it recognizes a time slew of 3600 seconds.

 

Unfortunately, before ntpd runs AND syncs with its stratum servers, puppet starts... and of course the time checks are 3600 seconds off, so puppet refuses to work with the puppet master.... and the entire process falls apart.

 

So time is a HUGE issue.  Network devices in a data center are considered (on scale) your backbone of operations and relatively immutable.  When you have 200+ access switches, multiple cores, etc, you want a framework that is synced across the board, etc.

 

So the real issue is that on scale, all the intricate parts effect each other in ways not always understood.  In case you hadn't guessed, we have spent a HUGE amount of time (and consequently man hours * $150/hr) trying to understand the problem and how to deal with it.  Easily enough money spent to buy a few core switches.  Or understanding of the problem is much better (and better documented throughout the organization) but its the frustration of "going backwards" on an area we thought was done that prompted the above posting.

 

Don't get me wrong, we're using HP switches now throughout our backbone system (for reasons beyond the fact that they cost a quarter of cisco gear) but that doesn't change the $$$ spent in understanding what we lost in transition.

 

My point above was not to necessarly complain, but to help document what we found and our frustrations.  Also to maybe (though a forum) get someone at HP/H3C to notice and think maybe someone out there does actually care about NTP4 as an industry standard, not as something to "add on later".

 

Marcos

 

Hi Marcos,

This is probably getting a bit off-topic now, but am i curious about your daylight time issues. Am i understanding you correctly? You seem to be implying that the hardware clock and NTP are both affected by daylight time. Most of the systems i've worked with expect the hardware clock to remain in UTC all the time, and handle daylight time in userspace.

So the server has only one time, whatever is in the RTC and it counts regardless of interpertation.  The issue isn't the clock itself (nor NTP which also does it this way).  The problem is in how other programs "interpret" time and what they do with it.

 

For instance, iLO has an SNTP that reads configuration items out of DHCP.  In our case, we point to our primary two NTP servers via the DHCP system.  Unfortunately, iLO seems to set the timezone (based on using DHCP) to European/London (which I suppose used to be GMT, but GMT doesn't shift like london).  Since iLO "thinks" its really in London time, it applies its "changes" (ie, 1 hour difference) and writes that to the RTC. 

 

Now the RTC onboard has been set to be one hour off (RTC has no comphrension of timezone, it just has numbers that rotate).  When the linux OS boots, it reads time off of the RTC, and applies that to ITS timezone (in this case UTC) which means it takes the 1 hour shifted RTC and believes that that is actually UTC time so it applies it to the OS.

 

A little bit later, ntpd loads and starts doing its thing to sync time....  First time run there is a parameter to allow ntpd to skew > 3000 seconds (in this case its 3600 seconds) so ntpd moves the clock BACK to the correct time shift for UTC.  If you're smart enough to apply the SYNC_HWCLOCK=yes in /etc/sysconfig/clock to at least push this back into the RTC.

 

HOWEVER, if you are running (dl series, gen7) iLO3 version 1.55 or earlier, the iLO will reset your RTC every time the machine is reset.  If you are running 1.57 or later, iLO will ONLY overwrite the RTC upon power cycle.

 

We are still working on getting iLO to recognize the DHCP 122 field to set the timezone to Etc/UTC rather than the default of Eurpoean/London (that or getting HP to fix their iLO to put in the correct default setting as London is NOT the same as UTC).

 

Marcos

 

P.S., another plug for getting comware5 fixed... DHCP on all linux boxes does read the ntp fields, HOWEVER there is no provision automatically for changing the default of version 4 to version 3 of NTP.

Hi Marcos,

That's definitely a bit of a pickle. Are your iLOs in the same DHCP scope as your Linux host frontend LANs? If not, what i would probably do in that case is simply remove NTP from the DHCP parameters for the iLO VLAN. That way you at least avoid the iLO TZ bug, and you can put in the correct manual NTP configuration with puppet.

Chicken and egg problem. We already solved this, this is more documentation for those that follow our footsteps in the issue of trying to use COMWARE5 devices as their NTP sources.

 

Puppet doesn't fix your problem if it detects your clocks are off. So you cant use puppet to update things if things are wrong to begin with :-)

 

 

Hey since we are all talking about it, I am having an issue with my ntp stuff upon review. It seems as if my offset has climbed insanely high. How would I go about correcting it? Currently it appears that my offset is at 226 seconds. 

 

I think the issue may be I am mis-interpreting what the use of the ntp-server unicast-peer functionality is for. I was under the impression that was used for configuring devices you want to use the A-Series as an NTP server. The unicast-server I have setup has an offset of -226237.7 all the unicast-peers i have setup have a drift of less then -2.

Hi L1nklight,

Given how far this thread has gone, i think you would be best to start a new one. :-)

MDella, i'm keen to hear a follow-up if you come across an elegant solution.