multicast - wrong interface - NTP

This is a discussion on multicast - wrong interface - NTP ; Hello ! My NTP server sends all multicast traffic from eth0 and I don't know how to configure it to send it to the LAN connected via eth2. The details are below. Could you please give me some hints or ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: multicast - wrong interface

  1. multicast - wrong interface

    Hello !

    My NTP server sends all multicast traffic from eth0 and I don't
    know how to configure it to send it to the LAN connected via eth2.
    The details are below. Could you please give me some
    hints or help ?

    Thank you

    Martin

    - - - - - -

    In the ntp.conf there is:
    broadcast 224.0.1.1 key 145 ttl 3

    and the linux kernel has a route for class D addresses, it uses eth2:
    Destination Gateway Genmask Flags Metric Ref Use Iface
    224.0.0.0 * 240.0.0.0 U 0 0 0 eth2

    but the output from ntp -D2 shows, that NTP has chosen eth0 (fd #18) and
    not eth2 (verified with tcpdump):
    created interface #2: fd=18, bfd=-1, name=eth0, flags=0x19, scope=0,
    ifindex=0, sin=217.XX.XXX.XX, bcast=217.XX.XXX.223,, mask=255.255.255.224,
    Enabled:
    ......
    created interface #3: fd=19, bfd=-1, name=eth2, flags=0x19, scope=0,
    ifindex=0, sin=192.168.XX.XX, bcast=192.168.XX.255,, mask=255.255.255.0,
    Enabled:
    ......
    MCAST ***** sendpkt(fd=18 dst=224.0.1.1, src=217.XX.XXX.XX, ttl=96, len=68)

    (BTW, why is ttl=96 and not 3 ? But that's not the problem.)







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


  2. Re: multicast - wrong interface

    Martin,

    I recommend you put all of the information into a report at
    http://bugs.ntp.isc.org .

    H

  3. Re: multicast - wrong interface

    Martin wrote:
    > Hello !
    >
    > My NTP server sends all multicast traffic from eth0 and I don't
    > know how to configure it to send it to the LAN connected via eth2.
    > The details are below. Could you please give me some
    > hints or help ?
    >


    Right now you can't do it. I am aware of this issue. A related issue is
    in Bug #725 though that's for IPv6. Part of the question is whether or
    not there should be additional arguments to specify which interface to
    broadcast on or whether to broadcast on all interfaces which is much
    harder to do as there would need to be a lot of changes.

    > Thank you
    >
    > Martin
    >
    > - - - - - -
    >
    > In the ntp.conf there is:
    > broadcast 224.0.1.1 key 145 ttl 3
    >
    > and the linux kernel has a route for class D addresses, it uses eth2:
    > Destination Gateway Genmask Flags Metric Ref Use Iface
    > 224.0.0.0 * 240.0.0.0 U 0 0 0 eth2
    >
    > but the output from ntp -D2 shows, that NTP has chosen eth0 (fd #18) and
    > not eth2 (verified with tcpdump):
    > created interface #2: fd=18, bfd=-1, name=eth0, flags=0x19, scope=0,
    > ifindex=0, sin=217.XX.XXX.XX, bcast=217.XX.XXX.223,, mask=255.255.255.224,
    > Enabled:
    > ......
    > created interface #3: fd=19, bfd=-1, name=eth2, flags=0x19, scope=0,
    > ifindex=0, sin=192.168.XX.XX, bcast=192.168.XX.255,, mask=255.255.255.0,
    > Enabled:
    > ......
    > MCAST ***** sendpkt(fd=18 dst=224.0.1.1, src=217.XX.XXX.XX, ttl=96, len=68)
    >
    > (BTW, why is ttl=96 and not 3 ? But that's not the problem.)
    >


    That's a separate question and most likely a bug. I don't know why the
    ttl is set to 96, there aren't that many hops in the world...

    Please enter separate bug reports on these.

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


  4. Re: multicast - wrong interface

    Martin wrote:
    > Hello !
    >
    > My NTP server sends all multicast traffic from eth0 and I don't
    > know how to configure it to send it to the LAN connected via eth2.
    > The details are below. Could you please give me some
    > hints or help ?
    >
    > Thank you
    >
    > Martin
    >
    > - - - - - -
    >
    > In the ntp.conf there is:
    > broadcast 224.0.1.1 key 145 ttl 3
    >
    > and the linux kernel has a route for class D addresses, it uses eth2:
    > Destination Gateway Genmask Flags Metric Ref Use Iface
    > 224.0.0.0 * 240.0.0.0 U 0 0 0 eth2
    >
    > but the output from ntp -D2 shows, that NTP has chosen eth0 (fd #18) and
    > not eth2 (verified with tcpdump):
    > created interface #2: fd=18, bfd=-1, name=eth0, flags=0x19, scope=0,
    > ifindex=0, sin=217.XX.XXX.XX, bcast=217.XX.XXX.223,, mask=255.255.255.224,
    > Enabled:
    > ......
    > created interface #3: fd=19, bfd=-1, name=eth2, flags=0x19, scope=0,
    > ifindex=0, sin=192.168.XX.XX, bcast=192.168.XX.255,, mask=255.255.255.0,
    > Enabled:
    > ......
    > MCAST ***** sendpkt(fd=18 dst=224.0.1.1, src=217.XX.XXX.XX, ttl=96, len=68)
    >
    > (BTW, why is ttl=96 and not 3 ? But that's not the problem.)
    >
    >
    >
    >
    >
    >
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


    Try going with the flow. If ntpd wants to multicast via eth0, then
    connect eth0 to the network you want to multicast to. Reassign another
    interface to do whatever eth0 was doing.

    It may be a lot of work but you'll get much faster results than you
    would by waiting for a major redesign of ntpd networking.

    Alternatively, you could try hacking the code yourself and contributing
    any solution you find.


  5. Re: multicast - wrong interface

    Danny Mayer schrieb am 17.02.2007 04:43:
    > That's a separate question and most likely a bug. I don't know why the
    > ttl is set to 96, there aren't that many hops in the world...


    That's by design. Please see

    https://ntp.isc.org/bugs/show_bug.cgi?id=715#c16
    http://lists.ntp.isc.org/pipermail/q...st/006427.html


    Regards,
    Peter


  6. Re: multicast - wrong interface

    mayer@ntp.isc.org (Danny Mayer) writes:

    > Martin wrote:
    >> Hello !
    >>
    >> My NTP server sends all multicast traffic from eth0 and I don't
    >> know how to configure it to send it to the LAN connected via eth2.
    >> The details are below. Could you please give me some
    >> hints or help ?
    >>

    >
    > Right now you can't do it. I am aware of this issue. A related issue is
    > in Bug #725 though that's for IPv6. Part of the question is whether or
    > not there should be additional arguments to specify which interface to
    > broadcast on or whether to broadcast on all interfaces which is much
    > harder to do as there would need to be a lot of changes.


    I looked into that issue today on NetBSD. As it turns out the IPv4 mcast
    implementation will copy the multicast pakets to any interface where
    the respective multicast groups have been joined. For that to happen
    on a multihomed host (one with several multicast capable interfaces) you
    need to run mrouted or some other multicast routing daemon.
    It is relatively easy to modify ntpd to find out the preferred/default
    multicast interface, but it should not be neccessary when a
    multicast routing daemon installs the appropriate Multicast Forwarding
    Cache entries in the kernel.

    Frank

  7. Re: multicast - wrong interface

    I suspect many would appreciate having information like this added to:

    http://ntp.isc.org/Support/ConfiguringMulticastServers

    http://ntp.isc.org/Support/ConfiguringMulticastClients

    H

    >>> In article , Frank Kardel writes:


    Frank> I looked into that issue today on NetBSD. As it turns out the IPv4
    Frank> mcast implementation will copy the multicast pakets to any interface
    Frank> where the respective multicast groups have been joined. For that to
    Frank> happen on a multihomed host (one with several multicast capable
    Frank> interfaces) you need to run mrouted or some other multicast routing
    Frank> daemon. It is relatively easy to modify ntpd to find out the
    Frank> preferred/default multicast interface, but it should not be
    Frank> neccessary when a multicast routing daemon installs the appropriate
    Frank> Multicast Forwarding Cache entries in the kernel.

  8. Re: multicast - wrong interface

    Frank Kardel wrote:
    > mayer@ntp.isc.org (Danny Mayer) writes:
    >
    >> Martin wrote:
    >>> Hello !
    >>>
    >>> My NTP server sends all multicast traffic from eth0 and I don't
    >>> know how to configure it to send it to the LAN connected via eth2.
    >>> The details are below. Could you please give me some
    >>> hints or help ?
    >>>

    >> Right now you can't do it. I am aware of this issue. A related issue is
    >> in Bug #725 though that's for IPv6. Part of the question is whether or
    >> not there should be additional arguments to specify which interface to
    >> broadcast on or whether to broadcast on all interfaces which is much
    >> harder to do as there would need to be a lot of changes.

    >
    > I looked into that issue today on NetBSD. As it turns out the IPv4 mcast
    > implementation will copy the multicast pakets to any interface where
    > the respective multicast groups have been joined. For that to happen
    > on a multihomed host (one with several multicast capable interfaces) you
    > need to run mrouted or some other multicast routing daemon.
    > It is relatively easy to modify ntpd to find out the preferred/default
    > multicast interface, but it should not be neccessary when a
    > multicast routing daemon installs the appropriate Multicast Forwarding
    > Cache entries in the kernel.


    Yes, this is an unfinished piece of work. Figuring out which interface
    to use is rather difficult, particularly if there is more than one to
    choose from. Even worse, every O/S usually has sightly different and
    incompatible requirements which makes getting it right particularly hard.

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


  9. Re: multicast - wrong interface

    On Feb 14, 9:08 am, mar...@pr41.sk (Martin) wrote:
    >
    > In the ntp.conf there is:
    > broadcast 224.0.1.1 key 145 ttl 3
    >
    >
    > (BTW, why is ttl=96 and not 3 ? But that's not the problem.)
    >


    Hi Martin. The pointer in another post to :
    http://lists.ntp.isc.org/pipermail/q...st/006427.html

    has the earlier discussion on this question.

    The quick answer is to put this in your config file:

    ttl 0 1 2 3 4 5 6 7

    This creates a one-to-one mapping for ttl.

    Roger


  10. Re: multicast - wrong interface

    Thank you for all responses I've got.

    The most important information for me came from Danny Mayer:
    > Right now you can't do it. I am aware of this issue

    So I will stop trying and will use broadcast as a workaround
    for the multicast until the problem gets fixed.

    And because it is already known, I will not report it as a bug.

    Richard B. gilbert wrote:
    > Try going with the flow. If ntpd wants to multicast via eth0, then
    > connect eth0 to the network you want to multicast to. Reassign another
    > interface to do whatever eth0 was doing.

    This would be the last resort. I can't rely on the fact, that ntpd
    prefers eth0, or can I ? IMHO using broadcast instead is easier
    and the outcome is predictable.

    Martin

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


  11. Re: multicast - TTL

    (I changed the subject for this separate issue,
    it was: multicast - wrong interface)

    Peter Pramberger wrote:
    > > That's a separate question and most likely a bug. I don't know why the
    > > ttl is set to 96, there aren't that many hops in the world...

    >
    > That's by design. Please see
    >
    > https://ntp.isc.org/bugs/show_bug.cgi?id=715#c16
    > http://lists.ntp.isc.org/pipermail/q...st/006427.html


    Such behavior seems to be not in line with the documentation:
    - - - - - - -
    ttl ttl
    This option is used only with broadcast server and manycast client modes.
    It specifies the time-to-live ttl to use on broadcast server and multicast
    server ...

    http://www.eecis.udel.edu/~mills/ntp/html/confopt.html
    - - - - - - -

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


  12. Re: multicast - TTL

    wa6zvp wrote:
    > The quick answer is to put this in your config file:
    >
    > ttl 0 1 2 3 4 5 6 7
    >
    > This creates a one-to-one mapping for ttl.

    Roger, thank you for solving the issue.

    I've read the discussion you mentioned. It looks to me that unless overridden
    with the ttl command like the one above, the whole TTL range 0-255 is reduced
    to just 8 values: 0,32,64, ... 224. The ttl option to the broadcast command is
    then not the real TTL value, but an index selecting one from those 8 values.

    It probably causes no harm to use incorrect (larger) TTL, but this feature
    could be better documented, IMHO.

    Thank you

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


  13. Re: multicast - TTL

    Martin,

    The descrete values used for the TTL is consistent with the
    administrative scoping rules spelled out in the RFC cited in the
    documentation.

    Dave

    Martin wrote:
    > wa6zvp wrote:
    >
    >>The quick answer is to put this in your config file:
    >>
    >>ttl 0 1 2 3 4 5 6 7
    >>
    >>This creates a one-to-one mapping for ttl.

    >
    > Roger, thank you for solving the issue.
    >
    > I've read the discussion you mentioned. It looks to me that unless overridden
    > with the ttl command like the one above, the whole TTL range 0-255 is reduced
    > to just 8 values: 0,32,64, ... 224. The ttl option to the broadcast command is
    > then not the real TTL value, but an index selecting one from those 8 values.
    >
    > It probably causes no harm to use incorrect (larger) TTL, but this feature
    > could be better documented, IMHO.
    >
    > Thank you
    >
    > Martin
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


  14. Re: multicast - TTL

    > The quick answer is to put this in your config file:
    >
    > ttl 0 1 2 3 4 5 6 7
    >
    > This creates a one-to-one mapping for ttl.


    There still seems to be a small problem ...

    For multicast (224.0.1.1) it works as you have described, but
    for the regular UDP broadcast it does not.

    The config file:
    ttl 0 1 2 3 4 5 6 7
    broadcast 192.168.XX.255 key 144 ttl 3

    ntpd with -D2 flag says the TTL is 3:
    ***** sendpkt(fd=20 dst=192.168.XX.255, src=192.168.XX.XXX, ttl=3, len=68)

    but the tcpdump says the TTL is 64:
    IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],

    The broadcast will not leave the LAN, so the TTL does not really matter,
    but the behaviour is strange.

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


  15. Re: multicast - wrong interface

    wa6zvp wrote:
    > On Feb 14, 9:08 am, mar...@pr41.sk (Martin) wrote:
    >> In the ntp.conf there is:
    >> broadcast 224.0.1.1 key 145 ttl 3
    >>
    >>
    >> (BTW, why is ttl=96 and not 3 ? But that's not the problem.)
    >>

    >
    > Hi Martin. The pointer in another post to :
    > http://lists.ntp.isc.org/pipermail/q...st/006427.html
    >
    > has the earlier discussion on this question.
    >
    > The quick answer is to put this in your config file:
    >
    > ttl 0 1 2 3 4 5 6 7
    >
    > This creates a one-to-one mapping for ttl.
    >


    I'm going to need to take a closer look at this. It doesn't make a lot
    of sense to me. If Dave remembers why things were done this way I'd
    appreciate the feedback but it seems to me that the ttl option on the
    broadcast line should specify the hop count to be used.

    Danny

    > Roger

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


  16. Re: multicast - wrong interface

    Martin wrote:
    > Thank you for all responses I've got.
    >
    > The most important information for me came from Danny Mayer:
    >> Right now you can't do it. I am aware of this issue

    > So I will stop trying and will use broadcast as a workaround
    > for the multicast until the problem gets fixed.
    >
    > And because it is already known, I will not report it as a bug.
    >


    Well you should since I don't think we have a bug report on this.
    Furthermore, I don't know yet whether or not we should try and figure
    out which interface should be used or just add a option to the broadcast
    line to tell it what to use.

    > Richard B. gilbert wrote:
    >> Try going with the flow. If ntpd wants to multicast via eth0, then
    >> connect eth0 to the network you want to multicast to. Reassign another
    >> interface to do whatever eth0 was doing.

    > This would be the last resort. I can't rely on the fact, that ntpd
    > prefers eth0, or can I ? IMHO using broadcast instead is easier
    > and the outcome is predictable.


    There's no guarantee that you'll get the desired result.

    Danny

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


  17. Re: multicast - TTL

    Martin wrote:
    > (I changed the subject for this separate issue,
    > it was: multicast - wrong interface)
    >
    > Peter Pramberger wrote:
    >>> That's a separate question and most likely a bug. I don't know why the
    >>> ttl is set to 96, there aren't that many hops in the world...

    >> That's by design. Please see
    >>
    >> https://ntp.isc.org/bugs/show_bug.cgi?id=715#c16
    >> http://lists.ntp.isc.org/pipermail/q...st/006427.html

    >
    > Such behavior seems to be not in line with the documentation:
    > - - - - - - -
    > ttl ttl
    > This option is used only with broadcast server and manycast client modes.
    > It specifies the time-to-live ttl to use on broadcast server and multicast
    > server ...
    >
    > http://www.eecis.udel.edu/~mills/ntp/html/confopt.html
    > - - - - - - -
    >


    Yes, and this whole idea troubles me. The phrase "Principle of Least
    Astonishment" comes to mind.

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


  18. Re: multicast - TTL

    Martin,

    Yes it does; see the RFC. In any case, you are free to design your own ttl.

    Dave

    Martin wrote:
    >>The quick answer is to put this in your config file:
    >>
    >>ttl 0 1 2 3 4 5 6 7
    >>
    >>This creates a one-to-one mapping for ttl.

    >
    >
    > There still seems to be a small problem ...
    >
    > For multicast (224.0.1.1) it works as you have described, but
    > for the regular UDP broadcast it does not.
    >
    > The config file:
    > ttl 0 1 2 3 4 5 6 7
    > broadcast 192.168.XX.255 key 144 ttl 3
    >
    > ntpd with -D2 flag says the TTL is 3:
    > ***** sendpkt(fd=20 dst=192.168.XX.255, src=192.168.XX.XXX, ttl=3, len=68)
    >
    > but the tcpdump says the TTL is 64:
    > IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
    > v
    > The broadcast will not leave the LAN, so the TTL does not really matter,
    > but the behaviour is strange.
    >
    > Martin
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


  19. Re: multicast - TTL

    > Yes it does; see the RFC. In any case, you are free to design your own ttl.

    Dave,

    I'm trying to design my own TTL to be at least 40 years from now :-)

    I am by no means an expert to discuss the design of the TTL code, but IMHO
    the ntpd program and its documentation (particularly the ntp.conf man page)
    regarding the setting of the TTL on multicast/broadcast are "not is sync" and
    that is a source of confusion for admins like me.

    Martin

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


  20. Re: multicast - TTL

    Martin wrote:
    > wa6zvp wrote:
    >> The quick answer is to put this in your config file:
    >>
    >> ttl 0 1 2 3 4 5 6 7
    >>
    >> This creates a one-to-one mapping for ttl.

    > Roger, thank you for solving the issue.
    >
    > I've read the discussion you mentioned. It looks to me that unless overridden
    > with the ttl command like the one above, the whole TTL range 0-255 is reduced
    > to just 8 values: 0,32,64, ... 224. The ttl option to the broadcast command is
    > then not the real TTL value, but an index selecting one from those 8 values.
    >
    > It probably causes no harm to use incorrect (larger) TTL, but this feature
    > could be better documented, IMHO.


    No, the code should be corrected. In spite of its name, the value is
    actually a hop count when you are doing multicasting. Originally when
    the IPv4 multicast protocol was being developed it was thought that this
    should really be a time-to-live. In practice this didn't happen. The
    routers actually take the value and subtract one and send it on if the
    new value is greater than 0. With IPv6 multicasting it's actually called
    a hop count. Multicasting is not really well developed beyond site-local
    and I doubt that any of the Internet backbone routers will pass on
    multicast packets outside of their own though I haven't checked that
    myself. In fact your border routers should stop them.

    In summary, the ttl on the broadcast line should be what you want to set
    the outgoing ttl to and not something else. It should always been that
    way. I don't understand why you want an extra line to specify what the
    value means.

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


+ Reply to Thread
Page 1 of 2 1 2 LastLast