Conference netcad::hub_mgnt

    >   4/ When DEChub ONE plugged in the modules, like DS900TM,
    >      DC900MX and DR900TM, it works fine. But when it is plugged
    >      to a DB900MX, the lights on the DB900MX front planel
    >      was not light up.
    >      However when that DB900MX is plugged on the DEChub900,
    >      it works fine. Since I don't have the other DB900MX to
    >      verify, so my question is does DB900MX work in
    >      standalone mode ? According to the manual, it can.
    >      Could it be a hardware problem ?
    
    Burance, my guess is you have a DB900MX plugged into a 45 watt
    DEChub One. The DB900MX is the first (I believe), of the 900
    series HUB modules which requires the higher power 90 watt docking
    station (DEChub One). If you look at the serial label for the DEChub
    One that you have there, you might very well find that it is a 45
    watt variety DEChub One. This may explain why the DB900MX works in the
    HUB but not standalone.
    
    Bob

    	1/ When accessing 900FP's "port grouping" through HUBwatch,
    	   there is a 'MAC', what is the fuction of it ?
>>
>>	The MAC is the hardware which receives and transmits in-band
>>	messages on behalf of the repeater's integrated SNMP agent.
>>	The MAC is not in any way involved in the core repeater 
>>	functions (i.e. retiming/re-amplifying/re-transmitting data, 
>>	collision enforcement, auto-partitioning, etc). The MAC is 
>>	also used when the repeater is providing IP services. 
>>
>>	The HUBwatch grouping view for the DECrepeater 900FP allows 
>>	you to place repeater ports, as well as the MAC, onto any of 6 
>>	"internal lan"  segments ( which can in turn be placed onto any
>>      of 6 backplane Ethernet flexible channels). The MAC in the 900FP
>>	can only connect to one of the 6 internal lans at a time.
>>	Therefore, the MAC should be placed on a LAN segment which can be
>>	reached by your network management station if you are managing the
>>	900FP as a stand-alone module or the 900FP is configured as the
>>	hub's IP server. This is explained in the online help for HUBwatch's
>>	grouping view.    
>>
>>
>> 	Regards,
>>
>>	Rich
    

                When DC900MX is swapped to another slot, let's say 1,
               it is found that the FDDI port setup (both AB ports
               pointed to backplane) of DC900MX lost.
    
    
    
 >>  module configurations such as you describe above do NOT follow the                    
     module when it is removed from the hub.  When a module is removed from
     the hub, all port configuration information is deleted, and the module           
     goes back to its default configuration.  The configuration is NOT
     lost, however, in the event of a power loss to the hub, but only if a
     module is removed from the hub...
    
    
    
    
    

Hi Burance,
    
    From reading your questions regarding the DR900TM I first need to make
    sure that we're both using the same terminology.
    
    >	5/ I have one DR900TM. When using in standalone mode and the
    >	   NMS is connected to the front planel port, I can ping
    >	   and manage it through HUBwatch.
    
    Ok, no problem here.
    
    
    >	   But when it is plugged on the HUB900MS, I cannot
    >	   use the redirect method to access it through the NMS.
    
    Hmmm... this confuses me a bit.  The DR900TM supports local console
    redirect through the HUB900MS.  You can't use an NMS with this.  Are
    you trying to manage the DR900TM via the HUB900MS OBM port?  This is
    possible but I need more information on what you're trying to do. 
          
    
    >      But I can do the redirect through the other modules 
    >	   like the other DR900TM and DB900MX. Besides ping 
    >	   fails from the NMS (redirect from the other DETMM) to
    >	   that DR900TM.
    
    Once again, I'm unclear on your use of 'redirect'.  This almost sounds
    like you're trying to make the DR900TM your IP server for the HUB900MS. 
    Is this right?
    
    
    >	   I have checked the 'LAN INTERCONNECT', that DR900TM's
    >	   lan assignment is all right.
    
    What is the LAN Interconnect for the DR900TM?
    
    
    
    >	6/ I want to upgrade the DR900TM from V1.0b to V1.0g through 
    >	   VMS using NDUplus but fail.
    
    >	   The error message is shown in the attachment.
    
    The transcript shown below indicates that you have access to the DR900TM
    until you get to the TFTP stage.  Let me know what your LAN
    interconnect set up is like, and then I may be able to help more with
    this question.
    
    thanks,
    
    Charlie
    
--------------------------------------------------------------------------------
$ down load /force=pcommon 16.157.0.110 DETMM10G.BIN

(c) Digital Equipment Corporation. 1993. All Rights Reserved.

DECNDU: (TFTP) Target address = 16.157.0.110
[PCOMMON] Getting sysDescr
   DECrepeater 900TM 32 Port TP Ethernet Rptr SNMP, HW=v1,RO=v1,SW=v1.0B

[PCOMMON] Setting server IP address (pcomLoadIpHostAddr).
[PCOMMON] Getting Server IP Address
   16.157.0.229
[PCOMMON] Setting filename (pcomLoadFilename).
[PCOMMON] Get filename.
   DETMM10G.BIN
[PCOMMON] Setting AdminStatus/trigger (pcomLoadAdminStatus).
[PCOMMON] TFTP serve.
DECNDU: (TFTP) Blocks sent = 1

DECNDU: (TFTP) TIMEOUT on port.
[PCOMMON] TFTP server completed.
[PCOMMON] Polling for sysDescr
 Interrupt
    

    Hi,
    
    Thanks for the previous notes' reply.
    
    Below is more detail of problem #5 (DR900TM problem).
    
    There are 2 DR900TM, I name them A and B.
    
    B is attached to DEChub900ms and function all right. There are also
    DB900MX, DC900MX and DS900TM. A NMS is attached to DR900TM and
    it can ping to any devices attached on to the hub.
                                 
    When A is in standalone mode, through the console port, I set up the
    in-band and out-of-band IP address. I can use PC's SLIP protocol 
    to access A without any problem (through PC hubwatch).
    
    However when the NMS is connected to one of the UTP port, I cannot
    ping to the in-band ip address.
    
    Then A is connected to the HUB900 and NMS is attached to one of the
    UPT port of A. Through A's UTP port, I CAN ping any devices attached
    to the hub. However I still cannot ping the in-band ip address of A.
    
    Besides when NMS is attached to B, I stll cannot ping A either.
    
    Could it be the hardware problem ?
    
    Thanks,
    Burance.
    
    p.s. SW version of A is 1.0G.

    Burance,
    
    	It sounds like it may be a hardware problem of some sort, but from
    your description, it should never have made it out of self test.  Try
    clearing to factory defaults through the local console.  Then add the
    ip address once again and see if things improve.
    
    
    Charlie

    Hi Charlie,
    
    I have tried to reset it several times but still same problem.
    But that's a good point that self test should not pass if DETMM
    has such problem.
    
    Burance.

    Did you set the default gateway address on 'A'?
    

    .-1.          
    I will try it by tomorrow. But what is the point to set the gateway
    address ? The other DR900TM works fine without the gateway address.
    
    rds,
    Burance.

Hi Rich,

Ref to .2 reply from Rich ...


>>	The MAC is the hardware which receives and transmits in-band
>>	messages on behalf of the repeater's integrated SNMP agent.
>>	The MAC is not in any way involved in the core repeater 
>>	functions (i.e. retiming/re-amplifying/re-transmitting data, 
>>	collision enforcement, auto-partitioning, etc). The MAC is 
>>	also used when the repeater is providing IP services. 

   Why do we need to have a seperate MAC which takes care the
   SNMP management in 900FP but not in DR900TM ?
 
>>
>>	The HUBwatch grouping view for the DECrepeater 900FP allows 
>>	you to place repeater ports, as well as the MAC, onto any of 6 
>>	"internal lan"  segments ( which can in turn be placed onto any
>>      of 6 backplane Ethernet flexible channels). The MAC in the 900FP
>>	can only connect to one of the 6 internal lans at a time.
>>	Therefore, the MAC should be placed on a LAN segment which can be
>>	reached by your network management station if you are managing the
>>	900FP as a stand-alone module or the 900FP is configured as the
>>	hub's IP server. 

   Why MAC must be assigned to one of the flexible channel but not
   the thinwire (ethernet 7) segment ?
   Since it is a repeater why MAC must be assigned to a channel same
   as the NMS ?

>>	This is explained in the online help for HUBwatch'sgrouping view.    

   I have tried it but I can't find the grouping view. Besides do you
   know that is there any hardcopy manual of HUBwatch as the one in
   help ?

