Conference 7.286::fddi

959.0. "Problem vith DEC ELAN MIB V2.7" by ANTIK::WESTERBERG (Stefan Westerberg DS Stockholm) Tue May 18 1993 09:23

Hi, I'am trying to use the DEC ELAN mib V2.7 to manage the DECconcentrator 500 
with firmware release V3.2.1.

The first problem I'am having is that when I read the esysFddiPortTrapSwitch
attribute the concentrator returns 0 (zero). Reading the mib it state only
two possible return values and none of them is 0. 

    esysFddiPortTrapSwitch OBJECT-TYPE
        SYNTAX  INTEGER {
                           true(1),
                           false(2)
                        }
        ACCESS  read-write
        STATUS  mandatory
        DESCRIPTION
               "This is a switch to enable or diable FDDI port up and port
               down traps.  When set to true, the concentrator will
               send a trap when one of its ports comes up or goes down."
        ::= { esysConcConfig 2 }

If I try to set esysFddiPortTrapSwitch to 1 or 2 I don't get any response from
the concentrator. Do I need to set somethine else up to make this work ?

The V2.7 ELAN mib has no reference of the defcnPortTrap but I have found it
in the relase notes. But I can't find any reference of "ENTERPRISE defcn" in
the ELAN mib.

defcnPortTrap     TRAP-TYPE
      ENTERPRISE   defcn -- 1.3.6.1.4.1.36.2.15.5.0
      VARIABLES    {   snmpFddiPORTConnectState   }
      DESCRIPTION  "The DECconcentrator 500 (DEFCN) sends this trap"
      ::= 1

I suspect it could be defined as:

	defcn	 OBJECT IDENTIFIER ::=  { emaSystem 5 }

Also reading the ELAN mib the emaSystem defines groups of devices not specific
devices as defcn or decbridge90.

    emaSystem       OBJECT IDENTIFIER ::=  { ema 15 }

    bridges         OBJECT IDENTIFIER ::=  { emaSystem 3 }
    defcn           OBJECT IDENTIFIER ::=  { emaSystem 5 }  -- Added by SW
    terminalServers OBJECT IDENTIFIER ::=  { emaSystem 6 }
    hub             OBJECT IDENTIFIER ::=  { emaSystem 8 }
    repeaters       OBJECT IDENTIFIER ::=  { emaSystem 9 }
    proxyAgent      OBJECT IDENTIFIER ::=  { emaSystem 10 }
    brouters        OBJECT IDENTIFIER ::=  { emaSystem 11 }
    routers         OBJECT IDENTIFIER ::=  { emaSystem 12 }
    networkProbes   OBJECT IDENTIFIER ::=  { emaSystem 13 }

    decbridge90     OBJECT IDENTIFIER ::=  { bridges 5 }
    decbridge90FL   OBJECT IDENTIFIER ::=  { bridges 6 }

    decserver90Lv1  OBJECT IDENTIFIER ::=  { terminalServers 1 }
    decserver90Lv2  OBJECT IDENTIFIER ::=  { terminalServers 2 }
    decserver90TLv1 OBJECT IDENTIFIER ::=  { terminalServers 3 }
    decserver90M    OBJECT IDENTIFIER ::=  { terminalServers 4 }

    dechub90Backplane OBJECT IDENTIFIER ::=  { hub 1 }

    decrepeater90C  OBJECT IDENTIFIER ::=  { repeaters 1 }
    decrepeater90T  OBJECT IDENTIFIER ::=  { repeaters 2 }
    decrepeater90FA OBJECT IDENTIFIER ::=  { repeaters 3 }
    decrepeater90FL OBJECT IDENTIFIER ::=  { repeaters 4 }

    decagent90      OBJECT IDENTIFIER ::=  { proxyAgent 1 }

    decbrouter90T1  OBJECT IDENTIFIER ::=  { brouters 1 }
    decbrouter90T2  OBJECT IDENTIFIER ::=  { brouters 2 }
    decbrouter90T2A OBJECT IDENTIFIER ::=  { brouters 3 }

    decwanrouter90  OBJECT IDENTIFIER ::=  { routers 1 }

    decpacketprobe90  OBJECT IDENTIFIER ::=  { networkProbes 1 }


But wouldn't be better to supply a ELAN mib ready to be compiled into DECmcc ?

Regards Stefan

    My copy of the  DEC Vendor MIB V2.7  has no mention of the
    emaSystem, bridges, etc  groups.  Is this a new release?
    
    Thanks,
    Bill

   > My copy of the  DEC Vendor MIB V2.7  has no mention of the
   > emaSystem, bridges, etc  groups.  Is this a new release?

	Sorry about that, I was trying to use the ELAN mib with the
	DEChub90 mib and for that reason I had to merge the files.
	In the the DEChub mib the emaSystem group is defined. And some
	where along the path i forgot that (I'am located in a temporary
	office with a very poor ventilation system).

	I have no sorted my problem out, after reading the releae notes
	I found the write-community name and where able to set 
	esysFddiPortTrapSwitch to a valid value. And then MCC where
	able to read the attribute.

	But still I have some questions on how "ENTERPRISE   defcn" is
	to be defined. An enterpriseSpecific trap returns an 
	enterprise string as "1.3.6.1.4.1.36.2.15.5.1". But in the
	release note it state "1.3.6.1.4.1.36.2.15.5.0".

	/Stefan