Date: Mon, 30 Jun 2008 22:05:08 -0400 From: Mike Tancsa <mike@sentex.net> To: "Wilkinson, Alex" <alex.wilkinson@dsto.defence.gov.au>, freebsd-net@freebsd.org Subject: Re: Freebsd IP Forwarding performance (question, and some info) [7-stable, current, em, smp] Message-ID: <200807010205.m61250IT083199@lava.sentex.ca> In-Reply-To: <20080701004346.GA3898@stlux503.dsto.defence.gov.au> References: <4867420D.7090406@gtcomm.net> <200806301944.m5UJifJD081781@lava.sentex.ca> <20080701004346.GA3898@stlux503.dsto.defence.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
At 08:43 PM 6/30/2008, Wilkinson, Alex wrote: > 0n Mon, Jun 30, 2008 at 03:44:48PM -0400, Mike Tancsa wrote: > > >OK, I setup 2 boxes on either end of a RELENG_7 box from about May > >7th just now, to see with 2 boxes blasting across it how it would > >work. *However*, this is with no firewall loaded and, I must enable > >ip fast forwarding. Without that enabled, the box just falls over. > >What is "ip fast forwarding" ? From /usr/src/sys/netinet/ip_fastfwd.c /* * 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 destination router was not the * default gateway. In one case it was filling the routing table of a host * with approximately 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 fail in other ways. */ > -aW > >IMPORTANT: This email remains the property of the Australian Defence >Organisation and is subject to the jurisdiction of section 70 of the >CRIMES ACT 1914. If you have received this email in error, you are >requested to contact the sender and delete the email. > > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807010205.m61250IT083199>