On Mon, 23 Apr 2001 [EMAIL PROTECTED] wrote:
> James,
>
> There are a couple of different possibilities. For the standard SNMP
> elements you can look at the RFCs. They define what must be contained in
> each of replies pretty well. When you get into vendor specific replies
> that's a little different. If you read through the various MIBs you can
> usually get some idea of what they are reporting on, then you can look
> that item up in the router manuals to get more details.
>>For a few sleepless nights, one may want to check out the following
books since many vendors fail to list the particulars of their particular
MIB may respond to certain common SNMP calls.
Building Network Management Tools With Tcl/Tk
(Prentice Hall Professional Technical Reference)
by Dave Zeltserman and Gerard Puoplo
Published by Prentice Hall
Publication date: April, 1998
ISBN: 0-13-080727-3
Effective Network Management Using SNMP
Book and Disk
by Dale Cabell
Published by Sams
Publication date: July 1993
ISBN: 0672303310
Hands-On SNMP
(McGraw-Hill Series on Computer Communications)
by Paul Simoneau
Published by Computing McGraw-Hill
Publication date: June 1, 1997
ISBN: 0079130755
How to Manage Your Network Using SNMP : The Networking Management
Practicum
by Marshall T. Rose, Keith McCloghrie
Published by Prentice Hall
Publication date: January 1995
ISBN: 0131415174
LAN Management With SNMP and RMON
by Gilbert Held
Published by John Wiley & Sons
Publication date: August 1, 1996
ISBN: 0471147362
Management with SNMP and SNMPv3: A Survival Guide
by Jeffrey Case, Rob Frye, and Jon Saperia
Published by John Wiley & Sons, Inc.
Publication date: In Production
Managing Internetworks With SNMP
Publication date: September 1993
ISBN: 9993613541
Managing Internetworks With SNMP
(Network Troubleshooting Library)
by Mark A. Miller
2nd Bk&Cd- Edition
Published by M & T Books
Publication date: June 1, 1997
ISBN: 1558515615
Managing Internetworks With SNMP : The Definitive Guide to the Simple
Network Management Protocol (SNMP and SNMP Version 2)
by Mark A. Miller, P.E.
Published by Mis Pr
Publication date: September 1993
ISBN: 1558513043
SNMP Application Developer's Guide
(Vnr Communications Library) Bk&2 disks Edition
by Robert L. Townsend
Published by Van Nostrand Reinhold
Publication date: April 1995
ISBN: 0442018746
http://www.faqs.org/rfcs/rfc1213.html
>
> Cisco is particularly difficult because they have busted their MIB into 40
> pieces.
>> Not exactly true, but their MIB complies with RFC 1213 and
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_4_1/mib/getmib
.htm#xtocid2003512
At the top of each MIB it tells you what MIBs are included so you
> can walk backward through the includes until to get to the base MIBs.
> These are the RFC MIBs and the primary Cisco enterprise MIBs. The primary
> MIBs has reasonable descriptions of each of the various modules.
>
> Also, a lot of SNMP replies are numerics and are enumerate into strings so
> made sure and look in the enumeration areas, they often help explain the
> parameter you are looking at.
>> If one is a wiz at regular expression parsing with PERL, then this the
above problem is not an issue, just check the particular syntax of the
particular MIB fields, some are not as simple as listed in the material
one may be perusing.
>
> The best approach to using SNMP data is to define what it is you would
> like to monitor/look at and then find the appropriate call. A lot of the
> replies return stuff that has very little value.
>> I disagree, a lot of information gathered by SNMP queries is
underutilized, if one were to really understand the possibilities of SNMP,
one could maintain and operate a large ISP with les than a thousand lines
of perl code. Been there, done that, and even modified it so that it can
current network speeds. The issue comes down to throttling the SNMP query
and response commands. Some networking equipment may send some weird
responses due latency in the network, so therefore wait() comes in very
handy.. :)
If you want to
> understand it all, your in for a lot of late evenings. Been there, done
> that, got the bulging eyeballs to provide it! ;-]
>
> Bill Stackpole, CISSP
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
