[openstack-dev] [neutron]Performance of security group

Édouard Thuleau thuleau at gmail.com
Thu Jun 19 07:11:12 UTC 2014


Do you though about nftables that will replace {ip,ip6,arp,eb}tables?
It also based on the rule set mechanism.
The issue in that proposition, it's only stable since the begin of the year
and on Linux kernel 3.13.
But there lot of pros I don't list here (leverage iptables limitation,
efficient update rule, rule set, standardization of netfilter commands...).

Édouard.


On Thu, Jun 19, 2014 at 8:25 AM, henry hly <henry4hly at gmail.com> wrote:

> we have done some tests, but have different result: the performance is
> nearly the same for empty and 5k rules in iptable, but huge gap between
> enable/disable iptable hook on linux bridge
>
>
> On Thu, Jun 19, 2014 at 11:21 AM, shihanzhang <ayshihanzhang at 126.com>
> wrote:
>
>> Now I have not get accurate test data, but I  can confirm the following
>> points:
>> 1. In compute node, the iptable's chain of a VM is liner, iptable filter
>> it one by one, if a VM in default security group and this default security
>> group have many members, but ipset chain is set, the time ipset filter one
>> and many member is not much difference.
>> 2. when the iptable rule is very large, the probability of  failure  that  iptable-save
>> save the iptable rule  is very large.
>>
>>
>>
>>
>>
>> At 2014-06-19 10:55:56, "Kevin Benton" <blak111 at gmail.com> wrote:
>>
>> This sounds like a good idea to handle some of the performance issues
>> until the ovs firewall can be implemented down the the line.
>> Do you have any performance comparisons?
>> On Jun 18, 2014 7:46 PM, "shihanzhang" <ayshihanzhang at 126.com> wrote:
>>
>>> Hello all,
>>>
>>> Now in neutron, it use iptable implementing security group, but the
>>> performance of this  implementation is very poor, there is a bug:
>>> https://bugs.launchpad.net/neutron/+bug/1302272 to reflect this
>>> problem. In his test, with default security groups(which has remote
>>> security group), beyond 250-300 VMs, there were around 6k Iptable rules on
>>> evry compute node, although his patch can reduce the processing time, but
>>> it don't solve this problem fundamentally. I have commit a BP to solve
>>> this problem:
>>> https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security
>>> <https://blueprints.launchpad.net/neutron/+spec/add-ipset-to-security,>
>>> There are other people interested in this it?
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/af7685ae/attachment.html>


More information about the OpenStack-dev mailing list