Uwe Sauter <uwe.sauter...@gmail.com> wrote on 04/27/2015 10:54:15 AM:
> Am 27.04.2015 um 16:36 schrieb Mike Spreitzer: > > Uwe Sauter <uwe.sauter...@gmail.com> wrote on 04/25/2015 04:17:35 PM: > > > >> Or instead of using Linux bridges you could use a manually created > >> OpenVSwitch bridge. This allows you to add "internal" > >> ports that could be used by Neutron like any other interface. > >> > >> - Create OVS bridge > >> - Add your external interface to OVS bridge > >> * If your external connection supports/needs VLANs, configure > >> external interface as trunk > >> - Add any number of internal interfaces to OVS bridge > >> * Tag each interface with its VLAN ID, if needed > >> - Configure Neutron to use one internal interface for each subnet > >> you'd like to use (no VLAN configuration required as > >> this happenes outside of Neutron) > >> > >> Regards, > >> > >> Uwe > >> > >> Am 25.04.2015 um 21:41 schrieb George Shuklin: > >> > Can you put them to different vlans? After that it would be > very easy task. > >> > > >> > If not, AFAIK, neutron does not allow this. > >> > > >> > Or you can trick it thinking it is (are) separate networks. > >> > > >> > Create brige (br-join), plug eth to it. > >> > Create to fake external bridges (br-ex1, br-ex2). Join them > >> together to br-join by patch links > >> > (http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with- > >> patch-ports/) > >> > > >> > Instruct neutron like there is two external networks: one on br- > >> ex1, second on br-ex2. > >> > > >> > But be alert that this not very stable configuration, you need to > >> maintain it by yourself. > >> > > >> > On 04/25/2015 10:13 PM, Mike Spreitzer wrote: > >> >> Is there a way to create multiple external networks from > >> Neutron's point of view, where both of those networks are > >> >> accessed through the same host NIC? Obviously those networks > >> would be using different subnets. I need this sort of > >> >> thing because the two subnets are treated differently by the > >> stuff outside of OpenStack, so I need a way that a tenant > >> >> can get a floating IP of the sort he wants. Since Neutron > >> equates floating IP allocation pools with external > >> >> networks, I need two external networks. > >> >> > >> >> I found, for example, http://www.marcoberube.com/archives/248--- > >> which describes how to have multiple external > >> >> networks but uses a distinct host network interface for each one. > > > > Now that I have found my bridge_mappings configuration statement, > I can return to thinking about what you said. It sounds very > > similar to what George said --- it is just that you suggest an OVS > switch in place of George's br-join (which I had assumed was > > also an OVS switch, since it is named like the others). Do I have > this right? > > > > Thanks, > > Mike > > > > Mike, > > > if I understood Georges answer correctly he suggested one bridge > (br-join, either OVS or linux bridge) to connect other bridges > via patch links, one for each external network you'd like to create. > These second level bridges are then used for the Neutron > configuration: > > br-ext1 -> Neutron > / > patch-link > / > ethX –br-join > \ > patch-link > \ > br-ext2 -> Neutron > > > > I suggested to use an OVS bridge because there it'd be possible to > stay away from the performance-wise worse patch-links and Linux > bridges and use "internal" interfaces to connect to Neutron directly > – which on second thought won't work if Neutron expects a > bridge in that place. > > What I suggested later on is that you probably don't need any second > level bridge at all. Just create a second/third external > network with appropriate CIDR. As long as those networks are > externally connected to your interface (and thus the bridge) you > should be good to go. In parallel emails we have established that I have to do what you have drawn. I need to do that the node(s) that run L3 agents. Do I need to modify the bridge_mappings, flat_networks, or network_vlan_ranges configuration statement on the other nodes (compute hosts)? Thanks, Mike
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators