[Kimchi-devel] [PATCH] VLAN: Do not allow bridge to be the trunk device

[Zhou Zheng Sheng]

on 2014/03/19 02:16, Aline Manera wrote:
> On 03/17/2014 05:26 AM, zhshzhou at linux.vnet.ibm.com wrote:
>> From: Zhou Zheng Sheng <zhshzhou at linux.vnet.ibm.com>
>>
>> In Linux networking, a usual VLAN + bridge network setup is as the
>> following.
>>
>> eth0 |-> eth0.10 -> br10 -> vnet101, vnet102, ...
>>       |-> eth0.20 -> br20 -> vnet201, vnet202, ...
>>
>> While the eth0 trunk and VLAN interfaces provide the isolation service,
>> the bridges provide the switching inside the respective VLAN.
>>
>> It's not very useful to have a bridge device as the trunk because the
>> VLAN interfaces on a trunk should be isolated.
>>
>> This patch checks if the front-end submits an invalid setup to use a
>> bridge as the VLAN trunk device and raises exception.
>>
>> Before this patch, if the user creates a bridged network over an
>> existing bridge with VLAN tag set. The back-end just ignores the VLAN
>> and creates an ordinary bridged network. After this patch, the back-end
>> raises an exception with an explanation in this case, so the user knows
>> what's going on and can re-try with correct parameters.
>>
>> Signed-off-by: Zhou Zheng Sheng <zhshzhou at linux.vnet.ibm.com>
>> ---
>>   src/kimchi/i18n.py           | 1 +
>>   src/kimchi/model/networks.py | 2 ++
>>   2 files changed, 3 insertions(+)
>>
>> diff --git a/src/kimchi/i18n.py b/src/kimchi/i18n.py
>> index 589c8cb..b463bd1 100644
>> --- a/src/kimchi/i18n.py
>> +++ b/src/kimchi/i18n.py
>> @@ -182,6 +182,7 @@ messages = {
>>       "KCHNET0016E": _("Specify name and type to create a Network"),
>>       "KCHNET0017E": _("Unable to delete network %(name)s. There are
>> some virtual machines and/or templates linked to this network."),
>>       "KCHNET0018E": _("Unable to deactivate network %(name)s. There
>> are some virtual machines and/or templates linked to this network."),
>> +    "KCHNET0019E": _("Bridge device %(name)s can not be the trunk
>> device of a VLAN."),
>>
>>       "KCHDR0001E": _("Debug report %(name)s does not exist"),
>>       "KCHDR0002E": _("Debug report tool not found in system"),
>> diff --git a/src/kimchi/model/networks.py b/src/kimchi/model/networks.py
>> index 0242156..531f614 100644
>> --- a/src/kimchi/model/networks.py
>> +++ b/src/kimchi/model/networks.py
>> @@ -151,6 +151,8 @@ class NetworksModel(object):
>>               raise MissingParameter("KCHNET0004E", {'name':
>> params['name']})
>>
>>           if netinfo.is_bridge(iface):
>> +            if 'vlan_id' in params:
>> +                raise InvalidParameter('KCHNET0019E', {'name': iface})
> 
> In addition to that we should avoid user to provide wrong information.
> So you should also filter the interfaces properly while sending them to UI.
> 

I agree. The interfaces information fetched from the back-end contains
the type of the interface, such as "bridge" or "nic". The front-end can
filter the "bridge" interfaces when the user click "enable vlan".

I think a sane behavior may be like this. When the user ticks the
"enable vlan" check box, all "bridge" interfaces should be removed from
the option box. When the user empties the check box, "bridge" interfaces
go back. A special case is that if all interfaces a "bridge" ones, we
should disable the vlan check input box.

I'm adding the author of the kimchi.network.js and see if he can kindly
share some ideas.
>>               params['bridge'] = iface
>>           elif netinfo.is_bare_nic(iface) or netinfo.is_bonding(iface):
>>               if params.get('vlan_id') is None:
> 


-- 
Thanks and best regards!

Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou at linux.vnet.ibm.com
Telephone: 86-10-82454397