Open Stack

What is the status of the conntrack integration with respect to
availability in distributions? The lack of state tracking has blocked the
ability for us to get rid of namespaces for the L3 agent (because of SNAT)
and the filtering bridge between the VM and OVS (stateful firewall for
security groups).

It has been known for a long time that these are suboptimal, but our hands
are sort of tied because we don't want to require kernel code changes to
use Neutron.

Are Ubuntu 1404 or CentOS 7 shipping openvswitch kernel modules with
conntrack integration? If not, I don't see a feasible way of eliminating
any of these problems with a pure OVS solution. (faking a stateful firewall
with flag matching doesn't count)

In the short term, we should probably switch back to veth pairs to handle
the namespace issue for the dhcp agent and the L3 agent.
[Sorry for the resend, I had to subscribe to openstack-dev first,
 maybe worth removing the subscribe requirement for outsiders]

[Copying ovs-dev]

On 02/13/15 at 01:47pm, Miguel Ángel Ajo wrote:
> Sorry, I forgot about
>
> 5)  If we put all our OVS/OF bridge logic in just one bridge (instead of
N: br-tun, br-int, br-ex, br-xxx),
>      the performance should be yet higher, since, as far as I understood,
flow rule lookup could be more
>      optimized into the kernel megaflows without forwarding and
re-starting evaluation due to patch ports.
>      (Please correct me here where I’m wrong, I just have very high level
view of this).

Some preliminary numbers were presented at the OVS Fall Conference 2014
which indicate that a pure OVS ACL solution scales better as the
number of rules changes. You can find the number on slide 9 here:

http://www.openvswitch.org/support/ovscon2014/17/1030-conntrack_nat.pdf

Another obvious advantage is that since we have to go through the OVS
flow table anyway, traversing any additional (linear) ruleset is
likely to have more overhead.

FYI: Ivar (CCed) is also working on collecting numbers to compare both
architectures to kick of a discussion at the next summit. Ivar, can
you link to the talk proposal?

> On Friday, 13 de February de 2015 at 13:42, Miguel Ángel Ajo wrote:
>
> > I’m working on the following items:
> >
> > 1) Doing Openflow traffic filtering (stateful firewall) based on
OVS+CT[1] patch, which may
> >     eventually merge. Here I want to build a good amount of benchmarks
to be able to compare
> >     the current network iptables+LB solution to just openflow.
> >
> >      Openflow filtering should be fast, as it’s quite smart at using
hashes to match OF rules
> >      in the kernel megaflows (thanks Jiri & T.Graf for explaining me
this)
> >
> >      The only bad part is that we would have to dynamically change more
rules based on security
> > group changes (now we do that via ip sets without reloading all the
rules).

Worth pointing out that it is entirely possible to integrate ipset
with OVS in the datapath in case representing ipsets with individual
wildcard flows is not sufficient. I guess we'll know when we have more
numbers.

> >       To do this properly, we may want to make the OVS plugin a real OF
controller to be able to
> > push OF rules to the bridge without the need of calling ovs-ofctl on
the command line all the time.

We should synchronize this effort with the OVN effort. There is a lot
of overlap.

> > 2) Using OVS+OF to do QoS
> >
> > other interesting stuff to look at:
> >
> > 3) Doing routing in OF too, thanks to the NAT capabilities of having
OVS+CT

Just want to point out that this is still WIP with several issues
outstanding. I think everybody agrees that it's tremendously useful
to have, we need to be able to implement it properly. I'll let you
and anybody else interested know as soon as it's ready for testing.

> > 4) The namespace problem, what kinds of statistics get broken by moving
ports into namespaces now?,
> >     the short-term fix could be using vets, but “namespaceable” OVS
ports would be perfect, yet I understand
> >     the change is a big feature.
> >
> >     If we had 1 & 3, may be 4 wouldn’t be a problem anymore.

Implementing VRF in OVS will hide (4) for OpenStack but we should
still fix it in OVS as Ben suggested in the Bugzilla. It looks
feasible to support netns properly in OVS.

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
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/20150215/cdf6f47a/attachment.html>