[Xorp-users] Multicast in general, and perhaps xorp in particular

[Pavlin Radoslavov]

Kees Jan Hermans <kees at pink-frog.com> wrote:

> Dear reader,
> 
> I'm a bit at my wits' end; I have until Friday to complete this demo, 
> which is for a prototype of a networking device that must also do IP 
> multicasting.  I have the following network topology:
> 
> host1----------device------------router-------------device------host2
> 192.168.2.20 anonymous 192.168.2.1 <-> 192.168.3.1 anonymous 192.168.3.20
> 
> The router is using xorp, which I think is a fantastic product, altough 
> I'm not all that familiar with it, having discovered it only a few days 
> ago.  That being said, getting routing done was a piece of cake, so 
> nothing but compliments there.  I must add that I was a little bit 
> surprised to discover that one had to make special arrangements for 
> getting multicasting work out of the box; apparently it isn't in the 
> design philosophy of xorp to have one segment subscribe to a multicast 
> address, and route traffic to that segment's interface automatically 
> when traffic to that multicast address is discovered on another 
> interface.  I wonder why that is, but not for too long, because I got it 
> to work (through a 'rp').  That is to say, if you take out the two 

This is how multicast routing works: in general, you must have a
multicast routing protocol (or equivalent like IGMP proxy) running
on the routing devices in the middle.

> 'devices' in the diagram above, everything works flawlessly: host2 has 
> VLC subscribe to a multicast address, and on host1 VLC sends packets to 
> that address, which arrive and I can hear pretty music play on host2.  
> So far, so good.
> 
> The devices in question, amongst other tasks, proxy for the IGMP and 
> multicast traffic; they act as bridges effectively, cleaning and 
> monitoring the network packets.  To do what they have to do, the devices 
> cache the multicast subscriptions, and create IGMP packets themselves on 
> a timely basis.  And when I have those devices in the middle (as drawn 
> in the diagram above), it doesn't work.  By now I'm pretty sure that 
> 'my' IGMP packets are good, and equal to the packets sent by 'host2', 
> however, when I send them, the subscriptions won't show up in the 'show 
> igmp groups' list (they do if you take my devices out).  I've noticed a 

I presume you see the IGMP packets your device generates if you run
tcpdump on the XORP router.
If you enable all tracing options for the MFEA and IGMP do you see
any log messages about the packets being received?
Any warning or error messages that might be helpful?

> few things though, that I wonder could be related to this problem: 
> namely that 'host2' sends IGMP subscriptions TWICE in quick succession 
> (where I send them only once), and that there's some PIM traffic going 
> on to address 224.0.0.13 (that I don't react to at all).  My questions are:
> 
> a) are my suspicions about the differences in behaviour any good ?

The problem is the IGMP joins don't show in "show igmp groups".
Even if you think your IGMP packets are exactly same, obviously
there is something different which stops them from being received by
XORP.

> b) do I have to react to PIM traffic, and in effect create a dialog 
> before subscription to a multicast address becomes effective in the router ?

In general you have to forward the PIM control messages so they can
reach the PIM neighbor routers.
For this particular experiment with a single PIM-SM router you can
get away even without forwarding the PIM control messages, but you
MUST do the right thing for the product itself :)

> c) is there a way to see in the xorp router what happens with a packet 
> such as a IGMP report packet ?

Try to enable the traceoptions in the XORP config (in both the mfea4
and igmp blocks:

        traceoptions {
            flag all {
                disable: false
            }
        }

Also, enable the XRLTRACE environmental variable. E.g., in csh/tcsh:

setenv XRLTRACE yes

This will print all IPC interprocess exchange in XORP (the so called
XRLs).
Warning: it will be a lot, so save all the output to a file and then
post-process it. My personal preference is to use script(1) and
start XORP in foreground.
Look for XRLs like raw_packet4_client/0.1/recv which will print the
IGMP and PIM control messages beint sent from the FEA to the IGMP
and PIM processes.

Please let us know how it goes.
Pavlin

> Thanks for your time, and only too willing to also post configurations 
> and packet data in hexadecimal,
> 
> Sincerely,
> 
> KJ Hermans
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users