[25425] in North American Network Operators' Group
Re: Regarding global BGP community values
daemon@ATHENA.MIT.EDU (Alex P. Rudnev)
Wed Oct 13 07:14:54 1999
Date: Wed, 13 Oct 1999 15:08:13 +0400 (MSD)
From: "Alex P. Rudnev" <alex@virgin.relcom.eu.net>
To: Oleg Tabarovsky <olg@amt.ru>
Cc: Tony Li <tony1@home.net>, danny@ice.ip.qwest.net,
"'nanog@merit.edu'" <nanog@merit.edu>
In-Reply-To: <380459DA.E1C6151B@amt.ru>
Message-ID: <Pine.SUN.4.10.9910131503500.547-100000@virgin.relcom.eu.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
Hmm.
In the 'SNMPSTATD' monitoring I use (it's in the near plans) to monitor
not _FREE MEMORY but _THE BIGGEST PIECE OF THE FREE MEMORY_. It's the most
critical argument. If it is less than 128K, 'config' command do not work;
if it is less than 1500 bytes, nothing works at all -:)
>
> AFAIK, there is some more memory wasting and dangerous feature in
> current (at least it was so year ago) implementation of memory allocation
> subsystem in Cisco: when you are going below some magic value
> (for defaultless routers usualy below 10-8 megs) and have even
> moderate BGP activity, very soon (less then a day) you will be out of
> memory even in the presence of this 8-10 megs of free memory because your largest fragment will be very close to 0.
> As I was told several years ago this is fundamental "feature" of
> memory allocation implementation (poor fragmentation resistance with low memory and lots of small alloc's/free's).
The fundamental feature for the REAL-TIME device (such as ROUTER) should be
a lot of HOT-DOG mechanisms preventing /at least/ lost of the control over
the device. In case of such _voracious_ processes (as BGP is) it should
be used any mechanism preventing it from catching all existing
resources
(CPU and MEMORY in our case).
