From owner-freebsd-stable@FreeBSD.ORG Tue Dec 9 12:08:57 2008 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED2FB1065670 for ; Tue, 9 Dec 2008 12:08:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by mx1.freebsd.org (Postfix) with ESMTP id B6C138FC17 for ; Tue, 9 Dec 2008 12:08:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so1319129rvb.4 for ; Tue, 09 Dec 2008 04:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Hte1yJOQQjLt2qk0RVYq10ZU2RRzOkZcjvspLTWBWgg=; b=l/ipDpNuZZjtyJICscns6cTc20XB9LJZISu5PmCZB02L8QlPu0sVSQHT8XLFYXD4+y nGech8EvgCiY5qyK4K/8Dbz6wb2jEj39k8vYqPctBdrGRKFVJRZmTHa/CWmRH3MBnzkL KxqzoxFZMxHTlAD8lJnxuEciwzZLzhpCoCA6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=fj7Oa9WJ7z9zzRslMsJ/ZG3Vs82MauB3JbiKMMnxFUEKaEQoMybopPLcpj5HZdTW0k mqB6XsFdQaXq4/IrSU/AXCOvJoRA6eNHXNPqXhtkp1KmYJ/mqqcUkDY1ZHxch64DwxQh RUP0//9aifpcSerdymPqfXzjBqYziagTVUkxM= Received: by 10.141.67.21 with SMTP id u21mr12103rvk.123.1228823254222; Tue, 09 Dec 2008 03:47:34 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k37sm9818803rvb.1.2008.12.09.03.47.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 09 Dec 2008 03:47:33 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mB9BlPK7035800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 20:47:25 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mB9BlNPh035799; Tue, 9 Dec 2008 20:47:23 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 9 Dec 2008 20:47:23 +0900 From: Pyun YongHyeon To: Goran Lowkrantz Message-ID: <20081209114723.GE33723@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org Subject: Re: Regression in vr - not receiveing multicast X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2008 12:08:58 -0000 On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote: > Hi, > > in July, vr had this problem and was fixed: > > > > but now it's back again! > There was just one bug fix since then and I guess the fix is not related with your issue. > On a system with the following: > 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #3: Thu Oct 16 12:31:04 UTC 2008 > > I have to set all vr interfaces in promisc to get routing info. > > Using Quagga > # pkg_info -Ix uagga > quagga-0.99.10_3 Free RIPv1, RIPv2, OSPFv2, BGP4, IS-IS route software > > on an inner network using RIPv2 > # ifmcstat -i vr0 > vr0: > inet xxx.xxx.xxx.xxx > group 224.0.0.9 > igmpv2 > mcast-macaddr 01:00:5e:00:00:09 refcnt 1 > group 224.0.0.1 > mcast-macaddr 01:00:5e:00:00:01 refcnt 1 > > > On the same box, we have some em devices also and they work without any > problems. > There is fundamental differences between em(4) and vr(4). The vr(4) for VT6105M takes advantage of perfect multicast filtering feature which is not present on all em(4) interface. Perfect multicast filtering can reduce unwanted multicast traffics such that it could save a lot of CPU cycles. The downside is that vr(4) cannot accept multicast frames for a multicast group without joining the multicast group first. For multicast routing purpose I guess 'options MROUTING' kernel option should be enabled to accept all multicast frames. Does your kernel have that option? > Let me know what I can do to help fix this. > > /glz > -- Regards, Pyun YongHyeon