a different view of SNMP

Alex P. Rudnev alex at Relcom.EU.net
Mon Sep 6 09:59:07 UTC 1999

> 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

 telnet cisco
 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)

More information about the NANOG mailing list