Re: [Rdo-list] Compute Node without firewall (iptables) and Linux bridge

Hi Chris,  If you care a lot about performance, try to make sure that you either: a) Increase MTU on all your tunneling interfaces to avoid fragmentation. or b) work with VLANs instead of VXLAN/GRE. Best regards. Miguel Ángel. --- irc: ajo / mangelajoMiguel Angel Ajo Pelayo +34 636 52 25 69 skype: ajoajoajo 2014-11-11 4:24 GMT+01:00 Chris <contact(a)progbau.de&gt;: > Hello Ihar, > > Thanks for taking care of this! Let's hope the backport for > Icehouse will be > available soon. > We will use it in our setup! > > Cheers > Chris > > -----Original Message----- > From: rdo-list-bounces(a)redhat.com > [mailto:rdo-list-bounces@redhat.com] On > Behalf Of Ihar Hrachyshka > Sent: Monday, November 10, 2014 17:53 > To: rdo-list(a)redhat.com > Subject: Re: [Rdo-list] Compute Node without firewall (iptables) > and Linux > bridge > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hey, > > I've looked closer into the issue. Indeed, neutron does not send > proper VIF > details flags to disable hybrid bridging on nova side. The issue > was fixed > with the following patch in master: > > - - https://review.openstack.org/#/c/104240/ [1] > > I've requested a backport for the patch for Icehouse and Juno: > > - - https://review.openstack.org/133421 [2] (Icehouse) > - - https://review.openstack.org/132759 [3] (Juno) > > We'll need to wait for the patch to be merged in corresponding > branches and > be released to reach RDO repos though. So if you're keen to get the > functionality ASAP, you can apply the patch to your setup in the > meantime. > > Cheers, > /Ihar > > On 30/10/14 13:32, Ihar Hrachyshka wrote: >> Do you use monolithic OVS plugin or ML2 mechanism? If the latter, > then >> the file is not involved, and you should instead try to change > the >> value in: >> >> > /usr/lib/python2.6/site-packages/neutron/plugins/ml2/drivers/mech_open >> vswitch.py >> >>   That said, removal of .py file is not enough to make sure it's > not >> involved since .pyc file is still there and is used when there is > no >> .py counterpart. >> >> On 30/10/14 11:56, Chris wrote: >>> I just found out that the file in the compute node: >>> > /usr/lib/python2.6/site-packages/neutron/plugins/openvswitch/ovs_neut >>> ron_plu >> >>> >> >> gin.py >>> where I edit the portbindings.OVS_HYBRID_PLUG doesn't has any > effect. >>> I even can delete the whole file, the bridge is still being > created >>> and everything works normal. >> >>> Where I can edit the code to prevent the bridge creation? >> >>> Cheers Chris >> >>> -----Original Message----- From: Chris > [mailto:contact@progbau.de] >>> Sent: Thursday, October 30, 2014 >>> 01:28 To: 'Ihar Hrachyshka'; &#39;rdo-list(a)redhat.com&#39; Subject: RE: >>> [Rdo-list] Compute Node without firewall (iptables) and Linux > bridge >> >>> What do you mean with re-plugged? During my testing I always > delete >>> and create new Instances and every time the Linux >>> bridge+interfaces gets deleted and created as well. >> >>> Cheers Chris >> >>> -----Original Message----- From: Ihar Hrachyshka >>> [mailto:ihrachys@redhat.com] Sent: Thursday, October 30, 2014 >>> 00:04 To: Chris; rdo-list(a)redhat.com Subject: Re: [Rdo-list] > Compute >>> Node without firewall (iptables) and Linux bridge >> >>> Have you replugged your instances? VIF objects are persisted in > db, I >>> guess with flags including the one that control whether a bridge >>> should be created. >> >>> Do you still see those bridges created for new instances? >> >>> /Ihar >> >>> On 29/10/14 11:26, Chris wrote: >>>> Hello, >> >>>> 1) we just don't need it, we are using the provider network > which >>>> includes hardware firewalls. 2) We have huge performance > problems >>>> regarding TCP_CRR / TCP_RR. The OpenStack VMs can deal just > half of >>>> TCP connections per second compared to our bare metal > installations. >>>> Throughput (10Gbit NIC) is fine though. Specs VMs and bare > metal are >>>> of course equal (RAM, Cores, etc.) >> >>>> Did a lot of testing regarding the performance issues, it > happens >>>> "after" the both (br-int/br-ex) openvswitches. Upgraded ovs to >>>> version 2.3 just fyi. >> >>>> Cheers Chris >> >> >>>> -----Original Message----- From: rdo-list-bounces(a)redhat.com >>>> [mailto:rdo-list-bounces@redhat.com] On Behalf Of Ihar > Hrachyshka >>>> Sent: Wednesday, October 29, 2014 16:51 To: >>>> rdo-list(a)redhat.com Subject: Re: [Rdo-list] Compute Node > without >>>> firewall (iptables) and Linux bridge >> >>>> On 29/10/14 09:33, Chris wrote: >>>>> Hello >> >> >> >>>>> I?m looking for a way to disable any firewall feature in one > of our >>>>> compute nodes and prevent the creation of the Linux bridge in > the >>>>> data path inside of this compute node. >> >>>> Can you elaborate on reasons to disable it? Of course it sounds > a >>>> bit not optimal, but do you have any performance concerns that > you >>>> try to address in this way? >> >> >>>>> We using the RDO Icehouse release. >> >> >> >>>>> Here is the configuration in the compute node: >> >>>>> #/etc/neutron/plugin.ini >> >>>>> [securitygroup] >> >>>>> #firewall_driver = >>>>> > neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriv >>>>> er >> >>>>>   firewall_driver = neutron.agent.firewall.NoopFirewall >> >>>>> # enable_security_group = True >> >>>>> enable_security_group = False >> >> >> >>>>> #/etc/nova/nova.conf >> >>>>> firewall_driver = nova.virt.firewall.NoopFirewallDriver >> >>>>> #security_group_api = neutron >> >> >> >>>>> #/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini >> >>>>> [securitygroup] >> >>>>> firewall_driver = neutron.agent.firewall.NoopFirewallDriver >> >>>>> enable_security_group = False >> >> >> >>>>> The firewall seems to be disabled but the bridge and the > interfaces >>>>> are being still created. >> >>>>> I found an older post about it: >>>>> > http://lists.openstack.org/pipermail/openstack/2014-May/007079.html > [4] >> >>>>>   But changing ?portbindings.OVS_HYBRID_PLUG" from a > hard-coded >>>>> "True" to "False" didn?t change anything. >> >> >> >>>>> Please advise! >> >> >> >>>>> Cheers >> >>>>> Chris >> >> >> >> >> >>>>> _______________________________________________ Rdo-list > mailing >>>>> list Rdo-list(a)redhat.com >>>>> https://www.redhat.com/mailman/listinfo/rdo-list [5] >> >> >>>> _______________________________________________ Rdo-list > mailing >>>> list Rdo-list(a)redhat.com >>>> https://www.redhat.com/mailman/listinfo/rdo-list [5] >> >> >> >> >> >> _______________________________________________ Rdo-list mailing > list >> Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list [5] >> > > _______________________________________________ > Rdo-list mailing list > Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list [5] > > _______________________________________________ > Rdo-list mailing list > Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list [5] Links: ------ [1] https://review.openstack.org/#/c/104240/ [2] https://review.openstack.org/133421 [3] https://review.openstack.org/132759 [4] http://lists.openstack.org/pipermail/openstack/2014-May/007079.html [5] https://www.redhat.com/mailman/listinfo/rdo-list