yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #87794
[Bug 1952867] Re: [ml2][ovs] allow multiple physical networks map to one physical ovs bridge
On today's drivers meeting we discussed this bug:
https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-12-03-14.01.log.html#l-15
The conclusion was to keep the current 1 Nic - 1 bridge - 1 physnet
mapping/relation.
** Tags added: rfe
** Changed in: neutron
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1952867
Title:
[ml2][ovs] allow multiple physical networks map to one physical ovs
bridge
Status in neutron:
Won't Fix
Bug description:
In real cloud production environment, there are many hosts, which can
access external network, which may not. Some have enough NICs to work
for different networks, while some are lack of NICs.
For instance, an external network, provider:network_type is ``vlan``,
provider:physical_network is ``external``, provider:segmentation_id is
``4000``.
While tenant network, provider:network_type is ``vlan``,
provider:physical_network is ``user``, provider:segmentation_id is
``1000-3000``.
So for neutron's limitation, in one single host, you have to add two
ovs-bridges which are mapping external->br-ex, user->br-usr. And br-ex
adds physical port eth0, br-usr adds eth1.
But, in real world, these vlans can work in same physical nic, and physical hosts may be lack of NICs, which means, Neutron should allow set bridge mapping like this:
{"external": br-vlan, "user": br-vlan}
Then, for those hosts with only one NIC (or one bond NIC), can work
for both physical types of network.
You may say, may be we can set one network with two types of
"provider:physical_network". One single network is currently type
uniq. This will be a bit more complicated than the former solution.
This needs not only neutron-server side DB model changes, but also
agent side change. While the former may only need agent side change
to allow set that mappings.
Any ideas?
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1952867/+subscriptions
References