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

[Pavlin Radoslavov]

[Note: I am addressing only some of the high level questions posted
below, because it seems you have found workaround for the problem]

Erik Slagter <erik at slagter.name> wrote:

> [Background information: I want to multicast a stream using IPv6 that is
> originating (locally) from a linux server that has a number of interfaces
> connected, each interface should only send out the packets when it has one or
> more clients that have joined the group, no PIM is in use, only MLD. The
> kernel native multicast forwarding functionality should be used, no packet
> forwarding in user space.]
> 
> Finally I came to the conclusion that both xorp and mrd6 are not designed for
> what I need, xorp only functions with multicasting when pim is enabled (and
> set up properly) and the source should be outside the host xorp is running
> on. Mrd6 also needs an external multicast source (and maybe (configured) pim
> as well, I am not shure).

Theoretically, it shouldn't matter whether the source is on the host
running XORP/MRD6 or external. Though, I have seen reports in the
past for some odd behavior (for IPv4) if one of the participants
(sender/receiver?) was on the same host.

> So hacked myself a little (well..) program that does exactly this and not
> more. Due to the documentation about ipv6 multicast routing (api) being very
> sparse (not to say next to non-existent) I had to try and error the thing
> together. If anyone is interested (either for experimenting or for giving
> feedback for improvement (please!)) please yell.
> 
> This is what is does: it listens on all system network interfaces for MLD
> messages (currently MLDv2 REPORT only, only INCLUDE and EXCLUDE, like current
> linux kernels send them, the RFC is incomprehensable). When a join request
> arrives, the requested multicast group is added to the list of groups of the
> interface the request came from and the multicast route for this group is
> again added with the changed interface list. Likewise for a leave
> request. Sounds simple, not? Well it's not :-/
> 
> Thanks to Todd Hayton BTW, I used his example program as a starting point
> (although my goal is different).
> 
> Although I have it working now, I still do have some questions for the experts.
> 
> - Every now and then I have a line with multicast route with an interface of
> "65536" and silly data in /proc/net/ip6_mr_cache. This look like a side-effect
> of packets being queued when no applicable mc route is found?

I am not familiar with the implementation details of ip6_mr_cache,
but if there is no matching multicast route, it is up to the
userland program to install such route.
The new route should have the appropriate incoming and outgoing
interfaces, or no outgoing interfaces if no receivers.
In other words, it is valid to have a MFC (Multicast Forwarding
Cache) entry with no outgoing interfaces, for the purpose of
stopping upcalls to userland.

> - As far as I know, it should be ok for a multicast group to be forwarded
> regardless of the source address. If I set mc.mf6cc_origin to all (binary)
> zeroes (bzero) and then call MRT6_ADD_MFC, it simply doesn't work, it only
> works if I request the address from the  incoming interface from the routing
> table, and fill the entry with that address and the corresponding interface
> index, which I think is a dirty hack :-/
> Isn't there a way to specify a wildcard origin address and interface?

No unfortunately. The MFC entries granularity in the kernel
(BSD/Linux/Solaris/etc) is (S,G). It is possible to modify the
kernel to support (*,G)  (long time ago I did a prototype
implementation for BSD), but so far there hasn't been strong need
for this feature to become part of the kernel.

> - When I start the program that feeds the multicast stream, before my own
> program is started, the packets are routed to a (for me) random
> interface. This is not always the same interface. It would be logical to me if
> the packets are routed to the lo interface or are discarded instead, when no
> "MRT6_INIT" program is running...
> 
> - After I start my program, and I have installed a multicast route with one or
> more interfaces, the packets are STILL (also) forwarded to this interface (see
> above) regardless whether the interface is mentioned in the mc route.
> 
> - To resolve the above issue, I add a dummy ethernet interface (dummy0), which
> I try to set as multicast source for locally generated mc traffic using
> IPV6_MULTICAST_IF, sometimes this works, sometimes it doesn't. If it doesn't,
> I need to stop both programs (no MRT6_INIT apps, so no more mcast route
> cache...) and type "ip -6 route del ff05::4242" until ip returns an
> error. This route doesn't show up in "ip -6 route show", btw... If I now start
> both programs, the mc traffic seems to originate from dummy0 and is not
> physically sent out to unsubscribed interfaces anymore, although tshark
> reveals the packets are actually still "sent" on dummy0. I am not shure
> whether is this a result of IPV6_MULTICAST_IF or that I am just "lucky".
> 
> - What is the intended use of IPV6_MULTICAST_IF actually?
> 
> - Although I only request MLDv2 packets (143) I still get all sorts of
> messages on the raw socket (icmp type 0, expected, probably "upcall" packets)
> but also all sorts of other types?!
> 
> - The semantics of MRT6_ADD_MFC and MRT6_DEL_MFC are still more or less a
> mystery to me. Adding and deleting one specific multicast route seems
> straightforward, but how is one supposed to add an interface to an existing
> route or delete one interface? Currently I call MRT6_ADD_MFC simply with the
> updated set of interfaces and this seems to work, but imho this is not
> "adding" a route like the name suggests... Likewise is it possible to call
> MRT6_DEL_MFC with a minimal set of information (like, delete all routes to mc
> group xx, regardless interface, origin address, etc.)? This to clean up the
> cache every now and then...

Yes, the granularity for ADD_MFC/DEL_MFC is per MFC entry. Every
time you need to update the MFC entry you must call MRT6_ADD_MFC
with the complete set of information for that entry (iif, updated
outgoing interface set, etc). Once the entry is not needed anymore,
you call MRT6_DEL_MFC to remove it from the kernel.

Regards,
Pavlin

> Thank you for your time and efford!
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users