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

Chris contact at progbau.de
Wed Oct 29 18:27:51 UTC 2014


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 at redhat.com] 
Sent: Thursday, October 30, 2014 00:04
To: Chris; rdo-list at redhat.com
Subject: Re: [Rdo-list] Compute Node without firewall (iptables) and Linux
bridge

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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 at redhat.com 
> [mailto:rdo-list-bounces at redhat.com] On Behalf Of Ihar Hrachyshka
> Sent: Wednesday, October 29, 2014 16:51 To: rdo-list at 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.OVSHybridIptablesFirewallDriver
>
>>  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
>
>>  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 at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list
> 
> 
> _______________________________________________ Rdo-list mailing list 
> Rdo-list at redhat.com https://www.redhat.com/mailman/listinfo/rdo-list
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUUR4LAAoJEC5aWaUY1u57uQgIAIUWQaBW9HshqnJiUSgsuH/5
9a7p0fZJW2JwhZ00TFq6K4njjPV2xnHKQrae1MbEduOD0SwpcXlzR2dXbOXLx8Mm
swWJim87X4uKNnK2c6MD1WB7wB1d3yVS4SurgS7/DFPyQD1ysHq4FM/XyWSNGcy/
n2GW5TMNokFe6gLXU9r/yDQlsnQsARmK5wnZ63VXHl3S9qnH2gnLPsuZh7X3FUV8
RAsiA9IR2RqiBamS3oGssgP0zIxkNRUwS+muZx//dwRr1NkqZMBNrkdN2t/PZLnD
MBwTX5e8uwJ1Jn5mQB7Wy9n1NdkNTPxZT2R5fBU70UVn8qJbXVzzyif7h4we0zU=
=VUIE
-----END PGP SIGNATURE-----





More information about the dev mailing list