From owner-freebsd-net@FreeBSD.ORG Wed Jul 25 18:21:07 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC4301065675; Wed, 25 Jul 2012 18:21:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 8A9D98FC1E; Wed, 25 Jul 2012 18:21:07 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 16CBA7300A; Wed, 25 Jul 2012 20:41:04 +0200 (CEST) Date: Wed, 25 Jul 2012 20:41:04 +0200 From: Luigi Rizzo To: net@freebsd.org Message-ID: <20120725184104.GA35621@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: ipfw@freebsd.org Subject: PREVIEW - netmap-enabled ipfw X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 18:21:07 -0000 First and foremost: this is just a preview, only usable for testing now, but very very close to working. http://info.iet.unipi.it/~luigi/netmap/20120725-ipfw-user.tgz At the above URL you can find a userspace version of ipfw that reads packet from a netmap-compatible port (i.e. a netmap supported interface, or a port on a VALE bridge), and processes them through ipfw. It builds and run on both linux and FreeBSD, and uses the ipfw sources from today's HEAD. Right now the output is thrown away, but very shortly the code will also send it to an output port. The way it works is very simple (see also the picture below, drawn with http://www.asciiflow.com/ ) The formerly-kernel-side part of the firewall now runs in a userspace process (kipfw) and is controlled by a slightly modified ipfw that routes the sockopt commands over TCP to localhost:5555 (hardwired). kipfw stores rules persistently, and also reads from a netmap port. The configuration below shows how to use pkt-gen to test the performance of the system: you need to load the VALE-enabled netmap module, then in one terminal run "kipfw vale-test", in another terminal use the ipfw that you just built to add/delete/show stuff, and you can use netmap's pkt-gen to generate traffic. +------------+ | | +----------+ +----------------+ | | | | tcp/5555 | | | pkt-gen | | ipfw +--------->| kipfw | | | | | | | | | +----------+ +----------------+ +-----+------+ ^ | | | | | | v +-------+--------------------------+ | | | VALE bridge | | | +----------------------------------+ A quick test with a simple ruleset (4 rules, see below) shows a processing speed of 9-10Mpps on one core. I think there is still room for a little bit of improvement. Especially, we can now test the performance impact of changes to the firewall code without the need for complex hardware setups. > ipfw/ipfw show connected to 127.0.0.1:5555 00100 30628621 1408916566 count ip from any to any dst-ip 10.1.0.1 00100 0 0 count ip from any to any dst-ip 10.1.0.2 00100 0 0 count ip from any to any dst-ip 10.1.0.3 65535 30628621 1408916566 allow ip from any to any cheers luigi