Conference netcad::hub_mgnt

    try loading the current version of the bridge code onto your bridge. 
    It is V3.0.  V1.14 is not guaranteed to manage anything!
    
As of 28 December 1992, the following files are on the public directory
EMDS::MANAGEMENT:   To copy a file from this directory, type:
	COPY EMDS::MANAGEMENT: file_name
where file_name is the name of the file you want to copy.

# BRIDGE_LOAD.TXT= How to load new micro-code on bridge

    Thanks for the quick reply.  I'll get that done ASAP and post the
    result here!
    
    Richard

The problem still seems to be there after I loaded the new FPROM code.  I put
some comments in the below screen captures (framed by asterisks) to point out
my concerns.  Is this a known bug or should I get field service to log a call
and start the problem escallation procedure to get product support involved,
etc.  

HUB CONFIGURATIONS --

The hub that has bridge D2H2BR in it is configured as follows (these 2 hubs are
joined by thinwire at the backplane BNC and at the MMJ by BC16.  I am assuming
that "Hub 1" is designated by the fact that the bridge is in that hub):

Hub 1 slot 8	DEWGB (08-00-2B-18-B5-76)
      slot 7-1	DSRVDs

Hub2  slot 8-5  DETMRs
      slot 4-1  empty

The hub that has bridge D2H4BR in it is configured as follows (same inter-
connect as above):

Hub 1 slot 8	DEWGB (08-00-2B-25-d4-38)
      slot 7-1  DSRVDs
Hub 2 slot 8-1  DETMRs

****Screen captures of hub information**************

NCP>connect node D2H2BR
Console connected (press CTRL/D when finished)
DECbridge 90 V1.14  08-00-2B-18-B5-76 � 1991 Digital Equipment Corp
FPROM V3.0 �1991,92 Digital Equip Corp 1-OCT-92

DECbridge> SHOW BRIDGE
DECbridge 90 V1.14  08-00-2B-18-B5-76 � 1991 Digital Equipment Corp
FPROM V3.0 �1991,92 Digital Equip Corp 1-OCT-92  ***********Latest FPROM code*
Bridge states:
        Console owner: AA-00-04-00-5A-08        Uptime: 82,002.87 seconds
        Bridge state: 17                        Work group size: 11
        Hub mgmt enable: 1                      Spanning tree enable: 1
        Flash ROM erasures:  4                  Address lifetime: 450*2 sec.
Event counters:
        Sys buffer unavail. errors: 0
        WG size exceeded errors: 0

Spanning tree parameters:
        Bridge id:       FF-FF-08-00-2B-18-B5-76        Root port: 1
        Designated_root: 00-7B-08-00-7C-00-03-6E        Root path cost: 10
        Current Forward delay: 15, Hello interval: 1, Listen time: 15
        Def. Forward delay: 15, Hello interval: 1, Listen time: 15
        Topology change flag: 0         Topology change timer: 30
        Bad hello limit: 15             Bad hello reset interval: 5
        Epoch_mode: 3   Epoch1 who: 00-00-00-00-00-00   Mode changes: 0
        Epoch 1 poll time: 18 seconds   Epoch 1 response time: 15 seconds

