Re: Simple Question

[[e-mail] (Keith McCloghrie)]

Ken,

I think a better analogy would be: a workstation with several
interfaces, and you are incoporating into the workstation, a 
terminal server-type capability for some of the interfaces.
To refer to the 2nd SLIP interface on the 2nd terminal server,
you would need different MIB views for the different terminal 
servers.  Since you don't want to assign IP addresses to the 
individual terminal servers, and you presumably want to have a 
single SNMP agent manage everything, you would need to assign 
different community names (or party OIDs) to each of them.
A standard NMS having the ability to communicate via a proxy 
agent (e.g., the NMS that I am most familiar with) would then 
be able to refer to ifOperStatus.2 in the appropriate community 
(or party).  

Why do I think this is a better analogy ?  Because it is adding
additional *devices* (not just *interfaces*), which is what you 
are doing in your scenario by incorporating multiple repeater 
devices into an existing bridge device.  Thus, to refer to your
2nd port of the 2nd group of the 2nd repeater, the NMS would refer
to rptrPortOperStatus.2.2 in the appropriate community (or party).

[Also note that that there is no (longer a) separate "View MIB", and
implementing the Party MIB is (expected to become) required irrespective
of whether or not you add repeater functionality.]

Keith.
----------
>From [e-mail] Mon Jun 15 16:00:56 1992
From: [e-mail] (Kenneth Virgile)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Simple Question
Cc: [e-mail]

I already have a box with FDDI and
Ethernet interfaces.  So my box supports
the mib-2, fddi, and the dot3 MIBs.
Just about any NMS can manage my box, (all
the NMS needs is that standard MIB support),
and each mib-2 ifEntry corresponds to a real
physical interface.

Now I try to add a new type of interface, an
Ethernet repeater.  In order for that interface
to be manageable, the NMS must implement a highly
complex set of new MIBs!!!  It needs the ethernet
repeater MIB, but that is just for a single repeater,
not for a box that might have several repeaters.
The NMS also needs the Chassis MIB, and the Party
and View MIBs.  And it's still not clear how
the NMS can access any of a repeater interface's
parameters.

I have a simple question for the Chassis and
Hub Working Groups.

First the scenario:

  A customer wants a simple plug-and-play bridge,
  including some ethernet repeater interfaces.

  The customer knows a little about IP, and wants
  to assign a single IP address to the bridge (I'm
  not about to correct the customer - what the
  customer wants is what the customer gets;
  otherwise, I can't sell my product).

  The customer expects to then turn on the bridge, and
  use a standard NMS (e.g., HP Open View) to manage
  the bridge.

Now the question:

  What MIB parameter should the NMS access in order
  to, say, determine if a particular repeater port has
  been auto-partitioned?  [For example purposes, say
  the repeater port is the 2nd port of the 2nd group of
  the 2nd repeater interface, which is also the 2nd
  interface of the bridge.]

  Please be specific with your response.  As an analogy,
  if the 2nd interface was just dot3 or FDDI, then
  the NMS would reference ifOperStatus.2 to determine if
  it was operational.

Please post all responses to both Working Groups:

  [e-mail]
  [e-mail]

Thanks,
Ken