<div dir="ltr">><span style="font-size:12.8px">Is there a difference between "integration_bridge" and </span><span style="font-size:12.8px">"ovs_integration_bridge"? They should match, shouldn't </span><span style="font-size:12.8px">they??</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div>For example:</div><div><br></div><div>eth1 -> br-external</div><div>eth0 -> br-physical</div><div>bridge_mappings = external:br-external,physical:br-physical</div><div><br></div><div>neutron net-create external --router-external=True --provider:physical_network=external --provider:network_type=flat --shared=True</div><div><br></div><div>neutron net-create internal --provider:physical_network=physical --provider:network_type=flat</div><div><br></div><div><br></div><div>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.)</div><div><br></div><div>Also, in your l3_agent.ini, you should leave the '<span style="font-size:12.8px">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.</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">That chart came from:</span></div><div><span style="font-size:12.8px"><a href="http://docs.openstack.org/mitaka/networking-guide/scenario-classic-ovs.html">http://docs.openstack.org/mitaka/networking-guide/scenario-classic-ovs.html</a></span><br></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 28, 2016 at 4:51 PM, Turbo Fredriksson <span dir="ltr"><<a href="mailto:turbo@bayour.com" target="_blank">turbo@bayour.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div>On Jun 28, 2016, at 11:19 PM, Kevin Benton wrote:</div><br><blockquote type="cite"><div dir="ltr"><div><span style="font-size:12.8px">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.</span></div></div></blockquote><div><br></div></span><div>That gave me the indication that maybe I've mixed the two</div><div>bridges up. Which I vaguely thought about that a few days</div><div>ago, but this way was the only way that gave ANY result, so</div><div>I was afraid to meddle with it :). Also, I've read _A LOT_ of</div><div>howtos and examples, and I think not :).</div><div><br></div><div><br></div><div>On the Controller:</div><div><br></div><div><div><div><div>bladeA01b:~# rgrep integration /etc/neutron/ | egrep -v '\.orig|~:|# '</div><div>/etc/neutron/plugins/ml2/openvswitch_agent.ini:integration_bridge = br-provider</div><div>/etc/neutron/dhcp_agent.ini:ovs_integration_bridge = br-provider</div><div>/etc/neutron/lbaas_agent.ini:ovs_integration_bridge = br-provider</div><div>/etc/neutron/l3_agent.ini:ovs_integration_bridge = br-provider</div></div><div><br></div></div><div>On the Compute:</div><div><br></div><div><div><div><div>bladeA03b:~# rgrep integration /etc/neutron/ | egrep -v '\.orig|~:|# '</div><div>/etc/neutron/plugins/ml2/openvswitch_agent.ini:integration_bridge = br-provider</div><div>/etc/neutron/l3_agent.ini:ovs_integration_bridge = br-provider</div><div>/etc/neutron/lbaas_agent.ini:ovs_integration_bridge = br-provider</div><div><br></div></div></div><div>Is there a difference between "integration_bridge" and</div><div>"ovs_integration_bridge"? They should match, shouldn't</div><div>they??</div><div><br></div><div><br></div><div>If I understand it correctly, the term "integration bridge" is the</div><div>one that "<span style="color:rgb(51,51,51);font-family:Lato,sans-serif;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:20px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline!important;float:none">performs VLAN tagging and un-tagging for traffic coming from and</span></div><div><span style="color:rgb(51,51,51);font-family:Lato,sans-serif;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:20px;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);display:inline!important;float:none">to your instances".</span></div></div></div><div><br></div>So if this is the case, then I think I've configured it correctly (?).</div><div><br></div><div><div><div>bladeA01b:~# rgrep br-physical /etc/neutron/ | egrep -v '\.orig|~:|:# '</div><div>/etc/neutron/plugins/ml2/openvswitch_agent.ini:bridge_mappings = external:br-physical</div><div>/etc/neutron/l3_agent.ini:external_network_bridge = br-physical</div><div><br></div></div><div><div><div>bladeA03b:~# rgrep br-physical /etc/neutron/ | egrep -v '\.orig|~:|:# '</div><div>/etc/neutron/l3_agent.ini:external_network_bridge = br-physical</div><div><br></div></div></div><span class=""><blockquote type="cite"><div dir="ltr"><div><span style="font-size:13px">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.</span></div></div></blockquote><div><br></div></span><div>If I understood the config file correctly, your reference to "physnet"</div><div>should be "physical" in my case (because that's what I call my</div><div>physical network in/with "neutron net-create"):</div><div><br></div><div><div><font face="Courier" style="font-size:10px">bladeA01b:~# openstack network show physical</font></div><div><font face="Courier" style="font-size:10px">+---------------------------+--------------------------------------+</font></div><div><font face="Courier" style="font-size:10px">| Field | Value |</font></div><div><font face="Courier" style="font-size:10px">+---------------------------+--------------------------------------+</font></div><div><font face="Courier" style="font-size:10px">| admin_state_up | UP |</font></div><div><font face="Courier" style="font-size:10px">| availability_zone_hints | nova |</font></div><div><font face="Courier" style="font-size:10px">| availability_zones | nova |</font></div><div><font face="Courier" style="font-size:10px">| created_at | 2016-06-26T12:50:02 |</font></div><div><font face="Courier" style="font-size:10px">| description | |</font></div><div><font face="Courier" style="font-size:10px">| id | eadb3df0-3c4b-46e5-afb7-fe5d2ef09328 |</font></div><div><font face="Courier" style="font-size:10px">| ipv4_address_scope | None |</font></div><div><font face="Courier" style="font-size:10px">| ipv6_address_scope | None |</font></div><div><font face="Courier" style="font-size:10px">| is_default | False |</font></div><div><font face="Courier" style="font-size:10px">| mtu | 1500 |</font></div><div><font face="Courier" style="font-size:10px">| name | physical |</font></div><div><font face="Courier" style="font-size:10px">| port_security_enabled | True |</font></div><div><font face="Courier" style="font-size:10px">| project_id | 2985b96e27f048cd92a18db0dd03aa23 |</font></div><div><font face="Courier" style="font-size:10px">| provider:network_type | flat |</font></div><div><font face="Courier" style="font-size:10px">| provider:physical_network | external |</font></div><div><font face="Courier" style="font-size:10px">| provider:segmentation_id | None |</font></div><div><font face="Courier" style="font-size:10px">| router_external | External |</font></div><div><font face="Courier" style="font-size:10px">| shared | True |</font></div><div><font face="Courier" style="font-size:10px">| status | ACTIVE |</font></div><div><font face="Courier" style="font-size:10px">| subnets | 172bdf64-9291-415a-8930-455f1f59453f |</font></div><div><font face="Courier" style="font-size:10px">| tags | [] |</font></div><div><font face="Courier" style="font-size:10px">| updated_at | 2016-06-26T12:50:02 |</font></div><div><font face="Courier" style="font-size:10px">+---------------------------+--------------------------------------+</font></div><div><br></div></div>and I'm mapping that to "br-physical" (which have eth0</div><div>specified as the port).</div><span class=""><div><br><blockquote type="cite"><div dir="ltr"><div><span style="font-size:13px">This pic helps illustrate the two different OVS bridges that the agent will patch together and setup the rules for: <a href="http://docs.openstack.org/mitaka/networking-guide/_images/scenario-classic-ovs-compute2.png" target="_blank">http://docs.openstack.org/mitaka/networking-guide/_images/scenario-classic-ovs-compute2.png</a></span></div></div></blockquote><br></div></span><div>I'm going to have to study that in much more detail, and a lot</div><div>longer to understand it. Where did it come from (what page)</div><div>so I can get a little more substance?</div><div>
--<br>Geologists recently discovered that "earthquakes" are<br>nothing more than Bruce Schneier and Chuck Norris<br>communicating via a roundhouse kick-based cryptosystem.
</div>
<br></div><br>_______________________________________________<br>
Mailing list: <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
Post to : <a href="mailto:openstack@lists.openstack.org">openstack@lists.openstack.org</a><br>
Unsubscribe : <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack</a><br>
<br></blockquote></div><br></div>