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