DECbridge> SHO REPEATER
Hub 2 slot 5 twisted pair repeater, rev.0, 8 ports.\**************************
Hub 2 slot 6 twisted pair repeater, rev.0, 8 ports. \  All repeaters in hub 2
Hub 2 slot 7 twisted pair repeater, rev.0, 8 ports. /
Hub 2 slot 8 twisted pair repeater, rev.0, 8 ports./**************************

DECbridge> SHO ADDRESS
Address 1: AA-00-04-00-07-08 hub 2 slot 7 port 1   ************************
Address 2: AA-00-04-00-06-08 hub 1 slot 8 port 3 --No repeater in hub 1!!!
Address 5: 08-00-2B-26-4E-8F                        ***********************
Address 6: 08-00-2B-26-3D-42
Address 7: 08-00-2B-26-4D-64
Address 8: 08-00-2B-26-55-74
Address 9: AA-00-04-00-0E-08 hub 2 slot 6 port 4
Address 10: 08-00-2B-26-5C-30
Address 11: 08-00-2B-26-45-00
Address 12: 08-00-2B-26-5B-6D
Address 16: AA-00-04-00-54-0B hub 2 slot 8 port 1

DECbridge>

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
NCP>connect node D2H4BR
Console connected (press CTRL/D when finished)
DECbridge 90 V1.14  08-00-2B-25-D4-38 � 1991 Digital Equipment Corp
FPROM V3.0 �1991,92 Digital Equip Corp 1-OCT-92

DECbridge> SHO BRIDGE
DECbridge 90 V1.14  08-00-2B-25-D4-38 � 1991 Digital Equipment Corp************
FPROM V3.0 �1991,92 Digital Equip Corp 1-OCT-92     ******LATEST FPROM CODE!!!
Bridge states:                                       **************************
        Console owner: AA-00-04-00-5A-08        Uptime: 80,749.34 seconds
        Bridge state: 17                        Work group size: 10
        Hub mgmt enable: 1                      Spanning tree enable: 1
        Flash ROM erasures:  65,288 \            Address lifetime: 450*2 sec.
Event counters:                      \----->******************************
        Sys buffer unavail. errors: 0        Is this an unusual number?   *
        WG size exceeded errors: 0          ******************************

Spanning tree parameters:
        Bridge id:       FF-FF-08-00-2B-25-D4-38        Root port: 1
        Designated_root: 00-7B-08-00-7C-00-03-6E        Root path cost: 10
        Current Forward delay: 15, Hello interval: 1, Listen time: 15
        Def. Forward delay: 15, Hello interval: 1, Listen time: 15
        Topology change flag: 0         Topology change timer: 30
        Bad hello limit: 15             Bad hello reset interval: 5
        Epoch_mode: 3   Epoch1 who: 00-00-00-00-00-00   Mode changes: 0
        Epoch 1 poll time: 18 seconds   Epoch 1 response time: 15 seconds

DECbridge> SHOW REPEATER
Hub 2 slot 1 twisted pair repeater, rev.0, 8 ports.\**************************
Hub 2 slot 2 twisted pair repeater, rev.0, 8 ports. \
Hub 2 slot 3 twisted pair repeater, rev.0, 8 ports.  \
Hub 2 slot 4 twisted pair repeater, rev.0, 8 ports.   \
Hub 2 slot 5 twisted pair repeater, rev.0, 8 ports.    \ Note all repeaters are
Hub 2 slot 6 twisted pair repeater, rev.0, 8 ports.    / in hub 2 slots 1-8
Hub 2 slot 7 twisted pair repeater, rev.0, 8 ports.   /
Hub 2 slot 8 twisted pair repeater, rev.0, 8 ports.  /*************************

DECbridge> SHO ADDRESS
Address 1: unused
Address 2: 08-00-2B-26-4E-15
Address 3: 08-00-2B-26-56-47
Address 4: 08-00-2B-26-46-C3
Address 5: 08-00-2B-26-46-C1
Address 6: 08-00-2B-26-5B-DE
Address 7: 08-00-2B-26-4E-1C
Address 8: 08-00-2B-26-4E-88
Address 9: AA-00-04-00-20-0B hub 2 slot 3 port 4    ***************************
Address 10: AA-00-04-00-6C-0B hub 1 slot 2 port 2 \__ Hub 1 doesn't have any 
Address 11: AA-00-04-00-55-0B hub 1 slot 3 port 8 /   repeaters!
                                                  *****************************

    Hi Gurus,
    What I posted a while ago:
       <<< NAC::DISK$WORK295:[NOTESLIBRARY_1]RBMS_LANBRIDGE100.NOTE;1 >>>
                       -< RBMS and LAN Bridge 100 Notes >-
================================================================================
Note 567.0          Addresses moving between ports on DECMR ?         No replies
LEMAN::BRUNNER                                       20 lines  21-AUG-1992 04:46
--------------------------------------------------------------------------------
    Customer reports a problem with DEWGB90's when trying to locate
    addresses on a DECMR90 port. Addresses seem to move once in
    a while to another port, no need to say that the PC or system hasn't
    moved in the meantime. If the PC is moved to another DEChub 90 its
    address moves in the 15 minutes (450*2 second aging out), this is
    correct. They are using "ccr" on an Ultrix station.
    Customer has about 1000 PC's connected with 12 VAXservers (3100's and
    4000's). Customer's tool available on SOLARX:: (node 48.522) as saveset.
    
    DECbridge 90 V1.14 firmware 1.4
    Tried  V2.5b, V2.9 and V3.0 on one DECbridge, same results.
    All DEWGB are at version 3.0 since Christmas and they all exhibit the
    same errors. Is this a known problem ?
    
    Compressed tar file available on SOLARX:: as  "itu.tar.Z"
    
    Thanks for looking at it. 
    Walter

    I mailed 112.* to engineering and they have been unable to make time
    to look into this problem.  Today I logged a CLD through the product
    support organization to see if something can't be done. 
    
    I'm curious to know if anyone using HubWatch (any flavor) has verified
    the accuracy the configuration information.
    
    Richard

I know it's been a while...but I actually looked at this problem today...

I think I can explain part of what is going on here.  I can explain why
stations seem to move from one port to another, and why they would show
more than one station on the same port, etc.  I can NOT explain why it
would ever report a station in the wrong hub, or in an empty slot. 
That will require more research, but I think it's related.

A way to test my hypothesis is to set the bridge address age time to 0
so that it will never age out an address.  This means that the address
table will only change by learning, or by migration.  (The other thing
is not to move any stations, so that they don't migrate to the other
side of the bridge, because migration can cause this too.)

Here is what I think is happening.  There is a window of opportunity in
the DECbridge 90 software for the following sequnce to occur:

� Learn a station address, store it in address database location 'n'.

� Learn the station's repeater port, store it in repeater port database
location 'n'.  (The address database is maintained by the bridge
forwarding hardware.  The repeater port database is maintained by the
bridge software.  They are in different places.)

� Age out or migrate out the station address, which clears address
database location 'n', but not the repeater port database location n.
 
� Learn a new station address, store it in address database location 'n',
before the software has a chance to notice that address database
location 'n' was cleared.

If you follow this through, it means that the original station's address
entry will be associated with the old station's repeater port number. 

Ordinarily, the software would eventually notice that the station aged
out, and clear the address database information before a new station was
learned.  If the new station is learned too quickly, this procedure
doesn't run.

This is the classic multiprocess synchronization problem from CS101. 
As the professionals say: "oops".

The workaround makes it so that it is less likely that a station will be
removed from the database, thereby reducing the opportunity for the
problem to occur.

The software fix for this will be to check every address's age
periodically, and zero the corresponding entry in the port number
database for any entry that is nearing maturity.  This will catch the
case where the station aged out of the address database, which is by far
the more common case.

This, however, is inadequete to account for the failure to catch an
address that migrated to the other side of the network.  I fear that
that case may be impossible to eliminate entirely, since the software
can't know that it happened until after it's already too late.

    I have a customer who is reporting the same problem.
    Show repeater will report multiple devices in the same slot, or
    repeaters in empty slots.
    I think they logged a call today, so I guess there will be another CLD
    open on this soon as they are *real* unhappy about this.
    I am going there monday, so will try the bridge address ageing stuff...
    thanks,
    Mike

    Jeff, I tried your .6 suggestion but the problem only seemed to be
    worse.  I then realized that with the infinite age out, none of the
    bogus entries would ever age out either (I guess).  I have now
    gone through the following process:
    
    	1.  Set age to 2 seconds - wait a few seconds
    	2.  SET and DEFINE age to 43200 (21600*2).
    
    I'll have a look at this in a few days - end of next week as I'll
    be out of town the first three days of the week!
    
    Regards,
    
    Richard

I have a similar situation, but the previous explaination does not fit this
senario.  With a 16-slot hub, and one DEWGF (v3.1) in slot 8.  Whenever we
do a SHOW ADDRESS, and then wait a bit and do it again, the report appears
to show addresses moving from one hub to the other.  What we see is that
the slot and port numbers are unchanged, but they flip back and forth between
hub1 and hub2.  The nodes themselves are not moving, just the way the bridge
reports it.  Check out the following SHOW ADDRESS outputs, both given within
a few seconds of each other (only the first 5 addresses are included, but
the symptom appears throughout the list.  Note that not every address does it.

DECbridge> SHOW ADDR
Address  1: AA-00-04-00-AC-72 hub 1 slot 5 port 5	!ADDRESS 1 IN HUB 1
Address  2: AA-00-04-00-BB-72 hub 1 slot 1 port 1	!ADDRESS 2 IN HUB 1
Address  3: AA-00-04-00-60-F8 hub 2 slot 2 port 2
Address  4: AA-00-04-00-48-F8 hub 2 slot 6 port 1
Address  5: AA-00-04-00-4C-F8 hub 2 slot 7 port 6	!ADDRESS 5 IN HUB2
Address  6: AA-00-04-00-59-F8 hub 1 slot 1 port 1
.
.
.
DECbridge> SHOW ADDR
Address  1: AA-00-04-00-AC-72 hub 2 slot 5 port 5	!ADDRESS 1 IN HUB 2 !!!
Address  2: AA-00-04-00-BB-72 hub 2 slot 1 port 1	!ADDRESS 2 IN HUB 2 !!!
Address  3: AA-00-04-00-60-F8 hub 2 slot 2 port 2
Address  4: AA-00-04-00-48-F8 hub 2 slot 6 port 1
Address  5: AA-00-04-00-4C-F8 hub 1 slot 7 port 6	!ADDRESS 5 IN HUB 1 !!!
Address  6: AA-00-04-00-59-F8 hub 2 slot 1 port 1
.
.
.

    re: .9
    The site I was at has a 16 slot hub.
    I am going there tomorrow and will some more details, but I think it
    was similar to what you were seeing.
    I have opened a CLD on this today....
    thanks,
    Mike

    re: .10
    I went to site and hubwatch is considered useless unless the address
    information on the repeaters is correct.
    They also would like the ability to restrict a repeater port to every
    using one address so that they can stop people from randomly moving
    their pc's around to different ports (as all the other vendors hubs do
    was added as a comment...eg cabletron etc)
    
    With 2 CLD's open is there any progress being made on this problem?
    thanks,
    Mike

    You won't be able to lock addresses to keep people from moving with
    the 90T and 90C repeaters.  You will have to wait for the 900 modules.
    Maybe the 8 port min modules will have that feature.  I don't know.
    
    dave

    According to the latest status on my CLD (# CXO09906), engineering is
    "actively working this issues".  They expect to have resolution by the
    end of May!
    
    Regards,
    
    Richard

    Adjusting the bridge age timer doesn't seem to help a lot.  I still
    see multiple addresses showing up on the same hub/slot/port of the
    90Ts.  As an example, one of the ones I just looked at was
    
    	Address 1:  AA-00-04-00-07-08	Hub 2  Slot 7 Port 1
    	.
    	.
    	.
    	Address 34: 08-00-2B-26-4D-64	Hub 2  Slot 7 Port 1
    
    Address 1 is a node a DECnet address 2.7 and its Ethernet hardware
    address is 08-00-2B-30-90-E1.  I also know that the customer has
    not moved this node (hub/port/slot wise) in a long time.
    
    Regards,
    
    Richard

    I have asked the engineer about the status of the fix.
    
    re: address security (notes .11, .12)  It will be in the 32 port DEChub
    900 repeater and will eventually (December) be in an 8 port UTP
    repeater that will fit into the DEChub 90.  Both repeaters will have
    their own SNMP agent and will not need a DECagent 90 or a DECbridge 90.

    Just for everyones info., engineer says they are still working on
    resolving this problem.  Currently, I have no status as to what is
    really happening!  The CLD is still open, the product support manager
    in our area periodically asked engineer for an update, engineer says
    they are still working on it!
    
    Regards,
    
    Richard