|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: a different view of SNMP
> 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)
|