Date: Tue, 16 Jan 2001 09:20:17 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Antonio Carlos Pina <apina@infolink.com.br> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: Dummynet stopping ? Message-ID: <20010116092017.G91029@gsmx07.alcatel.com.au> In-Reply-To: <3a62e370.5b5.0@infolink.com.br>; from apina@infolink.com.br on Mon, Jan 15, 2001 at 09:48:00AM -0500 References: <3a62e370.5b5.0@infolink.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-Jan-15 09:48:00 -0500, Antonio Carlos Pina <apina@infolink.com.br> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010116092017.G91029>