> For an example of SNMP / MRTG taken to
> an extreme go to http://ardnoc82.canet3.net/CAnet3map/CAnet3map.htm

That's too cool!  

If it weren't for your funny money, (L'unes and Tunies and way too
colorful paper currency) I'd want to work for Canada.  I can even speak
Canadian, eh, hoser! 8^)

But seriously, that's a really cool application for SNMP.

I've been biting my tongue on this thread.  But let me just chime in
with Robert and Michel: SNMP is a good thing, not a bad thing, provided
it is managed properly.  

You do need to beware that SNMP community strings, at least until
SNMPv3, are clear-text and can be sniffed.  It would be ideal if each
device had its own unique SNMP community strings, but this is not
manageable.  Instead, I recommend using different strings for different
classes of devices (i.e., routers get one set, internal servers get a
second set, dmz servers a third set, etc...).  Network switches are
cheap, and will help limit access to SNMP traffic by your general user
community.  Of course border routers and firewalls need to deny SNMP in
both directions.  It may also be possible to use a separate IP subnet
for SNMP traffic for most devices, so you can separate your SNMP traffic
from your user base, but this may be more trouble than it's worth for
the limited devices where it's possible.

If remote access is needed for SNMP, use VPN to bypass the
firewall/router restrictions.

As Robert points out, SNMP is sometimes the difference between extended
downtime and no downtime.  For example, I mostly do HP NetServers, which
come with a lightweight management application called TopTools.
TopTools uses SNMP to warn about predictive and reactive failures.  I
setup TopTools for all of my small-to-medium customers.  This way they
can call me when the FIRST drive in a RAID array fails (and it can be
easily replaced and fixed), instead of after the SECOND drive fails and
data is lost.  Sometimes they even call me because a drive or memory is
PREDICTED to fail (and HP will replace hardware based on a TopTools
predictive failure warning).

Reply via email to