From owner-freebsd-ipfw@FreeBSD.ORG Mon Jul 31 12:16:02 2006 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFE5516A4DF for ; Mon, 31 Jul 2006 12:16:02 +0000 (UTC) (envelope-from ianf@hetzner.co.za) Received: from hetzner.co.za (office.dc2.cpt.your-server.co.za [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id D01E643D6B for ; Mon, 31 Jul 2006 12:15:57 +0000 (GMT) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1] helo=ian.hetzner.africa) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1G7Wge-0005G0-7G for freebsd-ipfw@FreeBSD.org; Mon, 31 Jul 2006 14:15:56 +0200 To: freebsd-ipfw@FreeBSD.org From: Ian FREISLICH X-Attribution: BOFH Date: Mon, 31 Jul 2006 14:15:56 +0200 Sender: ianf@hetzner.co.za Message-Id: Cc: Subject: ipfw performance and random musings. X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Jul 2006 12:16:02 -0000 Hi I was wondering if anyone here had any ideas for improving the performance (packet rate) of ipfw. I have about 500 interfaces on my firewall and I need to match and filter packets on a per interface basis. I've found that while the server can move in excess of 360kpps bewteen arbitrary interfaces using about 5% CPU, if I turn on the firewall, my average packet rate falls off to about 60kpps on a UP system and 90kpps on a SMP system. The maximum rate I can forward packets with ipfw enabled is 120kpps and that is with 1 rule allowing ip from any to any. At these maximum rates, CPU utilization is close to 100% on both CPUs in the interrupt handler. This low packet rate and high CPU utilization does not make the system effective (for other users) while filtering a DoS attack perpetrated by a host behind the firewall. Perhaps these are 2 easy wins: 1. Change the order of the case statements in ipfw_chk() to move more frequently used items to the top. The options seem to have been added mostly in chronological feature order, rather than reverse most frequently used order. 2. Caching of ifp->if_index in the rule 'microinstructions' to remove the need for a strncmp to match interface names. Might be tricky if interfaces are destroyed and recreated without invalidating this cache. Then, state is not interface aware. I have used this effect to inject packets from one network to another where the rules on the other interface specifically deny these packets. There is a patch in kern/97951 to fix this problem. Ian -- Ian Freislich