From owner-freebsd-net@FreeBSD.ORG Wed Oct 7 12:10:33 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19272106566B; Wed, 7 Oct 2009 12:10:33 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx34.mail.ru (mx34.mail.ru [94.100.176.48]) by mx1.freebsd.org (Postfix) with ESMTP id C76E28FC1D; Wed, 7 Oct 2009 12:10:32 +0000 (UTC) Received: from [217.25.27.27] (port=15365 helo=[217.25.27.27]) by mx34.mail.ru with asmtp id 1MvVLi-000Q03-00; Wed, 07 Oct 2009 16:10:30 +0400 Message-ID: <4ACC8535.70403@mail.ru> Date: Wed, 07 Oct 2009 17:10:29 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Oleg Bulyzhin References: <4AC8A76B.3050502@mail.ru> <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <20091007115425.GD88982@lath.rinet.ru> In-Reply-To: <20091007115425.GD88982@lath.rinet.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets 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, 07 Oct 2009 12:10:33 -0000 Oleg Bulyzhin wrote: > On Wed, Oct 07, 2009 at 03:52:56PM +0500, rihad wrote: > >> You probably have some special sources of documentation ;-) According to >> man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the packet >> unless one_pass=0. Or do you mean sprinkling smart skiptos here and >> there? ;-) > > you can > 1) use ng_ether & ng_netflow. (so no need in 'ngtee' rule). > 2) use 'tee' rule with ng_ksocket & ng_netflow > Thanks, I'll see into that if fast-forwarding doesn't help. >>> Could you show your 'ipfw show' output? (hide ip addresses if you wish but >>> keep counters please). >>> > >> Here it is, in its whole glory: >> >> 00100 10434423 1484891105 allow ip from any to any via lo0 >> 00200 2 14 deny ip from any to 127.0.0.0/8 >> 00300 1 4 deny ip from 127.0.0.0/8 to any >> 01000 3300039938 327603104711 allow ip from any to any in >> 01010 26214900 421138433 allow ip from me to any out >> 01020 5453857 46806278 allow icmp from any to any out >> 01030 3268289053 327224694165 ngtee 1 ip from any to any out >> 01040 18681181 1089636054 skipto 1100 ip from table(127) to any out >> recv bce0 xmit bce1 >> 01060 777488848 76743392754 pipe tablearg ip from any to table(0) out >> recv bce0 xmit bce1 >> 01070 776831109 76682499457 allow ip from any to table(0) out recv >> bce0 xmit bce1 >> 01100 13102697 808411842 pipe tablearg ip from any to table(2) out >> 65535 662648946 66711487830 allow ip from any to any > > I guess this one would be better(faster): > > 00050 allow ip from any to any in > 00100 allow ip from any to any via lo0 > 01010 allow ip from me to any > 01020 allow icmp from any to any > 01030 ngtee 1 ip from any to any > 01035 skipto 1040 ip from any to any recv bce0 xmit bce1 > 01036 allow ip from any to any > 01040 skipto 1100 ip from table(127) to any > 01060 pipe tablearg ip from any to table(0) > 01070 allow ip from any to any > 01100 pipe tablearg ip from any to table(2) > 65535 allow ip from any to any > Phew, were "out" that bad? I left them in as commentary. And the localhost anti-spoof check isn't such a bad security ring to get rid of in the name of performance ;-) Ok, got you, I'll take a note of it, thanks. > P.S. have you tried net.inet.ip.fastforwarding=1? > man 4 inet: IPCTL_FASTFORWARDING (ip.fastforwarding) Boolean: enable/disable the use of fast IP forwarding code. Defaults to off. When fast IP forwarding is enabled, IP packets are for- warded directly to the appropriate network inter- face with direct processing to completion, which greatly improves the throughput. All packets for local IP addresses, non-unicast, or with IP options are handled by the normal IP input processing path. All features of the normal (slow) IP forwarding path are supported including firewall (through pfil(9) hooks) checking, except ipsec(4) tunnel brokering. The IP fastforwarding path does not generate ICMP redirect or source quench messages. I'm afraid a bit that it will lock up the live remote system. Is it a drop in replacement given my ipfw rules? Why isn't it enabled by default?