From owner-freebsd-ipfw@FreeBSD.ORG Sun Jun 22 11:36:48 2003 Return-Path: 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 8F76837B401 for ; Sun, 22 Jun 2003 11:36:48 -0700 (PDT) Received: from mail.is.lt (mail.is.lt [193.219.14.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE36B43F3F for ; Sun, 22 Jun 2003 11:36:46 -0700 (PDT) (envelope-from maxim@lans.lt) Received: from localhost ([193.219.14.152]) by mail.is.lt (8.9.3/8.9.3) with ESMTP id VAA26198 for ; Sun, 22 Jun 2003 21:36:43 +0300 (EEST) Date: Sun, 22 Jun 2003 21:36:46 +0300 From: Maxim LANS X-Mailer: The Bat! (v1.62/Beta5) Organization: LANS X-Priority: 3 (Normal) Message-ID: <464935968.20030622213646@lans.lt> To: freebsd-ipfw@freebsd.org In-Reply-To: References: 20030428001533.GA20138@palomine.net MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Traffic Shaper Question X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Maxim LANS List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2003 18:36:48 -0000 Hi, I have read your message and here is the solution: You've wrote: /sbin/ipfw pipe 1 config bw 250Kbits/s /sbin/ipfw pipe 2 config bw 155Kbytes/s /sbin/ipfw queue 1 config pipe 2 weight 1 /sbin/ipfw queue 2 config pipe 2 weight 1 /sbin/ipfw queue 3 config pipe 1 weight 1 The error is very simple, you just had to write it this way: /sbin/ipfw pipe 1 config bw 250Kbits/s /sbin/ipfw pipe 2 config bw 155Kbytes/s /sbin/ipfw queue 1 config weight 1 pipe 2 /sbin/ipfw queue 2 config weight 1 pipe 2 /sbin/ipfw queue 3 config weight 1 pipe 1 And that is it. Your welcome. ILJA, rusas@delfi.lt P.S. Meaby you have/know where to find some documents/how-to's/information about ALTQ/CBQ From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 23 06:57:12 2003 Return-Path: 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 F31CF37B401; Mon, 23 Jun 2003 06:57:11 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90E6843FB1; Mon, 23 Jun 2003 06:57:11 -0700 (PDT) (envelope-from luigi@FreeBSD.org) Received: from freefall.freebsd.org (luigi@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h5NDvBUp014627; Mon, 23 Jun 2003 06:57:11 -0700 (PDT) (envelope-from luigi@freefall.freebsd.org) Received: (from luigi@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h5NDvBe4014623; Mon, 23 Jun 2003 06:57:11 -0700 (PDT) Date: Mon, 23 Jun 2003 06:57:11 -0700 (PDT) From: Luigi Rizzo Message-Id: <200306231357.h5NDvBe4014623@freefall.freebsd.org> To: pawmal@unia.3lo.lublin.pl, luigi@FreeBSD.org, ipfw@FreeBSD.org Subject: Re: bin/48015: make ipfw2 work with iplen ranges X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 13:57:12 -0000 Synopsis: make ipfw2 work with iplen ranges State-Changed-From-To: open->closed State-Changed-By: luigi State-Changed-When: Mon Jun 23 06:56:28 PDT 2003 State-Changed-Why: committed code that implements the requested functionality. http://www.freebsd.org/cgi/query-pr.cgi?pr=48015 From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 23 11:01:37 2003 Return-Path: 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 775DC37B404 for ; Mon, 23 Jun 2003 11:01:37 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8282F43FBF for ; Mon, 23 Jun 2003 11:01:34 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h5NI1YUp000646 for ; Mon, 23 Jun 2003 11:01:34 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h5NI1XIB000641 for ipfw@freebsd.org; Mon, 23 Jun 2003 11:01:33 -0700 (PDT) Date: Mon, 23 Jun 2003 11:01:33 -0700 (PDT) Message-Id: <200306231801.h5NI1XIB000641@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 18:01:37 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/01/26] kern/47529 ipfw natd/ipfw lose TCP packets for firewalled o [2003/03/23] kern/50216 ipfw kernel panic on 5.0-current when use ipfw 2 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues o [2003/04/18] kern/51132 ipfw kernel part of ipfw1 processes 'to not me o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu o [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp 4 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w f [2002/01/11] kern/33804 ipfw ipfw bug/problem o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2002/12/27] kern/46564 ipfw IPFilter and IPFW processing order is not o [2003/01/05] bin/46785 ipfw [patch] add sets information to ipfw2 -h o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/03/12] bin/49959 ipfw ipfw tee port rule skips parsing next rul o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/04/20] kern/51182 ipfw ipfw2. -d list shows couters for dynamic 11 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jun 23 11:46:16 2003 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B3D137B401; Mon, 23 Jun 2003 11:46:16 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26A8A43F85; Mon, 23 Jun 2003 11:46:16 -0700 (PDT) (envelope-from ceri@FreeBSD.org) Received: from freefall.freebsd.org (ceri@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h5NIkGUp007751; Mon, 23 Jun 2003 11:46:16 -0700 (PDT) (envelope-from ceri@freefall.freebsd.org) Received: (from ceri@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h5NIkGhN007747; Mon, 23 Jun 2003 11:46:16 -0700 (PDT) Date: Mon, 23 Jun 2003 11:46:16 -0700 (PDT) From: Ceri Davies Message-Id: <200306231846.h5NIkGhN007747@freefall.freebsd.org> To: ceri@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: kern/53624: patches for ipfw2 to support ipsec packet filtering X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 18:46:17 -0000 Synopsis: patches for ipfw2 to support ipsec packet filtering Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: ceri Responsible-Changed-When: Mon Jun 23 11:46:02 PDT 2003 Responsible-Changed-Why: Over to the ipfw maintainers. http://www.freebsd.org/cgi/query-pr.cgi?pr=53624 From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 02:47:18 2003 Return-Path: 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 9285337B401 for ; Wed, 25 Jun 2003 02:47:18 -0700 (PDT) Received: from andy.btvs.net (andy.btvs.net [80.253.107.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 215DB43FE0 for ; Wed, 25 Jun 2003 02:47:18 -0700 (PDT) (envelope-from andy@bribed.net) Received: from andy by andy.btvs.net with local (Exim 4.10) id 19V6sl-000PxI-00 for freebsd-ipfw@freebsd.org; Wed, 25 Jun 2003 10:48:03 +0100 Date: Wed, 25 Jun 2003 10:48:02 +0100 From: Andy Coates To: freebsd-ipfw@freebsd.org Message-ID: <20030625094802.GK84062@andy.btvs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 09:47:18 -0000 Hi, Up until now I've been fairly happy with just using a simple pipe with: pipe 1 config bw 2400Kbit/s However recently under a more utilised link we start to see every third packet or so have a higher latency than the rest. For example, an icmp ping to the host would show 10ms, 10ms, and then 190ms, then back to 10ms for another 2 pings and upto 190ms again. I decided to play with the queue settings, and tried: pipe 1 config bw 2400Kbit/s queue 15 This then brought that third ping down to 70ms, so an improvement. This still isn't acceptable however, since the amount of bandwidth being used is only 1000Kbit/s so I can't see where the problem is. Is there anything else I can change to improve the response/latency? Or is this some type of bug? Thanks in advance. Andy. From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 03:08:10 2003 Return-Path: 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 2271737B401 for ; Wed, 25 Jun 2003 03:08:10 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F4F143FB1 for ; Wed, 25 Jun 2003 03:08:09 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h5PA86Qg087587; Wed, 25 Jun 2003 03:08:06 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h5PA86OF087586; Wed, 25 Jun 2003 03:08:06 -0700 (PDT) (envelope-from rizzo) Date: Wed, 25 Jun 2003 03:08:06 -0700 From: Luigi Rizzo To: Andy Coates Message-ID: <20030625030805.B87521@xorpc.icir.org> References: <20030625094802.GK84062@andy.btvs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030625094802.GK84062@andy.btvs.net>; from andy@bribed.net on Wed, Jun 25, 2003 at 10:48:02AM +0100 cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 10:08:10 -0000 you must have some huge traffic source somewhere else which perhaps fires every 3 seconds ? The default queue is 50 slots so the fact that reducing the queue to 15 brings the latency down to 70ms probably means that for some reason the queue is almost full cheers luigi On Wed, Jun 25, 2003 at 10:48:02AM +0100, Andy Coates wrote: > Hi, > > Up until now I've been fairly happy with just using a simple pipe with: > > pipe 1 config bw 2400Kbit/s > > However recently under a more utilised link we start to see every third > packet or so have a higher latency than the rest. For example, an icmp > ping to the host would show 10ms, 10ms, and then 190ms, then back to 10ms > for another 2 pings and upto 190ms again. > > I decided to play with the queue settings, and tried: > > pipe 1 config bw 2400Kbit/s queue 15 > > This then brought that third ping down to 70ms, so an improvement. This > still isn't acceptable however, since the amount of bandwidth being used > is only 1000Kbit/s so I can't see where the problem is. > > Is there anything else I can change to improve the response/latency? Or > is this some type of bug? > > Thanks in advance. > > Andy. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 03:15:04 2003 Return-Path: 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 67C8037B401 for ; Wed, 25 Jun 2003 03:15:04 -0700 (PDT) Received: from andy.btvs.net (andy.btvs.net [80.253.107.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFCAE43FF3 for ; Wed, 25 Jun 2003 03:15:03 -0700 (PDT) (envelope-from andy@bribed.net) Received: from andy by andy.btvs.net with local (Exim 4.10) id 19V7Jc-000Pyh-00; Wed, 25 Jun 2003 11:15:48 +0100 Date: Wed, 25 Jun 2003 11:15:48 +0100 From: Andy Coates To: Luigi Rizzo Message-ID: <20030625101548.GL84062@andy.btvs.net> References: <20030625094802.GK84062@andy.btvs.net> <20030625030805.B87521@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030625030805.B87521@xorpc.icir.org> User-Agent: Mutt/1.4.1i cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 10:15:04 -0000 Luigi Rizzo (rizzo@icir.org) wrote: > you must have some huge traffic source somewhere else which perhaps > fires every 3 seconds ? > The default queue is 50 slots so the fact that reducing the > queue to 15 brings the latency down to 70ms probably means > that for some reason the queue is almost full There's nothing that fires every 3 seconds - I've sat and constantly watched the interface with trafshow etc. The level is usually always constant at 1000Kbit/s (maybe rising to 1200 or so, but no where near the 2400 the limit is set to) And I also agree about the queue, but no matter how I tweak that part there is still that intermittent latency. Andy. From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 03:27:18 2003 Return-Path: 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 DC3B637B401 for ; Wed, 25 Jun 2003 03:27:17 -0700 (PDT) Received: from andy.btvs.net (andy.btvs.net [80.253.107.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2840E43FAF for ; Wed, 25 Jun 2003 03:27:17 -0700 (PDT) (envelope-from andy@bribed.net) Received: from andy by andy.btvs.net with local (Exim 4.10) id 19V7VR-000PzN-00 for freebsd-ipfw@freebsd.org; Wed, 25 Jun 2003 11:28:01 +0100 Date: Wed, 25 Jun 2003 11:28:01 +0100 From: Andy Coates To: freebsd-ipfw@freebsd.org Message-ID: <20030625102801.GM84062@andy.btvs.net> References: <20030625094802.GK84062@andy.btvs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030625094802.GK84062@andy.btvs.net> User-Agent: Mutt/1.4.1i Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 10:27:18 -0000 Andy Coates (andy@bribed.net) wrote: > Hi, > > Up until now I've been fairly happy with just using a simple pipe with: > > pipe 1 config bw 2400Kbit/s > > However recently under a more utilised link we start to see every third > packet or so have a higher latency than the rest. For example, an icmp > ping to the host would show 10ms, 10ms, and then 190ms, then back to 10ms > for another 2 pings and upto 190ms again. > > I decided to play with the queue settings, and tried: > > pipe 1 config bw 2400Kbit/s queue 15 > > This then brought that third ping down to 70ms, so an improvement. This > still isn't acceptable however, since the amount of bandwidth being used > is only 1000Kbit/s so I can't see where the problem is. > > Is there anything else I can change to improve the response/latency? Or > is this some type of bug? Just to clarify what I mean: 64 bytes from x.x.x.x: icmp_seq=0 ttl=248 time=70.803 ms 64 bytes from x.x.x.x: icmp_seq=1 ttl=248 time=3.850 ms 64 bytes from x.x.x.x: icmp_seq=2 ttl=248 time=3.551 ms 64 bytes from x.x.x.x: icmp_seq=3 ttl=248 time=123.844 ms 64 bytes from x.x.x.x: icmp_seq=4 ttl=248 time=3.759 ms 64 bytes from x.x.x.x: icmp_seq=5 ttl=248 time=3.600 ms 64 bytes from x.x.x.x: icmp_seq=6 ttl=248 time=3.507 ms 64 bytes from x.x.x.x: icmp_seq=7 ttl=248 time=3.687 ms 64 bytes from x.x.x.x: icmp_seq=8 ttl=248 time=3.594 ms 64 bytes from x.x.x.x: icmp_seq=9 ttl=248 time=3.527 ms 64 bytes from x.x.x.x: icmp_seq=10 ttl=248 time=23.543 ms 64 bytes from x.x.x.x: icmp_seq=11 ttl=248 time=123.615 ms 64 bytes from x.x.x.x: icmp_seq=12 ttl=248 time=3.637 ms 64 bytes from x.x.x.x: icmp_seq=13 ttl=248 time=3.661 ms 64 bytes from x.x.x.x: icmp_seq=14 ttl=248 time=103.323 ms 64 bytes from x.x.x.x: icmp_seq=15 ttl=248 time=13.101 ms 64 bytes from x.x.x.x: icmp_seq=16 ttl=248 time=3.569 ms 64 bytes from x.x.x.x: icmp_seq=17 ttl=248 time=23.151 ms 64 bytes from x.x.x.x: icmp_seq=18 ttl=248 time=92.962 ms 64 bytes from x.x.x.x: icmp_seq=19 ttl=248 time=3.555 ms 64 bytes from x.x.x.x: icmp_seq=20 ttl=248 time=43.122 ms 64 bytes from x.x.x.x: icmp_seq=21 ttl=248 time=72.781 ms 64 bytes from x.x.x.x: icmp_seq=22 ttl=248 time=3.547 ms 64 bytes from x.x.x.x: icmp_seq=23 ttl=248 time=122.583 ms 64 bytes from x.x.x.x: icmp_seq=24 ttl=248 time=42.509 ms 64 bytes from x.x.x.x: icmp_seq=25 ttl=248 time=3.540 ms 64 bytes from x.x.x.x: icmp_seq=26 ttl=248 time=52.660 ms Thats just plain odd to me. Andy. From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 06:35:54 2003 Return-Path: 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 EF6C337B405 for ; Wed, 25 Jun 2003 06:35:53 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54E2943FEA for ; Wed, 25 Jun 2003 06:35:53 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h5PDZoQg000318; Wed, 25 Jun 2003 06:35:50 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h5PDZnd3000311; Wed, 25 Jun 2003 06:35:49 -0700 (PDT) (envelope-from rizzo) Date: Wed, 25 Jun 2003 06:35:49 -0700 From: Luigi Rizzo To: Andy Coates Message-ID: <20030625063549.A99499@xorpc.icir.org> References: <20030625094802.GK84062@andy.btvs.net> <20030625102801.GM84062@andy.btvs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030625102801.GM84062@andy.btvs.net>; from andy@bribed.net on Wed, Jun 25, 2003 at 11:28:01AM +0100 cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 13:35:54 -0000 On Wed, Jun 25, 2003 at 11:28:01AM +0100, Andy Coates wrote: > Andy Coates (andy@bribed.net) wrote: ... > > However recently under a more utilised link we start to see every third > > packet or so have a higher latency than the rest. For example, an icmp ... > > ping to the host would show 10ms, 10ms, and then 190ms, then back to 10ms > > for another 2 pings and upto 190ms again. well your numbers below are actually quite different from your description above -- anyways, pleaspost the output of ipfw pipe show to see what is going on in the pipe. My impression is still that you have a fair amount of (bursty) traffic going through the pipe which causes queues to build up. cheers luigi > > I decided to play with the queue settings, and tried: > > > > pipe 1 config bw 2400Kbit/s queue 15 > > > > This then brought that third ping down to 70ms, so an improvement. This > > still isn't acceptable however, since the amount of bandwidth being used > > is only 1000Kbit/s so I can't see where the problem is. > > > > Is there anything else I can change to improve the response/latency? Or > > is this some type of bug? > > Just to clarify what I mean: > > 64 bytes from x.x.x.x: icmp_seq=0 ttl=248 time=70.803 ms > 64 bytes from x.x.x.x: icmp_seq=1 ttl=248 time=3.850 ms > 64 bytes from x.x.x.x: icmp_seq=2 ttl=248 time=3.551 ms > 64 bytes from x.x.x.x: icmp_seq=3 ttl=248 time=123.844 ms > 64 bytes from x.x.x.x: icmp_seq=4 ttl=248 time=3.759 ms > 64 bytes from x.x.x.x: icmp_seq=5 ttl=248 time=3.600 ms > 64 bytes from x.x.x.x: icmp_seq=6 ttl=248 time=3.507 ms > 64 bytes from x.x.x.x: icmp_seq=7 ttl=248 time=3.687 ms > 64 bytes from x.x.x.x: icmp_seq=8 ttl=248 time=3.594 ms > 64 bytes from x.x.x.x: icmp_seq=9 ttl=248 time=3.527 ms > 64 bytes from x.x.x.x: icmp_seq=10 ttl=248 time=23.543 ms > 64 bytes from x.x.x.x: icmp_seq=11 ttl=248 time=123.615 ms > 64 bytes from x.x.x.x: icmp_seq=12 ttl=248 time=3.637 ms > 64 bytes from x.x.x.x: icmp_seq=13 ttl=248 time=3.661 ms > 64 bytes from x.x.x.x: icmp_seq=14 ttl=248 time=103.323 ms > 64 bytes from x.x.x.x: icmp_seq=15 ttl=248 time=13.101 ms > 64 bytes from x.x.x.x: icmp_seq=16 ttl=248 time=3.569 ms > 64 bytes from x.x.x.x: icmp_seq=17 ttl=248 time=23.151 ms > 64 bytes from x.x.x.x: icmp_seq=18 ttl=248 time=92.962 ms > 64 bytes from x.x.x.x: icmp_seq=19 ttl=248 time=3.555 ms > 64 bytes from x.x.x.x: icmp_seq=20 ttl=248 time=43.122 ms > 64 bytes from x.x.x.x: icmp_seq=21 ttl=248 time=72.781 ms > 64 bytes from x.x.x.x: icmp_seq=22 ttl=248 time=3.547 ms > 64 bytes from x.x.x.x: icmp_seq=23 ttl=248 time=122.583 ms > 64 bytes from x.x.x.x: icmp_seq=24 ttl=248 time=42.509 ms > 64 bytes from x.x.x.x: icmp_seq=25 ttl=248 time=3.540 ms > 64 bytes from x.x.x.x: icmp_seq=26 ttl=248 time=52.660 ms > > > Thats just plain odd to me. > > Andy. > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 06:59:59 2003 Return-Path: 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 597A837B404 for ; Wed, 25 Jun 2003 06:59:59 -0700 (PDT) Received: from mout2.freenet.de (mout2.freenet.de [194.97.50.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B4ED44017 for ; Wed, 25 Jun 2003 06:59:56 -0700 (PDT) (envelope-from ino-qc@spotteswoode.de.eu.org) Received: from [194.97.55.147] (helo=mx4.freenet.de) by mout2.freenet.de with asmtp (Exim 4.20) id 19VAoW-0004C7-3Q for freebsd-ipfw@freebsd.org; Wed, 25 Jun 2003 15:59:56 +0200 Received: from p3e9baaac.dip.t-dialin.net ([62.155.170.172] helo=spotteswoode.dnsalias.org) by mx4.freenet.de with asmtp (ID inode@freenet.de) (Exim 4.20 #1) id 19VAoV-0003dx-LW for freebsd-ipfw@freebsd.org; Wed, 25 Jun 2003 15:59:55 +0200 Received: (qmail 14605 invoked by uid 0); 25 Jun 2003 13:59:55 -0000 Date: 25 Jun 2003 15:59:54 +0200 Message-ID: From: "clemens fischer" To: "Andy Coates" In-Reply-To: <20030625102801.GM84062@andy.btvs.net> (Andy Coates's message of "Wed, 25 Jun 2003 11:28:01 +0100") References: <20030625094802.GK84062@andy.btvs.net> <20030625102801.GM84062@andy.btvs.net> User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 13:59:59 -0000 * Andy Coates: > 64 bytes from x.x.x.x: icmp_seq=0 ttl=248 time=70.803 ms > 64 bytes from x.x.x.x: icmp_seq=1 ttl=248 time=3.850 ms > 64 bytes from x.x.x.x: icmp_seq=2 ttl=248 time=3.551 ms > 64 bytes from x.x.x.x: icmp_seq=3 ttl=248 time=123.844 ms what type of network-card do you have installed? some people claim that this can be an issue with the card, although i don't believe this having tried a couple. PING (some external host): 56 data bytes 64 bytes from x1.x2.x3.x4: icmp_seq=0 ttl=246 time=74.959 ms 64 bytes from x1.x2.x3.x4: icmp_seq=1 ttl=246 time=69.179 ms 64 bytes from x1.x2.x3.x4: icmp_seq=2 ttl=246 time=68.582 ms 64 bytes from x1.x2.x3.x4: icmp_seq=3 ttl=246 time=70.825 ms 64 bytes from x1.x2.x3.x4: icmp_seq=4 ttl=246 time=69.149 ms 64 bytes from x1.x2.x3.x4: icmp_seq=5 ttl=246 time=68.967 ms 64 bytes from x1.x2.x3.x4: icmp_seq=6 ttl=246 time=67.849 ms 64 bytes from x1.x2.x3.x4: icmp_seq=7 ttl=246 time=69.080 ms 64 bytes from x1.x2.x3.x4: icmp_seq=8 ttl=246 time=68.407 ms 64 bytes from x1.x2.x3.x4: icmp_seq=9 ttl=246 time=67.727 ms 64 bytes from x1.x2.x3.x4: icmp_seq=10 ttl=246 time=69.813 ms 64 bytes from x1.x2.x3.x4: icmp_seq=11 ttl=246 time=70.237 ms 64 bytes from x1.x2.x3.x4: icmp_seq=12 ttl=246 time=70.484 ms 64 bytes from x1.x2.x3.x4: icmp_seq=13 ttl=246 time=68.549 ms 64 bytes from x1.x2.x3.x4: icmp_seq=14 ttl=246 time=70.120 ms 64 bytes from x1.x2.x3.x4: icmp_seq=15 ttl=246 time=69.537 ms 64 bytes from x1.x2.x3.x4: icmp_seq=16 ttl=246 time=1075.376 ms 64 bytes from x1.x2.x3.x4: icmp_seq=17 ttl=246 time=75.057 ms 64 bytes from x1.x2.x3.x4: icmp_seq=18 ttl=246 time=1076.529 ms 64 bytes from x1.x2.x3.x4: icmp_seq=19 ttl=246 time=74.996 ms 64 bytes from x1.x2.x3.x4: icmp_seq=20 ttl=246 time=69.312 ms 64 bytes from x1.x2.x3.x4: icmp_seq=21 ttl=246 time=70.170 ms 64 bytes from x1.x2.x3.x4: icmp_seq=22 ttl=246 time=71.475 ms 64 bytes from x1.x2.x3.x4: icmp_seq=23 ttl=246 time=69.761 ms 64 bytes from x1.x2.x3.x4: icmp_seq=24 ttl=246 time=67.868 ms i don't use any type of pipes/queues, and have been noticing this "phenomenon" for years without any god explanation. there's not much traffic into or out of this workstation, no bursts correlating with these delays. this is on A-DSL line. my firewall rules changed considerably over time, but not these numbers. the quoted delays appear on every tenth packet on average. clemens From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 07:11:37 2003 Return-Path: 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 3F97237B401 for ; Wed, 25 Jun 2003 07:11:37 -0700 (PDT) Received: from andy.btvs.net (andy.btvs.net [80.253.107.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61A0443FF2 for ; Wed, 25 Jun 2003 07:11:36 -0700 (PDT) (envelope-from andy@bribed.net) Received: from andy by andy.btvs.net with local (Exim 4.10) id 19VB0W-0000C9-00; Wed, 25 Jun 2003 15:12:20 +0100 Date: Wed, 25 Jun 2003 15:12:20 +0100 From: Andy Coates To: Luigi Rizzo Message-ID: <20030625141220.GV84062@andy.btvs.net> References: <20030625094802.GK84062@andy.btvs.net> <20030625102801.GM84062@andy.btvs.net> <20030625063549.A99499@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030625063549.A99499@xorpc.icir.org> User-Agent: Mutt/1.4.1i cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 14:11:37 -0000 Luigi Rizzo (rizzo@icir.org) wrote: > On Wed, Jun 25, 2003 at 11:28:01AM +0100, Andy Coates wrote: > > Andy Coates (andy@bribed.net) wrote: > ... > > > However recently under a more utilised link we start to see every third > > > packet or so have a higher latency than the rest. For example, an icmp > ... > > > ping to the host would show 10ms, 10ms, and then 190ms, then back to 10ms > > > for another 2 pings and upto 190ms again. > > well your numbers below are actually quite different from > your description above -- anyways, pleaspost the output of > > ipfw pipe show Sorry, the numbers were just examples - the ones below were the ones currently. It also depends on the amount being utilised, as when we're pushing 1500Kbit/s it can go a lot higher and vary more. With just the straight "pipe 1 config bw 2400Kbit/s": 00001: 2.400 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 xx.xx.xx.xx/2103 xx.xx.xx.xx/1238 424 44493 0 0 0 00002: 2.400 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 xx.xx.xx.xx/22 xx.xx.xx.xx/33231 477 360621 0 0 0 Bear in mind i've been tweaking the values so they keep restting the figures. When I add the "queue X" option, the slots change, as below: 00001: 2.400 Mbit/s 0 ms 15 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 xx.xx.xx.xx/32855 xx.xx.xx.xx/22 1967 219937 0 0 0 00002: 2.400 Mbit/s 0 ms 15 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 xx.xx.xx.xx/22 xx.xx.xx.xx/33231 2571 2236734 0 0 18 That was just for 15 slots, i've been trying different numbers since there would be a level at which they don't drop - but the latency still remains. > to see what is going on in the pipe. My impression is still that > you have a fair amount of (bursty) traffic going through the > pipe which causes queues to build up. I wouldn't call it bursty to the point where its varying by 50% or more. And this happens at all levels of traffic (the numbers just vary, but the odd packet still peaks). I'm going to try and upgrade to 4.8-STABLE (it'll be a while since its a production server and will have to be scheduled), but "rmkml" has been helping me off-list try different versions and there might be something different between 4.7 and 4.8 Andy. > cheers > luigi > > > > I decided to play with the queue settings, and tried: > > > > > > pipe 1 config bw 2400Kbit/s queue 15 > > > > > > This then brought that third ping down to 70ms, so an improvement. This > > > still isn't acceptable however, since the amount of bandwidth being used > > > is only 1000Kbit/s so I can't see where the problem is. > > > > > > Is there anything else I can change to improve the response/latency? Or > > > is this some type of bug? > > > > Just to clarify what I mean: > > > > 64 bytes from x.x.x.x: icmp_seq=0 ttl=248 time=70.803 ms > > 64 bytes from x.x.x.x: icmp_seq=1 ttl=248 time=3.850 ms > > 64 bytes from x.x.x.x: icmp_seq=2 ttl=248 time=3.551 ms > > 64 bytes from x.x.x.x: icmp_seq=3 ttl=248 time=123.844 ms > > 64 bytes from x.x.x.x: icmp_seq=4 ttl=248 time=3.759 ms > > 64 bytes from x.x.x.x: icmp_seq=5 ttl=248 time=3.600 ms > > 64 bytes from x.x.x.x: icmp_seq=6 ttl=248 time=3.507 ms > > 64 bytes from x.x.x.x: icmp_seq=7 ttl=248 time=3.687 ms > > 64 bytes from x.x.x.x: icmp_seq=8 ttl=248 time=3.594 ms > > 64 bytes from x.x.x.x: icmp_seq=9 ttl=248 time=3.527 ms > > 64 bytes from x.x.x.x: icmp_seq=10 ttl=248 time=23.543 ms > > 64 bytes from x.x.x.x: icmp_seq=11 ttl=248 time=123.615 ms > > 64 bytes from x.x.x.x: icmp_seq=12 ttl=248 time=3.637 ms > > 64 bytes from x.x.x.x: icmp_seq=13 ttl=248 time=3.661 ms > > 64 bytes from x.x.x.x: icmp_seq=14 ttl=248 time=103.323 ms > > 64 bytes from x.x.x.x: icmp_seq=15 ttl=248 time=13.101 ms > > 64 bytes from x.x.x.x: icmp_seq=16 ttl=248 time=3.569 ms > > 64 bytes from x.x.x.x: icmp_seq=17 ttl=248 time=23.151 ms > > 64 bytes from x.x.x.x: icmp_seq=18 ttl=248 time=92.962 ms > > 64 bytes from x.x.x.x: icmp_seq=19 ttl=248 time=3.555 ms > > 64 bytes from x.x.x.x: icmp_seq=20 ttl=248 time=43.122 ms > > 64 bytes from x.x.x.x: icmp_seq=21 ttl=248 time=72.781 ms > > 64 bytes from x.x.x.x: icmp_seq=22 ttl=248 time=3.547 ms > > 64 bytes from x.x.x.x: icmp_seq=23 ttl=248 time=122.583 ms > > 64 bytes from x.x.x.x: icmp_seq=24 ttl=248 time=42.509 ms > > 64 bytes from x.x.x.x: icmp_seq=25 ttl=248 time=3.540 ms > > 64 bytes from x.x.x.x: icmp_seq=26 ttl=248 time=52.660 ms > > > > > > Thats just plain odd to me. > > > > Andy. > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" -- n: Andy Coates e: andy@bribed.net From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 07:13:37 2003 Return-Path: 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 E5DB237B401 for ; Wed, 25 Jun 2003 07:13:37 -0700 (PDT) Received: from andy.btvs.net (andy.btvs.net [80.253.107.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C57E44011 for ; Wed, 25 Jun 2003 07:13:37 -0700 (PDT) (envelope-from andy@bribed.net) Received: from andy by andy.btvs.net with local (Exim 4.10) id 19VB2S-0000CK-00; Wed, 25 Jun 2003 15:14:20 +0100 Date: Wed, 25 Jun 2003 15:14:20 +0100 From: Andy Coates To: clemens fischer Message-ID: <20030625141420.GW84062@andy.btvs.net> References: <20030625094802.GK84062@andy.btvs.net> <20030625102801.GM84062@andy.btvs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 14:13:38 -0000 clemens fischer (ino-qc@spotteswoode.de.eu.org) wrote: > * Andy Coates: > > > 64 bytes from x.x.x.x: icmp_seq=0 ttl=248 time=70.803 ms > > 64 bytes from x.x.x.x: icmp_seq=1 ttl=248 time=3.850 ms > > 64 bytes from x.x.x.x: icmp_seq=2 ttl=248 time=3.551 ms > > 64 bytes from x.x.x.x: icmp_seq=3 ttl=248 time=123.844 ms > > what type of network-card do you have installed? some people claim > that this can be an issue with the card, although i don't believe this > having tried a couple. > > PING (some external host): 56 data bytes > 64 bytes from x1.x2.x3.x4: icmp_seq=0 ttl=246 time=74.959 ms [snip] The card is onboard (its an IBM netfinity 400R 1U high rackable type), but uses the FXP driver: fxp0@pci0:17:0: class=0x020000 card=0x105c1014 chip=0x12298086 rev=0x08 hdr=0x00 vendor = 'Intel Corporation' device = '82557/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet Also, if I remove all limiting (bw 0), there is no problem - so I wouldn't say its a hardware fault. Just when the limiting is applied... Cheers, Andy. From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 07:22:05 2003 Return-Path: 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 8EFCE37B401 for ; Wed, 25 Jun 2003 07:22:05 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E371D43FF2 for ; Wed, 25 Jun 2003 07:22:04 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h5PEM2Qg022147; Wed, 25 Jun 2003 07:22:02 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h5PEM263022146; Wed, 25 Jun 2003 07:22:02 -0700 (PDT) (envelope-from rizzo) Date: Wed, 25 Jun 2003 07:22:02 -0700 From: Luigi Rizzo To: Andy Coates Message-ID: <20030625072202.A19239@xorpc.icir.org> References: <20030625094802.GK84062@andy.btvs.net> <20030625102801.GM84062@andy.btvs.net> <20030625063549.A99499@xorpc.icir.org> <20030625141220.GV84062@andy.btvs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030625141220.GV84062@andy.btvs.net>; from andy@bribed.net on Wed, Jun 25, 2003 at 03:12:20PM +0100 cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 14:22:05 -0000 ok then it is very clear what is going on. You have some connection which occasionally sends a burst of data (more than 15 pkts because you have drops, but perhaps less than 50 as you don't see drops with a queue of 50), which in turn causes the long delay. 123ms at 2.4Mbit/s are approx 300Kbits or 32Kbytes of data + headers, or 22-23 full-sized packets. Given the above numbers, I suspect (indeed, I would bet money on this!) that the offender is a TCP connection which has the window fully open and sends data intermittently -- e.g. a persistent http connection, or even the typical ssh connection in response to a command that causes a large burst of data. cheers luigi On Wed, Jun 25, 2003 at 03:12:20PM +0100, Andy Coates wrote: > Luigi Rizzo (rizzo@icir.org) wrote: > > On Wed, Jun 25, 2003 at 11:28:01AM +0100, Andy Coates wrote: > > > Andy Coates (andy@bribed.net) wrote: > > ... > > > > However recently under a more utilised link we start to see every third > > > > packet or so have a higher latency than the rest. For example, an icmp > > ... > > > > ping to the host would show 10ms, 10ms, and then 190ms, then back to 10ms > > > > for another 2 pings and upto 190ms again. > > > > well your numbers below are actually quite different from > > your description above -- anyways, pleaspost the output of > > > > ipfw pipe show > > Sorry, the numbers were just examples - the ones below were the ones currently. > It also depends on the amount being utilised, as when we're pushing 1500Kbit/s > it can go a lot higher and vary more. > > With just the straight "pipe 1 config bw 2400Kbit/s": > > 00001: 2.400 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 xx.xx.xx.xx/2103 xx.xx.xx.xx/1238 424 44493 0 0 0 > > 00002: 2.400 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 xx.xx.xx.xx/22 xx.xx.xx.xx/33231 477 360621 0 0 0 > > Bear in mind i've been tweaking the values so they keep restting the figures. > > When I add the "queue X" option, the slots change, as below: > > > 00001: 2.400 Mbit/s 0 ms 15 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 xx.xx.xx.xx/32855 xx.xx.xx.xx/22 1967 219937 0 0 0 > > 00002: 2.400 Mbit/s 0 ms 15 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 xx.xx.xx.xx/22 xx.xx.xx.xx/33231 2571 2236734 0 0 18 > > That was just for 15 slots, i've been trying different numbers since there > would be a level at which they don't drop - but the latency still remains. > > > > to see what is going on in the pipe. My impression is still that > > you have a fair amount of (bursty) traffic going through the > > pipe which causes queues to build up. > > I wouldn't call it bursty to the point where its varying by 50% or more. > And this happens at all levels of traffic (the numbers just vary, but the > odd packet still peaks). > > I'm going to try and upgrade to 4.8-STABLE (it'll be a while since its a > production server and will have to be scheduled), but "rmkml" has been > helping me off-list try different versions and there might be something > different between 4.7 and 4.8 > > > Andy. > > > > > > cheers > > luigi > > > > > > I decided to play with the queue settings, and tried: > > > > > > > > pipe 1 config bw 2400Kbit/s queue 15 > > > > > > > > This then brought that third ping down to 70ms, so an improvement. This > > > > still isn't acceptable however, since the amount of bandwidth being used > > > > is only 1000Kbit/s so I can't see where the problem is. > > > > > > > > Is there anything else I can change to improve the response/latency? Or > > > > is this some type of bug? > > > > > > Just to clarify what I mean: > > > > > > 64 bytes from x.x.x.x: icmp_seq=0 ttl=248 time=70.803 ms > > > 64 bytes from x.x.x.x: icmp_seq=1 ttl=248 time=3.850 ms > > > 64 bytes from x.x.x.x: icmp_seq=2 ttl=248 time=3.551 ms > > > 64 bytes from x.x.x.x: icmp_seq=3 ttl=248 time=123.844 ms > > > 64 bytes from x.x.x.x: icmp_seq=4 ttl=248 time=3.759 ms > > > 64 bytes from x.x.x.x: icmp_seq=5 ttl=248 time=3.600 ms > > > 64 bytes from x.x.x.x: icmp_seq=6 ttl=248 time=3.507 ms > > > 64 bytes from x.x.x.x: icmp_seq=7 ttl=248 time=3.687 ms > > > 64 bytes from x.x.x.x: icmp_seq=8 ttl=248 time=3.594 ms > > > 64 bytes from x.x.x.x: icmp_seq=9 ttl=248 time=3.527 ms > > > 64 bytes from x.x.x.x: icmp_seq=10 ttl=248 time=23.543 ms > > > 64 bytes from x.x.x.x: icmp_seq=11 ttl=248 time=123.615 ms > > > 64 bytes from x.x.x.x: icmp_seq=12 ttl=248 time=3.637 ms > > > 64 bytes from x.x.x.x: icmp_seq=13 ttl=248 time=3.661 ms > > > 64 bytes from x.x.x.x: icmp_seq=14 ttl=248 time=103.323 ms > > > 64 bytes from x.x.x.x: icmp_seq=15 ttl=248 time=13.101 ms > > > 64 bytes from x.x.x.x: icmp_seq=16 ttl=248 time=3.569 ms > > > 64 bytes from x.x.x.x: icmp_seq=17 ttl=248 time=23.151 ms > > > 64 bytes from x.x.x.x: icmp_seq=18 ttl=248 time=92.962 ms > > > 64 bytes from x.x.x.x: icmp_seq=19 ttl=248 time=3.555 ms > > > 64 bytes from x.x.x.x: icmp_seq=20 ttl=248 time=43.122 ms > > > 64 bytes from x.x.x.x: icmp_seq=21 ttl=248 time=72.781 ms > > > 64 bytes from x.x.x.x: icmp_seq=22 ttl=248 time=3.547 ms > > > 64 bytes from x.x.x.x: icmp_seq=23 ttl=248 time=122.583 ms > > > 64 bytes from x.x.x.x: icmp_seq=24 ttl=248 time=42.509 ms > > > 64 bytes from x.x.x.x: icmp_seq=25 ttl=248 time=3.540 ms > > > 64 bytes from x.x.x.x: icmp_seq=26 ttl=248 time=52.660 ms > > > > > > > > > Thats just plain odd to me. > > > > > > Andy. > > > _______________________________________________ > > > freebsd-ipfw@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > -- > n: Andy Coates e: andy@bribed.net > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 07:43:11 2003 Return-Path: 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 9027537B401 for ; Wed, 25 Jun 2003 07:43:11 -0700 (PDT) Received: from andy.btvs.net (andy.btvs.net [80.253.107.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id E54BA43FF7 for ; Wed, 25 Jun 2003 07:43:10 -0700 (PDT) (envelope-from andy@bribed.net) Received: from andy by andy.btvs.net with local (Exim 4.10) id 19VBV6-0000Do-00; Wed, 25 Jun 2003 15:43:56 +0100 Date: Wed, 25 Jun 2003 15:43:56 +0100 From: Andy Coates To: Luigi Rizzo Message-ID: <20030625144356.GX84062@andy.btvs.net> References: <20030625094802.GK84062@andy.btvs.net> <20030625102801.GM84062@andy.btvs.net> <20030625063549.A99499@xorpc.icir.org> <20030625141220.GV84062@andy.btvs.net> <20030625072202.A19239@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030625072202.A19239@xorpc.icir.org> User-Agent: Mutt/1.4.1i cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 14:43:11 -0000 Luigi Rizzo (rizzo@icir.org) wrote: > ok then it is very clear what is going on. > > You have some connection which occasionally sends a burst of > data (more than 15 pkts because you have drops, but perhaps > less than 50 as you don't see drops with a queue of 50), which > in turn causes the long delay. > > 123ms at 2.4Mbit/s are approx 300Kbits or 32Kbytes of data + headers, > or 22-23 full-sized packets. > > Given the above numbers, I suspect (indeed, I would bet money on > this!) that the offender is a TCP connection which has the window > fully open and sends data intermittently -- e.g. a persistent http > connection, or even the typical ssh connection in response to a > command that causes a large burst of data. Very interesting analysis. Of the traffic I know about that consumes the majority of bandwidth, one would be ftp transfers (usually 3 or 4 times an hour lasting 5 minutes or so) and the other would be a partial news feed (suck). I'm not sure how we can get this to work then. When we're not using these high packets/per/sec programs there doesn't seem to be a problem, but when we are and I raise the slots to 35 (this seems to be the point at which packets are no longer dropped) we still see the high latency: 64 bytes from xx.xx.xx.xx: icmp_seq=108 ttl=248 time=3.578 ms 64 bytes from xx.xx.xx.xx: icmp_seq=109 ttl=248 time=3.555 ms 64 bytes from xx.xx.xx.xx: icmp_seq=110 ttl=248 time=3.538 ms 64 bytes from xx.xx.xx.xx: icmp_seq=111 ttl=248 time=7.028 ms 64 bytes from xx.xx.xx.xx: icmp_seq=112 ttl=248 time=3.620 ms 64 bytes from xx.xx.xx.xx: icmp_seq=113 ttl=248 time=3.555 ms 64 bytes from xx.xx.xx.xx: icmp_seq=114 ttl=248 time=17.211 ms 64 bytes from xx.xx.xx.xx: icmp_seq=115 ttl=248 time=3.600 ms 64 bytes from xx.xx.xx.xx: icmp_seq=116 ttl=248 time=3.526 ms 64 bytes from xx.xx.xx.xx: icmp_seq=117 ttl=248 time=6.432 ms 64 bytes from xx.xx.xx.xx: icmp_seq=118 ttl=248 time=3.603 ms 64 bytes from xx.xx.xx.xx: icmp_seq=119 ttl=248 time=3.597 ms 64 bytes from xx.xx.xx.xx: icmp_seq=120 ttl=248 time=3.545 ms 64 bytes from xx.xx.xx.xx: icmp_seq=121 ttl=248 time=3.519 ms 64 bytes from xx.xx.xx.xx: icmp_seq=122 ttl=248 time=6.389 ms 64 bytes from xx.xx.xx.xx: icmp_seq=123 ttl=248 time=6.407 ms 64 bytes from xx.xx.xx.xx: icmp_seq=124 ttl=248 time=3.560 ms 64 bytes from xx.xx.xx.xx: icmp_seq=125 ttl=248 time=16.571 ms Granted its lower than before, but its still there. This is us using about 900Kbit/s at the moment - so i'm lost as to what options and parameters we should be using. Any suggestions? Cheers, Andy. From owner-freebsd-ipfw@FreeBSD.ORG Wed Jun 25 08:34:14 2003 Return-Path: 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 B205E37B401 for ; Wed, 25 Jun 2003 08:34:14 -0700 (PDT) Received: from mwinf0501.wanadoo.fr (smtp4.wanadoo.fr [193.252.22.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E48943FFB for ; Wed, 25 Jun 2003 08:34:11 -0700 (PDT) (envelope-from rmkml@wanadoo.fr) Received: from wanadoo.fr (unknown [193.252.202.101]) by mwinf0501.wanadoo.fr (SMTP Server) with ESMTP id 4989940020B; Wed, 25 Jun 2003 17:34:09 +0200 (CEST) Sender: test@wanadoo.fr Message-ID: <3EF9C0EC.FFD00673@wanadoo.fr> Date: Wed, 25 Jun 2003 17:34:04 +0200 From: rmkml X-Mailer: Mozilla 4.8 [en] (...; U; Linux 2.4.21 i686) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo References: <20030625094802.GK84062@andy.btvs.net> <20030625063549.A99499@xorpc.icir.org> <20030625072202.A19239@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-ipfw@freebsd.org cc: Andy Coates Subject: Re: ipfw bandwidth shaping problems (intermittent latency) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 15:34:15 -0000 Hi Luigi, On my test : I have PIV2ghz, 2 network card intel giga onboard, 1Goram, this gw is connected to two host on 100Mbit network, host A in internal intf, and host B in external intf this three host is dedicated to the test, no other traffic fbsd47release, (no patch/cvs) configure ipfw with pipe bw = 2400Kbit/s (no other rules/pipe/queue) send 20 ping A -> B, in 10ieme ping : +-10ms and in 20ieme ping : +-10ms other ping have +- 1ms on same gw with fbsd48release (no patch/cvs), no pb ... (+- 1ms) in kernel conf, I add IPFIREWALL and DUMMYNET and HZ=1000 (not IPFW2) and no other process in system ... You possible confirm this test on fbsd47 ? Regard. PS: sorry for my bad speak english. Luigi Rizzo wrote: > ok then it is very clear what is going on. > > You have some connection which occasionally sends a burst of > data (more than 15 pkts because you have drops, but perhaps > less than 50 as you don't see drops with a queue of 50), which > in turn causes the long delay. > > 123ms at 2.4Mbit/s are approx 300Kbits or 32Kbytes of data + headers, > or 22-23 full-sized packets. > > Given the above numbers, I suspect (indeed, I would bet money on > this!) that the offender is a TCP connection which has the window > fully open and sends data intermittently -- e.g. a persistent http > connection, or even the typical ssh connection in response to a > command that causes a large burst of data. > > cheers > luigi > > On Wed, Jun 25, 2003 at 03:12:20PM +0100, Andy Coates wrote: > > Luigi Rizzo (rizzo@icir.org) wrote: > > > On Wed, Jun 25, 2003 at 11:28:01AM +0100, Andy Coates wrote: > > > > Andy Coates (andy@bribed.net) wrote: > > > ... > > > > > However recently under a more utilised link we start to see every third > > > > > packet or so have a higher latency than the rest. For example, an icmp > > > ... > > > > > ping to the host would show 10ms, 10ms, and then 190ms, then back to 10ms > > > > > for another 2 pings and upto 190ms again. > > > > > > well your numbers below are actually quite different from > > > your description above -- anyways, pleaspost the output of > > > > > > ipfw pipe show > > > > Sorry, the numbers were just examples - the ones below were the ones currently. > > It also depends on the amount being utilised, as when we're pushing 1500Kbit/s > > it can go a lot higher and vary more. > > > > With just the straight "pipe 1 config bw 2400Kbit/s": > > > > 00001: 2.400 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 xx.xx.xx.xx/2103 xx.xx.xx.xx/1238 424 44493 0 0 0 > > > > 00002: 2.400 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 xx.xx.xx.xx/22 xx.xx.xx.xx/33231 477 360621 0 0 0 > > > > Bear in mind i've been tweaking the values so they keep restting the figures. > > > > When I add the "queue X" option, the slots change, as below: > > > > > > 00001: 2.400 Mbit/s 0 ms 15 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 xx.xx.xx.xx/32855 xx.xx.xx.xx/22 1967 219937 0 0 0 > > > > 00002: 2.400 Mbit/s 0 ms 15 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 xx.xx.xx.xx/22 xx.xx.xx.xx/33231 2571 2236734 0 0 18 > > > > That was just for 15 slots, i've been trying different numbers since there > > would be a level at which they don't drop - but the latency still remains. > > > > > > > to see what is going on in the pipe. My impression is still that > > > you have a fair amount of (bursty) traffic going through the > > > pipe which causes queues to build up. > > > > I wouldn't call it bursty to the point where its varying by 50% or more. > > And this happens at all levels of traffic (the numbers just vary, but the > > odd packet still peaks). > > > > I'm going to try and upgrade to 4.8-STABLE (it'll be a while since its a > > production server and will have to be scheduled), but "rmkml" has been > > helping me off-list try different versions and there might be something > > different between 4.7 and 4.8 > > > > > > Andy. > > > > > > > > > > > cheers > > > luigi > > > > > > > > I decided to play with the queue settings, and tried: > > > > > > > > > > pipe 1 config bw 2400Kbit/s queue 15 > > > > > > > > > > This then brought that third ping down to 70ms, so an improvement. This > > > > > still isn't acceptable however, since the amount of bandwidth being used > > > > > is only 1000Kbit/s so I can't see where the problem is. > > > > > > > > > > Is there anything else I can change to improve the response/latency? Or > > > > > is this some type of bug? > > > > > > > > Just to clarify what I mean: > > > > > > > > 64 bytes from x.x.x.x: icmp_seq=0 ttl=248 time=70.803 ms > > > > 64 bytes from x.x.x.x: icmp_seq=1 ttl=248 time=3.850 ms > > > > 64 bytes from x.x.x.x: icmp_seq=2 ttl=248 time=3.551 ms > > > > 64 bytes from x.x.x.x: icmp_seq=3 ttl=248 time=123.844 ms > > > > 64 bytes from x.x.x.x: icmp_seq=4 ttl=248 time=3.759 ms > > > > 64 bytes from x.x.x.x: icmp_seq=5 ttl=248 time=3.600 ms > > > > 64 bytes from x.x.x.x: icmp_seq=6 ttl=248 time=3.507 ms > > > > 64 bytes from x.x.x.x: icmp_seq=7 ttl=248 time=3.687 ms > > > > 64 bytes from x.x.x.x: icmp_seq=8 ttl=248 time=3.594 ms > > > > 64 bytes from x.x.x.x: icmp_seq=9 ttl=248 time=3.527 ms > > > > 64 bytes from x.x.x.x: icmp_seq=10 ttl=248 time=23.543 ms > > > > 64 bytes from x.x.x.x: icmp_seq=11 ttl=248 time=123.615 ms > > > > 64 bytes from x.x.x.x: icmp_seq=12 ttl=248 time=3.637 ms > > > > 64 bytes from x.x.x.x: icmp_seq=13 ttl=248 time=3.661 ms > > > > 64 bytes from x.x.x.x: icmp_seq=14 ttl=248 time=103.323 ms > > > > 64 bytes from x.x.x.x: icmp_seq=15 ttl=248 time=13.101 ms > > > > 64 bytes from x.x.x.x: icmp_seq=16 ttl=248 time=3.569 ms > > > > 64 bytes from x.x.x.x: icmp_seq=17 ttl=248 time=23.151 ms > > > > 64 bytes from x.x.x.x: icmp_seq=18 ttl=248 time=92.962 ms > > > > 64 bytes from x.x.x.x: icmp_seq=19 ttl=248 time=3.555 ms > > > > 64 bytes from x.x.x.x: icmp_seq=20 ttl=248 time=43.122 ms > > > > 64 bytes from x.x.x.x: icmp_seq=21 ttl=248 time=72.781 ms > > > > 64 bytes from x.x.x.x: icmp_seq=22 ttl=248 time=3.547 ms > > > > 64 bytes from x.x.x.x: icmp_seq=23 ttl=248 time=122.583 ms > > > > 64 bytes from x.x.x.x: icmp_seq=24 ttl=248 time=42.509 ms > > > > 64 bytes from x.x.x.x: icmp_seq=25 ttl=248 time=3.540 ms > > > > 64 bytes from x.x.x.x: icmp_seq=26 ttl=248 time=52.660 ms > > > > > > > > > > > > Thats just plain odd to me. > > > > > > > > Andy. > > > > _______________________________________________ > > > > freebsd-ipfw@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > _______________________________________________ > > > freebsd-ipfw@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > > > > -- > > n: Andy Coates e: andy@bribed.net > > _______________________________________________ > > freebsd-ipfw@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Sat Jun 28 09:16:59 2003 Return-Path: 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 4724337B401; Sat, 28 Jun 2003 09:16:59 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD09743FEC; Sat, 28 Jun 2003 09:16:58 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h5SGGwkN001252; Sat, 28 Jun 2003 09:16:58 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h5SGGwZ8001251; Sat, 28 Jun 2003 09:16:58 -0700 (PDT) (envelope-from rizzo) Date: Sat, 28 Jun 2003 09:16:58 -0700 From: Luigi Rizzo To: ipfw@freebsd.org Message-ID: <20030628091658.A1191@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Subject: HEADS-UP: ipfw2 in RELENG_4 has been sync'ed with -current X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 16:16:59 -0000 [Bcc to -alpha and -sparc64 as I would appreciate feedback from those users...] See the attached commit log... if you are using ipfw2 on RELENG_4, you need to rebuild /sbin/ipfw next time you update your kernel. Please have a look at the new features for iplen, ipttl and address ranges, they might simplify the writing of your rulesets. Finally, I would be grateful if alpha and/or sparc64 users could test this change and confirm that it works (it is the same one that was recently committed to -current). cheers luigi ----- Forwarded message from Luigi Rizzo ----- Date: Sat, 28 Jun 2003 09:12:14 -0700 (PDT) From: Luigi Rizzo Subject: cvs commit: src/sbin/ipfw ipfw.8 ipfw2.c src/sys/netinet ip_dummynet.c ip_fw2.c ip_fw2.h To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org luigi 2003/06/28 09:12:14 PDT FreeBSD src repository Modified files: (Branch: RELENG_4) sbin/ipfw ipfw.8 ipfw2.c sys/netinet ip_dummynet.c ip_fw2.c ip_fw2.h Log: MFC: sync ipfw2 (kernel, userland, manpage) with the version in -current. Among other things, this includes the following: + pass to the preprocessor all command-line options after -p (except the last one, the ruleset file) + add the "verrevpath" option + support strong alignment architectures such as alpha and sparc64; + support multiple values and ranges for "iplen", "ipttl", "ipid" options. + support range notations such as 1.2.3.4/24{5,6,7,10-20,60-90} for sets of IP addresses The changes (also those in sys/netinet/ip_dummynet.c) are all IPFW2-specific, which is entirely optional in RELENG_4 so there are no ABI issues for those using the standard ipfw[1]. Note, however, that ipfw2 users MUST REBUILD /sbin/ipfw together with the new kernel. Revision Changes Path 1.63.2.35 +67 -18 src/sbin/ipfw/ipfw.8 1.4.2.15 +148 -51 src/sbin/ipfw/ipfw2.c 1.24.2.24 +9 -1 src/sys/netinet/ip_dummynet.c 1.6.2.15 +94 -23 src/sys/netinet/ip_fw2.c 1.1.2.3 +15 -5 src/sys/netinet/ip_fw2.h ----- End forwarded message ----- From owner-freebsd-ipfw@FreeBSD.ORG Sat Jun 28 09:30:20 2003 Return-Path: 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 AE7D637B401 for ; Sat, 28 Jun 2003 09:30:20 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4563C43FE3 for ; Sat, 28 Jun 2003 09:30:20 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h5SGUKUp093283 for ; Sat, 28 Jun 2003 09:30:20 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h5SGUKsk093282; Sat, 28 Jun 2003 09:30:20 -0700 (PDT) Date: Sat, 28 Jun 2003 09:30:20 -0700 (PDT) Message-Id: <200306281630.h5SGUKsk093282@freefall.freebsd.org> To: ipfw@FreeBSD.org From: Luigi Rizzo Subject: Re: bin/50749: ipfw2 incorrectly parses ports and port ranges X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Luigi Rizzo List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jun 2003 16:30:21 -0000 The following reply was made to PR bin/50749; it has been noted by GNATS. From: Luigi Rizzo To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: bin/50749: ipfw2 incorrectly parses ports and port ranges Date: Sat, 28 Jun 2003 09:25:34 -0700 as the ipfw manpage says, dashes in service names must be escaped by a backslash (which in the shell must be escaped by a backslash, so you have to write ipfw add 1000 allow tcp from any to any ftp,ftp\\-data,ssh,www to make it work). So that part of the patch certainly does not apply. I agree that the parser should not silently drop the remaining of the string in case of an error. cheers luigi