Conference netcad::hub_mgnt

>I am looking for a technical document that explains the Spanning Tree
>implementation on DECbridge 90. I am working on a DECHUB90 based configuration.

I don't know of a DECbridge 90 specific document.  I believe the
technical manual for the LANbridge 100 or the LANbridge 200 explans the
algorithm in some detail.

>1. List of DB90 parameters that can be set to optimally configure the 
>   network. In the config shown below, DB90 #2 will be root bridge while DB90
>   #1, #3 will be standby. 

On the DECbridge 90, none of the spanning tree parameters are settable. 
The "settable" part of the priority field is hard coded to be the lowest
possible priority "FF", so in a mixed environemnt with DECbridge 90 and
other bridges, the DECbridge 90 is the least favorable path.  (It is
MEANT to be a leaf bridge.)  In an all DECbridge 90 environment,
priority goes by station address.

You can configure the address age time, which some people consider to be
a spanning tree parameter.  In most case, the correct value for this is
"0", for "never age out addresses", because in most networks, all
address table changes can be accomplished by "station migration", which
instantly responds to a station that is moved from one side of the
network to the other.  See my answer to #2, below.


>2. If 90T in DEChub #2 fails, FTT will switch VAX from work-group to backbone
>   side (DEChub terms). Will I have to wait till the address from forwadring
>   database AGEd-out before VAX becomes accessible to the work-group again ?

No, as soon as the VAX transmits a messaage of any kind, DB90#2 will
"migrate" the VAX out of the work group address table.

>   My understanding of DECbridge 90 being an End-bridge is that it will NOT
>   learn addresses from backbone and the forwarding database will have addresses
>   only for systems on the workgroup side.

There is a subtle semantic difference between what it "learns" and what
is stored in the address database.  True, it only stores station
addresses that are on the work group side, but it actually "learns"
from both sides - in order to perform this migration function.  It
learns from both sides but only remembers what is on the work group side.

>   If this statement is correct and when FTT (see fig below) switched VAX to
>   standby link, then VAX (see fig below) will NOT be accessible till its
>   address is removed from the forwarding database. Right ? How can I make
>   DB90 do that quickly so that VAX becomes accessible again.

Because of migration, this is not a problem, it will nearly instantly
migrate from the work group side to the backbone side.

Regarding the drawing:

1. I How are you wiring the DECbridge 90FL in DEChub #2 with three wires? 
It only has two ports?  (Or is that a DECrepeater 90FL?)

    Thanks Jeffery for your input. I am talking about some document which
    discusses such finer points as "STATION MIGRATION" you have explained
    in relpy .1. I do have Bridge & Extended LAN Manual (EK-DEBAM-HR-003) but
    it does not discuss some of the parameters I get when I do "SHOW BRIDGE" -
    for example EPOCH MODE and the related parameters.
    
    DB 90 #2 (figure in .0) being root bridge - Jeffery your note seems to
    suggest we cannot guarantee that DB90 #2 will be Root Bridge. Any reasons ?
    I expect that DB90 #2 will be root bridge and then DB90 #3 will take over 
    from DB 90 #2 and DB90 #1 from DB90 #2 in case of failure. I mean that is
    the intent. Will not station address be sufficient to guarantee that ?
    Can you suggest me any changes in case there is likely to be any
    problems ? The configuration shown in .0 will work only if at least one
    DB90 is guaranteed to be active. Do you see any other problem areas ?
    UB hubs have no bridges which will take part in Spanning Tree.
    
    Yes, 90FL in DEChub #2 is DECrepeater 90FL. Just a drawing problem. The
    symbol "===" was used to draw Fibre-optic cable.
    
    Jeffery, please guide me in case you see any problems with the network
    topology as shown in .0.
    
    Thank you very much for you help.
    
    Regards,
    Surender
            

    Can anyone please help me answer the following questoins ?
    
    1. 	Considering the network topology drawn in .0, can we find out the
    	approximate time it will take for Spanning Tree to re-configure, in
    	case the root bridge fails ?
    
    2.	What are the DECnet parameters that I can tune so that the active
    	sessions are not lost during the time the spanning tree is
    	re-configuring ?
    
    Thanks and regards,
    Surender
            

    It will take about 30 seconds for the spanning tree reconfigure
    to complete.  That's about how long from the failure until the yellow
    lite goes out on the standby DB90 indicating that it is active.
    DECNET should ride through this just fine.  LAT, however will probably
    not.  May want to increase the retry count until failover doesn't
    kill every session.  May want to ask about terminal server parameter
    settings in the LAT conference.
    
    dave

    In one of the manuals on DB90, it is written that -
    
    "Receiving either DNA or IEEE 802.1d Hello or TCN message at the work
    group port at any time will light the configuration error lamp and
    place the bridge in the blocking mode"
    
    In the configuration displayed in .0, all the three DB90s will receive
    Hello on Work Group ports. Does that mean the configuration is not
    valid or the above referred statement is no longer true ?
    
    Thanks and regards,
    Surender

    The manual I was reading (being referred to in .5) is obsolete.
    
    Hence the statement being made in .5 is no longer correct and DECbridge
    90 has full spanning tree support (both IEEE & DNA).
    
    Thank you everybody for your help.
    
    Regards,                            
    Surender

    manuals, such as the DECbridge manual can be found in
    NAC::LENAC_USER[NETWORKS.HUB.MANUALS]

Ref .4

Hello Dave,

For the configuration shown below, Spanning Tree takes about 43 seconds to
reconfigure. As there are no parameters I can tune (for better/worse), any
reason why it is taking so much time ? I am using FPROM V3.1.

Regards,
Surender

                         ,-------------------------------------------,
LEGEND:                  |                                           |
                         |         VAX                               |
 ---- = ACTIVE LINK      |          |                                |
 .... = STANDBY LINK     |      ,--FTT..............,                |
                         |      |                   .                |
 FTT = FAULT TOLERANT	 |    	|                   .                |
       TRANSCEIVER	 |    	|                   .                |
 90FL= FO Repeater	 |    	|                   .                |
              90FA------90FL   90T       DB90-------UTP(REPEATER)  UTP REPTR
                |         |     |         |#2         |               |
-------------------	--------------------   	----------------  -----------
   DECHUB #1    |          |   DECHUB #2         |  UB HUB #1 .    UB HUB #2
              DB90 #1     90T                    |            .
                .          .                     |            .
                .          .                     |            .
		.          .                     |            .
                .        DB90 #3                 |            .
                .          |                   90FA           .
		.    ----------------------------------       .
                .               DECHUB #3                     .
		`.............................................'

		FIG: NETWORK CONNECTIVITY