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.
ipre...@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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