Thanks,
Bruance (HKMCS).

    

    Burance,

    Before I answer your questions I'd like to review the DECrepeater
    900FP's port switching capabilities so that I can make sure we are
    using the same terminology.
   
    As you know, the DECrepeater 900FP has 12 front bezel 10BaseFL repeater
    ports and a backplane Thinwire/docking station AUI repeater port. The
    fiber ports are divided into 6 port pairs. Each port pair may be
    arbitrarily connected to one of 6 *INDEPENDENT* "internal LAN"
    segments. Port pairs connected to the same internal LAN segment act as
    one logical repeater. Port pairs connected to different internal LAN
    segments are completely separate and act as multiple independent
    repeaters. This implies that the 900FP can be configured to be anything
    between a single 12 port fiber repeater to 6 2-port fiber repeaters.
    The 900FP does not repeat  between internal LAN segments.  Port pairs
    can be assigned to internal LAN segments whether the 900FP is
    configured stand-alone or in a hub.
    
    The HUBwatch Port Grouping window is used to assign port pairs to
    internal  LAN segments. This HUBwatch window calls the internal LAN
    segments "groups".
    
    Each of these independent internal LAN segments can be arbitrarily
    connected to one (or none) of 6 DEChub 900 backplane Ethernet flexible
    channels. Repeater ports on different modules connected to the same
    flex channel act in concert as one logical multi-port repeater. The
    900FP does not  repeat between backplane flex channels. 
    
    The HUBwatch LAN Interconnect window manages the mapping of internal
    LAN segments to backplane flex channels. 
    
>> Why do we need to have a separate MAC which takes care the
>> SNMP management in 900FP but not in DR900TM ?
 
    The DECrepeater 900TM does, in fact, have a MAC. The DECrepeaters 900TM,
    900GM, 900FP, 90FS, & 90TS all have MACs. A MAC in the repeater is
    necessary to support stand-alone management and provide IP services for
    the DEChub 900.
    
    The DECrepeater 900FP is unique among the above mentioned repeaters
    because its ports can be split between multiple internal LAN
    segments/groups. The repeater's MAC can only attach to one of these
    groups at a time. The HUBwatch port grouping view provides a mechanism
    to connect the 900FP's MAC to one of the 6 internal LAN segments
    supported by the 900FP.
    
>> Since it is a repeater why MAC must be assigned to a channel same
>> as the NMS ?
  
    The requirement is that the repeater's MAC must have some network path
    to  the NMS in order to be useful. If the flex channels to which the
    900FP's  internal LAN segments were mapped were in some way
    interconnected (by a DECbridge 900MX for example) then you would not
    necessarily have to put the 900FP's MAC on the same flex channel as the
    NMS.  As stated above, the DECrepeater 900FP does not repeat between
    its internal LAN segments or between backplane flex channels.
    
>> Why MAC must be assigned to one of the flexible channel but not
>> the Thinwire (ethernet 7) segment ?

    There is a hardware difference between the way the DECrepeater 900FP
    (and the 900TM, 900GM, 90FS, 90TS for that matter) connects to the
    backplane Thinwire segment and a backplane flex channel. Connection to
    the backplane Thinwire segment is made thru an internal repeater port.
    It is just like any other repeater port except that its connector is
    not accessible from the front bezel. Connection to  a flex channel is
    made thru a specialized, proprietary IMB (Inter-Module Bus) port.
    
    The repeater's MAC can only be connected to an internal LAN segment
    which may in turn be connected to a backplane flex channel. The
    backplane Thinwire port (or any front bezel port) and the MAC must be
    mapped to the same internal LAN segment in order for the MAC to be able
    to reach that LAN segment.
    
    While the 900FP cannot repeat between backplane flex channels, it can
    repeat between the backplane Thinwire segment and a backplane flex
    channel. This occurs when the repeater's backplane Thinwire port is
    enabled onto the backplane Thinwire segment and also mapped to an
    internal LAN segment which is connected to a backplane flex channel. 
    
    The 900TM, 900GM, 90TS, & 90FS can also repeat between the backplane
    Thinwire segment and whatever flex channel they are connected to. 
    
