[rdo-dev] [rdo-users] [tripleo] Neutron external bridge setting

Slawomir Kaplonski skaplons at redhat.com
Thu Sep 20 07:17:54 UTC 2018


Hi,

> Wiadomość napisana przez Dan Sneddon <dsneddon at redhat.com> w dniu 20.09.2018, o godz. 00:57:
> 
> 
> 
> On Wed, Sep 19, 2018 at 10:13 AM Cody <codeology.lab at gmail.com> wrote:
> Hi there,
> 
> I sent a similar question below to OpenStack ML last week, but haven't
> got any answers yet. Since it is a TripleO related question, I am
> reposting it here and hope for a better luck.
> 
> According to the TripleO documentation [1], the default Neutron
> external bridge (NeutronExternalNetworkBridge) is left empty. This
> seems to let the physical interface map to br-int instead of br-ex,
> and (somehow) use more CPU power as oppose to using br-ex directly. I
> don't get it... Does it mean the external traffic would go directly
> from br-int to the physical interface without using br-ex? Could
> someone walk me through the traffic flow in this case? I really
> appreciate your help!
> 
> [1] https://docs.openstack.org/tripleo-docs/latest/install/advanced_deployment/network_isolation.html#using-the-native-vlan-for-floating-ips
> 
> 
> Regards,
> Cody
> _______________________________________________
> users mailing list
> users at lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/users
> 
> To unsubscribe: users-unsubscribe at lists.rdoproject.org
> 
> If you set the Neutron external bridge explicitly (such as to "br-ex"), then only that bridge can be used for floating IPs and SNAT. This is because the router net namespace is attached directly to the external bridge, rather than to br-int. If you set this to a blank string, then everything will be tied to br-int, and you can have multiple external bridges, or multiple provider external networks on the same bridge. This is useful for separating floating IP pools for different tenants, or for other fine-grained traffic control.
> 
> While it is true that setting this to a blank string means one extra bridge hop in the data path (from the router namespace to br-int), this is no longer such an issue as the OVS code is significantly more efficient than it used to be. Keep in mind that traffic will traverse several bridges before hitting the VM even in the case of using an explicit external bridge, so it's not like the one extra bridge hop doubles OVS CPU utilization, it's just a small fractional increase. I have always recommend that a blank string be used in all cases, as this leaves flexibility to add bridge interfaces in the future, and has an overall small impact on CPU utilization. In fact, setting an explicit external bridge was deprecated, and if it hasn't been removed by now I'm surprised.

It’s not removed yet but there is patch proposed to remove it finally in Stein cycle: https://review.openstack.org/#/c/567369/
I hope it will be removed soon :)

> 
> https://bugs.launchpad.net/neutron/+bug/1511578
> 
> -- 
> Dan Sneddon         |  Senior Principal OpenStack Engineer
> dsneddon at redhat.com |  redhat.com/openstack
> dsneddon:irc        |  @dxs:twitter
> _______________________________________________
> dev mailing list
> dev at lists.rdoproject.org
> http://lists.rdoproject.org/mailman/listinfo/dev
> 
> To unsubscribe: dev-unsubscribe at lists.rdoproject.org

— 
Slawek Kaplonski
Senior software engineer
Red Hat



More information about the dev mailing list