How to change STRATUM on linux. - NTP

This is a discussion on How to change STRATUM on linux. - NTP ; Hello, i have debian with ntp installed. ntp works fine, it synchronizes with another pc (with net time and crontab), that other pc syncs with internet time server. i tested it with a ntp client on windows and a ups ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: How to change STRATUM on linux.

  1. How to change STRATUM on linux.

    Hello,



    i have debian with ntp installed.

    ntp works fine, it synchronizes with another pc (with net time and
    crontab), that other pc syncs with internet time server.

    i tested it with a ntp client on windows and a ups that can sync its
    time with the linux ntp server, works fine...

    i also want to sync all my cisco switches with that ntp server but
    that's not working and probably because the cisco switch thinks that the
    ntp server has stratum 16 (that's what it says in show ntp associations)
    so it thinks it is not reliable.

    Is there a way so that i can my the cisco thinks that the linux server
    has stratum 1 so that it will take that host as reliable and configure
    its time with it ?

    in other words, how can i change on linux the stratum value ?



    thanks.

    Phil

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: How to change STRATUM on linux.

    On 2006-10-18, Philippe Dhont Sea-ro wrote:

    > i also want to sync all my cisco switches with that ntp server but
    > that's not working and probably because the cisco switch thinks that the
    > ntp server has stratum 16 (that's what it says in show ntp associations)
    > so it thinks it is not reliable.


    If your "ntp server" is reporting that it is at Stratum-16 then it is
    most likely not synchronized to a time source. You need to fix this
    first.

    Please post the output from 'ntpq -p your.ntp.server' and the active
    lines from your ntp.conf.

    > Is there a way so that i can my the cisco thinks that the linux server
    > has stratum 1 so that it will take that host as reliable and configure
    > its time with it ?


    First you have to make sure that your "ntp server" is really working.

    > in other words, how can i change on linux the stratum value ?


    You can't do it directly (except in certain circumstances.

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

  3. RE: How to change STRATUM on linux.

    [ BROKEN THREAD - Missing References Line - manually repaired ]

    In article ,
    philippe.dhont@searo.be (Philippe Dhont Sea-ro) wrote:

    > Yes you can, and i finally found how.


    I think we all know about the local clock driver as it is so commonly
    included in configurations without justification and is dangerous in
    that context.

    > On the server, this is my ntp.org configuration:


    > server 127.127.1.0
    > fudge 127.127.1.0 stratum 5


    Redundancy already noted. Even when this is used in disaster scenarios
    with an otherwise valid time synchronisation architecture, the advice is
    to set this to at least 10, so that bogus times cannot propagate too
    far.

    > I also have a second one with higher stratum.


    ??????????????????

    > My local clock is sync'ed with a windows2003 server like this:


    > Net time -S x.x.x.x set , and put in crontab.


    This is an invalid time synchronisation architecture for NTP, as the
    upstream link is neither NTP nor a local hardware reference clock. It's
    actually also invalid for SNTP and would still be if SNTP were used
    rather than what I suspect here is SMB. (Typical Microsoft W32Time
    architectures are invalid because they use SNTP as a source for SNTP,
    but that is not as bad as your current one.)

    The latest service pack of Windows 2003 includes a version of W32Time
    that may actually be NTP architecture compliant; it is certainly much
    more compliant than this architecture. Although non-compliant, using
    older versions of W32Time, as though they were real NTP servers, would
    still be better.

    > My 2003 server is sync'ed with the daytime protocol to a internet time
    > server.


    This is perverse. Even the old version of W32Time would be better, as
    it at least isn't limited to a one second resolution. The latest
    service pack version of Windows 2003 ought to do really rather well,
    although the reference implementation of ntpd, which is free, is still
    better, and what we would advise. (I believe the latest W32Time is still
    limited to the system tick rate as resolution, whereas the reference
    implementation interpolates.)

    > I need a good stratum value because my cisco devices (switches etc) will
    > not sync if the stratum is 16.


    Obviously they won't synch if the source is unsynchronised. The source
    would also have been sending an alarm state in the leap bits.

    So this is my cisco configuration:

    > Best to put 2 time servers in cisco devices.


    Two is a bad number, as, if they disagree, you can't resolve the
    dispute. Having two local clocks in a system, unless one is slave
    to the other, is a very bad idea.

    > address ref clock st when poll reach delay offset disp
    > *~x.x.x.x 127.127.1.0 6 373 1024 377 3.1 0.28 0.3
    > ~x.x.x.x 127.127.1.0 8 1012 1024 377 2.4 -760.9 103.9


    If it weren't being rejected on stratum, the lack of overlap in the
    error bands between the second and first source would, I believe,
    cause both sources to be rejected as false tickers. It's faintly
    possible to have this amount of offset difference between two remote
    servers, but these servers will be indicating very tight error bounds.
    Unfortunately, when you use the local clock driver to propagate time
    that has been synchronised by non-NTP means, it fails to send the correct
    error information, although, in this case, if it had done, the Cisco should
    have rejected it for having too high a root dispersion.

    > So, it can be done.


    We know it can be done, but we strongly advise not to do it in this way,
    especially as it would seem that the choice of platforms etc. would
    actually permit a fully compliant solution.

  4. Re: How to change STRATUM on linux.

    On 2006-10-20, David Woolley wrote:

    > [ BROKEN THREAD - Missing References Line - manually repaired ]
    >
    > In article ,
    > philippe.dhont@searo.be (Philippe Dhont Sea-ro) wrote:


    I just checked the archive. The message/article that you are replying to
    contained neither a References: header nor an In-Reply-To: header. So
    there was no way to maintain threading.

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

  5. Re: How to change STRATUM on linux.

    David Woolley wrote:
    > Two is a bad number, as, if they disagree, you can't resolve the
    > dispute. Having two local clocks in a system, unless one is slave
    > to the other, is a very bad idea.
    >
    >> address ref clock st when poll reach delay offset disp
    >> *~x.x.x.x 127.127.1.0 6 373 1024 377 3.1 0.28 0.3
    >> ~x.x.x.x 127.127.1.0 8 1012 1024 377 2.4 -760.9 103.9

    >
    > If it weren't being rejected on stratum, the lack of overlap in the
    > error bands between the second and first source would, I believe,
    > cause both sources to be rejected as false tickers. It's faintly
    > possible to have this amount of offset difference between two remote
    > servers, but these servers will be indicating very tight error bounds.
    > Unfortunately, when you use the local clock driver to propagate time
    > that has been synchronised by non-NTP means, it fails to send the correct
    > error information, although, in this case, if it had done, the Cisco should
    > have rejected it for having too high a root dispersion.
    >


    This is even worse than having no time at all. The upstream servers are
    only synchronized to themselves, ie not at all, which is what those
    refids are telling you. They have no reference which will allow them to
    stay in synch, even loosely. You are better of synchronizing to just one
    of these, but even better to some real server that are providing proper
    time.

    Danny

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  6. Re: How to change STRATUM on linux.

    In article ,
    Steve Kostecke wrote:

    > I just checked the archive. The message/article that you are replying to
    > contained neither a References: header nor an In-Reply-To: header. So
    > there was no way to maintain threading.


    I wasn't necessarily blaming the gateway; in fact I was fairly sure that
    it was the poster's fault. It was, of course, possible to repair the
    threading by looking at the subject and content and working out the only
    possible article it could be responding to. That may be too late for
    some threading databases, as they may already have convinced themselves
    that they were dealing with a new root article.


  7. Re: How to change STRATUM on linux.

    In article <453983A3.2090108@ntp.isc.org>,
    mayer@ntp.isc.org (Danny Mayer) wrote:

    > This is even worse than having no time at all. The upstream servers are
    > only synchronized to themselves, ie not at all, which is what those


    No they are not. The problem is that they are synchronised using protocols
    which only have a precision of 1 second and which have no root delay
    compensation, have long poll delays and have no frequency compensation,
    so have high dispersions. I'm not sure if SMB has 1 second precision, in
    which case, with daytime, they would have two precision 1 second hops in
    tandem.

    > refids are telling you. They have no reference which will allow them to


    The refids only tell you the boundary of the NTP part of the synchronisation
    network.

    > stay in synch, even loosely. You are better of synchronizing to just one
    > of these, but even better to some real server that are providing proper
    > time.


    He is synchronizing to a real server, but using one daytime hop and one
    SMB hop. I did note that it is an NTP architecture violation to have
    non-NTP hops in the path to the real reference clocks. localclock is
    being used here in the synchronised by other means context, not in the
    completely undisciplined context.

+ Reply to Thread