From owner-freebsd-ipfw@FreeBSD.ORG Mon Oct 19 14:50:03 2009 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00C42106566C for ; Mon, 19 Oct 2009 14:50:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C9F708FC08 for ; Mon, 19 Oct 2009 14:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n9JEo2cZ057397 for ; Mon, 19 Oct 2009 14:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n9JEo2fx057396; Mon, 19 Oct 2009 14:50:02 GMT (envelope-from gnats) Date: Mon, 19 Oct 2009 14:50:02 GMT Message-Id: <200910191450.n9JEo2fx057396@freefall.freebsd.org> To: freebsd-ipfw@FreeBSD.org From: Ian Smith Cc: Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Smith List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 14:50:03 -0000 The following reply was made to PR kern/139581; it has been noted by GNATS. From: Ian Smith To: bug-followup@FreeBSD.org, freebsd@alexus.org Cc: Subject: Re: kern/139581: [ipfw] "ipfw pipe" not limiting bandwidth Date: Tue, 20 Oct 2009 01:24:17 +1100 May be a usage issue; I'll have a go. Partial quoting, out of order. : I'm trying to limit my apache that runs under daemon to up 2Mbit/s : when I do "ipfw pipe show" I don't see anything in my slots other then : very first entry that never chage, nor does it limits my traffic, as : if I look at my MRTG i see way more traffic then 2Mbit/s Unless you specify masks on your pipes you'll only ever see the first connection that used that pipe, that's normal. MRTG sees all traffic on an interface, and your ipfw stats indicate at least 25% more traffic than that due to your webserver, so it's not clear how you could tell if your pipe was exceeding 2Mbit/s or not? Also, it's recommended not to run your inbound and outbound traffic through the one pipe, unless simulating half-duplex connections; see explanation in ipfw(8), EXAMPLES section under TRAFFIC SHAPING. : su-3.2# ipfw show : 00100 1249368 205115325 allow ip from any to any via lo0 : 00200 0 0 deny ip from any to 127.0.0.0/8 : 00300 0 0 deny ip from 127.0.0.0/8 to any : 08380 2838075 3586421013 pipe 1 tcp from any 80 to any uid daemon : 08380 2097473 136454502 pipe 1 tcp from any to any dst-port 80 uid daemon : 65000 5740679 4716157064 allow ip from any to any : 65535 0 0 deny ip from any to any 3.586 GiB outbound from the webserver (served data) 0.136 GiB inbound to the webserver (requests, acks) + --- 3.722 GiB through the pipe. but 4.716 GiB passed from any to any, either way. So there's about 1 Gig of extra traffic shown here, assuming you have net.inet.ip.fw.one_pass=0 and all traffic eventually hits rule 65000 (and 4.7G extra traffic if net.inet.ip.fw.one_pass=1) but there's not enough info to see whether or not it's on the interface MRTG watches? : su-3.2# ipfw pipe show : 00001: 2.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail : mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 : BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp : 0 tcp 64.237.55.83/59388 208.80.152.3/80 4936077 3723134341 0 0 30179 Total packets and bytes match the above, indicating that this was done just after the ipfw show. 0.6% dropped packets indicates some limiting happening, but with a shared in/outbound pipe, not in which direction. If this is still an issue, please: . be more precise than "way more traffic" if you have more data? . say whether the extra ~25% traffic shown is on the same interface as the webserver, ie the interface MRTG monitors, or not? . the value of sysctl net.inet.ip.fw.one_pass ? cheers, Ian