[j-nsp] M10 FEB heap usage (RPF/route options)
Nicolaj Kamensek
nk at accelerated.de
Fri Dec 14 18:02:40 EST 2007
Kevin Day schrieb:
Hi Kevin,
> Heap utilization 97 percent
what does
show arp no-resolve | count
say?
> It made sense that whatever "route options" are was the difference. I
> found an old post here discussing SSB SDRAM usage (http://puck.nether.net/pipermail/juniper-nsp/2005-May/004275.html
> ) that mentioned that RPF can require route options. I disabled rpf on
> every interface, but that did no good. I restarted the router though,
> and sure enough the allocations for route options were gone. Heap
> usage is back down to 75%.
Unfortunately, restarting the FEB is the only thing that helps freeing
memory if you came close to 100%.
> Is this normal? I seem to remember being able to fit 500k+ routes not
> that long ago (multiple ribs). Did the size of each v4 route entry
> grow during a junos upgrade at some point?
500k+ routes is still possible. Those routes are stored in the 8MB SSRAM
on your FEB but also a copy of this table is stored in the DRAM, 64MB in
your case. You reached the limits of your DRAM, not the SSRAM. Upgrading
it should help, either by buying a newer router like M7i/M10i(with 256MB
DRAM on the FEB) or by installing a enhanced FEB for M10 routers.
> Does this mean those of us stuck on 64MB FEB/SSB systems are going to
> have to run without RPF now or in the very near future when the size
> of a full table grows a bit more?
Pretty much, yes. 64MB isn't simply large enough for todays full-table +
arp entries + RPF + ... 128MB or more might be sufficient for that.
We reached our limits on a M20 router with SSB-E with about 7500 arp
entries, full-table and no RPF. Upgrading to SSB-E16 solved that problem.
Best regards,
Nicolaj Kamensek
--
Accelerated IT Services GmbH
Schubertstrasse 10 D-67251 Freinsheim
nk at accelerated.de http://www.accelerated.de/
Telefon: +49 69-25738580-3 Telefax: +49 69-25738580-4
HRB: 60665 - Amtsgericht Ludwigshafen UstID: DE253684415
Geschäftsführende Gesellschafter: Nicolaj Kamensek & Ole Krieger
More information about the juniper-nsp
mailing list