[j-nsp] M20 buffer fault?

[Chris Cappuccio]

Mbufs are not used for file descriptors, but they are used for packets.
They are memory buffers for the networking code in the BSD kernel.

The BSD kernel should not typically run out of mbufs, especially since it
isn't doing any actual routing (and probably not allocating many mbufs) in a
Juniper router.

Juniper made a mistake, either there's a leak somewhere, or someone chose an
inefficient way of handling some condition that generates mbuf usage beyond
the compiled limit.

If it's a leak, then raising maxusers might delay the inevitable.

Michael Loftis [mloftis at wgops.com] wrote:
> 
> 
> --On October 27, 2005 7:40:58 AM +1300 Gordon Smith <gsmith at wxc.co.nz> 
> wrote:
> 
> > Hi all,
> >
> > Just came across an odd problem with one of our M20's - I've got JUNOS
> > 7.4 on there for testing at the moment. I noticed that the router had
> > become unresponsive, and when I went and had a look at it, both RE's
> > were online as masters.
> 
> That's a fairly common FreeBSD problem....but I was pretty sure that those 
> items went dynamic late in 4.x series, or atleast the initial computation 
> did...but...looking at my 7.3R1.5 M7i I see kern.maxusers: 32  -- however 
> kern.ipc.nmbufs is reasonable at 101356 on my box, which indicates it's 
> gettinc computed based on RAM.... however If you're seeing it you in theory 
> can try and add
> 
> kern.maxusers=256
> 
> in /boot/loader.conf.local on both REs and restart.  Should force it to 
> push up the number of mbufs allocated, no matter what the compile time 
> setting is.  This tunable isn't available except at boot time, and I 
> honestly have no idea if there's a 'Juniper' way of fixing that tunable up 
> in loader.conf (which I think JunOS does maintain).  You also might want to 
> try pushing it up in steps, 32, 64, 96, and so on and checking your free 
> RAM from 'top' -- if you turn it up too high and there's not enough memory 
> the system may not boot.
> 
> It does sound like you're getting some sort of max number of open 
> descriptors.  mbufs are used for quite a lot of things.  NMBCLUSTERS is the 
> compile time variable.
> 
> >
> > In the logs, this is what was occurring right up until I reset the box:
> >
> > Oct 26 21:37:49  jcore2 /kernel: Out of mbuf clusters - adjust
> > NMBCLUSTERS or increase maxusers!
> > Oct 26 21:37:49  jcore2 /kernel: Out of mbufs (error count: 1)
> > Oct 26 21:37:49  jcore2 /kernel: Out of mbufs (error count: 1)
> > Oct 26 21:37:49  jcore2 /kernel: Out of mbuf clusters (error count: 1)
> > Oct 26 21:37:50  jcore2 /kernel: Out of mbufs (error count: 1)
> >
> >
> > At the moment, the router is split into logicals (for vertical
> > aggregation), running BGP and IS-IS. Nothing really unusual. There are
> > still some unconfigured peers, but I wouldn't think that unconfigured
> > peers knocking on the door would cause resource exhaustion.
> >
> > Anyone have any info on this? It's not a fault I've seen before...
> >
> >
> > Cheers,
> > Gordon
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > http://puck.nether.net/mailman/listinfo/juniper-nsp
> >
> 
> 
> 
> --
> "Genius might be described as a supreme capacity for getting its possessors
> into trouble of all kinds."
> -- Samuel Butler
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
"Attacks always get better; they never get worse."
  -- "Old NSA saying"