"""george_joby ÐÉÓÁÌ(Á):
"""
> Hi
>
> I am trying to configure NTP server in Windows 2003 server and client
> as Redhat Linux AS 4. But if I use W32time of Windows my client will
> never synchronise with the server. But if I use the third part software
> in Windows server 2003 (http://www.meinberg.de/english/sw/ntp.htm) my
> Linux client will synchronise with the server. I heard that W32time is
> based on SNTP but read that SNTP and NTP can be used interchangebly.
> (http://www.microsoft.com/technet/sol...w/21wsdsu.mspx)
>
>
> But I am not able to syncronize with the server at all.
>
> My configuration is just between two system in a local lan using cross
> cable. Server is configured to use internal clock.
>
> My client want to try with w32time. Also I saw this ...
>
> http://ntp.isc.org/bin/view/Support/...P#Section_9.10.
>
> Can any body help me in this. Will w32time work with linux ?

http://sourceforge.net/projects/openrdate/

george_joby wrote:
> Can any body help me in this. Will w32time work with linux ?

Yes it will, but you are better off doing it the other way around
(having the windows box take time from the Linux box). The "real" NTP
provides better precision (Windows Time Service is limited to abotu
16ms), so it should be the source. You should also give it access to an
internet NTP time server if at all possible (simply opening UDP port
123 outbound for one machine isn't much of a security risk).

In most cases, Windows 2003 SP1 will not serve time to clients when it
has no access to an external time source itself. You will see error
messages indicating this in Event viewer. I am betting that is what you
are experiencing.

Ry wrote:
> george_joby wrote:
>
>>Can any body help me in this. Will w32time work with linux ?
>
>
> Yes it will, but you are better off doing it the other way around
> (having the windows box take time from the Linux box). The "real" NTP
> provides better precision (Windows Time Service is limited to abotu
> 16ms), so it should be the source. You should also give it access to an
> internet NTP time server if at all possible (simply opening UDP port
> 123 outbound for one machine isn't much of a security risk).
>

Isn't port 123 UDP inbound required as well?

Richard B. Gilbert wrote:

> Isn't port 123 UDP inbound required as well?

Not on a stateful firewall, which are the most common type these days.
In most firewall configuration tools, "allow UDP port 123 outbound"
means that when a outbound packet is sent, the firewall will remember
seeing it (that's the *stateful* part) allow a return UDP packet(s)
from the destination IP and source port for a few seconds before
closing things off again.

This assumes all he is doing is configuring his NTP to act as a client
to an internet-based NTP server. If he is going to be using
symmetric/active or another mode, that's going to require allowing UDP
port 123 inbound. But it doesn't seem to me that he would need to do
anything like that.

Our requirement is all our linux and nonstop systems synchronise to the
Windows 2003 server. We do not want Windows to syncronise with an
external clock and it should just synchronise with its internal clock.

So what I am doing is just configuring with a client (Redhat Linux) and
server (windows 2003) to check whether Linux gets synchronise with
Windows server and that is not happening. Our customer need this setup.

If i see the ntpq -pn in Linux it will show the correct offset and also
ntpdate works fine. But Linux not ready to synchronise with Server.

[root@txnaslload03 ~]# ntpq -pn
remote refid st t when poll reach delay offset
jitter
================================================== ============================
16.74.32.162 .LOCL. 1 u 967 1024 377 0.355 -180.34
5.407

Thanks
George

Ry wrote:
> Richard B. Gilbert wrote:
>
> > Isn't port 123 UDP inbound required as well?
>
> Not on a stateful firewall, which are the most common type these days.
> In most firewall configuration tools, "allow UDP port 123 outbound"
> means that when a outbound packet is sent, the firewall will remember
> seeing it (that's the *stateful* part) allow a return UDP packet(s)
> from the destination IP and source port for a few seconds before
> closing things off again.
>
> This assumes all he is doing is configuring his NTP to act as a client
> to an internet-based NTP server. If he is going to be using
> symmetric/active or another mode, that's going to require allowing UDP
> port 123 inbound. But it doesn't seem to me that he would need to do
> anything like that.

Also the ntpq association show reject in condition

ntpq> associations

ind assID status conf reach auth condition last_event cnt
================================================== =========
1 41148 9014 yes yes none reject reachable 1
2 41149 9614 yes yes none sys.peer reachable 1

Thanks
George

george_joby wrote:
> Our requirement is all our linux and nonstop systems synchronise to the
> Windows 2003 server. We do not want Windows to syncronise with an
> external clock and it should just synchronise with its internal clock.
>
> So what I am doing is just configuring with a client (Redhat Linux) and
> server (windows 2003) to check whether Linux gets synchronise with
> Windows server and that is not happening. Our customer need this setup.
>
> If i see the ntpq -pn in Linux it will show the correct offset and also
> ntpdate works fine. But Linux not ready to synchronise with Server.
>
> [root@txnaslload03 ~]# ntpq -pn
> remote refid st t when poll reach delay offset
> jitter
> ================================================== ============================
> 16.74.32.162 .LOCL. 1 u 967 1024 377 0.355 -180.34
> 5.407
>
> Thanks
> George
>
> Ry wrote:
> > Richard B. Gilbert wrote:
> >
> > > Isn't port 123 UDP inbound required as well?
> >
> > Not on a stateful firewall, which are the most common type these days.
> > In most firewall configuration tools, "allow UDP port 123 outbound"
> > means that when a outbound packet is sent, the firewall will remember
> > seeing it (that's the *stateful* part) allow a return UDP packet(s)
> > from the destination IP and source port for a few seconds before
> > closing things off again.
> >
> > This assumes all he is doing is configuring his NTP to act as a client
> > to an internet-based NTP server. If he is going to be using
> > symmetric/active or another mode, that's going to require allowing UDP
> > port 123 inbound. But it doesn't seem to me that he would need to do
> > anything like that.

george_joby wrote:
> Also the ntpq association show reject in condition
>
> ntpq> associations
>
> ind assID status conf reach auth condition last_event cnt
> ================================================== =========
> 1 41148 9014 yes yes none reject reachable 1
> 2 41149 9614 yes yes none sys.peer reachable 1
>
> Thanks
> George

Yes. They will. W32time is not a useable NTP server.

You could make your W2003 box an NTP server, but not a very good
one, by installing the reference implmentation of NTP
( http://www.meinberg.de/english/sw/ntp.htm ) and abandoning
W32time. It will then work, but as long as your server is Windows,
you'll still have to settle for poor accuracy, and as long as you
have no precision clock references, you'll have to settle for
no accuracy and poor stability.

As previously suggested, your best approach would be instead
to abandon the original idea and to use one of your other
non-Windows systems as your server, configuring your W2003
box as a client of that (w32time or NTP, if you want it
to work better).

You will, however, continue to have various problems until you
start with quality servers that are running both a full NTP
implementation AND use several precision reference sources.

-Tom

On 2007-01-18, Ry wrote:
>
> Richard B. Gilbert wrote:
>
>> Isn't port 123 UDP inbound required as well?
>
> Not on a stateful firewall, which are the most common type these days.

Port 123/UDP inbound must be open for NTP to work. It can either be
opened automatically (by a stateful firewall or NAT) or manually. But it
must be opened.

--
Steve Kostecke
NTP Public Services Project - http://ntp.isc.org/

On 2007-01-18, george_joby wrote:

> Our requirement is all our linux and nonstop systems synchronise to
> the Windows 2003 server. We do not want Windows to syncronise with an
> external clock and it should just synchronise with its internal clock.

Then your requirement precludes the use of NTP.

--
Steve Kostecke
NTP Public Services Project - http://ntp.isc.org/

george_joby wrote:
> Our requirement is all our linux and nonstop systems synchronise to the
> Windows 2003 server. We do not want Windows to syncronise with an
> external clock and it should just synchronise with its internal clock.
>
> So what I am doing is just configuring with a client (Redhat Linux) and
> server (windows 2003) to check whether Linux gets synchronise with
> Windows server and that is not happening. Our customer need this setup.
>
> If i see the ntpq -pn in Linux it will show the correct offset and also
> ntpdate works fine. But Linux not ready to synchronise with Server.
>
> [root@txnaslload03 ~]# ntpq -pn
> remote refid st t when poll reach delay offset
> jitter
> ================================================== ============================
> 16.74.32.162 .LOCL. 1 u 967 1024 377 0.355 -180.34
> 5.407
>
> Thanks
> George
>
> Ry wrote:
>


Windows does not include NTP by default. It runs Microsoft's
implementation of SNTP, a stripped down version which lacks many of the
features and safeguards included in the full implementation.
Microsoft's version, unless it is very recent, does not comply with
RFC-2030, the standard for SNTP. Systems running SNTP are not considered
acceptable as servers unless they are connected to a hardware reference
clock, such as a GPS Timing Receiver.

You can get a Windows version of NTP but there's no point if you insist
on operating without either an internet server or a hardware reference
clock.

You can "require" anything you please but the software is not obligated
to provide it.

If you client does not care about having the correct time you could
configure the local clock on the Linux system as a "reference clock" as
follows:

In ntp.conf, put:
#
# Declare the local clock to be the clock of last resort.
# It will be used to serve time in the absence of any other.
#
server 127.127.1.0 # Local clock, unit 0
fudge 127.127.1.0 stratum 10 # Ensure that no one with a choice
# will believe this clock!!

If you MUST use the Windows system as the server, you will have to
install NTP on it. There are three Windows versions available
Windows NT / 2000 / XP / Windows .NET Server 2003
http://norloff.org/ntp/ - Maintained by TerjeMathisen
(terje.mathisen@hda.hydro.com)
Windows NT 4, Windows 2000, Windows XP, Windows 2003 Server - English -
http://www.meinberg.de/english/sw/ntp.htm Maintained by HeikoGerstung
and
http://www.meinberg.de/german/sw/ntp.htm Windows NT 4, Windows 2000,
Windows XP, Windows 2003 Server - German - Maintained by HeikoGerstung

"Steve Kostecke" wrote in message
news:slrneqvgoq.k4p.kostecke@stasis.kostecke.net.. .
> On 2007-01-18, george_joby wrote:

>> Our requirement is all our linux and nonstop systems synchronise to
>> the Windows 2003 server. We do not want Windows to syncronise with an
>> external clock and it should just synchronise with its internal clock.
>
> Then your requirement precludes the use of NTP.

I don't get this. Install NTP on the Windows server, configure the
local clock (at stratum 10, please), done.

No, it won't make the real time magically appear on that server.
I think George is aware of that.

Insisting that NTP _doesn't work_ without a source of UTC somewhere
sounds like a political agenda. It does work. In a degraded manner,
for sure, but more gracefully so than some of the moping that can
be witnessed here.

Groetjes,
Maarten Wiltink

On 2007-01-18, Maarten Wiltink wrote:
> "Steve Kostecke"
>> On 2007-01-18, george_joby wrote:
>
>>> Our requirement is all our linux and nonstop systems synchronise to
>>> the Windows 2003 server. We do not want Windows to syncronise with an
>>> external clock and it should just synchronise with its internal clock.
>>
>> Then your requirement precludes the use of NTP.
>
> I don't get this.

Let me rephrase that: "Then your requirement precludes the use of NTP
on the client systems unless you install NTP on the Windows server."

> Install NTP on the Windows server, configure the local clock (at
> stratum 10, please), done.

Right. Except for the fact that the OP seems to be determined to use
w32time.

> No, it won't make the real time magically appear on that server.

There's more to it than that.

Without a proper "time base" how is NTP supposed to ensure that one
second is acceptably close (i.e. +/- a handful of ms) to one second?

--
Steve Kostecke
NTP Public Services Project - http://ntp.isc.org/

"Steve Kostecke" wrote in message
news:slrner0i3p.bu0.kostecke@stasis.kostecke.net.. .
> On 2007-01-18, Maarten Wiltink wrote:

>> won't make the real time magically
>> appear on that server.
>
> There's more to it than that.
>
> Without a proper "time base" how is NTP supposed to ensure that one
> second is acceptably close (i.e. +/- a handful of ms) to one second?

A handful of milliseconds is several thousand PPM. Few crystals are
_that_ bad. NTP requires a 'reasonable' crystal to begin with. Witness
the problems with speedstepping notebooks.

But this is one of the areas where operation without a proper time
reference is degraded, and awareness of that is a good thing.

Groetjes,
Maarten Wiltink

"Maarten Wiltink" wrote in message
news:45b07dba$0$335$e4fe514c@news.xs4all.nl...
> "Steve Kostecke" wrote in message
> news:slrner0i3p.bu0.kostecke@stasis.kostecke.net.. .
[...]
>> Without a proper "time base" how is NTP supposed to ensure that one
>> second is acceptably close (i.e. +/- a handful of ms) to one second?

> [...] this is one of the areas where operation without a proper time
> reference is degraded, and awareness of that is a good thing.

As would be, I wanted to mention but forgot, running _with_ external
servers for awhile to estimate native drift. You can cut your wires to
the big bad outside again before connecting your newly calibrated
timeserver to your own closed network.

Groetjes,
Maarten Wiltink

Steve Kostecke wrote:

> On 2007-01-18, Maarten Wiltink wrote:
>
>>"Steve Kostecke"
>>
>>>On 2007-01-18, george_joby wrote:
>>
>>>>Our requirement is all our linux and nonstop systems synchronise to
>>>>the Windows 2003 server. We do not want Windows to syncronise with an
>>>>external clock and it should just synchronise with its internal clock.
>>>
>>>Then your requirement precludes the use of NTP.
>>
>>I don't get this.
>
>
> Let me rephrase that: "Then your requirement precludes the use of NTP
> on the client systems unless you install NTP on the Windows server."
>
>
>>Install NTP on the Windows server, configure the local clock (at
>>stratum 10, please), done.
>
>
> Right. Except for the fact that the OP seems to be determined to use
> w32time.
>
>
>>No, it won't make the real time magically appear on that server.
>
>
> There's more to it than that.
>
> Without a proper "time base" how is NTP supposed to ensure that one
> second is acceptably close (i.e. +/- a handful of ms) to one second?
>

I think that should should be "+/- a hand full of microseconds"! If
the time base is off by more than 500 PPM a substantial number of
clients may not be able to synchronize to it at all!

Is this a documentation issue or a "wishful thinking" issue? A
substantial portion of the traffic here is due to people wanting to
"synchronize clocks to each other" without regard to UTC. It has always
seemed clear to me that NTP was designed to synchronize clocks to UTC
and that synchronization of clocks to each other is a happy consequence
of "things equal to the same thing are equal to each other"!

george_joby wrote:
> Our requirement is all our linux and nonstop systems synchronise to the
> Windows 2003 server. We do not want Windows to syncronise with an
> external clock and it should just synchronise with its internal clock.

As many others have stated, the configuration you wish to use is not
what NTP (or even w32time) were designed to do, and is very likely to
be troublesome. Without an external time reference, and at least SP1 on
Windows 2003, I am not sure the configuration you desire (w32time as
the master) can be made to work at all.

Could you explain why the built-in w32time on the Win2003 server must
be the "master" clock? If you're going to forgo synchronizing to UTC,
you must pick one machine's internal clock to be the master for the
network. In your situation, making one of the UNIX-like systems running
the "real" NTP your master is the best solution. You then configure the
Win2003 box to get time from that as a client. Or as others have
stated, install the Windows version of the "real" NTP at make it the
master (at stratum 10 or higher).

If you insist on trying to use w32time as the master, you can look at
the link below for some possible Windows-side tweaks that you might be
able to use:
http://technet2.microsoft.com/Window....mspx?mfr=true
If the Windows server is not a Windows domain controller, it is
probably not serving valid time at all. You need to set the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\W32Time\TimeProviders\NtpServer\Enabled
to 1. You could also try using the "Always a reliable time server"
registry or group policy settings that might make the w32time system
trick the UNIX-like systems into synchronizing with it.

George,

Have you noticed your Windows server is visible to your Linux client,
but the offset shows -180 ms, which is larger than the step interval?
Ordinarily, NTP steps the time after 900 s, but you show over this and
the step has not occured. You need to look at the association billboard
(rv ) and see the flashcodes (flash=xxx). I suspect the
Windows server packet has the usual casual disregard for the spec and
says something illegal.

Send the billboard in a message. There might be a simple workaround.

I echo other commentators that, even if a workaround can be found, you
will get terrible time and in particular are potential victim of
unstable operation. The NTP clock discipline algorithm expects a stable
clock source, either SNTP and a radio, or full NTP with clock discipline
algorithm. It's much safer to use SNTP, rather than NTP, in you clients.

Send the billboard se we can all have a good time bashing Windows.

Dave

george_joby wrote:
> Our requirement is all our linux and nonstop systems synchronise to the
> Windows 2003 server. We do not want Windows to syncronise with an
> external clock and it should just synchronise with its internal clock.
>
> So what I am doing is just configuring with a client (Redhat Linux) and
> server (windows 2003) to check whether Linux gets synchronise with
> Windows server and that is not happening. Our customer need this setup.
>
> If i see the ntpq -pn in Linux it will show the correct offset and also
> ntpdate works fine. But Linux not ready to synchronise with Server.
>
> [root@txnaslload03 ~]# ntpq -pn
> remote refid st t when poll reach delay offset
> jitter
> ================================================== ============================
> 16.74.32.162 .LOCL. 1 u 967 1024 377 0.355 -180.34
> 5.407
>
> Thanks
> George
>
> Ry wrote:
>
>>Richard B. Gilbert wrote:
>>
>>
>>>Isn't port 123 UDP inbound required as well?
>>
>>Not on a stateful firewall, which are the most common type these days.
>>In most firewall configuration tools, "allow UDP port 123 outbound"
>>means that when a outbound packet is sent, the firewall will remember
>>seeing it (that's the *stateful* part) allow a return UDP packet(s)
>>from the destination IP and source port for a few seconds before
>>closing things off again.
>>
>>This assumes all he is doing is configuring his NTP to act as a client
>>to an internet-based NTP server. If he is going to be using
>>symmetric/active or another mode, that's going to require allowing UDP
>>port 123 inbound. But it doesn't seem to me that he would need to do
>>anything like that.
>
>

Hi

Please see the requested information:

[root@txnaslload03 etc]# ntpq -pn
remote refid st t when poll reach delay offset
jitter
================================================== ============================
16.74.32.162 .LOCL. 1 u 98 256 377 0.403 -11.752
5.775
*127.127.1.0 LOCAL(0) 10 l 38 64 377 0.000 0.000
0.001
[root@txnaslload03 etc]# ntpq
ntpq> as

ind assID status conf reach auth condition last_event cnt
================================================== =========
1 40372 9014 yes yes none reject reachable 1
2 40373 9614 yes yes none sys.peer reachable 1

ntpq> rv 40372
assID=40372 status=9014 reach, conf, 1 event, event_reach,
srcadr=16.74.32.162, srcport=123, dstadr=16.74.35.185, dstport=123,
leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=10028.351, refid=LOCL, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=8, ppoll=8, flash=00 ok, keyid=0, ttl=0, offset=-11.752,
delay=0.403, dispersion=23.991, jitter=5.775,
reftime=c95f68b3.04189374 Mon, Jan 22 2007 10:45:39.016,
org=c95f6cfe.e0000000 Mon, Jan 22 2007 11:03:58.875,
rec=c95f6cfe.e50bc7b4 Mon, Jan 22 2007 11:03:58.894,
xmt=c95f6cfe.e4e4ead0 Mon, Jan 22 2007 11:03:58.894,
filtdelay= 0.59 0.58 0.59 0.42 0.42 0.45 0.42
0.40,
filtoffset= -19.41 -18.48 -18.53 -15.54 -7.28 -14.65 -5.35
-11.75,
filtdisp= 15.63 17.55 19.45 21.39 22.35 23.31 24.28
25.27

Please see the rootdispersion value itz too high. Is it the reason the
client not synchronising with the server?
Also see client "reject" the server .. in ntpq as command ...

I will give some more detail about our requirement. The environment
will be like this. We have 2-3 Linux box then many Non Stop systems and
a primary Windows 2003 server console and a backup console .. The Linux
box will be heavy loaded as all the request will be first coming into
that then to nonstop systems. So customer dont want to put the nonstop
or linux box as the server .. and the option is Windows 2003 server ...
Also we dont want to use any external time .. all these boxes should
sync up and have same time .. But i could see from all the mails and
from google that I cant use Windows SNTP as a server ... We are just
trying to figure out why it is not synching with Linux .. i mean the
real reason and also trying to contact Microsoft to get a confirmation
that it will not work. So our customer can think about some third party
NTP software.

Can some body help me from the above info why client reject the server
.... is it coz of the high value in root dispertion or due to some other
issue ??

Thanks in advance ...

David L. Mills wrote:
> George,
>
> Have you noticed your Windows server is visible to your Linux client,
> but the offset shows -180 ms, which is larger than the step interval?
> Ordinarily, NTP steps the time after 900 s, but you show over this and
> the step has not occured. You need to look at the association billboard
> (rv ) and see the flashcodes (flash=xxx). I suspect the
> Windows server packet has the usual casual disregard for the spec and
> says something illegal.
>
> Send the billboard in a message. There might be a simple workaround.
>
> I echo other commentators that, even if a workaround can be found, you
> will get terrible time and in particular are potential victim of
> unstable operation. The NTP clock discipline algorithm expects a stable
> clock source, either SNTP and a radio, or full NTP with clock discipline
> algorithm. It's much safer to use SNTP, rather than NTP, in you clients.
>
> Send the billboard se we can all have a good time bashing Windows.
>
> Dave
>
> george_joby wrote:
> > Our requirement is all our linux and nonstop systems synchronise to the
> > Windows 2003 server. We do not want Windows to syncronise with an
> > external clock and it should just synchronise with its internal clock.
> >
> > So what I am doing is just configuring with a client (Redhat Linux) and
> > server (windows 2003) to check whether Linux gets synchronise with
> > Windows server and that is not happening. Our customer need this setup.
> >
> > If i see the ntpq -pn in Linux it will show the correct offset and also
> > ntpdate works fine. But Linux not ready to synchronise with Server.
> >
> > [root@txnaslload03 ~]# ntpq -pn
> > remote refid st t when poll reach delay offset
> > jitter
> > ================================================== ============================
> > 16.74.32.162 .LOCL. 1 u 967 1024 377 0.355 -180.34
> > 5.407
> >
> > Thanks
> > George
> >
> > Ry wrote:
> >
> >>Richard B. Gilbert wrote:
> >>
> >>
> >>>Isn't port 123 UDP inbound required as well?
> >>
> >>Not on a stateful firewall, which are the most common type these days.
> >>In most firewall configuration tools, "allow UDP port 123 outbound"
> >>means that when a outbound packet is sent, the firewall will remember
> >>seeing it (that's the *stateful* part) allow a return UDP packet(s)
> >>from the destination IP and source port for a few seconds before
> >>closing things off again.
> >>
> >>This assumes all he is doing is configuring his NTP to act as a client
> >>to an internet-based NTP server. If he is going to be using
> >>symmetric/active or another mode, that's going to require allowing UDP
> >>port 123 inbound. But it doesn't seem to me that he would need to do
> >>anything like that.
> >
> >

George,

As I said in my message to you, Windows shows dispersion 10s, which is
ten times the ntpd default of 1 s. You will need to either modify
Windows code, ntpd code or tinker the maxdist to something above 10 s.

Windows shows a precision of 6, which will cause the ntpd server to
bounce around. If you exect to use multiple servers in the interest of
robustness, you will have to tinker the mindist to something well above
16 ms. You would be much better advised to use SNTP from a shell script.

Dave

george_joby wrote:

> Hi
>
> I am trying to configure NTP server in Windows 2003 server and client
> as Redhat Linux AS 4. But if I use W32time of Windows my client will
> never synchronise with the server. But if I use the third part software
> in Windows server 2003 (http://www.meinberg.de/english/sw/ntp.htm) my
> Linux client will synchronise with the server. I heard that W32time is
> based on SNTP but read that SNTP and NTP can be used interchangebly.
> (http://www.microsoft.com/technet/sol...w/21wsdsu.mspx)
>
>
> But I am not able to syncronize with the server at all.
>
> My configuration is just between two system in a local lan using cross
> cable. Server is configured to use internal clock.
>
> My client want to try with w32time. Also I saw this ...
>
> http://ntp.isc.org/bin/view/Support/...P#Section_9.10.
>
> Can any body help me in this. Will w32time work with linux ?
>