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

[Pavlin Radoslavov]

kees at pink-frog.com wrote:

> 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.

I am glad you got it working.

Thanks for the update,
Pavlin

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