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

[Kees Jan Hermans]

Yes, I did run tcpdump, but then on a host in between, like so:

host2----hub----router
          |
        tcpdumper

and:

host2---device---hub---router
                  |
                tcpdumper


I'll see if I can post the traffic later.  Gotta go to work now.

Cheers,

KJ

Pavlin Radoslavov wrote:
> 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
>>     
>
>
>