Conference netcad::hub_mgnt

    Giles,
    
       Make sure no pins are bent on the bridge. Do a visual inspection.
       Have you tried the bridge in different slots in the DECHUB900?
       This eliminates a bad slot in the hub.
    
       Does it comeup in a different DEChub900?
    
       Sometimes, you need to physically add and take out a module in a hub
       several times to establish pin connectivity. Have you tried that?
    
       I am just trying to eliminate some mechanical knowns.
    
       

    Also, while in the docking station (I assume a 90watt), per the bridge
    menu, what is its current hw,rom,sw version?

    Hi,
    
    	I have tried 3 different DECBridge 900s in all slots from 4 to 8
    with no success, even reseating them several times as you suggested.
    I only have one HUB to play with so I cannot try another. The Hub
    Manager reports the device being added/removed but always says device
    type unknown. The Hub is ok as I have currently a DR900TM in slot 1,
    a DS900TM in slot 2, a DR900FP in slot 3, a WANrouter 90 in slot 5 and
    a DB90FL in slot 6. 
    
    	When pulgging any of the three bridges into a docking station, I
    cannot talk to them via the setup port using a terminal or via a
    reverse lat port from the DECserver 900. This means I cannot see the
    menu and therefore what they have configured software wise. 
    
    	Should I be using the OBM port with a H8571-J or the port where the
    MP cable plugs straight in ? I have tried an MP to MMP cable from a
    terminal and a MP-MP cable to the DECserver port.
    
    
    Giles.

    Giles - When you have one of these bridges plugged into a docking
    station, as you mentioned the mod_ok led comes on and the power
    led is on. If you were to plug a lan cable (UTP or AUI), I'd be
    interested in knowing if the ports come up in forwarding. Also
    please tell me if you can, the serial number if the bridges and
    also please verify that the docking station being used is a 90
    watt docking station and not a 45 watt docking station.
    
    Bob

    
    OK, I am using a 90W docking station and the Mod_Ok light is not 
    lit, as I previously thought it was. If I plug an AUI cable into the
    the top AUI port the LED lights ok, the led marked with a # lights 
    at regular intervals and then goes off again. 
    
    The bridge serial numbers are : AS40300147
    				    AS40300156
    				    AS41200232
    
    Giles.

    If what you are telling me is correct, that is, that the state led
    # for port 2 (your top AUI port), lights up at regular intervals and
    goes out, anf then repeats again. While this is occuring, the
    traffic activity led -> adjacent to this led is indicating traffic.
    If this is what you are seeing, then I have a hunch the bridges
    are possibly brain dead and are sending out bootp requests to perform
    a primitive load. There is a note (I think it's 1193.1), with
    suggestions on how to set up your bootp server to respond to the
    bootp requests possibly coming from these bridges.
    Otherwise, I myself don't have any other suggestions.
    
    Bob

    Thanks for your help Bob, I will look at the note mentioned and
    see if I can load them. 
    
    Giles.

    Given the symptoms, this is almost certainly the problem.
    
    A couple of suggestions.  When you encounter a problem, check the
    "Problem Solving" section in the Installation Manual.  This problem
    is described clearly in there, for example.
    
    Secondly, the only way you can corrupt the Flash in this way
    is to power down the unit while a Flash downline upgrade is in
    process.  There is a rather strongly worded caution in lots of
    places (including the Installation Manual, Release notes, and Setup
    menu) that says not to power down the unit during a downline
    upgrade.  In the case of the DECbridge 900MX which has 4 MB of Flash,
    it takes up to 5 minutes to load.  LEAVE THE UNIT ALONE DURING
    THESE 5 MINUTES!  It will reboot itself when the load is complete.
    (This is true for all hub products.)  The problem is that if you unplug
    the unit in the middle, then only part of the image has been programmed
    into the non-volatile Flash memory; as a result you have some of the
    new image and some of the old one, which is basically a corrupted image
    that the bridge cannot execute (a CRC failure is detected by selftest).
    
    Anil

    
    These Bridges were loaned to me after another group had been testing
    them, so I guess they must have been screwing with them in a major 
    way. 
    
    By the way, I did check the Problem Solving section but wanted to be
    sure that I was seeing whats described before getting them replaced.
    
    Thanks again for the help.
    
    Giles.

    Did you try setting up a load server to see if they would load?
    
    Bob

    Just read your note Bob, trying it as I write. I'll let you know
    whether I can get one working or not.
    
    Giles.

    Bob,
    
    	Tried loading two of the Bridges via the HUB_LOAD.COM file
    but neither will load as I get the following :-
    
     download load 08-00-2B-A3-4D-90 MOM$LOAD:DEFBA140.BIN /force=pcommon
    /pass="public"
    
    (c) Digital Equipment Corporation. 1993. All Rights Reserved.
    %NDU-E-READ_DEVICE, error during read device
    %NDU-E-NORESP_ERR, no response from target
    %NONAME-E-NOMSG, Message number 00000002
    
	As the Hub900 reports the line cards for the bridges as not active
    I cannot load them by the Hub either, so I guess I'll have to wait for
    Field Service to replace them anyway.
    
    Giles.

Giles,

Why are you trying to load the DECbridge 900MX by specifying the MAC address? 
That won't work.  This causes NDU to attempt a MOP load which the bridge doesn't
support.  You have to specify the bridge's IP address so a TFTP load will be
initiated.

...Roger...

    Giles - Also, in addition to what Roger said, don't forget
    that there should be an AUI cable on port #2 (the first AUI
    port on the DECbridge 900MX). If the bridge then starts the
    load procedure, you should see the state leds walk through
    from left to right as the TFTP load commences, bridge verifies
    checksum, then writes loaded image in two parts to respective
    flash memories, FDDI image, and then main image. 
    As Roger said, the TFTP primitive load is done using in-band
    connectivity.
    
    Bob

    Bob/Roger,
    
    	Ok, appologies for misunderstanding this sequence, I have now
    tried to redo this using the IP address I had registered for the
    bridge but the load I get :-
    
    .
    .
    .
    [PCOMMON] Getting sysDescr
    DECNDU: ERROR STATUS = No response from device.
    
	when trying to load the first Bridge. What I don't understand is,
    if I havent been able to talk to the Bridges all along either through
    the Hub 900 backplane or via a terminal connected to a DEChub One, then
    I havent been able to set the IP address on the Bridge so how does it
    know that this is its IP address, and the load is for it ..?
    
    Giles.
                                                                           

    If the bridge is truely brain-dead, it has enough primitive code
    in ROM to perform the TFTP primitive load without needing an
    IP address. What the bridge does is to send out a BOOTP request
    executed from the code in ROM. Thus all one should have to do
    if one suspects the bridge is brain-dead is to connect (in this
    case of your bridges), an AUI cable to port #2 of the bridge and 
    apply power to it (either in stand-alone in a DEChub ONE or in a
    HUB). Assuming you have set up a system to act as a load server as
    described in that other note I made reference to, the bridge if it
    is brain-dead should load. If the bridge (and the other two), don't
    load, then there is something else wrong with them.
    
    Bob

    Giles - Please re-read note 1193.1, and you should understand what 
    we are saying.
    
    Bob

    Bob,
    
    	I have followed the correct procedure but the Bridge does not have
    the 1 LED lit to indicate BOOTP requests being sent out.
    
    
    Giles.

    OK, one last try!  (This note should probably be retitled to something
    like "Repairing Corrupted Flash on DB900MX", so others can benefit
    from it later.)
    
    You mentioned that an LED marked with # goes on and off at regular
    intervals (should be every 8 seconds).  This is the indication, with
    later revs of boot block, that a BootP request is being sent out
    regularly.
    
    When Flash is corrupted, you CANNOT use the normal load procedure.
    At this point, the bridge does not remember its IP address and does
    not have the smarts to process the SNMP used by NDU.  In this "primitive"
    mode, the module will look for a BootP server to tell it two things:
    
    a) what its IP address is (so it can go on to do TFTP),
    b) the IP address of the server, and the filename of the image it can TFTP
    into its Flash to fix itself.  The note referenced by Bob seems to
    describe the procedure correctly, at least for an ULTRIX BootP server.
    (If you have a different machine you want to use as a BootP server,
    see the man pages on it to figure out how to set up BootP.)
    
    Anil

    
    OK, my last try! Mr Moderator please change this notes title, re -1.
    
    I had configured a VMS 5.5-2 system with UCX 3.1 and enabled the
    BOOTP/TFTP service as instructed. I had set the hardware address in the
    ARP cache and added an entry in the BOOTP table eg:
    
    UCX> set arp 08-00-2b-a3-4d-90 db900mx.reo.dec.com
    UCX> sho arp
                                  ARP table entries
    
    Ethernet           Internet        Host name           ARP status
    AA-00-04-00-EA-AA  16.36.0.134     msuman.reo.dec.com  INUSE CMPL
    AA-00-04-00-5B-AB  16.36.0.4                           INUSE CMPL
    AA-00-04-00-FF-AB  16.36.0.2                           INUSE CMPL
    08-00-2B-A3-4D-90  16.36.0.173                         INUSE CMPL
    
    UCX> set bootp db900mx/hard=address=08-00-2b-a3-4d-90/file=defba140.bin
    UCX> show bootp/fu
    
    Host:         16.36.0.173
                                            Hardware Address:
    08-00-2B-A3-4D-90
    Network mask: 255.0.0.0                          Type:    Ethernet
    File:         DEFBA140.BIN
    
    Time offset:            0               Vendor:
    
    Gateways:     not defined
    
    Servers:
     Cookie:      not defined
     IEN:         not defined
     Impress:     not defined
     Log:         not defined
     LPR:         not defined
     Name:        not defined
     Resource:    not defined
     Time:        not defined
    UCX>
    %%%%%%%%%%%  OPCOM  20-SEP-1994 11:23:26.06  %%%%%%%%%%%
    Message from user INTERnet on QUAD
    INTERnet ACP TFTP Accept Request from Host: 16.36.0.173  Port: 65529
    
    The Bridge then goes through the process of illuminating the port state
    LEDs from port 2 through 6 in turn. All the port state LEDS then
    alternate with a green flash then yellow flash a couple of times and
    then I am left with port 2 permanently yellow, which is a port failure
    according to the "Problem Solving using the LEDs" section.
    
    I seem to be able to sort of talk to the console port but only get a
    letter "o" with an accent above, for every carriage return at 9600 baud.
    
    Looks like I have a further weeks wait at least on a replacement through
    Field Service on top of the two weeks already. Just as well this is
    just me trying to get to know the Bridge and not a failure of a live
    unit somewhere on the UK LAN. Is it really supposed to be this
    difficult for Engineers to get a replacment on P1 from the US for 
    new modules that are released. 
    
    I hope external customers in the UK don't have to wait this long. I was
    informed there were not only no replacement units in the UK, but there 
    were none in Nijmegan either so they have to be brought in from the US.
    
    
    Anyway, many thanks for all the help and pointers, I have certainly
    learned plenty that I would otherwise not have known about. I have
    always thought that before manuals/products are released they should
    be tested by someone with no experience of the subject as people in at 
    the deep end can very easily forget whats its like to approach the
    subject from scratch. 
    
    Cheers,                                                                
    
    	Giles.

>    The Bridge then goes through the process of illuminating the port state
>    LEDs from port 2 through 6 in turn. All the port state LEDS then
>    alternate with a green flash then yellow flash a couple of times and
>    then I am left with port 2 permanently yellow, which is a port failure
>    according to the "Problem Solving using the LEDs" section.
 
That permanently yellow port 2 LED is highly symptomatic of a wanna-be
V2.0 DB900MX - the brouter version that was not productized.  An older 
version of the debug boot block for a V2.0 will request a download and 
report a successful download just as you described.  The yellow port 2 LED
indicates that the ROM is waiting to sync up with the MRI XRAY symbolic
debugger.

A phone call with Giles verified that these units came from the Reading
group that had been working on V2.0.

These boards are out of hardware rev as well as firmware rev.  While you
could try taking the units apart and removing any jumpers you find, to
get rid of the pause for XRAY, I suspect other boot ROM differences will
prevent you from having a bona fide DB900MX. 

	Dotsie

    Looks like it will be Christmas before we get any replacements for
    these Bridges as I have been informed that due to problems making them,
    no units will be shipping over to the UK during the months of October
    and November. This is very frustrating as it means not only can we not
    test the Bridge, we cannot purchase any for use on the LAN here at
    REO.
    
    Giles.