Kirill Korotaev <dev@sw.ru> writes:
> Daniel Pittman wrote:
>> Kirill Korotaev <dev@sw.ru> writes:
>> 
>>>Is the same setup working without openvz?  Have you used multicast
>>>before? Multicast is a bit complex to set up, requires support from
>>>routers/switches etc., so this might well be not openvz-related.  But
>>>we setting up this test case right now to check ourselfes.
>>>
>>>Can you please also provide a bit more information about your
>>>configuration like whether you use bridge for veth-eth0 traffic
>>>bridging or routed networking, any configuration options (including
>>>sysctl) you used/changed etc.?
>> 
>> One thing that is worth noting: I found a bug in the ... veth code, I
>> think, where it wouldn't pass a multicast packet through.  The code
>> checked with the 'is_broadcast' flag, for a matching mac, and assumed
>> that anything else was not for this host.
>
> plz make sure you really use and look at the sources of 028stab039 kernel.
> this check in veth_xmit() was fixed in 028stab034 with this commit:
> http://git.openvz.org/?p=linux-2.6.18-openvz;a=commitdiff;h=993241dcdfc8ae22d339e08ed78db6e9760b1d89

I suspected that you would remember. :)

>> Perhaps this is a similar issue?  I can try to dig out the fault report
>> if it helps, but at the time it was simply changing is_broadcast to
>> include an is_multicast test on the Ethernet MAC.
>
> and it started to work?

I never got to test it; that particular job (enable CUPS server browse
announcements in a VE) is still outstanding on my list because it was
low priority.  (sorry)

        Daniel
-- 
Daniel Pittman <daniel@cybersource.com.au>           Phone: 03 9621 2377
Level 4, 10 Queen St, Melbourne             Web: http://www.cyber.com.au
Cybersource: Australia's Leading Linux and Open Source Solutions Company