Date: Mon, 27 Jul 2009 00:29:40 +0100 From: Bruce Simpson <bms@incunabulum.net> To: iprebeg@freebsd.org Cc: freebsd-net@freebsd.org Subject: Re: Wrong multicast destination IP Message-ID: <4A6CE6E4.3010106@incunabulum.net> In-Reply-To: <20090725130424.GA24589@valeria.zesoi.fer.hr> References: <20090725130424.GA24589@valeria.zesoi.fer.hr>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
It sounds as though you are in fact running into a regression in the ARP
cache code.
Please see recent threads on current@, this is a known issue.
Unfortunately I can't assist other than providing advice, I am very busy
at the moment.
iprebeg@freebsd.org wrote:
> In recent current kernel, it appears that IGMPv2 reports (not IGMPv3)
> are sent to wrong multicast address. I'm trying to setup mcast routing
> in this way:
> ...
> mrouted is started on mr with configuration containing only one line:
>
I wouldn't rely on mrouted for anything, DVMRP is quite obsolete.
mrouted does not support IGMPv3 to the best of my knowledge. It embeds
its own IGMPv2 router control, and will act as a querier. This is why
your boxes are reverting to IGMPv2 when mrouted is running.
I would recommend ports/net/mcast-tools for exercising the multicast
forwarding plane. There is a tool in there called 'mfc' which will let
you temporarily install entries in the Multicast Forwarding Cache.
Please don't use 'mfc' in a production environment -- there is no loop
detection.
The last time I fully tested multicast forwarding on the -CURRENT track
was in March, right after the IGMPv3 drop went in, and right after
MROUTING was cleaned up.
I'm not aware of any regressions on that track, apart from the ARP cache
regression which Xin Li was looking into. One chap on current@ reported
that one of Xin Li's interim patches fixed his multicast issues, I
believe I Cc'd you on that thread. Unfortunately Xin Li himself is also
tied up at the moment.
> ...
> 1) No packets are forwarded. I hope that reason is problem stated in 2).
> Anyway, I'd be happy if someone can confirm that I'm doing everything
> right. It would be also cool if someone could post XORP configuration
> that I can use for this configuration. I can see UDP packets reach em2
> iface on mr.
>
There is a config in XORP's tree called multicast4.boot, which is a
basic example of PIM config.
> 2) Even all machines support IGMPv3, after I start mrouted, network
> converges to IGMPv2. What I see in tcpdump is that DIP of IGMPv2
> packets isn't in IGMP-CONTROL range (224.0.0.X), but it is set to IP
> of group that it tries to join ( 235.0.0.1 in this case ). This is
> not cast with IGMP leave or IGMPv3 reports which are generated by
> same commands after I kill mrouted and network again converges to
> IGMPv3.
>
These are not regressions at all -- you are seeing entirely standards
conformant behaviour.
The behaviour you report is entirely correct for IGMPv2 control
traffic. Joins are always sent to the group itself. Leaves are sent to
the fast-leave group 224.0.0.2. To the best of my knowledge, this
behaviour has not regressed (at least at layer 3) in the network stack.
I did have a set of automated QEMU and PCS based regression tests
for IGMP. Unfortunately, due to broken serial behaviour, this does not
work with FreeBSD 8-CURRENT, however it has worked with prior versions
of FreeBSD.
I'm sorry, I am very tied up with $DAYJOB at the moment and can't
really be of further help. I can try to answer technical questions in
email about the code, but I can't set aside any free time at the moment
to test or debug.
A good reference for multicast deployment is the book 'Interdomain
Multicast Routing', I found it very helpful. Hopefully this is enough
information to get you started on the right track.
thanks,
BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A6CE6E4.3010106>