Conference netcad::hub_mgnt

    Ron,
    
    The DEChub 900 HUB manager will manage these modules.  However,
    in order to configure the HUB manager on the network you will
    need an IP services module (DECrepeater 900TM) or you can set up the
    OBM port via SLIP.
       
    If you can't do either of these then you will need a DECagent 90
    and a DECBridge 90 just like in the DEChub 90 case.
    
    Regards,
    
    Bob

SUMMARY: There has been some confusion about configuring the DEChub 900 MS for
management.  This note explains the management configuration rules for the
DEChub 900 MS which are much simpler than the rules for the DEChub 90.

DEChub 900 MultiSwitch MANAGEMENT CONFIGURATION RULES: Assuming you have a
module to provide IP services (currently only a DECrepeater 900 TM satisfies
this need), you do NOT need a DECbridge 90 or a DECagent 90 to manage
DECrepeater 90s.  You sill need a DECagent 90 on the LAN if you are going to
manage a DECbridge 90 or DECserver 90L or L+.  Also there is no slot 7 & 8
restriction in the DEChub 900 like there is in the DEChub 90.

RATIONALE: We are trying to design future modules so they do not need external
SNMP agents.  We also designed the DEChub 900 MultiSwitch so DECrepeater 90s
would be easily manageable in the hub (hub manager does Left Hitchcock to SNMP
translation).  Only the older DECserver 90 modules still need a DECagent 90
when they are in the DEChub 900 MS (the DECserver 90TL and M do not).  The
DECbridge 90 is the only other module in the DEChub 900 that still needs a
DECagent, but its use in the 900 should be very limited once the new 900 based
bridge comes out this spring.

Let me know if you are still confused,  Bill NAC::SEAVER

Reading the DEChub 900 multiswitch owners manual , draft SNMP management manual,
and the HUBWATCH Ver. 2.0 manual , I am not certain management of DECrepeater90s
in a DECHUB 900 offer more , less , or the same management capabilities 
available when managing the decrepeater 90s in a dechub 90.

I am looking for list of what management capabilities such as shown at the 
bottom of this reply that reflects the management capabilities for decrepeater
90s installed into a DECHUB 900ms when;

you want to manage the decrepeater 90s from the OBM , using command line snmp,

you want to manage the decrepeater 90s from the OBM , using HUBwatch,

you want to manage the decrepeater 90s via INBAND , no HUBwatch

you want to manage the decrepeater 90s from HUBwatch Ver 2.0, 


Can anyone point me in the right direction?

Thanks in advance,

Ron

I found this file in nac::lenac_user:[network.hub...]*****
       
           Here's a brief summary as to how the repeaters work. 
           ====================================================
           
           The DECrepeater 90C and 90T can handle a few basic management 
           tasks; 
           they can -
           
              1. Report the last address seen on a specified port.
              2. Watch for an address that it has been given to appear on any 
                 port.
              3. Enable and disable ports on command
              4. Report port status - OK or auto-partitioned
              5. Report the reason why a port was auto-partitioned
              6. Report the number of times that a port auto-partitioned and 
                 auto-restored itself.
              7. Report its type (10Base2 or 10BaseT) and number of ports.
              8. Report the slot in which it is installed.
           
           A repeater module must be asked these questions through a special 
           management bus that runs along the backplane of the DEChub 90. The 
           DECbridge 90 will regularly poll each repeater installed in the 
           same hub (or in a daisy-chained hub). The repeater is not 
           manageable outside the hub.
           
           We can tell which Ethernet addresses are attached to which 
           repeater ports, when the repeaters are configured 
           in a hub with a DECbridge 90.
           
           The information is not immediate, and it does depend on the 
           node sending regularly. However, connections can usually be 
           considered static in relation to the time it takes us to map the 
           addresses to ports.
      
           We cannot report traffic statistics on a per port basis. We can 
           report hub statistics if there is a DECbridge 90 in the hub.

	There is a difference - when you are managing DECrepeater 90's 
	in a DEChub 900 using the integral Hub Manager, you will not be 
	able to get the address information per repeater port. This 
	should be rectified in a future firmware update of the Hub Manager, 
	probably mid-to-late Q3 Fy94.

	There should be no difference in using HUBwatch in band or via 
	the OBM port. You should be able to get the same information using 
	command line SNMP, though with more difficulty. 

	Another difference is that the Dh 900 Hub Manager reports the 
	information using the IETF Repeater MIB, while the DECagent 90 
	will report it using DEC-specific MIB objects. I'm not sure 
	whether there are any objects supported by the DECagent 90 that 
	aren't in the IETF MIB.

	Because of the MIB difference, HUBwatch will use different 
	screens for a DECrepeater 90, depending on which agent is 
	proxying for the repeater.

    Specifically, you do get the last address seen on each repeater port,
    but cannot get a list of all addresses on each port (so the find
    address function does not work).
    
    This function was easier to do in the 90 case because the DECbridge90
    _knew_ what addresses to poll the repeaters about (from its forwarding
    database); the 900 hub manager will just have to watch the last address
    seen and build up the picture more slowly; the capability will be
    restored in a future release of the hub manager firmware.