[openib-general] [RFC] OpenSM Interactive Console
Troy Benjegerdes
hozer at hozed.org
Thu Oct 27 07:29:57 PDT 2005
For me, the only purpose for an SNMP MIB would be to get the information
into a network management system. In my case, I'll be using something
that's open-source or has a plugin architecture like Nagios, and I'd
really rather just have the network management system communicate with
the subnet manager or SMA packets directly rather than introducting an
extra translation to SNMP.
SNMP is only usefull to me because it is (in theory) an interoperable
cross-vendor standard. In the infiniband case, we already have a
cross-vendor standard implementation (OpenIB), and adding SNMP is
another dependency and layer of complexity that can break and be
difficult to set up.
If I knew of an open-source tool that was actually able to use SNMP to
query a random ethernet vendor's switch and be able to tell me what port
a particular MAC address was plugged into, I might be more positive. But
as far as I know, each vendor's SNMP implementation is broken in subtly
different ways, so that this gets to be a nightmare to actually
implement.
I guess the point of all this is find a end-user use-case for the SM
MIB, and work back from there to decide if haveing a MIB actually helps
solve the problem.
On Thu, Oct 27, 2005 at 08:03:57AM +0200, Eitan Zahavi wrote:
> Yes this MIB needs some cleanup.
> I would love to hear from the community some feedback regarding SM MIB
> usefulness.
>
> In the past we did not get any push for interactive SM or online
> configurable SM so I did not see any reason to work on it.
>
> I do not think it is a huge task to make SM MIB work with OpenSM. At least
> not the 90% of it that I glanced through.
>
>
> Eitan Zahavi
> Design Technology Director
> Mellanox Technologies LTD
> Tel:+972-4-9097208
> Fax:+972-4-9593245
> P.O. Box 586 Yokneam 20692 ISRAEL
>
>
> > -----Original Message-----
> > From: Hal Rosenstock [mailto:halr at voltaire.com]
> > Sent: Wednesday, October 26, 2005 7:44 PM
> > To: Eitan Zahavi
> > Cc: Troy Benjegerdes; openib-general at openib.org
> > Subject: RE: [openib-general] [RFC] OpenSM Interactive Console
> >
> > Hi Eitan,
> >
> > I sit corrected. There are R/W parameters in the SM MIB as you indicate. I
> was
> > thinking of all the other IPoIB MIBs. It's been a while since I looked at
> the SM MIB.
> >
> > Also, the SM MIB (draft-ietf-ipoib-subnet-manager-mib-00) expired a while
> ago. At a
> > minimum, it needs to be dusted off. That would include updating it for IBA
> 1.2.
> >
> > -- Hal
> >
> > ________________________________
> >
> > From: Eitan Zahavi [mailto:eitan at mellanox.co.il]
> > Sent: Tue 10/25/2005 5:19 AM
> > To: Hal Rosenstock
> > Cc: Troy Benjegerdes; openib-general at openib.org
> > Subject: Re: [openib-general] [RFC] OpenSM Interactive Console
> >
> >
> >
> > Hal Rosenstock wrote:
> > > On Mon, 2005-10-24 at 14:38, Eitan Zahavi wrote:
> > >
> > >>Hal Rosenstock wrote:
> > >>
> > >>>On Mon, 2005-10-24 at 03:08, Eitan Zahavi wrote:
> > >>>
> > >>>
> > >>>>I would suggest to use SNMP for the tasks below. IETF IPoIB group
> > >
> > > has
> > >
> > >>>>defined an SNMP MIB that can support the required functionality
> > >
> > > below.
> > >
> > >>>
> > >>>The IETF SNMP MIBs are one way of presenting the information to the
> > >>>outside world. There are other possible management interfaces. The
> > >
> > > SNMP
> > >
> > >>>MIB instrumentation would need to use lower layer APIs to get this
> > >>>information out of the SM.
> > >>
> > >>Yes but the IETF SM MIB is the only one that is close to a standard
> > >
> > > way.
> > >
> > >>It does not require low level interface if it will integrate into the
> > >
> > > OpenSM code.
> > >
> > >>One way to do it is buy extending OpenSM with an AgentX interface.
> > >>
> > >>IMO one clear advantage of using SNMP for SM integration is that the
> > >
> > > code will work with any SM that is IETF compliant.
> > >
> > >>Also if you want to write a "client server" type of application on top
> > >
> > > of an SM you
> > >
> > >>can either stick to sending MADs which translate into SA client based
> > >
> > > application or
> > >
> > >>you better stay with some known protocol for management (like SNMP)
> > >
> > > and not develop yet another protocol for
> > >
> > >>doing exactly the same things as SNMP already supports.
> > >
> > >
> > > There are limitations in the SNMP MIBs. One is that they are RO so they
> > > are more for monitoring. Also, many environments do not use SNMP. It is
> > > unclear how much of a requirement it is to manage any SM or how many
> > > other SMs support the SM MIB. (There are other IB associated MIBs too).
> >
> > SNMP MIBs are certainly not just RO a simple example from the SM MIB:
> > ibSmPortInfoLMC OBJECT-TYPE
> > SYNTAX Unsigned32(0..7)
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION
> > "LID mask for multipath support. User should take extra caution
> > when setting this value, since any change will effect packet
> > routing."
> > ::= { ibSmPortInfoEntry 19 }
> >
> >
> > I agree that it is possible that currently no SM is supporting the SM MIB.
> > But it does make sense to have ALL of the them support it. Such that they
> can
> > be activated/deactivated and configured in the manner.
> >
> > Most unix distributions and windows box have standard SNMP agent and
> client
> > included in them
> > So it does not take more then simple bash or C code to interact with the
> SM if it
> > supports SNMP.
> >
> > >
> > >
> > >>>>Everything but the dynamic partitioning (OpenSM does not have
> > >>>>partition manager to this moment)
> > >>>
> > >>>
> > >>>What Troy meant by partitioning is not necessarily IB partitioning.
> > >>
> > >>How are you sure about that? Troy - please comment.
> > >
> > >
> > > I think you missed an email on this.
> > >
> > >
> > >>>>and forwarding of Performance
> > >>>>Monitoring traps (which are generated by the PM) can be done through
> > >>>>osmsh or through SA client today.
> > >>>
> > >>>
> > >>>What PerfMgr are you referring to ?
> > >>
> > >>No specific one. But the specification does not require the SM too.
> > >
> > >
> > > Huh ? What spec ? An SM is required in a subnet. There is no subnet
> > > without this. There is a subnet without a PerfMgr.
> > Yes its a typo I meant PM. SM is a requirement. You know I did not mean
> that.
> > >
> > >
> > >>For various reasons (like load) it might make more sense to have the
> > >
> > > PM distributed.
> > >
> > > Sure. Also, the PerfMgr need not be colocated with the SM anyhow.
> > >
> > >
> > >>Anyway, my point is that the SM is not the owner of PM trap reporting.
> > >
> > > It is the PM that
> > >
> > >>should support Reporting (I.e InformInfo registration and Trap
> > >
> > > forwarding) for PM traps.
> > >
> > >>But the spec does not define such traps anyway.
> > >
> > >
> > > My point was that the PerfMgr is beyond the IBA spec. It is only the PMA
> > > that is defined and has no traps so these will all need synthesis by the
> > > PerfMgr.
> > Agree.
> > >
> > > -- Hal
> > >
>
--
--------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org
Somone asked me why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best answer:
"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's why
I draw cartoons. It's my life." -- Charles Shultz
More information about the general
mailing list