Mbuf Clusters on 4.8

[Greg Panula]

John Bdckstrand wrote:
> 
> Ive been googling quite a bit now for problems with
> running out of mbuf
> clusters. Im basically sending a 30k datachunk down
> 1000-4000 connections,
> but 1000 is more than enough to quickly fill upp 8192
> mbuf clusters. I also
> tried setting maximum amount of mbuf clusters to 65536,
> but that only made
> the box hard-wire 86MB of 96MB RAM, making it just as
> unsuable as a dead
> machine.

It isn't the amount data you are sending but the overhead required for
each network connection.

I would recommend adding more RAM.  Bump it up to 256MB.  With mbuf set
at 65536 and using 86MB, you should still have plenty left for your
application.

If that doesn't solve your problem or you can't add more memory, then
you'll want to look at controling the number of simultaneous connections
to a number that your box can handle.

> 
> Of course, when the machine runs out of mbuf clusters,
> it dies. I also found
> this with google:
> 
> "Finally, the fact that FreeBSD 3.x panics when it runs
> out of
> mbuf clusters is a well-known problem.  The solution is
> to not
> let it run out of mbuf clusters by configuring a
> sufficient
> number for them."
> 
> >From this it sounds as it is a problem that should be
> fixed, but it
> obviously isnt in 4.8. Is this behaviour now considered
> acceptable? And if
> so, doesnt this make FreeBSD extremely easy to kill
> using a simple
> DOS-attack? Is this "fixed" in any way on 5.1?

Yup, that is what DoS attack is... exhaustion of one or more resources
of the victim.

P2P software is an easy way to exhaust mbuf buffers on a box.  P2P
software(e.g. edonkey) can be a useful network stress tool; opens lots
of connections and pushes a lot of data.  My experience with mbuf
exhaustion on a 4-stable boxes has been the box basically loses network
connectivty until it can recover some buffers.  The box is still
responsive from the console and killing the offending application from
the console will free up the mbufs and restore network connectivity.

good luck,
  greg