Re: Regarding global BGP community values

["Alex P. Rudnev" <alex () virgin relcom eu net>]

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).