Conference netcad::hub_mgnt

1301.0. "Diary of an upgrade - bad docs & quirks" by PTOVAX::DANZAK (Pittsburgher �) Thu Aug 11 1994 01:53

I needed to set up a hub demo yesterday.  This required:
  - Upgrading DECbridge 900MX firmware to new level
  - Upgrading DECrepeater 900TM firmware to new level
  - Setting up per-port security for a SECRET environment

=====I'd like to suggest the following:

  1.) DECNDU be better documneted.  NOT knowing the right command line
      to use wasted several hours.  (note that when at a customer site
      you do not always have access to NOTES files, DTN, etc.)

      A simple TEXT file as part of the release notes that say:
        "For modules DECBRIDGE 90, DECREPEATE 90FL, do THIS: "mumble""
    
      Examples show commands using the '/FORCE=' but nothing explains
      WHAT it does! 
            
  2.) Firmware names should be the SAME across platforms and their naming
      should reflect version numbers (DB900123.BIN versus DB900MX_123.BIN)
      Something that works for (uugh) MS/DOS will work everwhere.  If it
      works everywhere we should use it everywhere and not make exceptions
      for aesthetics.  (Cross platform consistency before aesthetics)

     When we looked at the public FTP area on DECWRL it was not possible to
     know what versions of stuff was out there. Also, older firmware versions
     need to be there to be able to upgrade some things (i.e. DECAGENT V1 to
     V2.3 etc.)

  3.) DECNDU poorly reports errors or reports success incorrectly. This
      shoudl be fixed (i.e. there is no documentation on what TO expect as
       success, or failure, or duuh?)

   4.) HUBWATCH documentation needs to get specific about what the
       stuff does (i.e. repeater port security - very poorly defined)
       
   5.) One master cross-volume index is needed in the hhubwatch documentation
       it's terrible to flip thru three indices in three manuals to find
       one thing.

   6.) I've still yet to figure out how ALARMS work - the example (wrong)
       about how to set up a terminal server infers that the SNMP trap
       address needs to be set up...does that need to be done for ALL
       modules....WHY WOn't my alarms work? (but that's another topic..)

----
Below is the diary of what happened......aarugh/enjoy
j


I encountered the following problems:

Wednesday 4pm

1.) DECNDU reported that the DECrepeater900TM was upgraded. In fact
    it was not.  I used the command syntax:

    DOWNLOAD LOAD /FORCE="HUBMODULE" /MODULE=1 16.68.128.114 mom$load:DETMM10G.BIN

    DNU went through a rapid series of steps. Since the RELEASE NOTES for
    the firmware don't state what version to espect, it was difficult to
    tell that I'd upgraded (or failed to.)

Wednesday 8pm
2.) DECNDU timed out with the DECBRIDGE900MX upgrade.  I used the same
    syntax as above, substituting the /MODULE, IP address and
    firmware image.

Wednesday 10PM
3.) Tried to use TFTP on three UCX V3.1 systems.  That terminated with a
    ERROR OPENING SYS$INPUT in the log files.  And, it disabled the TFTP
    service on the VMS side.  After re-enabling it with the UCX ENABLE SERVICE,
    it would get disabled after an attempt to TFTP.  Stopped at about 11:30pm.

Thusday 7:30AM
4.) Read documentation to also be able to set up ALARMS for demo. Not very
    helpful.

Thursday 9:00AM
5.) Attempt to download DECbridge 900MX - call engineer.  He said that
     command should work, I was not waiting long enough. (located engineer
     at 11:00am.

6.) In between attempts, attempted to set up alarms - noted that command
    in HUBWATCH manual for terminal server alarm set-up is flat out
    WRONG - (needs to be 2 commands, not one command invalid syntax)

12:00AM
7.) Begin to give up on firmware upgrades. Figure that if I get security
    alarming (port disable alarms) for this customer (Government/SECRET)
    they would be happy.  No combination of start-ups works.  Start to
     call folks and check notes files.

2:55PM
8.) Engineer returns call. Customer walks in..

3:30pm
9.) Another engineer returns call/pages, interrupting demo was able to
    answer several security questions not documented in HUBWATCH manua
    with repeater security (i.e. grossly inadequate)  Customer wanted
    to know meaning of term "AUTHORIZED STATION"....well, does it mean
    the one connected station, or the one in the list of stations, etc.
    We say that we have "eavesdrop protection" yet it's not called out
    in the documentation how it's activated, nor does it map to a HUBWATCH
    menu item etc.  Engineer was able to help answer this.

4:00pm
10.) Discoverd while talking wtih engineer that DECNDU wanted the
      /FORCE=PCOMMON qualifier not the /FORCE="HUBMODULE".  Tried thtat
      and it worked.  Noted that:

      a.) Our firmware names on the internet do NOT reflect firmware versions
          so it's not possible from looking at a file name to determine what
          version of firmware it is. (or what you've just loaded) without
          going in and mucking about.

      b.) I'd suggest that we use MS-DOS compatible firmware names for all
          products...make it (the image) the same name across ALL platforms
          and include FIRMWARE VERSION in the name.....ONE SCHEME PLEASE FOLKS!

