From owner-freebsd-net@FreeBSD.ORG Sat Jan 17 09:53:49 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9218A16A4CE for ; Sat, 17 Jan 2004 09:53:49 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9318C43D1F for ; Sat, 17 Jan 2004 09:53:47 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 26618 invoked from network); 17 Jan 2004 17:53:46 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 17 Jan 2004 17:53:46 -0000 Message-ID: <400976AA.169D1440@freebsd.org> Date: Sat, 17 Jan 2004 18:53:46 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Xin LI References: <042601c3dcb0$de90c410$0401a8c0@phantasm205> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@FreeBSD.org Subject: Re: Newbie question: is net.inet.ip.fastforwarding intended for routersonly? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jan 2004 17:53:49 -0000 Xin LI wrote: > > As title. To my imagination (I have taken a sight on the kernel networking > code), the fastforwarding path is intended for routers only, so if I want > some functionalities, for example, NAT, the fastforwarding is not useful, > and my experiment shows that if I enable it, ipfilter's NAT will be broken. > Am I right? I have written a new fastforward code for 5.2 and -current which does everything including ipfw, NAT and ipfilter. Here is the blurb for it: /* * ip_fastforward gets its speed from processing the forwarded packet to * completion (if_output on the other side) without any queues or netisr's. * The receiving interface DMAs the packet into memory, the upper half of * driver calls ip_fastforward, we do our routing table lookup and directly * send it off to the outgoing interface which DMAs the packet to the * network card. The only part of the packet we touch with the CPU is the * IP header (unless there are complex firewall rules touching other parts * of the packet, but that is up to you). We are essentially limited by bus * bandwidth and how fast the network card/driver can set up receives and * transmits. * * We handle basic errors, ip header errors, checksum errors, * destination unreachable, fragmentation and fragmentation needed and * report them via icmp to the sender. * * Else if something is not pure IPv4 unicast forwarding we fall back to * the normal ip_input processing path. We should only be called from * interfaces connected to the outside world. * * Firewalling is fully supported including divert, ipfw fwd and ipfilter * ipnat and address rewrite. * * IPSEC is not supported if this host is a tunnel broker. IPSEC is * supported for connections to/from local host. * * We try to do the least expensive (in CPU ops) checks and operations * first to catch junk with as little overhead as possible. * * We take full advantage of hardware support for ip checksum and * fragmentation offloading. * * We don't do ICMP redirect in the fast forwarding path. I have had my own * cases where two core routers with Zebra routing suite would send millions * ICMP redirects to connected hosts if the router to dest was not the default * gateway. In one case it was filling the routing table of a host with close * 300'000 cloned redirect entries until it ran out of kernel memory. However * the networking code proved very robust and it didn't crash or went ill * otherwise. */ -- Andre