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


_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

Reply via email to