[Xorp-users] Very simple multicast setup, yet can't find any text on how to do it!

[Erik Slagter]

Pavlin Radoslavov wrote:

>> This involves PIM and router adverts. I try to avoid PIM as much as possible
>> ;-) Waaaaay too complex.
> 
> If you are running multicast in tightly controlled environment with
> a single sender in the center of a star topology directly connecting
> the receivers, then you can get away with your own program.
> Otherwise, if there are remote senders and receivers, then things
> can get easily out of control (there is a reason PIM is complex :)

Yeah, after some thinking I came to the same conclusion. But fortunately 
my own home is such a tightly controlled controlled environment :-)

> I've tried with 2.6.27.2 and 2.6.28.1 but I got same result.
> I haven't tried yet with the exact version you are using
> (2.6.27.10).

Nah, I cannot believe it comes down to such a minor variation.

> Were you able to get kernel upcalls and MLD_LISTENER_REPORT messages
> by using the unmodified original program from Todd
> (http://www.linux-ipv6.org/ml/usagi-users/msg04077.html) ?
> I am asking this question because I need a calibration point.

I will do so, but it won't be before friday.

> Re. API description online, you could try the FreeBSD multicast(4)
> manual page available from the following URL (enter keyword
> "multicast"):

I accidently found that page using google already :-) It was 
informative, but it doesn't supply some sort of starting point.

> Most of the info there should apply for Linux as well (at least for
> IPv4), but Linux doesn't have the "Advanced Multicast API" support.

Really? Linux appears to have support for various "advanced "ipv4" "api" 
mixtures. But maybe indeed not advanced ipv6 multicasting.

> The selection algorithm shouldn't matter to you if you are receiving
> and processing the upcall messages like
> MRT6MSG_NOCACHE/MRT6MSG_WRONGMIF/MRT6MSG_WHOLEPKT.
> The NOCACHE upcall for example should include the (S,G) and the iif
> for the multicast packet, so all you need to do is install back
> (S,G) with that iif and the oifs.

Yeah, indeed it looks like here lies the solution to my problem.

If I get an upcall for a group that has no listeners -> route it to a 
black hole.

> Even if you can somehow get all the mcast traffic appear with
> iif=dummy0, you must know the source address as well if you want to
> install the MFC entries in advance. Otherwise, you need to catch the
> NOCACHE upcalls and process them.

I resolved this using a dirty hack :/-. When a join request comes in and 
the multicast route needs to be updated or added, I ask the kernel for 
the route to the multicast address being processed. In the process this 
yields both address and "source" address being used. For the moment this 
works, although I could imagine this is not the correct way to do things 
and it will break someday.

I was really planning to do this using the kernel netlink api, but this 
appears to be so complex that I gave up this approach and used a 
system("ip -6 route ...") instead. Not nice, but for a quick hack it 
works very decently ;-)

But as mentioned before, processing kernel upcalls should make this 
problem void (fingers crossed).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3328 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20090127/801a3690/attachment.bin