(on the soapbox) 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 "easy" alternative you present is parsing CLI output. This can be just as evil as SNMP, at least in dealing with Cisco gear. 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. 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. 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.
[ On Saturday, September 4, 1999 at 13:36:03 (-0700), Jerry Scharf wrote: ]
Subject: a different view of SNMP
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.
I sometimes wonder why Wellfleet nee Bay nee Nortel haven't already taken over most of Cisco's market share for this reason given their almost total embracement of SNMP for configuration and management. Sure, they did leave a wide market niche for third party font-end tools that actually worked, but at least they embraced the standards! :-) -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
It's just the BRIGHT example when usage SNMP did not allow to create friendly configuration interface - all network admins here hate WellFleet for their confih methods and was happy to return back to CLI when they realised it' The first words they have saying when learned CISCO was _ohh, at least no GUI and SNMP!_ -:) In comparasion, all hare use WWW interface CISCO implemented into their Catalist 19xx and 29xx series withouth complains and angry words... -:) The reason - WWW is _SELF-DEFINED and SELF-HELPED_ protocol (sorry for the wrong english usage), SNMP with GUI are not at all... Thus, not everything us so easy to explain... Alex. On Sat, 4 Sep 1999, Greg A. Woods wrote:
Date: Sat, 4 Sep 1999 16:51:41 -0400 (EDT) From: Greg A. Woods <woods@most.weird.com> To: nanog@merit.edu Subject: Re: a different view of SNMP
[ On Saturday, September 4, 1999 at 13:36:03 (-0700), Jerry Scharf wrote: ]
Subject: a different view of SNMP
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.
I sometimes wonder why Wellfleet nee Bay nee Nortel haven't already taken over most of Cisco's market share for this reason given their almost total embracement of SNMP for configuration and management. Sure, they did leave a wide market niche for third party font-end tools that actually worked, but at least they embraced the standards! :-)
-- Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
[ On Monday, September 6, 1999 at 14:24:47 (+0400), Alex P. Rudnev wrote: ]
Subject: Re: a different view of SNMP
It's just the BRIGHT example when usage SNMP did not allow to create friendly configuration interface - all network admins here hate WellFleet for their confih methods and was happy to return back to CLI when they realised it' The first words they have saying when learned CISCO was _ohh, at least no GUI and SNMP!_ -:)
Yes, you're right, but of course there's nothing inherent about SNMP that requires a GUI. It does require a separate host platform on which to run the configuration tool(s) though, which is indeed a bit of the problem, at least until more recent times. Of course there's nothing about a CLI that precludes having a GUI either, or any other kind of screen based menu/forms interface.
The reason - WWW is _SELF-DEFINED and SELF-HELPED_ protocol (sorry for the wrong english usage), SNMP with GUI are not at all...
Yes, you're mostly right there. The interesting thing about a WWW interface is that it almost totally puts the user-interface parts in the right place -- i.e. on an *independent* terminal platform. The SNMP interface, GUI or not, will often have a lot of dependencies upon the exact version of whatever is running on the device to be configured, even though SNMP should allow these minor differences to be hidden. X11, the Bell Labs blit terminals, and other similar attempts to divorce the meaning of the interface from the interface itself and the device that implements it, all point in the right direction. The HTML and HTTP protocols provide a high enough level of abstraction that even novice programmers can create very sophisticated user interfaces that are platform independent. WWW interfaces in routers don't cost a whole lot in memory, code, or processing power, to implement and yet they give the device operator a most definite degree of not just version independence, but device independence. They are ideal for embedded systems because the complexity and and processing requirements are moved to the less resource-restricted browser environment. In theory any generic computer with a network interface and a generic WWW browser will allow an operator to get their job done no matter what kind of device they actually encounter in the field. Of course I'm not optimistic that things will continue to get better in this arena.... Inevitably the feature junkies will continue to create facets of the interface in a device that'll require specific tools to be used and which we the users won't be able to do without. Should we allow router vendors to require JavaScript support, or should we try to force them to always maintain total compliance with the lowest common denominator? However I am still optomistic (perhaps insanely so) that someday SNMP may still become purvasive enough that generic configuration tools will be powerful enough to use across device platforms (i.e. not just the toys we have today that can be used to prototype things with). After all we do now have tools that are generic enough to allow us to use SNMP to gather statistics and error reporting and other such stuff. Your own tools and your own paper are ample evidence of this! You see the real problem with CLI interfaces is that they require programming talent to use in any automated way -- they will always differ too much between platforms. While I'm one of the first to say more people should learn to program computers intelligently, I'm also a pessimist about this ever happening to the degree it is necessary to A similar, but even more insidious, problem occurs with WWW interfaces. They are also inevitably going to be different in many ways between platforms (or at least between manufactures). They assist in making human operators more portable but they are no better at offering standard programming interfaces than CLIs are. In fact they make it easy (and fun) enough for an operator to do boring and repetive tasks. In addition they make it even harder to write programs that interface with them. The result is that they require many more human robots to operate than should really be necessary. While I think these diversities in CLI and WWW user interfaces between platforms and manufacturers are still a good thing in this business, they are barriers to writing automated tools. If SNMP isn't the exact answer something like it must force a low-level commonality on the programming interface to these devices. SNMP *is* a very simple protocol, but it requires very sophisticated programmers to make it dance to the tune of a sophisticated network operator! One of the other complaints folks have about SNMP, and it shows up in your article too, is that SNMP isn't sophisticated enough to do the things that a very experienced CLI (or WWW) user can do. While this is indeed true for given instances of implementations, it is *not* the fault of SNMP itself. These complaints are usually due to the fact that the SNMP designers (particularly those building private MIBs) are either not experts in the inticracies of the products they are designing for, or are not experts in SNMP design. The result is that they try to take shortcuts that will make SNMP "easier" to use. Unfortunately this often also means that their MIBs are more limiting than necessary too. (This is one thing I don't think Wellfleet suffered from -- they very effectively forced themselves to design MIBs that were capable of doing all of the sophisticated things that their products were required to do!) I.e. the answer to your question of why hardware vendors did not realise SNMP in the proper way is that most of them were not forced to do so. They were often only implementing SNMP because they were required to do so to meet the perception of some requirement to have such support and they often took many short cuts in their designs because they thought they knew that the real experts would always want to use the CLI. One thing that vendors could do to help make SNMP more accessible would be to make their MIBs more widely available -- perhaps even storing them in the devices now that flash memory is almost affordable. Of course one thing that SNMP did not properly address is change mangement in itself -- i.e. MIBs are not easily changed, but rather are designed to be properly defined and frozen before they are ever used. I certainly do not disagree with your description of SNMP data representation as inside out and in-human! (But then I hate RPN calculators too! ;-) -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
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
Phil, you just read my mind... One more word - and you should reverse the data tree by this way to allow 'wildcard' requests and to allow easily add vendor branch to the every part of the tree. LDAP was (in this discussion) an other interesting idea, too. Alex (R).
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 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
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
> 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 "easy" alternative you present is parsing CLI output. This can be just > as evil as SNMP, at least in dealing with Cisco gear. Oh, sorry; I'v said _even the evil named CLI is easy to use than SNMP_; I never advice to use CLI widely... > 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 Ok, telnet cisco login/passwd ? sh interface ? Now let's imagine there is some standard describing the form of the variables, the form of request (may be, by http.1 protocol). For now, I used CLI as alternative only because: - this prodicts was 100% cisco-oriented - I need theresult and the effeciency; - there is not any alternative at all (except http which in the CISCO case is just the CLI at some other form). > 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 Yes, in case if: - the MIB three will be reversed up-down (indexes first, the data second; text indexes, not the terrible binary ones; the enterprise subtree can be add to the ANY branch, not to the root branch only). It's just my point of view. > less readable to users, so it could just replace current CLI output. This > could also improve configuration management greatly. > > 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. Yes, just agree. I'v attempted to attract any attention to this problem, through (and even sent this to the Simple-Times magazine - at leaqst it became the interesting reading for the some people there). Through I could not agree about this way. All hw vendors embed now httpd interface; why did not try to formalise some part of this interface by this way to mage authomatic data retrieve more easy to implement. > > > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
participants (4)
-
Alex P. Rudnev -
Jerry Scharf -
Phil Howard -
woods＠most.weird.com