From owner-freebsd-net@FreeBSD.ORG Sun Jul 26 23:29:46 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C4451065670; Sun, 26 Jul 2009 23:29:46 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 09C7F8FC14; Sun, 26 Jul 2009 23:29:45 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 76CB33BC2CD; Sun, 26 Jul 2009 19:29:45 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 26 Jul 2009 19:29:45 -0400 X-Sasl-enc: +1BIe/eZTEKYlZHUTR/SXT3fJUtsKGwlje09A+N88E+9 1248650985 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id DBF54CCB8; Sun, 26 Jul 2009 19:29:44 -0400 (EDT) Message-ID: <4A6CE6E4.3010106@incunabulum.net> Date: Mon, 27 Jul 2009 00:29:40 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: iprebeg@freebsd.org References: <20090725130424.GA24589@valeria.zesoi.fer.hr> In-Reply-To: <20090725130424.GA24589@valeria.zesoi.fer.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Wrong multicast destination IP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 23:29:46 -0000 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