Conference netcad::hub_mgnt

    Ole,
    
      What hardware version of the bridge do you have? In order to
    demonstrate FDDI Lanhopping, you will need the latest hardware version
    of the bridge which is REV E plus you will need to upgrade the 
    Hub management software.
    
    I have pointers to all this code in my VMS account. 
    
    Nat

	
	Hello,                  

	What do you mean HARDWARE revision "E plus"?
	Is there any defference HARDWARE revision and FIRMWARE revision?

	How can we check the HARDWARE revision? Does it mean the number 
	which was printed on backplane of DECbridge900 module? Or, the 
	number which can been shown from HUBwacth software?

	/Toyo	        

	

o From any SNMP tool, look at sysDescr.

o From HUBwatch, look at the Revision field in the DECbridge 900MX summary
  window.

o From the DECbridge 900MX console, select menu item [3]  Show Current Settings



You will see a string in the following format:

    DECbridge 900MX, 6-Ethernet/FDDI Bridge, HW=v0/0,RO=v0.2,SW=v1.2.0

RE: .0 .2   Ole, Toyo - 
To elaborate on what both Nat and Tom are alluding to, when the 
DECbridge 900MX is referred to as "rev E", we here in HUB Engineering, 
refer to the production version of the DECbridge 900MX as being rev E. 
That is, the revision of the I/O module half of the module pair inside 
is of rev "E" etch, and currently the etch rev of the Processor module 
is rev "D". Now when you look at the label on the DECbridge 900MX 
module box, you will see a rev "A01". This is the current production rev 
of the whole unit. To really verify whether you have a "rev E" production 
unit, you have to look at the "current settings" menu. As Tom mentioned, 
you will see the string as Tom showed it. If you see a "1" in the I/O 
module rev position, you have a rev "E" unit as we generically refer to it.

 DECbridge 900MX, 6-Ethernet/FDDI Bridge, HW=v0/1,RO=v0.2,SW=v1.2.1
                                              ^ ^
                                              | |
                    Processor Module rev------  |
                          I/O Module rev--------

So, to summarize, if you can see an "A01" on the box label, and see 
the hardware rev in the "current settings" menu as "HW=v0/1", you have
the most current DECbridge 900MX hardware being shipped from mfg.

Bob

    Thanks very much for the information.
    
    Nat, in the event that I could update the bridges where can I get the
    files from.
    
    Thanks.

	RE: .4
	
	Thanks, This Information.
	OK, I understand!

	I checked my customer's DECbridge900MX Revision field summary.

     DECbridge 900MX, 6-Ethernet/FDDI Bridge,HW=V0/1,RO=V0.2,SW=V1.1.2
                                                                ~~~~~~
	or.

     DECbridge 900MX, 6-Ethernet/FDDI Bridge,HW=V0/1,RO=V0.2,SW=V1.1 BL
                                                                ~~~~~~~

	o HW=V0/1  is OK , but SW=V1.1.2 and V1.1 BL is OK?

	Because now available Firmware Revision "V1.2.1" ,don't you?
	I Updated this Firmware.(I used NDU.)
	however,DECbridge900MX Firmware was not update. (DOWNLOAD command is
	successful complete.)

	After all. DB900MX's Firmware could not change,not update...

	I get Firmware form QUIVER::PROJ$722:[ONEHUB.RELEASE.DEFBA.V1_2_1]
	DB900MX_121.BIN;1

	Is this ture V1.2.1 Firmware?


	Regards,	
	/Toy.

    The most current revision of DECbridge 900MX firmware is v1.2.1,
    that's correct. 
    
    >> QUIVER::PROJ$722:[ONEHUB.RELEASE.DEFBA.V1_2_1]DB900MX_121.BIN;1
    
    If that's the pointer that was given you, then it is probably a 
    valid image of v1.2.1 firmware.
    
    Bob

Have the same problem like in .6. After the upgrade with NDUplus, the Bridge 
shows the same firmwareimage as before.

The failuremessage is:
DECNDU: (TFTP) Transfer Complete.
[HUBMODULE] TFTP DOWNLOAD COMPLETED
[HUBMODULE] Polling for chasLoadOperStatus
3 - FAILURE

[HUBMODULE] Getting Device specific load status
   -255


After I gave the Bridge an separate IP address and loaded with the command

$ download load/force=pcommon B900_121.BIN;1

and it worked


Roland

    re. .8
    
    I had the same problems (Note 1030.0) and loaded it with PCOMMON
    and everything is fine.  Until someone tells how to load thru the
    HUB i'll continue to do a direct load.  Remember to check to see
    if the IP address remains after the upgrade.  If it does, then zero
    it out.
    
    dave

    Bridge versions earlier than 1.2.1 did not have "MAM-assisted load" -
    that is, they could not load via the Hub manager.  1.2.1 does support
    it, so in future you should be able to do this.
    
    In practice, it is strongly recommended that a bridge get its own IP
    address.  For one thing, the loads will happen significantly quicker
    since they would then be done over one of the datalinks (either 10 Mbps
    or 100 Mbps), as opposed to going to the MAM first and then through an
    internal serial line to the bridge.  The image is quite large.  For
    another thing, the bridge looks like a router when doing IP
    fragmentation, and needs its own IP address to implement MTU Discovery.
    
    When a router upgrade becomes available, the image will become even
    larger, with the consequence that the Hub Manager will no longer be
    able to redirect a load to the bridge/router.  Bottom line is, it's
    best to give the bridge an IP address of its own and use
    PCOMMON to load it.  In general, never shuffle IP addresses around
    modules or Hub managers, it can cause difficult-to-debug problems.
    
    Anil