Re: [Bonding-devel] bonding inside a bridge does not work when using arp monitoring
From: Nicolas de Pesloüan <hidden>
Date: 2011-03-26 20:32:58
Also in:
bridge
Le 26/03/2011 16:42, Michał Mirosław a écrit :
2011/3/26 Jiri Pirko[off-list ref]:quoted
Sat, Mar 26, 2011 at 01:20:22PM CET, nicolas.2p.debian@gmail.com wrote:quoted
Le 23/03/2011 22:13, Leonardo Borda a écrit :quoted
Thank you for answering my question. Actually this is what I want to achieve: eth0----+ +----bond0.100----br0-100---{+virtual machines | | +----bond0----+----br0---(LAN) | | eth1----+ +----bond0.200----br0-200---{+virtual machinesHi Leonardo, I'm not sure recent kernels allow for a given interface to be a port for a bridge and the base interface for vlan interfaces at the same time. This might be particularly true for 2.6.38 or 2.6.38+, because of the new rx_handler usage.This topology is not legit and should/will be prohibited. Only consider that you have + br0.100 device on top of br0. Where should the packet go? I suggest to consider topology change.It should be possible to have bridge for untagged (or 802.1p only) packets independent of 802.1q tagged packets. I wonder if tag 0 devices should be expanded to have a flag that will enable handling untagged packets by it.
Isn't the BROUTING chain of the broute table of ebtables designed exactly for that?
I think DROPing in this chain should allow delivery to VLAN:
In br_input.c :
rhook = rcu_dereference(br_should_route_hook);
if (rhook) {
if ((*rhook)(skb)) {
*pskb = skb;
return RX_HANDLER_PASS;
}
RX_HANDLER_PASS causes the skb to be normally delivered in __netif_receive_skb.
Leonardo, would you please try to DROP vlan tagged packets in the BROUTING chain of the broute table
of ebtables?
Nicolas.