From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: "Michał Mirosław" <mirqus@gmail.com>,
"Leonardo Borda" <leonardo.borda@canonical.com>
Cc: Bridge <bridge@lists.linux-foundation.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
bonding-devel@lists.sourceforge.net,
Jiri Pirko <jpirko@redhat.com>
Subject: Re: [Bridge] [Bonding-devel] bonding inside a bridge does not work when using arp monitoring
Date: Sat, 26 Mar 2011 21:32:53 +0100 [thread overview]
Message-ID: <4D8E4D75.1020206@gmail.com> (raw)
In-Reply-To: <AANLkTimkVqHaU=Ye96xK4Zs7XyzcL3Xgh5ouz5m2KXur@mail.gmail.com>
Le 26/03/2011 16:42, Michał Mirosław a écrit :
> 2011/3/26 Jiri Pirko<jpirko@redhat.com>:
>> 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 :
>>>> 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.
WARNING: multiple messages have this Message-ID (diff)
From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: "Michał Mirosław" <mirqus@gmail.com>,
"Leonardo Borda" <leonardo.borda@canonical.com>
Cc: "Jiri Pirko" <jpirko@redhat.com>,
"Nicolas de Pesloüan" <nicolas.2p.debian@free.fr>,
Bridge <bridge@lists.linux-foundation.org>,
bonding-devel@lists.sourceforge.net,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: [Bonding-devel] bonding inside a bridge does not work when using arp monitoring
Date: Sat, 26 Mar 2011 21:32:53 +0100 [thread overview]
Message-ID: <4D8E4D75.1020206@gmail.com> (raw)
In-Reply-To: <AANLkTimkVqHaU=Ye96xK4Zs7XyzcL3Xgh5ouz5m2KXur@mail.gmail.com>
Le 26/03/2011 16:42, Michał Mirosław a écrit :
> 2011/3/26 Jiri Pirko<jpirko@redhat.com>:
>> 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 :
>>>> 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.
next prev parent reply other threads:[~2011-03-26 20:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-16 19:15 [Bridge] bonding inside a bridge does not work when using arp monitoring Leonardo Borda
2011-03-16 20:47 ` [Bridge] [Bonding-devel] " Nicolas de Pesloüan
2011-03-23 21:13 ` Leonardo Borda
2011-03-26 12:20 ` Nicolas de Pesloüan
2011-03-26 12:20 ` Nicolas de Pesloüan
2011-03-26 14:01 ` [Bridge] " Jiri Pirko
2011-03-26 14:01 ` Jiri Pirko
2011-03-26 15:42 ` [Bridge] " Michał Mirosław
2011-03-26 15:42 ` Michał Mirosław
2011-03-26 20:32 ` Nicolas de Pesloüan [this message]
2011-03-26 20:32 ` Nicolas de Pesloüan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D8E4D75.1020206@gmail.com \
--to=nicolas.2p.debian@gmail.com \
--cc=bonding-devel@lists.sourceforge.net \
--cc=bridge@lists.linux-foundation.org \
--cc=jpirko@redhat.com \
--cc=leonardo.borda@canonical.com \
--cc=mirqus@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.