From: Ed W <lists@wildgooses.com>
To: Lutfi ODUNCUOGLU <lutfio@metu.edu.tr>
Cc: netfilter@vger.kernel.org,
Eliezer Croitoru <eliezer@ngtech.co.il>,
ntop-dev@unipi.it
Subject: Re: New/Updated L7 netfilter option - nDPI
Date: Fri, 02 Nov 2012 13:40:21 +0000 [thread overview]
Message-ID: <5093CD45.8090607@wildgooses.com> (raw)
In-Reply-To: <5093BEAB.2040002@metu.edu.tr>
On 02/11/2012 12:38, Lutfi ODUNCUOGLU wrote:
> Hello,
>
> I compiled nDPI-nefilter patch and it works fine. What I want is to
> shape the p2p traffic in my network. For this purpose i just
> implemented the nDPI-netfilter patch as two different ways for testing
>
> iptables -t mangle -A POSTROUTING -o XXX -m ndpi --bittorrent -j
> CONNMARK --set-mark 1
>
>
> iptables -t mangle -A POSTROUTING -m connmark --mark 1 -j CLASSIFY
> --set-class 0001:0010
>
> or
>
> iptables -t mangle -A POSTROUTING -m ndpi --bittorrent -j CLASSIFY
> --set-class 0001:0010
>
>
> So which one is more suitable for use? I don't know if this patch
> inspects connections (marks connection) or every single packet (marks
> every single) for a match.
I would be interested in your feedback on CPU usage for both actually?
Internally nDPI implements a "connection cache", which means that it
asks conntrack to maintain the connection, but internally it maintains a
cache of what protocol is matched to a given connection. This should be
quite similar to asking conntrack to --set-mark *if* you also have some
iptables to subsequently skip the test once the connection is marked?
So, either way, the connection gets marked at some point and thereafter
no CPU is expended checking the connection further. Of course theory
and practice aren't the same...
Just beware that the connection may only get marked several packets in,
ie the first few packets might not match anything, then the protocol
will be detected, thereafter the protocol is wedged as being detected as
that protocol. This can obviously mean several packets potentially
going out unmarked even if the connection is subsequently marked (not
normally a problem)
Grateful for your benchmarks!
Ed W
next prev parent reply other threads:[~2012-11-02 13:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 22:53 New/Updated L7 netfilter option - nDPI Ed W
2012-10-28 8:20 ` Andrew Beverley
2012-10-28 14:57 ` Eliezer Croitoru
2012-11-01 22:03 ` Andrew Beverley
2012-11-01 22:56 ` Ed W
2012-11-02 12:38 ` Lutfi ODUNCUOGLU
2012-11-02 13:40 ` Ed W [this message]
2012-11-06 14:13 ` [Ntop-dev] " Eliezer Croitoru
2012-11-04 15:45 ` Andrew Beverley
2012-10-28 16:34 ` Ed W
2012-10-28 16:39 ` Eliezer Croitoru
2012-10-28 15:07 ` Eliezer Croitoru
2012-10-28 16:03 ` Ed W
2012-10-28 16:51 ` Eliezer Croitoru
2012-10-28 16:57 ` Ed W
2012-10-28 17:57 ` Eliezer Croitoru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5093CD45.8090607@wildgooses.com \
--to=lists@wildgooses.com \
--cc=eliezer@ngtech.co.il \
--cc=lutfio@metu.edu.tr \
--cc=netfilter@vger.kernel.org \
--cc=ntop-dev@unipi.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.