Subject: [ifmib] read-write access in IF-MIB

From: Michael MacFaden <[email-masked]>
Date: Thu, 25 Oct 2001 17:54:49 -0700

>From: "Miri Park" <[email-masked]>
>I'm designing the SNMP interface to manage the switch-routers.

Great!  NCON NGN-ESS lives?

>I need to configure the service through the NMS.
>For example, configuration of PPPoA on the OC12 port.
>However most objects in IF-MIB are read-only. (I believe this is for
>security reason)

That would not be the right reason. Please read rfc2863 section 3. 
IP in general and the IF-MIB in specific do not really care about 
the details of the underlying network technology. As a result, 
the IF-MIB represents a decidedly abstract IP only view of the 
actual physical or logical sub-interfaces.

>Then, How can the managing system set the object?

One would use the technology specific MIB module located
in either the standards space (MAU-MIB, SONET-MIB, 
ATM-MIB, DS1-MIB, etc) or a proprietary MIB module. 

A review of the current standard MIB modules one might
find today in today's gear are located in this tutorial I 
did with Chris Elliot of Cisco at NANOG (www.nanog.org)
a while back.

http://www.nmops.org/download/understanding-snmp-counters.pdf

This document has info on how to find a given MIB module
if it exists in the standards space.

>Do I have to use CLI or define a new proprietary table to allow the
>managing system to set?
>Which is the more common way?

That really depends on the product, vendor and feature you
want to configure.  

Here are my thoughts for Layer 2 and 3 configuration:

For layer 2 devices(IEEE bridges), SNMP sets are very well supported
and pretty simple to do and have been used to 
manage l2 gear since '93 (DEC giga-switches in MAEs deployments
for example or their newer replacements. 
So operationally many GigE/Metro operators are still using 
SNMP sets without problems with gear from a number of vendors. 
The amount of configuration data that needs to be sent
to any given brige is also pretty small. 

be warned: there is pretty great variability in how anybody does 
anything even if it is supposedly standard.
Consider RFC 1493, the BRIDGE-MIB, a very mature and well
done module: http://www.macfaden.com/ietf/bridge-test-results.txt

There is a cool mechanism to determine at runtime
a device's specific implementation of some MIB module without having to 
spend time guessing without a large amount of probing..
If the vendor provides an Agent Capablities MIB module for the 
product, you can quickly determine the implementation level for a 
given agent. As far as I know at least two switch-router vendors
publish agent-caps for their devices and implement the sysORTable 
in their agents which you can ftp freely from their respective websites.  

RFC 1907 has the extensions to the system group which you will
want to poll the sysORTable to obtain the OID for the agent-cap
which can allow your application to determine what a given device
supports and whether it is read-only or read-write.

----

For layer 3(IETF IP Routers), SNMP has not been sucessful as a 
configuration mechanism (but has been just dandy at monitoring it).

I think this is for two reasons. One the underlying technology 
has not had a clean mgmt plane definition of the likes seen
in the IEEE specs (just read the IP, OSPF (RFC1583)).
There is no mgmt considerations section on what should be 
exposed to management in a standard way. So different
routers make different weightings of their route types, direct,
static, ospf, ospf-ase, etc. All very difficult to manage in
any real dumb programmatic sense that scales. 

And from the operations side, if I heard Sean Doran correctly, he stated
at at NANOG this week that he thought bgp peering with another company 
is about as difficult as using two different vendor's gear in
one company. Ie it's doable, but really difficult.

Two, some of the IETF/IP technology is really hard to manage since any 
mistake can have world wide impact. See the presentations this
week at NANOG 23 from the research types. 
http://www.nanog.org/mtg-0110/agenda.html (beginning with Shining light on
dark address space). Some organizations have actually ended up
DDOSing themselves by announcing to general a prefix via ebgp...

As a result, highly skilled operators sit carefully over their 
devices 24/7 staring at "looking glass" and at router logs and prefer
to configure routers by building larger/better command line configuration
text files of size ~200k containing access-control lists, 
route maps, igp/egp router configuration and misc sundry bits.

In summary, for IP Routers/Layer 3, you have to use some vendor's CLI.
For Layer 2, SNMP will work but not without knowing alot about
the vendors snmp implementations. 

Lastly,
If Kaj Tesink is still at Telcoridia, he wrote rfc2558 
SONET-MIB (march 1999) and could probably help you out.

Regards,
Mike MacFaden
PS, For one description of an SNMP agent implementation 
for a layer 2/3 switch-router 
see: http://www.nmops.org/download/rs-snmp-mgmt.pdf
Appendix A and and B might be useful.

_______________________________________________
ifmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/ifmib