Date: Wed, 28 Jan 2015 00:32:40 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Antoine Beaupr? <anarcat@koumbit.org> Cc: freebsd-net@freebsd.org, wishmaster <artemrts@ukr.net> Subject: Re: is polling still a thing? Message-ID: <20150127233240.GA22364@onelab2.iet.unipi.it> In-Reply-To: <87h9vbbze1.fsf@marcos.anarc.at> References: <871tmgceup.fsf@marcos.anarc.at> <1422384769.867067950.y2iiuu53@frv34.fwdcdn.com> <87pp9zc1wk.fsf@marcos.anarc.at> <20150127223917.GA21883@onelab2.iet.unipi.it> <87h9vbbze1.fsf@marcos.anarc.at>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 27, 2015 at 06:02:46PM -0500, Antoine Beaupr? wrote:
> On 2015-01-27 17:39:17, Luigi Rizzo wrote:
> > On Tue, Jan 27, 2015 at 05:08:27PM -0500, Antoine Beaupr? wrote:
> >> On 2015-01-27 13:57:20, wishmaster wrote:
> >> > Have you consider to use netmap-based ipfw instead pf in DDoS mitigation? I think you should. And without any network ''haks'' like polling.
> >>
> >> My understanding of netmap was that it wasn't useful for packet
> >> forwarding, because its design is for transmitting packets directly to
> >> userland faster, whereas routers dataflow stay mostly in the router...
> >
> > i think the suggestion was to have let netmap-ipfw
> > drop the traffic you don't want to deal with, and then
> > inject the remaining ones into the kernel where
> > the processing occurs -- possibly even using pf or
> > a different firewall
> >
> > There are people using netmap-ipfw on external physical
> > boxes exactly in this way -- as a "bump in the wire",
> > but it is trivial to run it on the same machine.
>
> hmmm... i *was* using pf to drop a significant amount of the traffic, I
> am not sure I understand how using netmap/ipfw would help here.
>
> my understanding of the problem, at this stage, is not so much pf
> processing the packets as the kernel having trouble extracting the
> packets from the NIC fast enough.
The arrangement is as in the picture below (use a fixed size font).
+------------------+
| netmap-ipfw |
+-[HHH-------[HHH]-+
HHH H
HHH H
+-----[HHH]------[HHH]-----------------------+
| HHH H +-----------+ |
| HHH H | host | |
| HHH o=======| network | |
| +--[HHH]--+ | stack | |
| | netmap | +-----------+ |
| | enabled | |
| | NIC | |
+--+---------+-------------------------------+
A netmap-aware NIC has no problem dealing with high PPS rates,
deliver them through the fat pipe HHH to netmap-ipfw in userspace,
which does the filtering and drops the junk. The remaining part
is reinjected through another netmap port into the host stack,
which is the actual bottleneck. Presumably at this point the amount
of residual traffic is sustainable by the kernel. netmap-ipfw is
simmetric so it supports traffic in the other direction too.
another host netmap port. Presumably at thi
cheers
luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150127233240.GA22364>