[c-nsp] Network Software - Management/Performance

[Bill Nash]

On Mon, 19 Feb 2007, Phil Mayers wrote:

> Paul Stewart wrote:
> 
> > 
> > Anyways, just trolling for ideas.... oh, and prefer Linux support but not
> > ruling Windows out entirely....
> 
> It has warts, but we run Nagios relatively successfully. The config is 
> (re)built and (re)loaded every 5 minutes (if changed).
> 
> This only works because our (in-house) registration system is considered 
> authoritative and the config is wholly derived from that database - no 
> nonsense like "periodic discovery" (translation: periodic erasing of 
> devices and their history because a loopback was renumbered) or such. 
> Errors in the database are considered mistakes by the ops staff and 
> corrected by such (and generally detected by auxiliary processes like 
> parsing the configs and comparing to the database).
> 

	I'd just like to comment about this last paragraph, for those not 
seasoned in coping with large networks and large NMS deployments. Adding 
a new management tool to an existing network is hard. The only thing 
harder, in my experience, is adding best practice policies to the same 
existing network.

The stance taken above, dictating the reality of the deployed network from 
an authoritative source (that isn't the network), is an excellent one (in 
my opinion, at least.) It supports all kinds of efficient troubleshooting 
and auditing, and with a good backend platform that supports Role Based 
Access Control/User Accounting, you stand an excellent chance of keeping 
MTTR down. Periodic discovery should be used as an audit tool, not a 
configuration tool, to support error detection and reporting.

Also, keeping a tight rein on your auto-discovery means never getting a 
call from NASA saying, 'Stop that.' ;)

- billn