<p dir="ltr">How does ovs handle tcp flows?  Does it include stateful tracking of tcp -- as your wording below implies -- or does it do stateless inspection of returning tcp packets?  It appears it is the latter.  This isn't the same as providing a stateful ESTABLISHED feature.  Many users may not fully understand the differences.</p>

<p dir="ltr">One of the most basic use cases, which is to ping an outside Ip address from inside a nova instance would not work without connection tracking with the default security groups which don't allow ingress except related and established.  This may surprise many.</p>

<p dir="ltr">Carl</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<div>Hi all,</div>
<div><br>
</div>
In the Neutron weekly meeting today[0], we discussed the ovs-firewall-driver blueprint[1]. Moving forward, OVS features today will give us "80%" of the iptables security groups behavior. Specifically, OVS lacks connection tracking so it won’t have a RELATED
 feature or stateful rules for non-TCP flows. (OVS connection tracking is currently under development, to be released by 2015[2]). To make the “20%" difference more explicit to the operator and end user, we have proposed feature configuration to provide security
 group rules API validation that would validate based on connection tracking ability, for example.
<div><br>
</div>
<div>Several ideas floated up during the chat today, I wanted to expand the discussion to the mailing list for further debate. Some ideas include:</div>
<div><span style="white-space:pre-wrap"></span>- marking ovs-firewall-driver as experimental in Juno</div>
<div><span style="white-space:pre-wrap"></span>- What does it mean to be marked as “experimental”?</div>
<div><span style="white-space:pre-wrap"></span>- performance improvements under a new OVS firewall driver untested so far (vthapar is working on this)</div>
<div><span style="white-space:pre-wrap"></span>- incomplete implementation will cause confusion, educational burden</div>
<div><span style="white-space:pre-wrap"></span>- debugging OVS is new to users compared to debugging old iptables</div>
<div><span style="white-space:pre-wrap"></span>- waiting for upstream OVS to implement (OpenStack K- or even L- cycle)</div>
<div><br>
</div>
<div>In my humble opinion, merging the blueprint for Juno will provide us a viable, more performant security groups implementation than what we have available today.</div>
<div><br>
</div>
<div>Amir</div>
<div><br>
</div>
<div><br>
</div>
<div>[0] <a href="http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-06-02-21.01.log.html</a></div>

<div>[1] <a href="https://review.openstack.org/#/c/89712/" target="_blank">https://review.openstack.org/#/c/89712/</a></div>
<div>[2] <a href="http://openvswitch.org/pipermail/dev/2014-May/040567.html" target="_blank">http://openvswitch.org/pipermail/dev/2014-May/040567.html</a></div>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
<br></div>