5:00PM
11.) Discovered that on another system (on an UNLOADED LAN) DECNDU was able
     to upgrade the DECbridge 900MX.  It appears that in heavy traffic conditions
      across bridged/repeated segments DECNDU will timeout.

(break from6:30 to 10pm)

10PM-Midnight
12.) Found new firmware for DECbridge 900MX Version 1.23 - loaded it
     DECbridge comes up but FDDI does not appear live (Green LEDs do not
     glow - I think it's toast) and Ethernet bridge port 2 will NOT allow itself
     to be connected to a new Ethernet LAN just created.  (who knows why?)
     Read a few notes...noted that somebody wrote a few new com files
     for NDU.  (but nobody wrote documentation and explained the
     $*#($#*( command lines)  Gave up on getting alarms working until another
     day.

----


    

    
    
    	I know exactly how you feel!!! And I am only working with a
    	HUB90!
    
    
    	

Let me take your points about downline upgrades one by one:

1) Yes, we agree that DECndu is poorly documented.  For the 60-day upgrade of
the DEChub Consolidated Firmware Kit V1.1 (currently due to be submitted to SSB
on August 26th), there will be a file called HOW2LOAD.TXT that will explain,
with examples for both OpenVMS and MS-DOS, how to load each and every DEChub
device that supports network downline upgrades using DECndu Plus.  This
information will also be provided in each device's release notes.  DECndu's
/FORCE switch tells it which series of MIB objects need to be set and queried in
order to perform the downline load.  Since not all devices support the same
MIBs, different sets of MIB objects have been implemented by the devices to
support downline upgrades.  You might want to have a look at the command files I
wrote for OpenVMS (note 1008.10) and MS-DOS (1008.16).

2) For the 60-day upgrade, all firmware images will be given the same name in
both the kits and on the Internet.  We, too, came to the conclusion that the
disparity in file names is confusing.  The file names will be the same as in the
consolidated kit, and will therefore be valid in both the OpenVMS and MS-DOS
environments.  Your point about retaining old versions of firmware on the
Internet is a good one.  I will be certain this is implemented.

3) DECndu is currently being rewritten as an integrated application for
HUBwatch.  Many of the problems with error status are known and will be
addressed.  A standalone version for the MS-DOS platorm will also be made
available to allow upgrades in an environment where HUBwatch does not exist.  I
do not have any specific timeline for this, but it is expected to be available
as an integrated application in HUBwatch V4.0.  The standalone MS-DOS
application will likely be available before then.

One of the HUBwatch gurus will have to take the HUBwatch questions.

As for your "Diary of an upgrade" section, you encountered several problems
which, unfortunately, are not well documented (as you discovered).

* The /FORCE=HUBMODULE switch combined with the /MODULE=<slot> switch is used to
perform a MAM-assisted load of a hub module (that is, the file is actually
loaded into the hub manager, then it is sent to the device).  This *DOES NOT
WORK* on any module except the DECconcentrator 900MX.  Suffice it to say that
the DECbridge 900MX and all the DECrepeaters do not support MAM-assisted loads
(yet).  And do not look for this support in the 60-day upgrade.  This will be
addressed in the Wave 3 release.  So for now, you must use the /FORCE=PCOMMON
switch to load those devices.  This performs a direct load, but requires that
the device have its own IP address.  The HOW2LOAD.TXT file in the 60-day upgrade
will contain a section discussing how you can use a single IP address for
upgrading all your DEChub modules.

* I am not sure I understand your statement "Tried to use TFTP on three UCX V3.1
systems."  Were you trying to figure out how to load the devices directly with
TFTP?  If so, you would not have succeeded as the devices require certain MIB
objects to be set via SNMP prior to attempting the load (that's what DECndu's
/FORCE qualifier is for).

* Some of the later points I have addressed in 1) and 2) above.

I hope I have answered some of your questions.  Your feedback is greatly
appreciated.  As you can see, some of your suggestions have already been
implemented.

...Roger...  The "somebody" who "wrote a few new com files for NDU."

    Roger - I found your .COM files last night - (after I lived thru the
    process once in August for Duquesne University and then yesterday for
    Bettis Atomic).  Simply didn't have enough time to scrounge, etc., and
    figured that it was my stupidity (well ok  some if it *IS* my
    stupidity...) (grin).
    
    As long as you folks know about it and are FIXING it - that's all that
    I can ask/hope for at this point. Thanks for the feedback and prompt
    fix. (Looking forward to them with great anticipation...!)
    
    RE:The .TXT file that you mentioned...is that around today?  I'm going
    to be dealing with other folks who may need to do this and that sheet
    would help *today*.  Can u point me to it? (the HOW2LOAD.TXT)
    
    Thanks!
    j

    note - I found that UCX$TFTP does not copy the UCX$TFTP_STARTUP.COM
    into the LOGIN directory for UCX$TFTP.....TFTP will DIE on a VAX/ALFA
    before it starts up......ANOTHER group doing in Digital...aarugh!
    j