Expense can be measured in many ways.
The problem is having to keep track of which interfaces need to be up and
managed and which ones are not reachable/pingable. I know of several situations
where pinging just doesn't get the job done. Why use a management platform that
only manages a subset of important resources? In our environment many, many
interfaces are not reachable by pings since we are the center of a "hub" of
client networks. Its just a nightmare, and I speak from help desk experience,
to know what should be up and what should unmanaged. There are several ways to
control the amount of SNMP data and lets be realistic and suggest that most
networks now are not suffering from bandwidth restrictions they were a few
years ago. (Yes, some obviously will be).
If you want monitoring groups to be 100% autonomous from having to ask which
links should be reachable/up and which are unmanaged/unreachable, SNMP fills
the bill much better and will ultimately reduce the cost of managing an
enterprise.
-----Original Message-----
From: Todd H.
To: Barr, Scott
Cc: nv-l@lists.tivoli.com
Sent: 5/16/02 3:37 PM
Subject: Re: [nv-l] Netview Traps - Time to post
"Barr, Scott" <Scott_Barr@csgsystems.com> writes:
> SNMP status polling is set automatically for any router with
un-numbered
> serial interfaces OR it is coded in the seedfile:
>
> routername
> $routername
>
> The dollar sign forces the previous entry to use SNMP status polling.
You
> will probably have to delete and re-discover the node. I highly
recommend
> SNMP status polling whereever possible on the basis that it is FAR
less work
> to manage interfaces since you don't have to ping all of them (or
unmanage
> them).
On the other hand, as James has said, network bandwidth wise, isn't
ICMP pinging cheaper?
An ICMP echo and ICMP echo-reply pair are pretty tiny in comparison to
individual SNMP GET requests. IIRC NetView isn't particularly
efficient at aggregating GET's.
--
Todd H.
http://www.toddh.net/
|