netdev - RE: [PATCH iproute2/net-next 1/3] tc: Add support for the sample tc action

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Feb 2017 07:38:15 +0000
From:   Yotam Gigi <yotamg@...lanox.com>
To:     Florian Fainelli <f.fainelli@...il.com>,
        "stephen@...workplumber.org" <stephen@...workplumber.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jiri Pirko <jiri@...lanox.com>, Elad Raz <eladr@...lanox.com>
Subject: RE: [PATCH iproute2/net-next 1/3] tc: Add support for the sample tc
 action

>-----Original Message-----
>From: Florian Fainelli [mailto:f.fainelli@...il.com]
>Sent: Sunday, February 05, 2017 10:55 PM
>To: Yotam Gigi <yotamg@...lanox.com>; stephen@...workplumber.org;
>netdev@...r.kernel.org; Jiri Pirko <jiri@...lanox.com>; Elad Raz
><eladr@...lanox.com>
>Subject: Re: [PATCH iproute2/net-next 1/3] tc: Add support for the sample tc action
>
>Le 02/05/17 à 12:22, Yotam Gigi a écrit :
>>> -----Original Message-----
>>> From: Florian Fainelli [mailto:f.fainelli@...il.com]
>>> Sent: Sunday, February 05, 2017 8:37 PM
>>> To: Yotam Gigi <yotamg@...lanox.com>; stephen@...workplumber.org;
>>> netdev@...r.kernel.org; Jiri Pirko <jiri@...lanox.com>; Elad Raz
>>> <eladr@...lanox.com>
>>> Subject: Re: [PATCH iproute2/net-next 1/3] tc: Add support for the sample tc
>action
>>>
>>> On 02/04/2017 11:58 PM, Yotam Gigi wrote:
>>>> The sample tc action allows sampling packets matching a classifier. It
>>>> peeks randomly packets, and samples them using the psample netlink
>>>> channel. The user can specify the psample group, which the packet will be
>>>> sampled to, the sampling rate and the packet truncation (to save
>>>> kernel-user traffic).
>>>>
>>>> The sampled packets contain informative metadata, for example, the input
>>>> interface and the original packet length.
>>>>
>>>> The action syntax:
>>>> tc filter add [...] \
>>>> 	action sample rate <RATE> group <GROUP> [trunc <SIZE>]
>>>> 	[...]
>>>>
>>>> Where:
>>>>   RATE := The sampling rate which is the ratio of packets observed at the
>>>> 	  data source to the samples generated
>>>>   GROUP := the psample module sampling group
>>>>   SIZE := optional truncation size
>>>>
>>>> An example for a common usecase of the sample tc action: to sample ingress
>>>> traffic from interface eth1, one may use the commands:
>>>>
>>>> tc qdisc add dev eth1 handle ffff: ingress
>>>>
>>>> tc filter add dev eth1 parent ffff: \
>>>>        matchall action sample rate 12 group 4
>>>>
>>>> Where the first command adds an ingress qdisc and the second starts
>>>> sampling randomly with an average of one sampled packet per 12 packets
>>>> on dev eth1 to psample group 4.
>>>
>>> The group argument seems to be mandatory from looking at the code, but
>>> what if just wanted to have a port mirroring between, say sw0p1 and
>>> sw0p2 with the sample rate specified instead (without using the psample
>>> netlink channel at all)? Could we make this group an optional argument
>>> instead?
>>
>> The kernel action currently don't support it, and I am not sure it should.
>>
>> If I understand you correctly, you want to make the sample action identical
>> to mirred-mirror, only with random behavior. This can be done using the
>> matchall and mirred action, plus the 'random' gact keyword.
>
>It sounds like we can indeed, with random determ and using the VAL
>argument we should be able to configure the capture divider; thanks!

You're welcome. It took me some time to find that keyword too :)

>
>>
>> The sample action attaches some metadata in addition to the original packet
>> data, and that cannot be achieved by mirroring the packets, thus making it
>> unusable for our usecase. In the former version we attached the metadata
>> using the IFE protocol, but we decided to use a dedicated netlink channel
>> instead.
>
>Yeah I see that now, thanks for the explanation!
>--
>Florian