Date: Fri, 03 May 2002 08:29:10 -0400 From: Bill Moran <wmoran@potentialtech.com> To: Budec <budec@qwest.net> Cc: questions@freebsd.org Subject: Re: Networking Buffers Message-ID: <3CD28296.10201@potentialtech.com> References: <NGBBIILBAKIFGHHCHOHPKEBLCOAA.budec@qwest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Budec wrote: > I am currently running FreeBSD i386 4.5 Stable and having some network > issuses. > > The machine is a 300 Mhz, AMD K6-2 with 512 meg ram and 2 intel ether net > pro nicks. > Has dual 100 Gig WD IDE drives, and one 4 gig samsung HD. > > The main purpose of this box is for firewall between networks and file > server. > > The network traffic on it is quite high, it currently rsyncs/robocopies to 4 > other servers > on the same network over a 100mb connection though smb/nfs and currently > routes all traffic between > 2 network, each with 10+ workstation that require a high amount of bandwidth > (real time network application + vnc sessions + file copies). > The box seems to keep up fine without network delays, but sometimes one of > the nics just freezes. > > The issuse I am having on it, is it seems I am "blowing out" one of the > nics. > I am sure this FreeBSD related, because this box use to run W2K with a > higher > network load and didn't expeirence any issuses. > > After a high spike it network load (when we backup all data in the middle of > the night) one > of the ip address will stop responding. I log in locally and the network > tables are fine, but > when I try to ping out of that network card it gives the error message > "ping: no buffers avaiable" Have you checked the output of "netstat -m" at this point? I was having weird problems with this kind of thing when using vtund to create an encrypted tunnel over a wireless WAN link. The problem went away when we improved the reliability of the wireless. I tend to suspect that the problem was that a lot of connections were getting dropped or boogered up due to lost packets, and that the buffer space was getting used up maintaining these hung connections. Turning on net.inet.tcp.always_keepalive my have solved this ... > Taking the nic up then back down (`ifconfig fxp0 down; ifconfig fxp0 up`) > will fix the issuse, but > is a huge problem because it is very distrubating to network operation, > espically during nightly > backups/data merges when no one is onsite. I replaced the nic with a brand > new one that is the same > model, and also with a new one that is a differant brand/model and it is > still having issuses. Not a solution, but as a workaround I made a cron job that would regularly do "ifconfig fxp0 down;ifconfig fxp0 up" just to ensure the thing wasn't frozen. As dangerous as this sounds, we experienced very few problems with it. An even better idea (until you find the proper solution) is the icmpmonitor port, which will monitor your network connectivity and execute commands for you when it fails. You could configure it to down/up the interface when the connectivity goes down. These are just workarounds, you need to find out what the problem is and fix it right. But, since you seem to be under fire, these should take the heat off you while you figure out the right solution. > In sysctl I changed (IIRC) "net.inet.tcp.sendspace" and "net.inet.recvspace" > both to 8192 (thinking it is Kb?), > that still had issuses, so I change it to 8192000 (thinking it might be > bytes) and also tried 8192000000. > All these settings still cause FreeBSD to drop the nic. What is the size of > these variables? (ie. mb, kb, etc ?) Read "man tuning" In addition to answering your question here, there are other options explained in this doc that may help you. > Also is there any type of intelligent networking buffering in FreeBSD? > Something that would > say "If network buffers are full, pause network traffic, flush buffers, > continue with network > traffic" ? How do you do that? If a number of connection are hung, which ones do you flush? Is it better to drop a long idle connection than to drop a new connection? Turn on net.inet.tcp.always_keepalive, that should ensure that you don't get idle connections hanging around too long. kern.ipc.somaxconn may help as well. -- Bill Moran Potential Technology http://www.potentialtech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CD28296.10201>