From owner-freebsd-stable Mon Jan 15 14:21: 6 2001 Delivered-To: freebsd-stable@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id E30E737B401 for ; Mon, 15 Jan 2001 14:20:47 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id JAA04313; Tue, 16 Jan 2001 09:20:43 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01JYYXHSJRS0EMXV9L@cim.alcatel.com.au>; Tue, 16 Jan 2001 09:20:42 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.0/8.11.0) id f0FMKHB38355; Tue, 16 Jan 2001 09:20:17 +1100 (EST envelope-from jeremyp) Content-return: prohibited Date: Tue, 16 Jan 2001 09:20:17 +1100 From: Peter Jeremy Subject: Re: Dummynet stopping ? In-reply-to: <3a62e370.5b5.0@infolink.com.br>; from apina@infolink.com.br on Mon, Jan 15, 2001 at 09:48:00AM -0500 To: Antonio Carlos Pina Cc: freebsd-stable@FreeBSD.ORG Mail-followup-to: Antonio Carlos Pina , freebsd-stable@FreeBSD.ORG Message-id: <20010116092017.G91029@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <3a62e370.5b5.0@infolink.com.br> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2001-Jan-15 09:48:00 -0500, Antonio Carlos Pina wrote: >Today, after 2 months working like a charm, one of my dummynet pipes >stopped to pipe. The IP Address that it takes care was online and I >could even ping it from within my bridge machine, through his own >interface, but I couldn't ping or whatever from that ip address. That's really weird. The rules you posted are symmetrical, as is a ping - if you can ping his IP address, he should be able to ping your IP address. Did you check for other network problems (correct routes in both machines, appropriate ARP entries in both machines)? Did netstat or tcpdump show any traffic to/from that address via ep0? I presume there were no messages from the kernel. I'm also using dummynet and haven't noticed any similar problem (the machine in question has been up for just under 62 days). >I took a little look in ipfw pipe list, but I couldn't understand the >data that was showed (drps I presume are drops, it was increasing >while I was looking) The format is fairly self-explanatory. Since you aren't doing any address masking inside the pipe (the mask line is all zeroes), you should have a single bucket (BKT 0) on each pipe. The protocol, source and destination fields can be ignored. The remaining fields represent (in order) the total packets through the pipe, total bytes through the pipe, current packets queued in the pipe, current bytes queued in the pipe and number of packets dropped. If you created a pipe using "ipfw pipe 3 config bw 64Kbit/s", then your pipe can hold 50 packets (if the pipe has 50 packets in it, any extra packets sent to the pipe will be dropped). The bandwidth you specify is internally stored as bits per second (not bytes per tick as documented). An outgoing packet will be sent N ticks after the previous packet (where N = (packet_length * 8 * hz) / bandwidth). Obvious causes for the pipe not working are: - The dummynet scheduler has stopped. This can be checked with the sysctl net.inet.ip.dummynet.curr_time, which should be incrementing at HZ counts/sec. (This will affect all pipes). - Dummynet can't allocate memory for queued packets. This can be checked with "vmstat -m | grep IpFw". > I'm a bit concern because as I >can ping the IP address from within the bridge machine, I can't even >do a little script to test this situation and rebuild the pipes... :-/ The alternative would be to monitor the dropped packets and if the drop rate exceeds some limit, re-create the pipe. Your problem here is that you can't distinguish a drop because the pipe isn't working from a drop because the bandwidth is exceeded. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message