Help understanding some Lire conceptual issues

[Brad Knowles]

At 9:34 AM -0600 2004/03/06, Jim Lancaster wrote:

[ no longer off-topic, I hope ;-) ]

>  BTW, I've looked at Nagios, rrdtool, an interesting little php app
>  called 'Cacti', cricket, and just about every other open-source NMS I
>  could get my hands on.  I've also worked a great deal with WhatsUpGold,
>  which is actually quite good at what it does.  However, ALL of the
>  aforementioned products share one huge limitation for me as an MSP:
>  They are designed from the single-enterprise perspective. There is no
>  easy way to adapt them for use in a multi-company/customer environment.
>  There is no easy way to allow one customer to see their data and only
>  their data.

	Yup.  That's a problem.  I am not aware of any network monitoring 
or management system that allows you to virtualize the stuff that's 
handled.

>  Another huge limitation is that nearly all rely on "pull" rather than
>  "push" technology to gather the data to be analyzed. The NMS server
>  originates the polling process and pulls data in from the remote
>  devices.

	Yup.  This helps keep the load on the NMS down, and help keep it 
from missing data.

>            If a device is only remotely accessible via the Internet, a
>  VPN must be setup and maintained to allow the server to poll the remote
>  device.  VPNs are, quite frankly, a management nightmare, and in order
>  to use them all of the remote devices must--even if natted--reside on
>  uniquely addressed subnets. (Imagine how many companies out there are
>  using 192.168.0.0/24 or 10.0.0.0/24 subnets.)

	If they're NAT'ed, then they won't be able to push data to the 
NMS in any meaningful fashion.  There won't be any way that the 
client can identify itself to the server which will survive the NAT 
process.

>  However, if the NMS were to rely on agents that "push" data back to a
>  central server, think of the possibilities: (1) No firewall issues -
>  most networks do not restrict outbound traffic, so no changes need to be
>  made to the firewall. (2) No security issues - there is no hole in the
>  firewall to allow polling in; the polling data rides a one-way street
>  back to the NMS. (3) Reduced burden on the NMS server - The cpu cycles
>  required to support polling are gone. These are just a few of the
>  advantages that come quickly to mind.

	I don't think the push mechanism works nearly so well as you 
think it does.  You can use SNMP traps for those systems that support 
that, but I still don't think they work nearly as well.  If the use a 
UDP transmission mechanism, then you have to deal with all the 
dropped and lost packets, etc....  If they use a TCP transmission 
mechanism, then you have a communication method with a much heavier 
transport protocol and may still cause the server to get overloaded 
due to too many things trying to update at once.

>  Obviously, the use of agents introduces other issues that have to be
>  addressed like software updates and configuration changes, but I think
>  these can be managed much easier than the limitations just mentioned.

	If the push mechanism really was such a massive improvement, then 
I think all NMS systems would have adopted it years ago.

>  Very exciting news.  I think I can tackle the data collection, however
>  the analysis and reporting requires much greater "smarts." I would like
>  to be able to rely on (or at least build upon) the work of others for
>  this.

	I think that's an excellent idea.

-- 
Brad Knowles, <brad.knowles at skynet.be>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

-- 
To UNSUBSCRIBE, email to questions-request at logreport.org with a subject of 
"unsubscribe". Trouble? Send an email with subject "help" to 
questions-request at logreport.org