Re: [Bonding-devel] bonding inside a bridge does not work when using arp monitoring

Le 23/03/2011 22:13, Leonardo Borda a écrit :

Hi Nicolas,

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 machines

Hi 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.

cc: netdev and Jiri Pirko, for advices. For the history of the thread, see:

http://sourceforge.net/mailarchive/forum.php?thread_name=1300914794.32252.68.camel%40bordalnx&
forum_name=bonding-devel

br0 -->  br0 in my understanding is an untagged vlan therefore it
provides access to my LAN. So i am able to access that server from my
internal network.
br0-100 and br0-200 ->  Vlans over a bridged interface will allow me to
have many virtual machines in the same vlan on each bridged interface.

I am misunderstanding concepts, maybe?
If you need to do further tests I have a test environment ready for use.

Leonardo

Sat, Mar 26, 2011 at 01:20:22PM CET, nicolas.2p.debian@gmail.com wrote:

Le 23/03/2011 22:13, Leonardo Borda a écrit :

quoted

Hi Nicolas,

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 machines

Hi 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.

cc: netdev and Jiri Pirko, for advices. For the history of the thread, see:

http://sourceforge.net/mailarchive/forum.php?thread_name=1300914794.32252.68.camel%40bordalnx&
forum_name=bonding-devel

quoted

br0 -->  br0 in my understanding is an untagged vlan therefore it
provides access to my LAN. So i am able to access that server from my
internal network.
br0-100 and br0-200 ->  Vlans over a bridged interface will allow me to
have many virtual machines in the same vlan on each bridged interface.

I am misunderstanding concepts, maybe?
If you need to do further tests I have a test environment ready for use.

Leonardo

2011/3/26 Jiri Pirko [off-list ref]:

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 machines

Hi 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.

Best Regards,
Michał Mirosław

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 machines

Hi 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.