SNMP support - NTP

This is a discussion on SNMP support - NTP ; Heiko, A couple of comments about this mission. First, last I looked SNMP had a really hard time with floating point and the scaling issues are dangerous. Second, as mentioned several times on the NTP hackers wire, we would very ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 30 of 30

Thread: SNMP support

  1. Re: SNMP support

    Heiko,

    A couple of comments about this mission. First, last I looked SNMP had a
    really hard time with floating point and the scaling issues are
    dangerous. Second, as mentioned several times on the NTP hackers wire,
    we would very much like to shoot ntpdc and its fascist (mode 7)
    protocol. As of now, many configuration issues can be performed using
    the mode-6 (ntpq) protocol. While many ntpdc related issues can be
    easily moved to the mode-6 protocol, which is based on UDP, the monlist
    function of ntpdc really needs TCP, as experience with monlist and UDP
    demonstrates. This paritcular combination of UDP and TCP would not be
    friendly to SNMP.

    I continue to speculate that an SNMP agent in an expert system would be
    an ideal shotgun marriage between mode-6 and SNMP.

    Dave

    Heiko Gerstung wrote:

    > David J Taylor schrieb:
    >
    >> Heiko Gerstung wrote:
    >>
    >>> David J Taylor schrieb:
    >>>
    >>>> Does NTP include SNMP support (on Windows), and if not, are there any
    >>>> plans to add support?
    >>>>
    >>>> Thanks,
    >>>> David
    >>>
    >>> When the MIB for NTP has been standardized, I will try to write a
    >>> module for net-snmp which supports that standard NTPv4 MIB. Our
    >>> current NTP server appliances (like others on the market) already
    >>> offer NTP related data objects in their enterprise MIB.
    >>>
    >>> The current draft can be found here:
    >>> http://www.ietf.org/internet-drafts/...pv4-mib-03.txt
    >>>
    >>> Best Regards,
    >>> Heiko

    >>
    >>
    >> Heiko,
    >>
    >> I'm delighted to see this so well advanced, and even more delighted
    >> that we may even see an implementation! I would be after a Windows
    >> SNMP implementation which worked with MRTG and perhaps other reporting
    >> tools.
    >>
    >> A quick read suggests that you could get with SNMP everything which
    >> you can currently get from NTPQ, with the addition of optional
    >> notifications when things change. There is no other writeable input.
    >>
    >> Would that be a fair summary?

    >
    >
    > Well, I would not go as far as promising that you will get every that
    > NTPQ offers, but this was not the intention. We wanted to include as
    > many data objects as required to be able to automatically monitor your
    > NTP server instance(s) with your standard network management system a la
    > HP Openview or IBM Tivoli or whatever.
    >
    > Besides the effort to produce an NTP module for NET-SNMP (which is AFAIK
    > also available for Windows) it will be required to modify ntpd as well
    > to provide an interface that can be used by the net-snmp module (or any
    > other implementation).
    >
    > Using mode 6 / mode 7 packets will be working for most objects in the
    > MIB, other parts require additional data collecting on ntpd's side (e.g.
    > for the requests stats).
    >
    > It might be time to implement a new management interface for ntpd which
    > probably could use TCP/123 instead of UDP, but I am not sure if
    > everybody involved would be willing to go down that road. However, I see
    > a demand for simplifying the health and statistics monitoring side of NTP.
    >
    > People often tend to say that NTPQ already offers all they need, but the
    > core idea behind SNMP (IMHO) is that you need only one piece of software
    > to monitor your routers, servers, printers, coffee machines and, yes,
    > time servers.
    >
    > Since SNMP is to network monitoring what NTP is to network time
    > synchronization (the de facto standard protocol), it is time to enable
    > NTP to provide an SNMP interface. One day it might be even a way to
    > replace ntpdc when it comes to runtime reconfiguration issues. This
    > would overcome the current problems we see with ntpdc, mainly the tight
    > relationship between ntpdc's and ntpd's version.
    >
    > But this would require to add more "writable" data objects and since
    > this has a major implication on security, we will spare that until the
    > definition of NTPv5's MIB :-)
    >
    > Cheers,
    > Heiko


  2. Re: SNMP support

    David L. Mills wrote:
    > David,
    >
    > There are no plans that I know of for the reference implementation
    > itself to support SNMP directly. There is an alternative that in fact
    > was implemented for evaluation some years ago. It used an SNMP agent
    > program to send mode-6 (ntpq) commands to an NTP server and translate
    > what came back, then respond in the style of the MIB. That actually
    > worked quite well, considering the limitations of SNMP. While that
    > program is lost in the dust of time, it would not be too hard to
    > re-create it.


    Having an extra agent would seem to be a perfectly acceptable approach.
    It could have an OS-neutral part which did the queries and an OS-dependant
    part which handled the SNMP I/O. On Windows, that might all fit into a
    single DLL add-on.

    > The hard part in the agent implementation was how to translate the
    > episodic data from an NTP association into something a NOC engineer
    > coul see on a meter or tally light. The attraction of the agent
    > aproach was that the translation can be done by the agent without
    > tinkering the NTP server in possibly ugly ways.
    >
    > An approach that saw action some years ago was to embed the translator
    > in an expert system programmed in smalltalk, for example. The project
    > was funded by DARPA not specifically for NTP monitoring, but for
    > Internet NOCs in general. I just love that approach.
    >
    > Dave


    If that can be compiled into a single module, that's great. I would
    prefer that some third-party software (e.g. smalltalk) did not have to be
    installed just to get SNMP support!

    Cheers,
    David



  3. Re: SNMP support

    David L. Mills schrieb:
    > Heiko,
    >
    > We should reveal that at least some GPS/NTP appliances already do
    > implement some form of MIB.


    I mentioned that in another post. Since there is no standard NTP MIB,
    all those MIBs (including those in our own NTP time server products) are
    enterprise MIBs and not standardized nor compatible with each other.
    That results in more work and problems when you want to use more than
    one brand in your NTP time server zoo.

    Heiko



  4. Re: SNMP support

    Dave,

    thank you for your comments. Floating points is really a problem with
    SNMP and resulted in having quite a number of strings in the MIB where
    FP's would make much more sense. It will be up to the end user /
    monitoring application to parse those strings, but our experience shows
    that most people are OK with monitoring status variables (which can be
    integer or string).

    The ntpdc monlist stuff is really something we should start to work on.
    It is very important for a lot of customers/NTP users to get reliable
    and accurate usage statistics and the monlist provides that information,
    but only on not-so-occupied systems (exactly the type of machines which
    typically does not need these stats). The one and only reason for this
    seems to be the UDP way of talking to ntpdc, it would not be very hard
    to expand the maximum number of client records beyond the magic 600, but
    the mode 7 UDP transmission of the monlist table is often not even
    capable of reliably providing these 600 entries, at least not under
    heavy network conditions.

    Heiko


    David L. Mills schrieb:
    > Heiko,
    >
    > A couple of comments about this mission. First, last I looked SNMP had a
    > really hard time with floating point and the scaling issues are
    > dangerous. Second, as mentioned several times on the NTP hackers wire,
    > we would very much like to shoot ntpdc and its fascist (mode 7)
    > protocol. As of now, many configuration issues can be performed using
    > the mode-6 (ntpq) protocol. While many ntpdc related issues can be
    > easily moved to the mode-6 protocol, which is based on UDP, the monlist
    > function of ntpdc really needs TCP, as experience with monlist and UDP
    > demonstrates. This paritcular combination of UDP and TCP would not be
    > friendly to SNMP.
    >
    > I continue to speculate that an SNMP agent in an expert system would be
    > an ideal shotgun marriage between mode-6 and SNMP.
    >
    > Dave
    >
    > Heiko Gerstung wrote:
    >
    >> David J Taylor schrieb:
    >>
    >>> Heiko Gerstung wrote:
    >>>
    >>>> David J Taylor schrieb:
    >>>>
    >>>>> Does NTP include SNMP support (on Windows), and if not, are there any
    >>>>> plans to add support?
    >>>>>
    >>>>> Thanks,
    >>>>> David
    >>>>
    >>>> When the MIB for NTP has been standardized, I will try to write a
    >>>> module for net-snmp which supports that standard NTPv4 MIB. Our
    >>>> current NTP server appliances (like others on the market) already
    >>>> offer NTP related data objects in their enterprise MIB.
    >>>>
    >>>> The current draft can be found here:
    >>>> http://www.ietf.org/internet-drafts/...pv4-mib-03.txt
    >>>>
    >>>> Best Regards,
    >>>> Heiko
    >>>
    >>>
    >>> Heiko,
    >>>
    >>> I'm delighted to see this so well advanced, and even more delighted
    >>> that we may even see an implementation! I would be after a Windows
    >>> SNMP implementation which worked with MRTG and perhaps other
    >>> reporting tools.
    >>>
    >>> A quick read suggests that you could get with SNMP everything which
    >>> you can currently get from NTPQ, with the addition of optional
    >>> notifications when things change. There is no other writeable input.
    >>>
    >>> Would that be a fair summary?

    >>
    >>
    >> Well, I would not go as far as promising that you will get every that
    >> NTPQ offers, but this was not the intention. We wanted to include as
    >> many data objects as required to be able to automatically monitor your
    >> NTP server instance(s) with your standard network management system a
    >> la HP Openview or IBM Tivoli or whatever.
    >>
    >> Besides the effort to produce an NTP module for NET-SNMP (which is
    >> AFAIK also available for Windows) it will be required to modify ntpd
    >> as well to provide an interface that can be used by the net-snmp
    >> module (or any other implementation).
    >>
    >> Using mode 6 / mode 7 packets will be working for most objects in the
    >> MIB, other parts require additional data collecting on ntpd's side
    >> (e.g. for the requests stats).
    >>
    >> It might be time to implement a new management interface for ntpd
    >> which probably could use TCP/123 instead of UDP, but I am not sure if
    >> everybody involved would be willing to go down that road. However, I
    >> see a demand for simplifying the health and statistics monitoring side
    >> of NTP.
    >>
    >> People often tend to say that NTPQ already offers all they need, but
    >> the core idea behind SNMP (IMHO) is that you need only one piece of
    >> software to monitor your routers, servers, printers, coffee machines
    >> and, yes, time servers.
    >>
    >> Since SNMP is to network monitoring what NTP is to network time
    >> synchronization (the de facto standard protocol), it is time to enable
    >> NTP to provide an SNMP interface. One day it might be even a way to
    >> replace ntpdc when it comes to runtime reconfiguration issues. This
    >> would overcome the current problems we see with ntpdc, mainly the
    >> tight relationship between ntpdc's and ntpd's version.
    >>
    >> But this would require to add more "writable" data objects and since
    >> this has a major implication on security, we will spare that until the
    >> definition of NTPv5's MIB :-)
    >>
    >> Cheers,
    >> Heiko


  5. Re: SNMP support

    (I took the liberty of removing the lower half of this mail. See
    previous mails in this thread for complete history)
    David L. Mills wrote:
    > Heiko,
    >
    > A couple of comments about this mission. First, last I looked SNMP had

    a
    > really hard time with floating point and the scaling issues are
    > dangerous. Second, as mentioned several times on the NTP hackers wire,


    > we would very much like to shoot ntpdc and its fascist (mode 7)
    > protocol. As of now, many configuration issues can be performed using
    > the mode-6 (ntpq) protocol. While many ntpdc related issues can be
    > easily moved to the mode-6 protocol, which is based on UDP, the monlist


    > function of ntpdc really needs TCP, as experience with monlist and UDP


    > demonstrates. This paritcular combination of UDP and TCP would not be
    > friendly to SNMP.
    >
    > I continue to speculate that an SNMP agent in an expert system would be


    > an ideal shotgun marriage between mode-6 and SNMP.
    >
    > Dave
    >


    Disclaimer: I know parts of this has already been answered in the
    thread, and I know that a lot of the basis for my comments are made
    solely based on my memory of things, and memory (when you start to get
    my age) isn't a perfect match of things that were, but rather some
    guidlines to how things might have been. Thus I may be totally wrong, or
    answering the wrong question. (Now, I can get to the point. )

    One of the tricks I used in the old days for handling decimal numbers
    (which is why we need the floating point, isn't it?) was to use two
    variables, or to use a different (moving the decimal point) internal
    value, and dividing by 10^x for display.

    I'm guessing that what we need the floating point for, is the precision
    on our peers, and the precision of our drift. These values are (iirc)
    today a float number of milliseconds. And for all simplicity, they
    should remain that way for human presentation, to avoid unnecessary
    confusion.

    But, given that todays clocks are quite a bit more accurate than they
    were when ntp was conceived, a different unit than milliseconds might be
    a better solution than using a float, since floating numbers on our
    binary computers are inaccurate by design. Couldn't we solve this
    floating point problem by making a change in the internals of the code,
    to use nanoseconds (thus moving the decimal point quite far, and
    delaying our floating point problem to our grandchildren to solve)? SNMP
    has no problems in sending LARGE numbers, but it does have in sending
    the small fractions (floating point). If we do this by using two
    variables, such as Full_Seconds and Nano_Second_Offset, there should be
    sufficient precision to outlive our current perspective?

    I know that such a change will in parts increase the complexity of the
    current codebase, and I know that there are plenty on this list that can
    refine this idea (or give a very good explanation why this is stupid
    ), but can we atleast consider it?

    Regards,

    Svein Skogen.


    p.s. My current internet service provider does not have any nntp
    service, so replies to me should go through the questions-list or to my
    direct mailbox.


    --
    Svein Skogen | svein@d80.iso100.no
    Solberg ěstli 9 | PGP Key: 0xE5E76831
    2020 Skedsmokorset | svein@jernhuset.no
    Norway | PGP Key: 0xCE96CE13
    ------------------------+-----------------------------
    msn messenger: | Mobile Phone: +47 907 03 575
    svein@jernhuset.no | RIPE handle: SS16503-RIPE

  6. Re: SNMP support

    Svein,

    The operators of the questions list are well aware that I do not
    subscribe to the list and prefer to answer questions in the newsgroup,
    rather than any more limiting siscussion group. I would be happy to
    respond to your message in the newsgroup context. Meanwhile, please note
    that all internal calculations in ntpd are in floating double seconds
    and fraction in time offset and floating double seconds/seconds and
    fraction frequency offset. The single exception is first-order time
    differences, which are done in 64-bit integer. Justification for this is
    in the NTPv4 specification document.

    Dave

    Svein Skogen wrote:

    > (I took the liberty of removing the lower half of this mail. See
    > previous mails in this thread for complete history)
    > David L. Mills wrote:
    >
    >> Heiko,
    >>
    >> A couple of comments about this mission. First, last I looked SNMP had a
    >> really hard time with floating point and the scaling issues are
    >> dangerous. Second, as mentioned several times on the NTP hackers wire,
    >> we would very much like to shoot ntpdc and its fascist (mode 7)
    >> protocol. As of now, many configuration issues can be performed using
    >> the mode-6 (ntpq) protocol. While many ntpdc related issues can be
    >> easily moved to the mode-6 protocol, which is based on UDP, the monlist
    >> function of ntpdc really needs TCP, as experience with monlist and UDP
    >> demonstrates. This paritcular combination of UDP and TCP would not be
    >> friendly to SNMP.
    >>
    >> I continue to speculate that an SNMP agent in an expert system would be
    >> an ideal shotgun marriage between mode-6 and SNMP.
    >>
    >> Dave
    >>

    >
    > Disclaimer: I know parts of this has already been answered in the
    > thread, and I know that a lot of the basis for my comments are made
    > solely based on my memory of things, and memory (when you start to get
    > my age) isn't a perfect match of things that were, but rather some
    > guidlines to how things might have been. Thus I may be totally wrong, or
    > answering the wrong question. (Now, I can get to the point. )
    >
    > One of the tricks I used in the old days for handling decimal numbers
    > (which is why we need the floating point, isn't it?) was to use two
    > variables, or to use a different (moving the decimal point) internal
    > value, and dividing by 10^x for display.
    >
    > I'm guessing that what we need the floating point for, is the precision
    > on our peers, and the precision of our drift. These values are (iirc)
    > today a float number of milliseconds. And for all simplicity, they
    > should remain that way for human presentation, to avoid unnecessary
    > confusion.
    >
    > But, given that todays clocks are quite a bit more accurate than they
    > were when ntp was conceived, a different unit than milliseconds might be
    > a better solution than using a float, since floating numbers on our
    > binary computers are inaccurate by design. Couldn't we solve this
    > floating point problem by making a change in the internals of the code,
    > to use nanoseconds (thus moving the decimal point quite far, and
    > delaying our floating point problem to our grandchildren to solve)? SNMP
    > has no problems in sending LARGE numbers, but it does have in sending
    > the small fractions (floating point). If we do this by using two
    > variables, such as Full_Seconds and Nano_Second_Offset, there should be
    > sufficient precision to outlive our current perspective?
    >
    > I know that such a change will in parts increase the complexity of the
    > current codebase, and I know that there are plenty on this list that can
    > refine this idea (or give a very good explanation why this is stupid
    > ), but can we atleast consider it?
    >
    > Regards,
    >
    > Svein Skogen.
    >
    >
    > p.s. My current internet service provider does not have any nntp
    > service, so replies to me should go through the questions-list or to my
    > direct mailbox.
    >
    >


  7. Re: SNMP support

    In article <47628B0E.4080308@d80.iso100.no>,
    svein@d80.iso100.no (Svein Skogen) wrote:

    > (I took the liberty of removing the lower half of this mail. See
    > previous mails in this thread for complete history)
    > David L. Mills wrote:
    > > Heiko,
    > >
    > > A couple of comments about this mission. First, last I looked SNMP had

    > a
    > > really hard time with floating point and the scaling issues are
    > > dangerous. Second, as mentioned several times on the NTP hackers wire,

    >
    > > we would very much like to shoot ntpdc and its fascist (mode 7)
    > > protocol. As of now, many configuration issues can be performed using
    > > the mode-6 (ntpq) protocol. While many ntpdc related issues can be
    > > easily moved to the mode-6 protocol, which is based on UDP, the monlist

    >
    > > function of ntpdc really needs TCP, as experience with monlist and UDP

    >
    > > demonstrates. This paritcular combination of UDP and TCP would not be
    > > friendly to SNMP.
    > >
    > > I continue to speculate that an SNMP agent in an expert system would be

    >
    > > an ideal shotgun marriage between mode-6 and SNMP.
    > >
    > > Dave
    > >

    >
    > Disclaimer: I know parts of this has already been answered in the
    > thread, and I know that a lot of the basis for my comments are made
    > solely based on my memory of things, and memory (when you start to get
    > my age) isn't a perfect match of things that were, but rather some
    > guidlines to how things might have been. Thus I may be totally wrong, or
    > answering the wrong question. (Now, I can get to the point. )
    >
    > One of the tricks I used in the old days for handling decimal numbers
    > (which is why we need the floating point, isn't it?) was to use two
    > variables, or to use a different (moving the decimal point) internal
    > value, and dividing by 10^x for display.
    >
    > I'm guessing that what we need the floating point for, is the precision
    > on our peers, and the precision of our drift. These values are (iirc)
    > today a float number of milliseconds. And for all simplicity, they
    > should remain that way for human presentation, to avoid unnecessary
    > confusion.


    An alternative that comes to mind is to use the scaled binary
    representation of the base two logarithm of the millisecond value in
    question. Zero would need to be handled as a special case. If the
    value is signed, then a sign field will also be needed.

    For example, one could express 274591 milliseconds as 1000*Log2(274591)=
    18066.9248, or rounded to the integer 18067.

    Joe Gwinn

  8. Re: SNMP support

    On 2007-12-14, David L. Mills wrote:

    > The operators of the questions list are well aware that I do not
    > subscribe to the list and prefer to answer questions in the newsgroup,
    > rather than any more limiting siscussion group.


    There is no balkanization; the questions list and the
    comp.protocols.time.ntp news-group carry the same traffic.

    > I would be happy to respond to your message in the newsgroup context.


    And the OP will automagically receive his response via the questions
    list.

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

  9. Re: SNMP support

    "Joseph Gwinn" wrote in message
    news:joegwinn-412B6F.13271514122007@comcast.dca.giganews.com...
    > In article <47628B0E.4080308@d80.iso100.no>,
    > svein@d80.iso100.no (Svein Skogen) wrote:

    [...]
    >> One of the tricks I used in the old days for handling decimal numbers
    >> (which is why we need the floating point, isn't it?) was to use two
    >> variables, or to use a different (moving the decimal point) internal
    >> value, and dividing by 10^x for display.

    [...]
    > An alternative that comes to mind is to use the scaled binary
    > representation of the base two logarithm of the millisecond value in
    > question. Zero would need to be handled as a special case. If the
    > value is signed, then a sign field will also be needed.


    Don't lose sight of the fact that floating point _is_ a fixed-point
    number scaled by another fixed-point number. It should not come as a
    surprise that floating point can be emulated by two integers; in fact,
    the only surprising thing is that some people don't find this
    immediately obvious.

    One could even pack the two numbers as bit fields into a single
    integer. What an innovation! (For further details, see IEEE 754.)
    I would expect some of the more adventurous SNMP MIBs to already
    do this. In the end, it's all just bits.

    Groetjes,
    Maarten Wiltink



  10. Re: SNMP support

    >>> In article <7e4a35-f5c.ln1@gateway.py.meinberg.de>, Heiko Gerstung writes:

    Heiko> The ntpdc monlist stuff is really something we should start to work
    Heiko> on. It is very important for a lot of customers/NTP users to get
    Heiko> reliable and accurate usage statistics and the monlist provides that
    Heiko> information, but only on not-so-occupied systems (exactly the type of
    Heiko> machines which typically does not need these stats). The one and only
    Heiko> reason for this seems to be the UDP way of talking to ntpdc, it would
    Heiko> not be very hard to expand the maximum number of client records
    Heiko> beyond the magic 600, but the mode 7 UDP transmission of the monlist
    Heiko> table is often not even capable of reliably providing these 600
    Heiko> entries, at least not under heavy network conditions.

    Heiko,

    Please create a topic at http://support.ntp.org/Dev/DevelopmentIssues and we
    can get the specifications for this agreed upon and then implemented (as
    soon as we get either a volunteer to write it or the NTP Forum gets
    sufficient membership revenue to pay for writing this).
    --
    Harlan Stenn
    http://ntpforum.isc.org - be a member!

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2