Hello Miguele,

thanks for your input!

We avoided VXLAN/GRE, we use multi-flat provider network, so each compute node traffic going directly to the provider network without neutron routers in between.

Cheers
Chris

On 2014-11-11 14:21, Miguel Angel wrote:

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@progbau.de>:

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@redhat.com
[mailto:rdo-list-bounces@redhat.com] On
Behalf Of Ihar Hrachyshka
Sent: Monday, November 10, 2014 17:53
To: rdo-list@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'; 'rdo-list@redhat.com' 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@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@redhat.com
[mailto:rdo-list-bounces@redhat.com] On Behalf Of Ihar

Hrachyshka

Sent: Wednesday, October 29, 2014 16:51 To:
rdo-list@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@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list [5]

_______________________________________________ Rdo-list

mailing

list Rdo-list@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list [5]

_______________________________________________ Rdo-list mailing

list

Rdo-list@redhat.com

https://www.redhat.com/mailman/listinfo/rdo-list [5]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUYJkAAAoJEC5aWaUY1u57WZkIAII4LUJWK1dMh1BCM+fnZrJl
wKsNXNs7kgIT4rmStz2UsNo6m+nwnwT+OM36Jigi4N7XZEDLMOvujx27Efd3o6M7
F1Tl3Ld/To4te0Ayvd1CF+xV6jW6u/NegSrPSeT7edosi8cBeFlOdh3F5NN6lyJe
c6LDspyCh8thX71bSlswMK4uHMlX4N856197r3/tuWpDPcRRy9g9n9+wF0avV3pv
j8sf2zZupyR54xJbNdjAbOp/qwBmAEeFG+dapWYg5IvMcfH0g9eatbfGRegEb2XU
F5AA0q/yve36FCG5FSZFVZLApwpIp5i4u2Dl7pygSUT5UdY9rsxVsHQhs8DlSkw=
=DpTW
-----END PGP SIGNATURE-----

_______________________________________________
Rdo-list mailing list
Rdo-list@redhat.com
https://www.redhat.com/mailman/listinfo/rdo-list [5]

_______________________________________________
Rdo-list mailing list
Rdo-list@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