Discussion:
IP Multicast
(too old to reply)
Neel Sheyal
2008-09-19 18:06:29 UTC
Permalink
Hi,

I have two netbsd hosts both with two NICs.

HOSTA: ex0: 192.168.21.2/24 and ex1: 172.16.18.2/16
HOSTB: ex0: 192.168.22.2/24 and ex1: 172.18.20.2/16

There is an application sending multicast traffic on hostA to
239.198.1.2. There is another application on hostB which is subsribing
to this group.

The application on hostA or hostB does not specific the outgoing
interface for sending traffic or joining. I have also not send the
routing table with the multicast group information.

How does the OS know which interface to send the multicast traffic as in hostA?

How does the OS know which interface to subscribe to for receiving
multicast traffic as in hostB?

Thanks,
~~Neel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Eric Auge
2008-09-19 19:31:26 UTC
Permalink
Post by Neel Sheyal
Hi,
Hello,
Post by Neel Sheyal
I have two netbsd hosts both with two NICs.
HOSTA: ex0: 192.168.21.2/24 and ex1: 172.16.18.2/16
HOSTB: ex0: 192.168.22.2/24 and ex1: 172.18.20.2/16
There is an application sending multicast traffic on hostA to
239.198.1.2. There is another application on hostB which is subsribing
to this group.
The application on hostA or hostB does not specific the outgoing
interface for sending traffic or joining. I have also not send the
routing table with the multicast group information.
I might be wrong but peeking into various manpages and specifically
ip(4), you can find this :

[...]
For hosts with multiple interfaces, each multicast transmission is
sent from the primary network interface. The IP_MULTICAST_IF option
overrides the default for subsequent transmissions from a given socket:
[...]

and

[...]
A host must become a member of a multicast group before it can
receive datagrams sent to the group. To join a multicast group, use the
IP_ADD_MEMBERSHIP option:
[...]

and

[...]
imr_interface should be INADDR_ANY to choose the default multicast
interface, or the IP address of a particular multicast-capable interface
if the host is multihomed. Membership is associated with a single
interface; programs running on multihomed hosts may need to join the
same group on more than one interface. Up to IP_MAX_MEMBERSHIPS
(currently 20) memberships may be added on a single socket.
[...]
Post by Neel Sheyal
How does the OS know which interface to send the multicast traffic as in hostA?
How does the OS know which interface to subscribe to for receiving
multicast traffic as in hostB?
The program handling the multicast traffic (i.e. ospfd) need to make the
socket join the group on specific interface(s), this is according to my
understanding reading ip(4).

I have not tried it.

HTH,
Regards,
Eric.
Post by Neel Sheyal
Thanks,
~~Neel
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Robert Elz
2008-09-19 20:33:18 UTC
Permalink
Date: Fri, 19 Sep 2008 14:06:29 -0400
From: "Neel Sheyal" <***@gmail.com>
Message-ID: <***@mail.gmail.com>

| How does the OS know which interface to send the multicast traffic as in hostA?

If IP networks and IP multicasting were set up as they should be (as it
was all originally designed) it would make no difference (aside from some
network efficiency) - send on either interface, listen on either interface,
and the multicast system (the routers) get the packets through the net
from wherever to wherever.

Unfortunately ...

Given that, what Eric said is about right - either the application, or
the system, has to explicitly say which interface to use, and you need
to get it right for things to work. If the application is not bothering
(most multicast applications I've used have an option to allow the user to
say which to use) then the system default multicast interface is what
gets used.

I kind of half remember (from the ancient past) that there was a way
that you could set which interface that was, rather than it just being
some seemingly random interface selected by the kernel, but I do not
recall if NetBSD has a way to do that or not. Perhaps someone else
here knows how it is done, if there is a way.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Neel Sheyal
2008-09-19 21:51:06 UTC
Permalink
But is Solaris the multicast is implemented as follows:
"If the addressspecified is INADDR_ANY, it uses the unicast routing
table to select the outgoing interface (which is the default
behavior)."

Any idea about how the OS can figure out from the unicast routing
table (RT) if the RT does not contain information about the multicast
group?

Thanks,
--Neel

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Greg Troxel
2008-09-20 01:06:44 UTC
Permalink
Post by Robert Elz
I kind of half remember (from the ancient past) that there was a way
that you could set which interface that was, rather than it just being
some seemingly random interface selected by the kernel, but I do not
recall if NetBSD has a way to do that or not. Perhaps someone else
here knows how it is done, if there is a way.
For transmit, I think you can set a router for 224/5 to the interface
you want to use.

