a different view of SNMP
phil at whistler.intur.net
Sun Sep 5 17:38:14 UTC 1999
Jerry Scharf wrote:
> (on the soapbox)
That's always a fun place to be. So I guess I'll get up on my own, too.
> I agree with many of the things you said in hating SNMP. I have complained
> at times about the complexity and lack of efficiency of SNMP, as well at
> it's difficulty in representing certain types of arrays.
The whole of the information available that needs to be used is complex.
So we should not really put the blame of complexity, at least not all of it,
> The "easy" alternative you present is parsing CLI output. This can be just
> as evil as SNMP, at least in dealing with Cisco gear.
It certainly can be. But at the same time, it also gives a familiar frame
of reference. The very act of parsing (or having to parse, since IOS
intends its data output for humans with text interfaces to read) can be
> The big advantage of SNMP comes not from the protocol but from the
> formality that it brings. With SNMP, I can actually tell you what
> variables in what forms are available on a given system, based on the
> standard and proprietary MIBs published. Please tell me which commands are
> available in a given IOS release. Please tell me the parsing format of the
> output form these commands. Please guarantee that they won't change in
> ways that appear as random to the person dealing with them from release to
I don't find that SNMP gives me that. I have to first know what MIBs are
available in order to go get information. But the complicating factor is
that not all devices, nor even all versions, implement every described
standard or proprietary MIB. What's needed is the SNMP equivalent of "ls"
that lists what MIBs are there and implemented.
> The big win would be if there was some thing akin to CLI and worked across
> telnet sessions and the like, but had the formality, documentation and
> parsing regularity that comes with MIBs. I don't think this would be any
> less readable to users, so it could just replace current CLI output. This
> could also improve configuration management greatly.
Interestingly enough, this could be done with LDAP.
The obvious problem is that when designers of systems (be they server
operating systems, databases, routers, or whatever) proceed to implement
mechanisms of information interface, they often focus on human interfaces
(e.g. CLI), and forget about programming interfaces. Then when we need to
actually do a programmed interface to that system, we have to deal with a
human interface in the program.
SNMP clearly attempted to deal with the program interface. But it became
difficult in the process by implementing a protocol that could not be used
with existing tools (e.g. you can access CLI with telnet or by opening your
own TCP connection to port 23). It's own protocol was described in terms of
references to abstractions and other protocols, not all of which I have even
found yet (if you have a set of URLs to all the necessary documents to be
able to implement a full SNMP client and server, I'd sure like to see them).
Libraries were written to "hide" the protocol details, but as is typical for
libraries, imposed inefficiencies in the area of being able to do
concurrency programming. It's faster to dump the data out via CLI over
telnet by dumping in a sequence of commands, than it is to use an SNMP library.
SNMP is too much of a request/response kind of protocol for a lot of what
we need to do. Even if a library or some hidden program can take care of
the details of getting all the data items (MIBs) we need, it can be a slow
process. And if the data is to be analyzed in a time domain, that can
cause a skew in the data.
IMHO, the ideal compromise would be a TCP based program that would take a
full set of information requests, gather all of the data in an atomic way
so that time domain analysis is at least consistent (maybe even an option
to schedule data collection at a precise time and pick it up later), and
dump all of that data rapidly back over a single connection. If I were to
embark on implementing such a thing right now, I'd probably do it as a
POST method within HTTP, defining a new MIME type to encapsulate the bulk
request, and a new MIME type to encapsulate the bulk response. Authentication
would be in the HTTP request and headers. You specify all the MIBs you want,
including range and pattern requests, and all the responses have all the MIB
types attached. The MIBs could be encoded as dotted decimal or hexadecimal,
but I'd definitely _not_ use ASN.1/BER (everything will be "text safe").
If the device just doesn't have the resources to handle a large request
(such as not enough memory to record a snapshot of what you want to see all
at once), then the time-atomic aspect will have to be abandoned and the data
will then be picked up, encoded, and delivered sequentially. But the one
important thing is that it will be possible to request "everything" all at
once, if desired (and I desire it).
> The bad news is that very few people in the network management world,
> either within Cisco or elsewhere, believe this in any way. The only way
> for this to become real is for a significant number of major customers to
> demand this and make this a requirement of doing business with Cisco. When
> mo demands that Cisco do SNMPV3, they listen. When people start putting
> business on the line for this kind of thing, they will listen too.
The problem with this is that it will take getting business managers to
recognize there is a problem. But business managers are not really into the
kinds of raw information that technical people are into. Business managers
are more into pretty color graphics. Then when they see pretty colored
graphics as tools for their very expnsive investments (e.g. the deployment
of all those backbone routers) they feel all warm and fuzzy all over, and
expect the technical people to feel the same (which works fine in a totally
manually operated environment, and falls apart in a programmed, highly
Phil Howard KA9WGN
phil at intur.net phil at ipal.net
More information about the NANOG