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

[kees at pink-frog.com]

Ok.  I got it.  My program at one point made its IGMP packets exactly like
the ones it received, and then the checksumming showed to be at fault; I
had a struct ip4hdr* ip4hdr defined, and later on did the checksumming on
sizeof(ip4hdr) instead of a sizeof(struct ip4hdr).  It's not that I'm more
of a C++ programmer really, but it was just a stupid mistake.  Sorry to
waste your time.  It works now.  I'll have a look later to see if the
client also wants PIM, and if it's easy to implement.

Sincerely,

KJ

> 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
>>>
>>
>>
>>
>
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users
>