>> I have tried it but I can't find the grouping view. Besides do you
>> know that is there any hardcopy manual of HUBwatch as the one in
>> help ?

    By "HUBwatch grouping view" I meant the HUBwatch port grouping view
    which you referred to in .0.  You can access the on-line help button by
    pressing the "help" button in the lower right corner of the port
    grouping window.
    
    The part number for the HUBwatch Use Manual is AA-PW4BC-TE. However, it
    should be mentioned that there is much more detail in the On-line help 
    facility than in the Use manual. I don't believe there is any hardcopy
    available for the on-line help. Perhaps one of the HUBwatch engineers 
    following this string can comment?   
    

    Regards,

    Rich
    
                                  

  Rich,

  
  >>  While the 900FP cannot repeat between backplane flex channels, it can
  >>  repeat between the backplane Thinwire segment and a backplane flex
  >>  channel. This occurs when the repeater's backplane Thinwire port is
  >>  enabled onto the backplane Thinwire segment and also mapped to an
  >>  internal LAN segment which is connected to a backplane flex channel. 
    

    if you connect 6 internal segments of 900FP to 6 differents IMB 
    and Thinwire port to the Backplane Twinwire ,
    can you repeat on all ports ???

    a picture will be useful ..

    Jean-Yves

>>  if you connect 6 internal segments of 900FP to 6 differents IMB and
>>  Thinwire port to the Backplane Twinwire , can you repeat on all ports ???

    The following diagram is a MOSTLY accurate abstraction of the
    DECrepeater 900FP's port switching capabilities. HUBwatch and the hub
    manager (aka MAM) hide a lot of these complexities from  the end
    user...for good reason.
                       
                                                       BACKPLANE
   Rptr Ports/MAC               Internal LANs              |       
                     +-----+                     +-----+   |    
     +-------+       |     |       +-----+       |     |   |   +--------------+
    []Port  1[]-----[]  C  []-----[]LAN 1[]-----[]  C  []--|--[]Flex Channel 1|
    []Port  2|       |  R  |       +-----+       |  R  |   |   +--------------+
     +-------+       |  O  |                     |  O  |   |
     +-------+       |  S  |       +-----+       |  S  |   |   +--------------+
    []Port  3[]-----[]  S  []-----[]LAN 2[]-----[]  S  []--|--[]Flex Channel 2|
    []Port  4|       |  B  |       +-----+       |  B  |   |   +--------------+
     +-------+       |  A  |                     |  A  |   |
        .            |  R  |       +-----+       |  R  |   |   +--------------+
        .            |     []-----[]LAN 3[]-----[]     []--|--[]Flex Channel 3|
        .            |  F  |       +-----+       |  F  |   |   +--------------+
                     |  U  |                     |  U  |   |
     +-------+       |  N  |       +-----+       |  N  |   |   +--------------+
    []Port 11[]-----[]  C  []-----[]LAN 4[]-----[]  C  []--|--[]Flex Channel 4|
    []Port 12|       |  T  |       +-----+       |  T  |   |   +--------------+
     +-------+       |  I  |                     |  I  |   |
     +-------+       |  O  |       +-----+       |  O  |   |   +--------------+
     |  MAC  []-----[]  N  []-----[]LAN 5[]-----[]  N  []--|--[]Flex Channel 5|
     +-------+       |     |       +-----+       |     |   |   +--------------+
                     |     |                     |     |   |
     +-------+       |     |       +-----+       |     |   |   +--------------+
  +=[] BP TW []-----[]     []-----[]LAN 6[]-----[]     []--|--[]Flex Channel 6|
  |  +-------+       |     |       +-----+       |     |   |   +--------------+
  |                  +-----+                     +-----+   |
  |                                                        |   +--------------+
  +========================================================|==[] BP THINWIRE  |
                                                           |   +--------------+
   	                                                   |
                                                         
    As I wrote it .11, you can map the different repeater ports, including
    the backplane thinwire port, to different internal LAN segments. You
    can then map internal LAN segments to different backplane flex
    channels. 
    
    Consider the case in the diagram above if you were to map Ports 1 & 2
    and the BP Thinwire port to Internal LAN 2 and then map Internal LAN 2
    to Flex Channel 4. Map all other repeater ports to Internal LAN 6 and
    MAP Internal LAN 6 to Flex Channel 1. In this case, the 900FP would
    repeat between the backplane thinwire segment, Flex Channel 4 and front
    panel ports 1 & 2.  The 900FP would also repeater between ports 3, 4,
    5, 6, 7, 8, 9, 10, 11, & 12 and Flex Channel 1. In this example, a
    single 900FP is acting like 2 distinct repeaters. There is no
    connectivity between Flex Channel 1 and Flex Channel 4, nor is there
    connectivity between the backplane thinwire segment and Flex Channel 1.
                        
                                 
                                        

    
   

  thanks Ritch ,

  lovely picture and understand now clearly

  Jean-Yves