Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 09 Dec 2008 12:53:05 +0100
From:      Goran Lowkrantz <glz@hidden-powers.com>
To:        pyunyh@gmail.com
Cc:        stable@freebsd.org
Subject:   Re: Regression in vr - not receiveing multicast
Message-ID:  <80D07D8C17DAC73D69DCDC9A@[172.16.2.124]>
In-Reply-To: <20081209114723.GE33723@cdnetworks.co.kr>
References:  <C882ECF018726481EDA359B3@[172.16.2.124]> <20081209114723.GE33723@cdnetworks.co.kr>

next in thread | previous in thread | raw e-mail | index | archive | help
--On December 9, 2008 20:47:23 +0900 Pyun YongHyeon <pyunyh@gmail.com> 
wrote:

> On Tue, Dec 09, 2008 at 10:40:17AM +0100, Goran Lowkrantz wrote:
>  > Hi,
>  >
>  > in July, vr had this problem and was fixed:
>  > <http://www.FreeBSD.org/cgi/query-pr.cgi?pr=125010>;
>  > <http://www.FreeBSD.org/cgi/query-pr.cgi?pr=125024>;
>  >
>  > 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?

No it has not. I will create such a beast and return with stories.


/glz





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?80D07D8C17DAC73D69DCDC9A>