Re: Multicast question

John Vossler wrote:
Greetings,

I have a new system running Solaris 10 set up as an NTP server. IT is synchronizing correctly but I cannot get it to multicast on any interface except the systems primary Ethernet interface, bge0. I need it to multicast on interfaces bge1-bge3 and ce0 - ce7.

Client systems reside on the network segments on these other interfaces.

Anyone have any suggestions on getting the server to multicast on these other interfaces?

John

This issue has been discussed on the newsgroup around 2007-02-23. At
that time I taught ntpd to find the multicast default interface. This
solution is only suffcient on system with a single interface. To
quote the analysis from Bug #785 (https://support.ntp.org/bugs/show_bug.cgi?id=785):


As it turns out the IPv4 mcast implementation will copy the multicast
packets 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, zebra or some other
multicast routing daemon.

So usually IPv4 MCAST will go via one interface. The kernel and/or
Multicast routing deamons then run the IGMP and other protocols to
find out which subscribers are connected on which interface and instruct
the kernel to do the respective packet replications.

On NetBSD (probably other BSDs too ans systems derived from that) my
setup is like this:

ntp.conf:

broadcast 224.0.1.1 ttl 5 autokey

I run mrouted.

and mrouted detects via IGMP my multicast clients. The multicast
routing table of the kernel is currently:


netstat -g

Virtual Interface Table
Vif Thresh Limit Local-Address Remote-Address Pkt_in Pkt_out
0 1 0 10.x.y.1 0 31
1 1 0 84.xxx.xxx.xxx 0 613

Multicast Forwarding Cache
Hash Origin Mcastgroup Traffic In-Vif Out-Vifs/Forw-ttl
38 84.xxx.xxx.xxx 224.0.1.1 613 1 0/1

Total no. of entries in cache: 1


This means for the Mcastgroup 224.0.1.1 (NTP.MCAST.NET) 613 packets
where sent via the interface Vif1 84.... These packets are replicated to
the interfaces Vif0 10... and Vif1 84.... for real output. You also
see that the interface Vif0 (10....) only sent 31 packets. This is
because I just started my notebook which is a multicast client.
As soon as ntpd on the notebook joined the Mcastgroup 224.0.1.1
pakets started flowing via the Vif0.

Solaris may or may not be needing a multicast routing daemon, but
I leave that research to someone else for now. But one thing to
note is that you may not see NTP Mcast traffic unless IGMP
messages are visible on the network segments (you can snoop for them).
So for debugging you need an ntpd on the interesting network segments
that listens for the multicast packets *before* you are likely to see
NTP multicast packets leaving the interface for that segment.
Usually Mcast packets are only send when necessary except for the
primary interface.

My current IGMP traffic looks like this (tcpdump -v -v -s 512 -i <iface> igmp):
11:06:39.860323 IP (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto IGMP (2), length 28) server > ALL-SYSTEMS.MCAST.NET: igmp query v2
11:06:39.860404 IP (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto IGMP (2), length 32) server > DVMRP.MCAST.NET: igmp dvmrp Probe
genid 3783968839
11:06:45.498743 IP (tos 0x0, ttl 1, id 556, offset 0, flags [none], proto IGMP (2), length 28) client > NTP.MCAST.NET: igmp v2 report NTP.MCAST.NET
11:06:49.960402 IP (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto IGMP (2), length 32) server > DVMRP.MCAST.NET: igmp dvmrp Probe

Note the igmp v2 report line. Here the client documents interest in
NTP.MCAST.NET multicast packets which leads to forwarding the packets
to that network segment.

Hope this helps a bit.

Frank
.

Relevant Pages

  • Re: Cisco switches + Ghost
    ... Turning on global cgmp fast-leave doubled the multicast rate to ... interface FastEthernet0/1 ... switchport access vlan 10 ... input packets with dribble condition detected ...
    (comp.dcom.sys.cisco)
  • Re: Unexpected multicast IPv4 socket behavior
    ... The fact that IPv4 multicast sends appear to work using the default route is a historical quirk. ... For a host/endstation, the mere fact that the group was joined on a given socket, on a given interface, should be enough IP layer reachability information for the inpcb layer to figure out where to send the packets. ... From that point on, it's the problem of the multicast routers on the path between the end-station and the other members of the channel, which are normally speaking PIM-SM. ... If one follows how IGMP works, then the problem with multicast joins which are not scoped to an interface is readily obvious. ...
    (freebsd-net)
  • Re: data structure for network protocol
    ... This function is to listen the IGMP traffic (mainly Join ... must be added to a list of multicast groups. ... If I understood the IGMP protocol correct you need to perform ... (port number and interface number will probably be part of these keys, ...
    (comp.programming)
  • setsockopt IP_ADD_MEMBERSHIP not honored
    ... I've been working on a miniature multicast routing program and am ... socket to receive packets from. ... address is translated into an ifp for the interface that address is ... and the receive queue for the socket that has the membership on ...
    (freebsd-net)
  • Multicast Routing help
    ... So far I've attempted to use mrouted and smcroute from a local Linux ... I can get the multicast packets through the tunnel to show up on the ... put these packets onto the main interface. ...
    (comp.os.linux.networking)