I hope it's not all due to fragmentation and pooling overhead.
I'd note that in most cases Cisco's don't actually run out of memory
to service requests, the more commmon limiting factor is no block
large enough to statisfy a particular request, even though there are
megabytes 'free'.
George
> From gert@greenie.muc.de Thu May 31 15:13:52 2001
> Date: Thu, 31 May 2001 21:14:15 +0200
> From: Gert Doering <gert@greenie.muc.de>
> To: George Robbins <grr@shandakor.tharsis.com>, gert@greenie.muc.de,
> jared@puck.nether.net, kf@reign.sk
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: Full BGP and memory
> References: <200105311642.MAA18105@shandakor.tharsis.com> <20010531184821.H743@greenie.muc.de>
> In-Reply-To: <20010531184821.H743@greenie.muc.de>; from Gert Doering on Thu, May 31, 2001 at 06:48:21PM +0200
> X-mgetty-docs: http://alpha.greenie.net/mgetty/
>
> hi,
>
> On Thu, May 31, 2001 at 06:48:21PM +0200, Gert Doering wrote:
> > I did try "remove it on the eBGP session and reboot", but never thought of
> > "remove it on all the sessions (and optionally reboot)". Will try and
> > then report back.
>
> So... now I'm back with some numbers. Interesting, indeed.
>
> One fact that I observed was that 12.0(14)S is smarter than 11.1CC :-) -
> when disabling "soft in", it just drops the extra information. When
> enabling it, it sends out a "route refresh" request (if the peer supports
> it - mines do), and then stores the extra information.
>
> OTOH, it doesn't really make any difference.
>
> This is with no "soft in" configured at all:
>
> Cisco-INXS#sh mem
> Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
> Processor 612C1E20 97772000 70680688 27091312 24639840 13172380
> I/O 7000000 16777216 3667676 13109540 12837656 13093628
>
> and this is with "soft in" configured on the upstream link, with
> 102000 received prefixes:
>
> Cisco-INXS#sh mem
> Head Total(b) Used(b) Free(b) Lowest(b) Largest(b)
> Processor 612C1E20 97772000 71213680 26558320 24639840 13172380
> I/O 7000000 16777216 3667676 13109540 12837656 13093628
>
> - this half a megabyte isn't really worth discussing about.
>
>
> Now this leads to the question: what's BGP doing with all the memory?
>
> BGP router identifier 193.149.44.45, local AS number 5539
> BGP table version is 414460, main routing table version 414460
> 102939 network entries and 124917 paths using 14070339 bytes of memory
> 40202 BGP path attribute entries using 2090504 bytes of memory
> 3 BGP rrinfo entries using 72 bytes of memory
> 18815 BGP AS-PATH entries using 462124 bytes of memory
> 236 BGP community entries using 10148 bytes of memory
> 18229 BGP route-map cache entries using 291664 bytes of memory
> 40846 BGP filter-list cache entries using 653536 bytes of memory
> BGP activity 136579/29979 prefixes, 499546/367099 paths
>
> summed up this gives 17578387 "bytes of memory", which is a quite
> acceptable figure :-).
>
> "show proc mem" on the other hand gives:
>
> PID TTY Allocated Freed Holding Getbufs Retbufs Process
> 84 0 95271656 832412 56324252 0 0 BGP Router
>
> which seems to be about 3 times the abount that BGP admits to be
> using...
>
> I do know that when I enable CEF, the memory used by CEF will be charged
> to "BGP router". But CEF is disabled.
>
> So - can any of you wizards explain to me what this box is doing with
> the 40 Mbytes of "hidden" memory...?
>
> (I will reboot the box later tonight, to find out whether reloading
> after clearing "soft in" releases additional memory or not).
>
> regards,
>
> gert
> --
> USENET is *not* the non-clickable part of WWW!
> //www.muc.de/~gert/
> Gert Doering - Munich, Germany gert@greenie.muc.de
> fax: +49-89-35655025 gert.doering@physik.tu-muenchen.de
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:39 EDT