But really, you either need to have programs that deal with this
explicitly (like routing programs or other low-level stuff), or you
should run a multicast routing daemon. See mrouted(8).



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Robert Elz
2008-09-20 08:50:06 UTC
Permalink
Date: Fri, 19 Sep 2008 17:51:06 -0400
From: "Neel Sheyal" <***@gmail.com>
Message-ID: <***@mail.gmail.com>

| But is Solaris the multicast is implemented as follows:
| "If the addressspecified is INADDR_ANY, it uses the unicast routing
| table to select the outgoing interface (which is the default
| behavior)."

Sorry, I cannot even parse that - I have no idea what it is saying
(though there is probably more context that would help). For example
which address specified?

For sure, if you bind the socket you're sending through to a local address
then you have chosen the outgoing interface (the one that has been assigned
the address) - unlike unicast, multicast has no other choice, it must send
through that interface to work.

But if the socket is bound to INADDR_ANY (which is approximately equal to
saying not bound, though the port number might be, and probably is, set)
then the system should first pick the interface, and set the source address
to that of that interface. How it could possibly use the unicast routing
table to assist with that I have no idea (after all if it is a "unicast"
routing table, it cannot, by definition, be using the trick described by
Greg Troxel as that was a multicast group id in the routing table.)
That is, unless it means that it looks up INNADDR_ANY in the routing table,
which might be an obscure way of saying it uses the unicast default route,
which of course also assumes that you have one of those.

| Any idea about how the OS can figure out from the unicast routing
| table (RT) if the RT does not contain information about the multicast
| group?

Multicast group info in the routing table would really be a pretty silly
idea (other than used in a hack way as Greg described - that is implementing
the API "set this interface as the default transmit interface for multicast"
without having to add any new mechanism, just using the regular routing socket
or ioctls.) Members of the multicast group might be everywhere. Your
initial message described exactly one receiver, but imagine there was another
and the other was on the other interface compared with the first one.
Hosts only ever send multicast packets once, which interface would you pick
then?

You really do need both proper multicast routing (as hard as that might be
across a private/public address space boundary, though it is possible to NAT
multicast packets if you're very very careful and have only a single NAT,
redundancy will kill you with multicast and NAT), and your applications
really do need an interface selection method, and not to just rely upon some
notion of default - other than for hosts with only a single interface
multicast just doesn't work that way.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
David Young
2008-09-22 23:12:46 UTC
Permalink
Post by Neel Sheyal
Hi,
I have two netbsd hosts both with two NICs.
HOSTA: ex0: 192.168.21.2/24 and ex1: 172.16.18.2/16
HOSTB: ex0: 192.168.22.2/24 and ex1: 172.18.20.2/16
There is an application sending multicast traffic on hostA to
239.198.1.2. There is another application on hostB which is subsribing
to this group.
The application on hostA or hostB does not specific the outgoing
interface for sending traffic or joining. I have also not send the
routing table with the multicast group information.
How does the OS know which interface to send the multicast traffic as in hostA?
How does the OS know which interface to subscribe to for receiving
multicast traffic as in hostB?
Once, I figured out a lot about the multicast API on NetBSD, with the
help of the kernel source code, because I was writing a routing daemon.
Let me try to answer your questions with my best recollection of how
the attached code is used. Please refer to ip(4), also.

Suppose that I want to use a socket, `s', to transmit multicasts on a
particular interface, given by its index. I call beacon_tx_mcast_setup()
on `s'.

I also want to receive multicasts. I call beacon_rx_mcast_joinleave() to
join/leave a multicast group on a particular interface. `s' is a datagram
socket. `optname' is either IP_ADD_MEMBERSHIP or IP_DROP_MEMBERSHIP,
`addr' is the multicast address, `ifindex' the interface index from,
say, if_nametoindex(3).

I want the kernel to tell my app which interface it reads each multicast
packet from, using the "packet ancillary data". (See recvmsg(2).)
I call beacon_rx_pktinfo_enable(s, 1):

Dave
--
David Young OJC Technologies
***@ojctech.com Urbana, IL * (217) 278-3933 ext 24
Loading...