[PATCH] VLAN: Do not allow bridge to be the trunk device
From: Zhou Zheng Sheng <zhshzhou@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@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}) params['bridge'] = iface elif netinfo.is_bare_nic(iface) or netinfo.is_bonding(iface): if params.get('vlan_id') is None: -- 1.8.5.3
On 03/17/2014 05:26 AM, zhshzhou@linux.vnet.ibm.com wrote:
From: Zhou Zheng Sheng <zhshzhou@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@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.
params['bridge'] = iface elif netinfo.is_bare_nic(iface) or netinfo.is_bonding(iface): if params.get('vlan_id') is None:
on 2014/03/19 02:16, Aline Manera wrote:
On 03/17/2014 05:26 AM, zhshzhou@linux.vnet.ibm.com wrote:
From: Zhou Zheng Sheng <zhshzhou@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@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@linux.vnet.ibm.com Telephone: 86-10-82454397
on 2014/03/19 11:03, Zhou Zheng Sheng wrote:
on 2014/03/19 02:16, Aline Manera wrote:
On 03/17/2014 05:26 AM, zhshzhou@linux.vnet.ibm.com wrote:
From: Zhou Zheng Sheng <zhshzhou@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@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.
Had a little talk with Yu Xin. We agree that the front-end logic should be like this. When the user selects a bridge interface, the vlan check box should be disabled. When the user selects plain nic, the vlan check box should be enabled.
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@linux.vnet.ibm.com Telephone: 86-10-82454397
participants (3)
-
Aline Manera -
Zhou Zheng Sheng -
zhshzhou＠linux.vnet.ibm.com