[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BANLkTinPQSB_Jc5xGL=pSLekun4LZjbGfA@mail.gmail.com>
Date: Fri, 17 Jun 2011 09:47:27 -0700
From: Jesse Gross <jesse@...ira.com>
To: Dominique Martinet <rnfhrznznaq.tf@...lue.notk.org>
Cc: netdev@...r.kernel.org
Subject: Re: bnx2 vlan issue
On Thu, Jun 16, 2011 at 11:10 PM, Dominique Martinet
<rnfhrznznaq.tf@...lue.notk.org> wrote:
> Hi,
>
> Jesse Gross <jesse <at> nicira.com> writes:
>> On Thu, Mar 24, 2011 at 5:26 PM, Seblu <seblu <at> seblu.net> wrote:
>> > Maybe i was not enough clear. It seems to me that new behaviour, with
>> > vlan on top of bridge rather than above interface in bridge is not
>> > functional.
>> > In other words, i cannot use vlan and bridge together in 2.6.38 (with
>> > e1000e).
>>
>> Sorry, I misunderstood what you were saying before. Can you try and
>> see where the packets are getting lost or improperly handled by
>> running tcpdump on the various interfaces? For example, check that
>> packets are coming in with tags on the physical interfaces, have tags
>> on the bridge interface, no tag on the vlan interface, etc.
>
> I think I ran into the same problem, and my workaround for this was to add
> a vlan do the bridge and then add the vlan'ed bridge to another bridge, i.e.
> (since I can't draw, commands will be better :P)
>
> brctl addbr br0
> brctl addif br0 eth0
> ip link add link br0 name br0.42 type vlan id 42
> ip link set br0.42 up
>
> brctl addbr br_42
> brctl addif br_42 br0.42
>
> and then I could put VMs in br_42 which got network "as expected"
> before, I used to have br_42 with eth0.42 in it, so it is just one more
> step..
> What bothers me is that I also want to put VMs in br0, and it does work,
> but this bridge also sees all the tagged data - isn't there a way to just
> "pick" the untagged network?
You are bridging the VMs to the physical network, so it is expected
that they will see all traffic. That said, you could use ebtables to
only take vlan 0, similar to if you only wanted them to see packets to
their MAC address and not flooding.
> My other question is that I'm not certain if that's the expected way to
> use the new behaviour, if not I wouldn't mind light shining from above :)
Yes, that's the intended behavior and correct usage.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists