Conference netcad::hub_mgnt

>>  However, when we disable one of the bridge port (e.g. P5) of the
>>    DB900MX (via HUBwatch V3.0 onOpenVMS), we did not get any trap from the
>>    hub or from the DB900, could someone clarify how to set up
>>    DB900/DH900/DR900/DS900 to send out enterprisespecific traps 
>>    (brdgportstatuschange, rptportstauschange, srvrportstauschange, etc..)?

   no currently supported with current firmware version



>>    2) After we add DECserver 900TM into agent table, we can manager it as
>>    a standalone module. But in HUB window (where it shows
>>    DS900/DR900/DB900/DC900), when we click on DS900, we get error from
>>    HUBwatch), it is a known bug that we cannot manage DS900 in HUB window,
>>    but can only be managed as a standalone module?


   work for me,

  with version of NAS ??
   can you posted your error message

   hope that's help you

   Jean-Yves

    
    Andrew,
    
    >> 2) After we add DECserver 900TM into agent table, we can manager it as
    >> a standalone module. But in HUB window (where it shows
    >> DS900/DR900/DB900/DC900), when we click on DS900, we get error from
    >> HUBwatch), it is a known bug that we cannot manage DS900 in HUB window,
    >> but can only be managed as a standalone module?
    
    There was also a problem with this not working if the DS900's community
    string was anything but "PUBLIC".
    
    Bob
    

>    When we disable one of the M port of the DC900MX (via HUBwatch V3.0 on
>    OpenVMS), we get a trap from DC900MX and the message is 
>    'console password failure' and that's not the right message, is it a
>    known bug with DC900MX trap?
 
No, it's not a bug with the trap.  It may be an DECmcc bug though.
   
>    However, when we disable one of the bridge port (e.g. P5) of the
>    DB900MX (via HUBwatch V3.0 onOpenVMS), we did not get any trap from the
>    hub or from the DB900, could someone clarify how to set up
>    DB900/DH900/DR900/DS900 to send out enterprisespecific traps 
>    (brdgportstatuschange, rptportstauschange, srvrportstauschange, etc..)?
 
To clarify .1 a bit...Bridge newRoot and topologyChange traps are optional,
and are not currently implemented.

Where did you get "brdgportstatuschange, rptportstauschange, 
srvrportstauschange, etc..)" enterprise specific traps?  I know of no
such traps.
 
>    3) How can we get the following FDDI information from DB900MX:
>    
>     a) Upstream Neigbour Address (UNA) and Downstream Neigbour Address
>     b) In FDDIPORT table, it does not show port A and port B status, where
>    can we get these status?
    
In the fddi MIB (rfc1512) check out "fddimibMACUpstreamNbr" and 
"fddimibMACDownstreamNbr".

Port A and B should be in the "fddimibPORTTable".

    I am using POLYCENTER Netview and am having trouble reading
    snmpFddiMACUpstreamNbr, and cannot find fddiMACDownstreamNbr.
    
    If I input the IP address and community (public) of my DECbridge900MX
    and select:
    .iso.org.dod.internet.mgmt.mib-2.transmission.fddi.snmpFddiMAC.
    snmpFddiMACTable.snmpFddiMACEntry.snmpFddiMACUpstreamNBR
    and choose "start query", I get back "Warning: no value(s) returned for
    query."
    However if I select:
    .iso.org.dod.internet.mgmt.mib-2.transmission.fddi
    and do a "start querey" I get back all the info from the SMT, MAC, PORT
    and ATTACHMENT groups. However it's difficult to read as the MIB values
    come out as something like "73.2.2.1.9.1.1 : 08 00 2b a3 cc a0"
    
    Do I need to specify something under "MIB Instance" to get to a
    specific entry in the MAC table?
    Where is MACDownstreamNbr? 
    
    Thanks for your help
    Bernie

You're using the older FDDI MIB.  RFC1285 was updated by RFC1512.  You'll
need to get RFC1512 and compile it into POLYCENTER Netview.

>    I am using POLYCENTER Netview and am having trouble reading
>    snmpFddiMACUpstreamNbr, and cannot find fddiMACDownstreamNbr.
 
After compiling RFC1512, query "fddimibMACUpstreamNbr", and
"fddimibMACDownstreamNbr".
   
							-Shawn

    Hi,
    Thank for all response.
    
    re .1, is there any plan to have traps sent from DB900 when any port
    status changes that will generate a trap?
    
    DS900TM is configured with PUBLIC as the community string and can ONLY
    ne managed as a standalone module that mean all IP/SNMP setup are
    correct. But the problem is when we open the HUbwatch window with the
    IP address of the HUB900 (the IBM address is DB900MX), the DS900TM can
    be displayed, but not accessible in the HUB window. Could someone
    explain how to make it work?
    
    DC900MX send out 'in-correct' traps, is it a known problem?
    
    Does V4.0 help in this case?
    
    After we compile ELAN mib from gatekeeper, DECmcc can get
    brgdportstatus, etc.. events from help.
    
    
    Any idea?
    Andrew Chiu - NIS

    
    Andrew,
    
    >>DS900TM is configured with PUBLIC as the community string and can ONLY
    >>ne managed as a standalone module that mean all IP/SNMP setup are
    >>correct. But the problem is when we open the HUbwatch window with the
    >>IP address of the HUB900 (the IBM address is DB900MX), the DS900TM can
    >>be displayed, but not accessible in the HUB window. Could someone
    >>explain how to make it work?
    
    Could you clarify here a bit? Are you able to manage the DS900TM
    standalone in the DEChub 900 using the same network configuration?
    The reason I ask is that the DS900TM must have network connectivity
    to the HUBwatch station, unlike the repeaters, MAX bridges, etc..
    If your DS900TM is on a different LAN as your HUBwatch station, you
    will not be able to manage it.
    
    Regards,
    Bob
    

>    re .1, is there any plan to have traps sent from DB900 when any port
>    status changes that will generate a trap?
 
Not scheduled at this time.
   
>    DC900MX send out 'in-correct' traps, is it a known problem?
 
No.  

If you'd care to explain this problem again then maybe someone
can help.  If it's the same problem you mention in your base note
then I stand by my answer in .3 - "No, it's not a bug with the trap.  
It may be an DECmcc bug though."

The concentrator sends "enterprise specific" port traps.  I've seen 'em.
I've seen 'em on a CMU trap catcher.  I've seen 'em on a "Sniffer".
They are encoded correctly.  They are sent at the right time.  There
are no know problems with these traps.   (Hmm.  I've found that the chances 
of there being a bug increase in direct proportion to how strongly I 
protest that there is no bug ;-)
                      

						-Shawn

    re .7/.8,
    
    Sorry I missed understand .3  note and I will post in MCC note file. 
    
    DS900TM is in the same hub of DB900MX/DC900MX and can be managed as a
    standalone module (we add it via HUBwatch for VMS V3.0 in agent table)
    and when we select it, we can change any port of the DECserver900TM.
    However, when we select the HUB900 hub manager from the agent table
    (using the DB900MX' ip address), we can 'see' the DS900TM as well as
    other DB900MX/DC900MX/DR900FP) in the HUB900, we can manage to look
    into other modules (DB900MX/DC900MX/DR900FP) BUT NOT DS900TM, I would
    like it could be a configuration problem with my hubwatch?
    
    Could someone clarify how to put DS900TM into HUbwatch?
    
    Thanks
    Andrew chiu - NIS

* You must configure the DECserver 900TM for SNMP access (through the DECserver
  console).  Section 3.6.3 of the V3.0 HUBwatch installation manual explains
  specifically how to do this...
	Local> DEF INTER SUBNET MASK nnn.nnn.nnn.nnn
	Local> DEF INTER ADDRESS nnn.nnn.nnn.nnn
	Local> DEF SNMP STATE ENABLE
	Local> DEF SNMP COMM PUBLIC GETNEXT ENABLE
	Local> DEF SNMP COMM PUBLIC SET ENABLE
	Local> DEF SNMP COMM PUBLIC ADDRESS [ANY | nnn.nnn.nnn.nnn]
	Local> INIT DELAY 0

* You must have the DECserver 900TM's community string set to PUBLIC.

* There must be an entry in the agents file for the DECserver 900TM (which
  includes its MAC address).  Use the Community->Manage Table menu from the
  HUBwatch front panel to edit your agents file.

If you do these three things, you can bring up a hub, double-click on the
DECserver, and get the terminal server management windows.

Unfortunetly, the terminal servers don't follow the same plug-and-play rules
that the other 900-series modules do, so there's a couple of extra steps to
configure them.

Tom Hood
HUBwatch

    Small correction to .8: linkDown and linkUp traps will be part
    of "Wave 3" scheduled for March shipment.  When a DECbridge 900MX
    (aka DECswitch now) port goes down, the generic linkDown
    will be sent (as long as the NMS doesn't happen to be on
    the LAN connected to the port which broke), and linkUp when it
    comes back up.
    
    Anil

    re .11,
    
    Thanks, but do you have the list of traps that will be implmented on
    DECswitch 900-EF (DB900MX), customer is building a dual-ring FDDI and
    managed via DECmcc with DEChub900 and DEcbridge 500/DC500. They can set
    up the alarms/recovery procedures with DEcbridge 500, but not with 
    DEChub900 ring, so they would like to know more on traps sent from
    DECswitch 900-EF for ring recovery etc..
    
    thanks
    Andrew Chiu - NIS Sydney

    Currently, the only trap supported by DB900MX/DS900EF is
    authenticationFailure, sent when someone uses a wrong community
    string to set or query the SNMP agent.
    
    In Wave 3, it will support the following additional traps: coldStart;
    linkUp; and linkDown.  This is the same set of traps suppported
    by the DECbridge 500, which you said works for you currently.  linkDown
    and linkUp are generic traps - however there is a 1-to-1 correspondence
    the bridge's link and port since it has only 1 FDDI port (unlike the
    concentrator, which has one link but multiple ports).
    
    Anil