Open Stack

>Is there a difference between "integration_bridge" and "ovs_integration_bridge"?
They should match, shouldn't they??

Yes, 'ovs_integration_bridge' is for non-OVS things like the L3 agent, DHCP
agent, and Nova compute to refer to an OVS setting. Since you are using a
non-default integration bridge, you will also need to change that in the
nova compute config with the 'linuxnet_ovs_integration_bridge' setting,
otherwise Nova will plug the instances into br-int.

Whatever your integration bridge is, it should *not* have any physical
interfaces plugged into it directly. (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.)

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.

For example:

eth1 -> br-external
eth0 -> br-physical
bridge_mappings = external:br-external,physical:br-physical

neutron net-create external --router-external=True
--provider:physical_network=external --provider:network_type=flat
--shared=True

neutron net-create internal --provider:physical_network=physical
--provider:network_type=flat


That would give you two different networks, one of which is going to
connect to eth1, and one to eth0. (Note that neither of those are the
integration bridge. Everything plugs into the integration bridge and is
then wired up with patch ports to the correct bridges by the agent.)

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.

That chart came from:
http://docs.openstack.org/mitaka/networking-guide/scenario-classic-ovs.html


On Tue, Jun 28, 2016 at 4:51 PM, Turbo Fredriksson <turbo at bayour.com> wrote:

> On Jun 28, 2016, at 11:19 PM, Kevin Benton wrote:
>
> It sounds like the agents may be plugging their ports into the wrong OVS
> bridge. It sounds like you have br-physical configured as your integration
> bridge, but you also have eth0 directly plugged into that bridge as well.
> That's not going to work quite correctly because the OVS agent expects to
> have to wire between the integration bridge and the bridge with the
> physical ports.
>
>
> That gave me the indication that maybe I've mixed the two
> bridges up. Which I vaguely thought about that a few days
> ago, but this way was the only way that gave ANY result, so
> I was afraid to meddle with it :). Also, I've read _A LOT_ of
> howtos and examples, and I think not :).
>
>
> On the Controller:
>
> bladeA01b:~# rgrep  integration  /etc/neutron/ | egrep -v '\.orig|~:|# '
> /etc/neutron/plugins/ml2/openvswitch_agent.ini:integration_bridge =
> br-provider
> /etc/neutron/dhcp_agent.ini:ovs_integration_bridge = br-provider
> /etc/neutron/lbaas_agent.ini:ovs_integration_bridge = br-provider
> /etc/neutron/l3_agent.ini:ovs_integration_bridge = br-provider
>
> On the Compute:
>
> bladeA03b:~# rgrep  integration  /etc/neutron/ | egrep -v '\.orig|~:|# '
> /etc/neutron/plugins/ml2/openvswitch_agent.ini:integration_bridge =
> br-provider
> /etc/neutron/l3_agent.ini:ovs_integration_bridge = br-provider
> /etc/neutron/lbaas_agent.ini:ovs_integration_bridge = br-provider
>
> Is there a difference between "integration_bridge" and
> "ovs_integration_bridge"? They should match, shouldn't
> they??
>
>
> If I understand it correctly, the term "integration bridge" is the
> one that "performs VLAN tagging and un-tagging for traffic coming from and
> to your instances".
>
> So if this is the case, then I think I've configured it correctly (?).
>
> bladeA01b:~# rgrep br-physical /etc/neutron/ | egrep -v '\.orig|~:|:# '
> /etc/neutron/plugins/ml2/openvswitch_agent.ini:bridge_mappings =
> external:br-physical
> /etc/neutron/l3_agent.ini:external_network_bridge = br-physical
>
> bladeA03b:~# rgrep br-physical /etc/neutron/ | egrep -v '\.orig|~:|:# '
> /etc/neutron/l3_agent.ini:external_network_bridge = br-physical
>
> So I would leave the integration bridge to the default of 'br-int', then
> define a bridge_mapping in the OVS agent config that maps a 'physnet' to
> br-physical. Then when you create the network, it should be of the 'flat'
> type with a physical network that matches the physnet in the
> bridge_mapping. That's the part that tells the agent to wire ports on that
> network to that particular OVS bridge without VLAN tags.
>
>
> If I understood the config file correctly, your reference to "physnet"
> should be "physical" in my case (because that's what I call my
> physical network in/with "neutron net-create"):
>
> bladeA01b:~# openstack network show physical
> +---------------------------+--------------------------------------+
> | Field                     | Value                                |
> +---------------------------+--------------------------------------+
> | admin_state_up            | UP                                   |
> | availability_zone_hints   | nova                                 |
> | availability_zones        | nova                                 |
> | created_at                | 2016-06-26T12:50:02                  |
> | description               |                                      |
> | id                        | eadb3df0-3c4b-46e5-afb7-fe5d2ef09328 |
> | ipv4_address_scope        | None                                 |
> | ipv6_address_scope        | None                                 |
> | is_default                | False                                |
> | mtu                       | 1500                                 |
> | name                      | physical                             |
> | port_security_enabled     | True                                 |
> | project_id                | 2985b96e27f048cd92a18db0dd03aa23     |
> | provider:network_type     | flat                                 |
> | provider:physical_network | external                             |
> | provider:segmentation_id  | None                                 |
> | router_external           | External                             |
> | shared                    | True                                 |
> | status                    | ACTIVE                               |
> | subnets                   | 172bdf64-9291-415a-8930-455f1f59453f |
> | tags                      | []                                   |
> | updated_at                | 2016-06-26T12:50:02                  |
> +---------------------------+--------------------------------------+
>
> and I'm mapping that to "br-physical" (which have eth0
> specified as the port).
>
> This pic helps illustrate the two different OVS bridges that the agent
> will patch together and setup the rules for:
> http://docs.openstack.org/mitaka/networking-guide/_images/scenario-classic-ovs-compute2.png
>
>
> I'm going to have to study that in much more detail, and a lot
> longer to understand it. Where did it come from (what page)
> so I can get a little more substance?
> --
> Geologists recently discovered that "earthquakes" are
> nothing more than Bruce Schneier and Chuck Norris
> communicating via a roundhouse kick-based cryptosystem.
>
>
> _______________________________________________
> 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/20160628/e0fe4797/attachment.html>