[Openstack] Networking - next step?

Kevin Benton kevin at benton.pub
Wed Jun 29 15:10:44 UTC 2016


>These three sentences put together means that I should remove both ethernet
interfaces from my two bridge interfaces!

No, just remove the interfaces from whichever one is your integration
bridge. There can be interfaces in the other OVS bridges that you put in
bridge_mappings. So as I understand it, you intend 'br-physical' to be the
equivalent of 'br-ex' in the example scenario, in which case its fine to
have an interface in it and you should have a bridge_mapping entry for it
in the L2 agent.

>In my case, that's "br-physical" and "eth0". Which I have done.
>In my setup, "br-provider" is the integration bridge..

So br-physical should have a real interface in it and br-provider should
not have any.

>Well, I'm not sure. In EVERY image, howto and example I've seen, including
>the one your linked to yesterday, there's always two networks: The
administration
>network and the (isolated) "where VMs reside" network..

Neutron supports an arbitrary number of networks so it depends on what you
want. Each Neutron network corresponds to a particular unique (physnet +
encapsulation) or an overlay encapsulation (e.g. VXLAN VNI).

Let's assume you just want two networks to start. Your external network is
using the br-physical bridge with flat segmentation (a.k.a. untagged). So
your VM network needs to either have another bridge with a different
interface or it needs to use another encapsulation (e.g. VLAN or VXLAN) to
keep the traffic between the two isolated.

On Wed, Jun 29, 2016 at 4:18 AM, Turbo Fredriksson <turbo at bayour.com> wrote:

> On Jun 29, 2016, at 12:28 AM, Kevin Benton wrote:
>
> > you will also need to change that in the
> > nova compute config with the 'linuxnet_ovs_integration_bridge' setting
>
> Ah, perfect! Thanx.
>
> > Whatever your integration bridge is, it should *not* have any physical
> > interfaces plugged into it directly.
>
> Oh. Oh?
>
> > (In your original ovs-vsctl output it shows that eth0 is a member of
> > 'br-provider' and eth1 is a member of 'br-physical'.
>
> > So you need to remove eth1 from that if 'br-provider' is the
> > integration bridge.)
>
> These three sentences put together means that I should remove both
> ethernet interfaces from my two bridge interfaces!
>
> And that isn't what the pages on os.org say:
>
> http://docs.openstack.org/admin-guide/networking_config-agents.html
>
>   To uplink the node that runs neutron-l3-agent to the external
>   network, create a bridge named br-ex and attach the NIC for the
>   external network to this bridge.
>
>   For example, with Open vSwitch and NIC eth1 connected to the
>   external network, run:
>
>     # ovs-vsctl add-br br-ex
>     # ovs-vsctl add-port br-ex eth1
>
> In my case, that's "br-physical" and "eth0". Which I have done.
>
> In my setup, "br-provider" is the integration bridge..
>
> > In your topology, did you want two networks to map to two separate real
> > networks on different interfaces? If so, create two physnets for them,
> each
> > with their own bridge_mapping.
>
> Well, I'm not sure. In EVERY image, howto and example I've seen, including
> the one your linked to yesterday, there's always two networks: The
> administration
> network and the (isolated) "where VMs reside" network..
>
> In my case, eth1/br-physical and eth0/br-provider respectively.
>
> Eth0 does not have an uplink anywhere, and is only switched between the
> host, traffic can't go any where else.
>
>
> So in my understanding, traffic should go like this:
>
>   VM/eth0 -> Compute/eth1 -> Control/eth1 -> Control/eth0 -> Site FW/GW
>
> Or, I guess, it could go out via eth0 on the Compute node directly. But
> eventually, one day, perhaps, I'll break out Neutron to it's own, separate
> physical machine, so I'd like to work that possibility into the design
> right now. Which I thought I did :)
>
> > Also, in your l3_agent.ini, you should leave the
> 'external_network_bridge'
> > option explicitly set to a blank value. That will let the L2 agent do all
> > of the wiring and will result in the correct operational status for your
> > router gateway ports.
>
> Ok, thanx.
>
> > That chart came from:
> >
> http://docs.openstack.org/mitaka/networking-guide/scenario-classic-ovs.html
>
> That doesn't talk about creating any bridges either.
> --
> Ehhhhm - The battle cry of the cronical masturbater.
> - Charlie Harper
>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160629/044b17f8/attachment.html>


More information about the Openstack mailing list