<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">Hi all,</p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px"><br></p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">A recent critical issue that has come up that has compelled me to propose reconsidering our default and OVS based network configuration examples :   </p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px"><a href="https://bugs.launchpad.net/tripleo/+bug/1640812">https://bugs.launchpad.net/tripleo/+bug/1640812</a> - Network connectivity lost on node reboot</p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">I've been thinking about it for awhile, but you could say this bug was the "last straw". </p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">While the precise root cause of this issue is still in question, part of the problem is that the overcloud nodes communicate with the undercloud and each other through an OVS bridge which is also used by the overcloud neutron service for external network traffic. For several valid reasons, neutron sets the OVS bridge fail_mode to secure (details in respective man pages, etc, etc). This mode is stored persistently so when the system is rebooted, the bridge is recreated with the secure fail_mode in place, blocking network traffic - including DHCP - until something comes along and starts setting up flow rules to allow traffic to flow.  Without an IP address, the node is effectively "unplugged". For some reason this isn't happening 100% of the time on the current version of CentOS (7.2), but seems to be pretty much 100% on RHEL 7.3. </p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">It raises the question if it is valid for neutron to modify an OVS bridge that it *did not create* in a fundamental way like this. If so, it implies a contract between the deployer and neutron that the deployer can make "no assumptions" about what will happen with the bridge once neutron has been configured to access it. If this implied contract is valid, required and acceptable, then bridges used for neutron should not be used for anything else. The implications with respect to tripleo is that we should reconsider how we use OVS bridges for network configuration in the overcloud. For example, in single NIC situations, instead of having:<br></p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">(triple configured)<br>- eth0<br>  - br-ex -used for control plane access, internal api, management, external, etc. also neutron is configured to use this for the external traffic e.g. dataplane in our defaults, which is why the fail_mode gets altered</p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">(neutron configured)</p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">- br-int<br>- br-tun</p><p id="gmail-yui_3_10_3_1_1478787875964_2870" style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">To something like:<br>(triple configured)<br>- eth0<br> - br-ctl - used as br-ex is currently used except neutron knows nothing about it.<br>- br-ex -patched to br-ctl - ostensibly for external traffic and this is what neutron in the overcloud is configured to use<br>(neutron configured)<br>- br-int<br>- br-tun</p><p id="gmail-yui_3_10_3_1_1478787875964_2870" style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">(In all cases, neutron configures patches, etc. between bridges *it knows about* as needed. That is, in the second case, tripleo would configure the patch between br-ctl and br-ex)<br></p><p id="gmail-yui_3_10_3_1_1478787875964_2878" style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">At the cost of an extra bridge (ovs bridge to ovs bridge with patch ports is allegedly cheap btw) we get:<br> 1. an independently configured bridge for overcloud traffic insulates non-tenant node traffic against changes to neutron, including upgrades, neutron bugs, etc.<br> 2. insulates neutron from changes to the underlying network that it doesn't "care" about.<br> 3. In OVS only environments, the difference between a single nic environment and one where there is a dedicated nic for external traffic is, instead of a patch port from br-ctl to br-ex, it is directly connected to the nic for the external traffic. </p><p id="gmail-yui_3_10_3_1_1478787875964_2878" style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">Even without the issue that instigated this message, I think that this is a change worth considering. <br></p><p id="gmail-yui_3_10_3_1_1478787875964_2878" style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px"><br></p><p id="gmail-yui_3_10_3_1_1478787875964_2878" style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">Cheers,</p><p id="gmail-yui_3_10_3_1_1478787875964_2878" style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px"><br></p><p id="gmail-yui_3_10_3_1_1478787875964_2878" style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">Brent</p></div></div>