On Sat, Nov 30, 2013 at 6:32 PM, Édouard Thuleau <thul...@gmail.com> wrote:
> And what do you think about the performance issue I talked ? > Do you have any thought to improve wildcarding to use megaflow feature ? > I have invested a little further, here is my environment X1 (10.0.5.1) <---> OVS BR <---> X2 (10.0.5.2) I have set up several flows to make port 5000 open on X2: $ sudo ovs-ofctl dump-flows br NXST_FLOW reply (xid=0x4): cookie=0x0, duration=49.672s, table=0, n_packets=7, n_bytes=496, idle_age=6, priority=256,tcp,nw_src=10.0.5.2,tp_src=5000 actions=NORMAL cookie=0x0, duration=29.854s, table=0, n_packets=8, n_bytes=562, idle_age=6, priority=256,tcp,nw_dst=10.0.5.2,tp_dst=5000 actions=NORMAL cookie=0x0, duration=2014.523s, table=0, n_packets=96, n_bytes=4032, idle_age=35, priority=512,arp actions=NORMAL cookie=0x0, duration=2006.462s, table=0, n_packets=51, n_bytes=4283, idle_age=40, priority=0 actions=drop and here is the kernel flows after 2 connections created: $ sudo ovs-dpctl dump-flows skb_priority(0),in_port(8),eth(src=2e:19:44:50:9d:17,dst=ae:7f:28:4f:14:ec),eth_type(0x0800),ipv4(src= 10.0.5.1/255.255.255.255,dst=10.0.5.2/255.255.255.255,proto=6/0xff,tos=0/0,ttl=64/0,frag=no/0xff),tcp(src=35789,dst=5000), packets:1, bytes:66, used:2.892s, flags:., actions:10 skb_priority(0),in_port(8),eth(src=2e:19:44:50:9d:17,dst=ae:7f:28:4f:14:ec),eth_type(0x0800),ipv4(src= 10.0.5.1/255.255.255.255,dst=10.0.5.2/255.255.255.255,proto=6/0xff,tos=0/0,ttl=64/0,frag=no/0xff),tcp(src=35775,dst=5000), packets:0, bytes:0, used:never, actions:10 skb_priority(0),in_port(10),eth(src=ae:7f:28:4f:14:ec,dst=2e:19:44:50:9d:17),eth_type(0x0800),ipv4(src= 10.0.5.2/255.255.255.255,dst=10.0.5.1/0.0.0.0,proto=6/0xff,tos=0/0,ttl=64/0,frag=no/0xff),tcp(src=5000/0xffff,dst=35789/0), packets:1, bytes:78, used:1.344s, flags:P., actions:8 conclusion: mac-src,mac-dst can't be wildcard, because they are used by l2 bridging and mac learning. ip-src and port-src can't be wildcard only ip-dst and port-dst can be wildcard I don't know why ip-src and port-src can't be wildcard, maybe I just hit an ovs bug. > Édouard. > > On Fri, Nov 29, 2013 at 1:11 PM, Zang MingJie <zealot0...@gmail.com> > wrote: > > On Fri, Nov 29, 2013 at 2:25 PM, Jian Wen <jian....@canonical.com> > wrote: > >> I don't think we can implement a stateful firewall[1] now. > > > > I don't think we need a stateful firewall, a stateless one should work > > well. If the stateful conntrack is completed in the future, we can > > also take benefit from it. > > > >> > >> Once connection tracking capability[2] is added to the Linux OVS, we > >> could start to implement the ovs-firewall-driver blueprint. > >> > >> [1] http://en.wikipedia.org/wiki/Stateful_firewall > >> [2] > >> > http://wiki.xenproject.org/wiki/Xen_Development_Projects#Add_connection_tracking_capability_to_the_Linux_OVS > >> > >> > >> On Tue, Nov 26, 2013 at 2:23 AM, Mike Wilson <geekinu...@gmail.com> > wrote: > >>> > >>> Adding Jun to this thread since gmail is failing him. > >>> > >>> > >>> On Tue, Nov 19, 2013 at 10:44 AM, Amir Sadoughi > >>> <amir.sadou...@rackspace.com> wrote: > >>>> > >>>> Yes, my work has been on ML2 with neutron-openvswitch-agent. I’m > >>>> interested to see what Jun Park has. I might have something ready > before he > >>>> is available again, but would like to collaborate regardless. > >>>> > >>>> Amir > >>>> > >>>> > >>>> > >>>> On Nov 19, 2013, at 3:31 AM, Kanthi P <pavuluri.kan...@gmail.com> > wrote: > >>>> > >>>> Hi All, > >>>> > >>>> Thanks for the response! > >>>> Amir,Mike: Is your implementation being done according to ML2 plugin > >>>> > >>>> Regards, > >>>> Kanthi > >>>> > >>>> > >>>> On Tue, Nov 19, 2013 at 1:43 AM, Mike Wilson <geekinu...@gmail.com> > >>>> wrote: > >>>>> > >>>>> Hi Kanthi, > >>>>> > >>>>> Just to reiterate what Kyle said, we do have an internal > implementation > >>>>> using flows that looks very similar to security groups. Jun Park was > the guy > >>>>> that wrote this and is looking to get it upstreamed. I think he'll > be back > >>>>> in the office late next week. I'll point him to this thread when > he's back. > >>>>> > >>>>> -Mike > >>>>> > >>>>> > >>>>> On Mon, Nov 18, 2013 at 3:39 PM, Kyle Mestery (kmestery) > >>>>> <kmest...@cisco.com> wrote: > >>>>>> > >>>>>> On Nov 18, 2013, at 4:26 PM, Kanthi P <pavuluri.kan...@gmail.com> > >>>>>> wrote: > >>>>>> > Hi All, > >>>>>> > > >>>>>> > We are planning to implement quantum security groups using > openflows > >>>>>> > for ovs plugin instead of iptables which is the case now. > >>>>>> > > >>>>>> > Doing so we can avoid the extra linux bridge which is connected > >>>>>> > between the vnet device and the ovs bridge, which is given as a > work around > >>>>>> > since ovs bridge is not compatible with iptables. > >>>>>> > > >>>>>> > We are planning to create a blueprint and work on it. Could you > >>>>>> > please share your views on this > >>>>>> > > >>>>>> Hi Kanthi: > >>>>>> > >>>>>> Overall, this idea is interesting and removing those extra bridges > >>>>>> would certainly be nice. Some people at Bluehost gave a talk at the > Summit > >>>>>> [1] in which they explained they have done something similar, you > may want > >>>>>> to reach out to them since they have code for this internally > already. > >>>>>> > >>>>>> The OVS plugin is in feature freeze during Icehouse, and will be > >>>>>> deprecated in favor of ML2 [2] at the end of Icehouse. I would > advise you to > >>>>>> retarget your work at ML2 when running with the OVS agent instead. > The > >>>>>> Neutron team will not accept new features into the OVS plugin > anymore. > >>>>>> > >>>>>> Thanks, > >>>>>> Kyle > >>>>>> > >>>>>> [1] > >>>>>> > http://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/towards-truly-open-and-commoditized-software-defined-networks-in-openstack > >>>>>> [2] https://wiki.openstack.org/wiki/Neutron/ML2 > >>>>>> > >>>>>> > Thanks, > >>>>>> > Kanthi > >>>>>> > _______________________________________________ > >>>>>> > OpenStack-dev mailing list > >>>>>> > OpenStack-dev@lists.openstack.org > >>>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OpenStack-dev mailing list > >>>>>> OpenStack-dev@lists.openstack.org > >>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> OpenStack-dev mailing list > >>>>> OpenStack-dev@lists.openstack.org > >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>>> > >>>> > >>>> _______________________________________________ > >>>> OpenStack-dev mailing list > >>>> OpenStack-dev@lists.openstack.org > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> OpenStack-dev mailing list > >>>> OpenStack-dev@lists.openstack.org > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>> > >>> > >>> > >>> _______________________________________________ > >>> OpenStack-dev mailing list > >>> OpenStack-dev@lists.openstack.org > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >> > >> > >> > >> -- > >> Cheers, > >> Jian > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev