Conference netcad::hub_mgnt

    That's uhm "interesting", there's a whole other faction of input 
    that has told us to provide current product with default set to 
    802.1. This is current epoch bridge spanning tree algorythm, and it
    makes much more sense to default to the industry spanning tree
    epoch standard rather than the older DEC LB100 implementation.
    The bridges can be set to autoselect mode via management, so that
    in the case of sites where there are older bridges the three
    HUB DECswitch bridges (DS900EF, DS900EE, PES900TX) will detect the
    older epoch spanning tree mode.
    There had been many discussions on the setting of this parameter, 
    and it was decided to default to 802.1 instead of autoselect.
    
    Bob
    
    

  Thanks bob but

 >>   The bridges can be set to autoselect mode via management, so that
 >>   in the case of sites where there are older bridges the three
 >>   HUB DECswitch bridges (DS900EF, DS900EE, PES900TX) will detect the
 >>   older epoch spanning tree mode.

  it's sometimes too late , because bridge starting to speak STP 802.1
before any Hubwatch connection...

  May be,could you add a "warning note" in release notes , i think just
  few words save many networks trouble ..

  Jean-Yves

    >May be,could you add a "warning note" in release notes , i think just
    >few words save many networks trouble ..
      
    That's good feedback, and I suppose it could be considered making
    a mention in the next versions of the release notes. I'll forward 
    your suggestion to the appropriate people for putting on the table
    for consideration.
    
    regds,
    bob

    The "autoselect" feature was a migration strategy that was meant to
    help customers transition from Digital's STP to the IEEE 802.1
    standard.  We have reached the point where most customers are
    currently running 802.1.  Customer feedback indicated that they
    preferred to run a standards-based algorithm, which would keep
    things simple when they have a multi-vendor network.
    
    Those that have the old LB100's do one of two things: they let things
    be, and the network runs with two spanning trees - one DEC, one IEEE.
    This may be unavoidable when you have a multivendor network.  This
    actually works, even though it is not recommended.  In your case, it's
    not too late to switch over to autoselect with management even though
    the bridge starts using 802.1 -- the bridges will still provide
    connectivity.  Thereafter the whole extended LAN would be running DEC
    STP as long as it was a DEC-only site.  Note that even with auto-select
    the bridge starts with 802.1 and then transitions to DEC when it hears
    DEC hellos.  (BTW, to use the right terminology I should have said
    "LB100" wherever I said "DEC" above.)
    
    If you are still concerned about this, then another alternative
    is to upgrade the 100's to 150's which are capable of 802.1 STP -- I
    believe this upgrade was made low-cost specifically to solve this
    problem.
    
    Anil

  Swaps proms in the LANbridge or Add an items in the documentation
  that is the question 


  anyway thanks gentlemen

  jean-yves

    
    Another important factor in this decision is the fact that the Cisco
    implementation of LB100 spanning tree is incomplete - it does not
    support the RBMS that DECs autoselect depends upon; if an autoselect
    bridge is in a network with a Cisco device (including the
    DECbrouter90s) that are configured to do LB100 bridging, then the
    autoselect briges (all of them) will constantly toggle between IEEE and
    LB100.  This is much worse than having two spanning trees (which
    actually works).  We had regular network problems here in engineering
    when our bridges were in autoselect because someone would plug in a
    DECbrouter and the network would just continuously thrash (it drove the
    DECbridge90s crazy).
    

    >Swaps proms in the LANbridge or Add an items in the documentation
                                                         ^^^^^^^^^^^^^
      Jean-Yves, just for the record, if you look at the installation
    guides for all three bridges (oops er, switches) :-) that is
    the DECswitch 900EF, DECswitch 900EE, and PEswitch 900TX, you will
    notice that on page 2 under the bullet for "Spanning tree loop
    detection protocol", it does in fact mention that the IEEE 802.1d
    spanning tree protocol is the default for all three bridge products.
    
      The installation documentation does get significant attention
    during the development cycle of a product, and *is* (it really is)
    written for the customer to read without expending too much effort.
    So irregardless whether we are talking about a TV set, stereo, car,
    or even software installed, there are those manuals or files which
    usually say "readme". That's usually a hint that there is an implied
    benefit for the new user of the equipment to "read me first if you
    want to avoid problems due to unfamiliarity with said product".
    
    Bob

          
    I just finished repairing a project (over $2M US) which had several
    DECnis, over 30 TransLANs, DECbridge900mx's, ten to fifteen
    DECbridge90's, and twenty or more DECbrouter90's.  It was a spanning
    tree nightmare.  Each time a Disco was programmed, it would
    automatically switch itself to "DEC Mode", if not specifically told
    IEEE.  The TransLANs would find the DEC address and lock on it, and the
    DECnis would toggle, and the 900mx's as the root would pause the FDDI,
    and cause a cluster state transition, bringing down over 3000
    All-in-one users....
    
    I locked the DECNII into IEEE mode, I locked the DECbridge900 into IEEE
    mode, and there is no way to lock a TransLAN.  So I had multiple
    spanning trees.  We had to telnet to each Disco (if it stayed up long
    enough) to reprogram them all...  I stayed up ALL NIGHT several days in
    a row to try to get all of these bridges doing what I wanted, and
    needed to use six different management tools. (DECmcc, Vitalink
    Consoles, Telnet, Hubwatch, IRIS and NCL...)   What a mixture.
    
    Don't underestimate how FATAL a spanning tree problem can be on your
    network.  I had cluster satellite LAVC nodes that wouldn't boot for
    days, until the spanning tree converged.   Once it starts flipping, you
    have to go to each bridge, and try to determine the "LB100 being
    polled", and change it.  IRIS really helped me alot, seeing the actual
    spanning tree messages on the cable, I could count (sometimes up to
    five) the number or spanning tree roots, and where they were in
    hops from the designated bridge. 
    
    The DECnis console program does not have a way to specifically call out
    which spanning tree to use, so you have to edit the EXTRA NCL command
    files, to add your own boot commands, and the sentence to force IEEE is
    a long one.  but without it, the DECnis will not join the IEEE tree,
    cause the DECbrouter 90's below could be in DEC mode, out of the box.
    
    I would have liked to be able to lock the spanning tree into DEC, IEEE
    or AUTO.  Not just IEEE or AUTO.   It cost me several nights of sleep,
    and my customer several months of unhappy users until I was called in
    to find out why their cluster kept crashing, and leased lines were
    dropping out...
    
    JR

  Thanks all,

  i agree with all replies/comments,but referring many lans here
  with old lanbridge stuff  products autoselect mode should be better than      
  802.1.

  Jean-yves