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.
Alex,
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, on SNMP.
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 variably complicated.
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 release.
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 automated environment). -- Phil Howard KA9WGN phil@intur.net phil@ipal.net