Subject: Loading RFC 2108 802.3 Repeater MIB into OpenView NNM.

From: [email-masked]
Date: Mon, 1 Dec 97 15:53:00 +0100

I have been trying to load the repeater MIB into NNM by taking the RFC 
     2108 and cut away anything but the definitions part. 
     
     NNM didn't like the NOTIFICATION-TYPE's and the end, even though it 
     should be SNMPv2C compliant. Is the NOTIFICATION-TYPE defined in a 
     RFC?
     
     The rest compiled ok, but e.g. the rptrAddrSearchTable is missing when 
     using the MIB browser. Is it supposed to be directly under 
     snmpDot3RptrMgt or further down the tree?
     
     Has anybody loaded this MIB into a management system?

     Best regards,
     
     Michael.

     +------------------------------------------------------------------+
     | Michael Imhoff Nielsen    Phone:      +45 4599 1000              |
     | OpenView Consultant       Direct:     +45 4599 1431              |
     | Professional Services     Fax:        +45 4281 5810              |
     | Hewlett-Packard           Private:    +45 4731 6640              |
     | Kongevejen 25             Internet:   [email-masked]      |
     | DK-3460 Birkeroed         TN:         546-1431                   |
     | Denmark                   WWW:        http://www.hp.dk           |
     +------------------------------------------------------------------+

---

From: John Flick <[email-masked]>
Date: Mon, 1 Dec 1997 14:14:37 -0800 (PST)

>      should be SNMPv2C compliant. Is the NOTIFICATION-TYPE defined in a 

NOTIFICATION-TYPE is defined in RFC 1902.  NNM does understand
NOTIFICATION-TYPE, but it seems to have problems with the OID value
assigned to the notifications in 2108.  For example, the value of the
rptrInfoHealth notification is { snmpDot3RptrMgt 0 4 }, which NNM
chokes on.  It doesn't seem to like having more than two OID
components in the value, though I believe this is a legal (though
unusual) construct.

One workaround may be to define a new OID:
snmpDot3RptrTrapPrefix OBJECT IDENTIFIER ::= { snmpDot3RptrMgt 0 },
and modify the NOTIFICATION-TYPE values to use this prefix.  In the
example above, rptrInfoHealth would have the value
{ snmpDot3RptrTrapPrefix 4 }.  This does mean editing the MIB to make
it acceptable to NNM.

Does anyone have a better workaround for this?

 >      snmpDot3RptrMgt or further down the tree?

The path to this tree is:
snmpDot3RptrMgt.rptrAddrTrackPackage.rptrAddrTrackRptrInfo.rptrAddrSearchTable

Note that this is a rather new table, so there are likely to be many
repeater agents out there that don't support this table yet.
An agent that does not support this table would not return it when you
are browsing that agent.

Hope this helps.

John

---

From: "Brian O'Keefe" <[email-masked]>
Date: Mon, 01 Dec 1997 16:35:17 -0700

> components in the value, though I believe this is a legal (though

Older versions of NNM are definitely broken.  I believe that
version 5.0 allows more than two OID components BUT it requires
that all except the last one have an associated descriptor, e.g., 
{ snmpDot3RptrMgt foo(0) 4 }.  I think (poor memory) I had a
conversation about { foo 2 3 4 } type OID defintions with Dave
Perkins some time ago, and I thought he agreed that the latter
is not legal, but the former is legal.  Dave, are you out there
to comment?

> { snmpDot3RptrTrapPrefix 4 }.  This does mean editing the MIB to make

Granted, my product is the guilty (at least accused) party
here, but this hardly sounds like a "workaround".  Instead,
I'd say it is the more explicit / complete way of defining
the mib.  As far as the descriptor (name) goes , why not just 
use "snmpDot3RptrTraps" for the "0" component...  after all,
the mib object sub-tree isn't called
"snmpDot3RptrObjectsPrefix" ;^)

bok

---

From: John Flick <[email-masked]>
Date: Mon, 1 Dec 1997 16:40:57 -0800 (PST)

> is not legal, but the former is legal.  Dave, are you out there

As an additional data point, both smicng and mosy accept both forms
with no complaints.

 > "snmpDot3RptrObjectsPrefix" ;^)

I guess I don't care whether it is NNM or the MIB module that is the
"guilty party".  I do agree that there is no good reason for not
defining the "0" subtree using an OBJECT IDENTIFIER assignment, but
the RFCs have already been published and the damage is done.

I don't care what descriptor is given to the traps sub-tree.

My response to the original post was not intended to critisize NNM.
It was intended to give the minimum edits that a user needs to make
to the MIB module to be able to load it into NNM.

John

---

From: [email-masked]
Date: Tue, 2 Dec 97 08:20:49 +0100

The reason for RFC 2108 being so interesting is the fact that it's 
     used for level-2 discovery together with MAU MIB (RFC 1515) and bridge 
     MIB (RFC 1493). As far as I can tell is either repeater/MAU MIB or 
     Bridge MIB (that is for NNM 5.0x UNIX, NNM NT only uses Bridge MIB).
     
     I just wanted to load RFC 2108 (and not just the old repeater MIB RFC 
     1516 that comes with NNM) in order to test whether the switches 
     supports this MIB or not in order to do proper level-2 discovery.
     
     Anybody know how far implementation is with Cisco and 3Com switches?

     - Michael.

______________________________ Reply Separator _________________________________
Subject: Re: Loading RFC 2108 802.3 Repeater MIB into OpenView NNM.
Author:  johnf-at-rose ([email-masked]) at HP-Belgium,mimegw3
Date:    02-12-97 01:40

John

---

From: "Brian O'Keefe" <[email-masked]>
Date: Tue, 02 Dec 1997 08:36:46 -0700

> As an additional data point, both smicng and mosy accept both forms

Dave Perkins wrote:
On what is valid OID values, both of the following are legal:
    { snmpDot3RptrMgt foo(0) 4 } (first form)
      and 
    { snmpDot3RptrMgt 0 4 }  (second form)

Looks like an NNM defect. I'll submit the defect report to
get the repair wheels turning.  In the mean time, the workaround
that John identified is easy enough to do.

> the RFCs have already been published and the damage is done.

Understood.  Can updating the mib as suggested be a work item
for the next time the MIBs come up for review.

> to the MIB module to be able to load it into NNM.

Understood.

bok

---

From: John Flick <[email-masked]>
Date: Tue, 2 Dec 1997 13:28:22 -0800 (PST)

>      Anybody know how far implementation is with Cisco and 3Com switches?

RFC 2108 is a repeater MIB.  Switches are not repeaters.  I would be
rather surprised if switches did implement RFC 2108.  I would expect
switches to implement the Bridge MIB (RFC 1493), where the address
table provides the information needed for layer-2 discovery.

A better question would be to ask how far along hub vendors are at
implementing RFC 2108.

John