Regarding global BGP community values

Alex P. Rudnev alex at virgin.relcom.eu.net
Wed Oct 13 11:08:13 UTC 1999


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






More information about the NANOG mailing list