On 06/12/15 20:31, Ansis Atteka wrote:
On Fri, Jun 12, 2015 at 5:50 AM, Franck Baudin <franck.bau...@qosmos.com> wrote:
Hi Ansis,
On 06/09/15 22:59, Ansis Atteka wrote:
Hi Franck
On 8 June 2015 at 09:34, Franck BAUDIN <franck.bau...@qosmos.com
<mailto:franck.bau...@qosmos.com>> wrote:
Hello,
Conntrack looks in very good progress on
https://github.com/justinpettit/ovs.git
However, I didn't find any code related to "nfqueue" openvswitch
action, neither on
https://github.com/tgraf/ovs.git.
Is the nfqueue action still planned to be implemented for
openvswitch 2.4? Do you need a hand on this topic?
Unfortunately, I am not aware of anyone working actively on this. There
are some difficulties that we see with implementing NFQueue verdicts
properly so that packet processing could be resumed. If you have design
proposal on how to solve this, then I would be glad to hear your opinion.
Also, do you think that Open vSwitch kernel module's userspace() action
might somehow suffice your use cases so that user-space process would be
able to get packet from kernel-space?
Unfortunately, userspace() is not an option as DPI is not embedded in
ovs-vswitchd. DPI is a standalone userland process.
While I haven't tried it myself, It is possible for process other than
ovs-vswitchd to get packets sent from OVS kernel module to userspace
via userspace() action by making your process to subscribe to the
right OVS NETLINK notifications. Of course we would still have to
figure out how to implement corresponding OpenFlow DPI action that
would translate into this Kernel userspace(dpi) action.
Thanks for the tip! I need to dig a bit to see if this would require a
datapath patch, an to figure out if this way would perform better than tap.
However, I found another way which is pretty straightforward: I can use a
dedicated vswitch port to get a copy of the traffic I want to analyze with
the DPI. I just need one port per conntrack zone.
Yes, it must be somehow possible to be able to pass "conntrack zone"
context to the DPI engine. However, are you implying here that you
would create Interfaces with type="internal" per conntrack zone?
Yes, I need to find a way to get the conntrack zone for every packet, so
having a port per zone is an option. I can also use an encapsulation to
encode the conntrack zone (vlan for instance) if there are numerous
conntrack zones.
I used the following rules successfully to send the packets 'under DPI
classification' (conn_mark=0 in this example, I'm gonna try conn_label
as well as both should work) to the LOCAL port, and when I mark it at
some point (conntrack -U -s 1.1.1.1 -p tcp --sport 37120 -m 8), I see
that the packet is properly forwarded and no more copied to LOCAL:
ovs-ofctl del-flows br0
ovs-ofctl add-flow br0
'priority=50000,tcp,conn_state=-trk,action=ct(commit,recirc)'
ovs-ofctl add-flow br0
'priority=36000,tcp,conn_state=+trk,conn_mark=8,action=mod_nw_tos:8,NORMAL'
ovs-ofctl add-flow br0
'priority=35000,tcp,conn_state=+trk,action=mod_nw_tos:4,LOCAL,NORMAL'
ovs-ofctl add-flow br0 'action=NORMAL'
Just to say that with Justin's current code, we have everything to
implement DPI/L7 classification on openvswitch. Then, we'll see if
optimizations/enhancements like NFQUEUE are relevant. Or did I miss
something and this design doesn't fly?
Best Regards
Franck
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
