Thread (29 messages) 29 messages, 7 authors, 2011-10-30

Re: [net-next PATCH] net: allow vlan traffic to be received under bond

From: Jesse Gross <hidden>
Date: 2011-10-14 00:22:23

2011/10/13 John Fastabend [off-list ref]:
On 10/13/2011 8:59 AM, Hans Schillström wrote:
quoted
Thu, Oct 13, 2011 at 05:04:34PM CEST, mbizon@freebox.fr wrote:
quoted
quoted
On Tue, 2011-10-11 at 00:37 +0200, Jiri Pirko wrote:
quoted
Hmm, I must look at this again tomorrow but I have strong feeling this
will break some some scenario including vlan-bridge-macvlan.
unless I'm mistaken, today's behaviour:

# vconfig add eth0 100
# brctl addbr br0
# brctl addif br0 eth0

=> eth0.100 gets no more packets, br0.100 is to be used

after the patch won't we get the opposite ?
Looks like it. The question is what is the correct behaviour...
I think this it become correct now, you should not destroy lover level if possible.
I.e. as John wrote "it's not an unexpected behaviour"

Consider adding a bridge to a vlan like this

vconfig add eth0 100
brctl addbr br1
brctl addif br1 eth0.100

If you later add a bridge (or bond) should the previous added bridge still work ?
Yes I think so, for me it's the expected behaviour.

brctl addbr br0
brctl addif br0 eth0

Regards
Hans
Sorry I'm not entirely sure I followed the above two posts. Note
this patch restores behavior that has existed for most of the
2.6.x kernels. In the 3.x kernels VLAN100 is dropped in the
schematic below (assuming eth0 is active), I think this is
incorrect.
Actually, for most of 2.6.x the behavior was somewhat
non-deterministic since it depended on kernel version and the NIC.  As
a result, I think we can safely say that this wasn't a particularly
firm interface that we have to be wedded to.  Based on overwhelming
feedback, I think the interface in this patch is the preferred one and
what we should stabilize on.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help