<p dir="ltr">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).</p>
<p dir="ltr">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.</p>
<p dir="ltr">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) </p>
<p dir="ltr">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. </p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Sorry for the resend, I had to subscribe to openstack-dev first,<br>
maybe worth removing the subscribe requirement for outsiders]<br>
<br>
[Copying ovs-dev]<br>
<br>
On 02/13/15 at 01:47pm, Miguel Ángel Ajo wrote:<br>
> Sorry, I forgot about<br>
><br>
> 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),<br>
> the performance should be yet higher, since, as far as I understood, flow rule lookup could be more<br>
> optimized into the kernel megaflows without forwarding and re-starting evaluation due to patch ports.<br>
> (Please correct me here where I’m wrong, I just have very high level view of this).<br>
<br>
Some preliminary numbers were presented at the OVS Fall Conference 2014<br>
which indicate that a pure OVS ACL solution scales better as the<br>
number of rules changes. You can find the number on slide 9 here:<br>
<br>
<a href="http://www.openvswitch.org/support/ovscon2014/17/1030-conntrack_nat.pdf" target="_blank">http://www.openvswitch.org/support/ovscon2014/17/1030-conntrack_nat.pdf</a><br>
<br>
Another obvious advantage is that since we have to go through the OVS<br>
flow table anyway, traversing any additional (linear) ruleset is<br>
likely to have more overhead.<br>
<br>
FYI: Ivar (CCed) is also working on collecting numbers to compare both<br>
architectures to kick of a discussion at the next summit. Ivar, can<br>
you link to the talk proposal?<br>
<br>
> On Friday, 13 de February de 2015 at 13:42, Miguel Ángel Ajo wrote:<br>
><br>
> > I’m working on the following items:<br>
> ><br>
> > 1) Doing Openflow traffic filtering (stateful firewall) based on OVS+CT[1] patch, which may<br>
> > eventually merge. Here I want to build a good amount of benchmarks to be able to compare<br>
> > the current network iptables+LB solution to just openflow.<br>
> ><br>
> > Openflow filtering should be fast, as it’s quite smart at using hashes to match OF rules<br>
> > in the kernel megaflows (thanks Jiri & T.Graf for explaining me this)<br>
> ><br>
> > The only bad part is that we would have to dynamically change more rules based on security<br>
> > group changes (now we do that via ip sets without reloading all the rules).<br>
<br>
Worth pointing out that it is entirely possible to integrate ipset<br>
with OVS in the datapath in case representing ipsets with individual<br>
wildcard flows is not sufficient. I guess we'll know when we have more<br>
numbers.<br>
<br>
> > To do this properly, we may want to make the OVS plugin a real OF controller to be able to<br>
> > push OF rules to the bridge without the need of calling ovs-ofctl on the command line all the time.<br>
<br>
We should synchronize this effort with the OVN effort. There is a lot<br>
of overlap.<br>
<br>
> > 2) Using OVS+OF to do QoS<br>
> ><br>
> > other interesting stuff to look at:<br>
> ><br>
> > 3) Doing routing in OF too, thanks to the NAT capabilities of having OVS+CT<br>
<br>
Just want to point out that this is still WIP with several issues<br>
outstanding. I think everybody agrees that it's tremendously useful<br>
to have, we need to be able to implement it properly. I'll let you<br>
and anybody else interested know as soon as it's ready for testing.<br>
<br>
> > 4) The namespace problem, what kinds of statistics get broken by moving ports into namespaces now?,<br>
> > the short-term fix could be using vets, but “namespaceable” OVS ports would be perfect, yet I understand<br>
> > the change is a big feature.<br>
> ><br>
> > If we had 1 & 3, may be 4 wouldn’t be a problem anymore.<br>
<br>
Implementing VRF in OVS will hide (4) for OpenStack but we should<br>
still fix it in OVS as Ben suggested in the Bugzilla. It looks<br>
feasible to support netns properly in OVS.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>