Conference 7.286::fddi

In auto-select mode the bridge defaults to IEEE 802.1 spanning
tree.  If it detects any bridges operating in the LAN Bridge 100
spanning tree mode it automatically switches to that mode.
If you want to force IEEE spanning trre you should disable 
auto-select mode.

There is a discussion on this in the "Bridge and Extended
LAN" Reference Manual (EK-DEBAM-HR-003).

>
>There is a discussion on this in the "Bridge and Extended
>LAN" Reference Manual (EK-DEBAM-HR-003).
>

Is this online somewhere or in Bookreader format??

>        I have a requirement that our DECbridge 620's be put in 802.1d Spanning
>        Tree mode, If I look at them now with MCC, I see that they are in Auto
>        Select mode. So I am assuming, if a bridge that uses 802.1d is put in
>        parrellel with our DECbridge that is in Auto select mode it will match
>        the 802.1d spanning tree and not use the decbridge 100 spanning tree
>        algorithm. Is this assumption correct?
    
    Depends on what you mean by "match".  If the bridge is a non-DEC
    bridge running 802.1D ST, *and* the DEC bridge is running 802.1D ST,
    then they will become part of the same spanning tree.
    
    If the DEC bridge is running LB100 ST, because the Spanning Tree mode
    is "Auto-Select" and there was an actual LB100 somewhere, then the
    other bridge will run an 802.1D spanning tree of its own, separate
    from the LB100 ST that is run by the DEC bridges in the extended LAN.
    
    You can lock down a DEC bridge into 802.1D mode by changing the
    Spanning Tree mode from Auto-select to 802.1.  In this mode,
    LB100 hellos will not cause it to go automatically into LB100
    mode, but rather forwarded like any other multicast frame.

    Finally, note that the "Auto-select" feature is implemented only
    on DEC bridges.  You may find other vendors bridges which can
    run either LB100 (usually referred to as "dec") ST or 802.1,
    but this needs to be configured manually into one mode or the
    other.  This, although we have not made our LB100 algorithm public
    so its a mystery how they get away with offering such a feature..
    suffice it to say that it would probably be safer in a mixed bridge
    environment to run 802.1.
    
>        Also, what is the latest rev level of 802.1d spanning tree firmware?
>        Right now if I look at this with MCC it reads V0.0.0. (this bothers
>    	me)
    
    I think it should say just 0 -- this is an integer extracted from
    the BPDU indicating the version, no provisions for decimal
    notation are made in the spec.  The current version is 0
    as per IEEE 802.1D-1990.
    
    Anil

Incidentally, I think that the literature will tell you that it's possible
to run LB100s and 802.1d bridges in the same extended LAN -- in other words,
have the two spanning tree protocols operating at the same time.

A number of us argued against allowing this.  Technically it is true that
it is POSSIBLE to construct topologies of this kind that work.  However, it
is not at all easy to do so, and there are plenty of reasonable-looking
topologies with this mix that do NOT work properly.

So unless you like serious intellectual challenges at random times of the
night, I'd recommend you set up your extended LANs so that only ONE
spanning tree protocol is in use.  This means combining LB100s with other
bridges that support the old spanning tree (including autoconfiguring ones,
i.e., the newer DEC bridges) OR using 802.1d bridges (including autoconfiguring
DEC bridges, but without ANY LB100s present).

	paul

    This is good stuff. Next question is, if the DECbridge 620 is in
    Autoselect mode, is there any way of telling if the bridge is actually
    using 802.1d or LB100? With DECmcc I have tried to no avail.
    
    Thanks, Mike Beaulieu
    
    ps. the reason for asking is, the customer wants to force the 802.1d
    Spanning Tree, but is wondering what the risk is? If I could show him
    he is already 802.1d, not LB100, his risk factor is nothing.
     

...This should work using the ELM access module:
    
MCC> sho bridge br_08002b0f2fe5  spanning tree mode

Bridge LOCAL_NS:.br_08002b0f2fe5
AT 30-OCT-1992 16:03:29 Status

                     Spanning Tree Mode = LAN Bridge 100 Mode
MCC>
    

The forcing feature is ONLY useful if you have one of the configurations
with both 802.1d bridges and LB100s in them -- in other words, one of the
tricky/dangerous/pick_your_adjective ones.  In the preferred configurations,
you should not use it, because:

1. if autoselect would put you in 802.1d mode, locking it down makes
   no difference.
2. if autoselect mode would put you into LB100 mode, locking down 802.1d mode
   breaks things!  (It will cause the same sort of problems as the LB100+802.1d
   mix: two spanning trees, and all that implies.)

	paul

    There's a parameter called "LB 100 bridge" (or something like
    that), which helps track down the bridge keeping the
    Auto-select bridges in LB100 mode.  This is useful *only* on the
    Root which knows for sure the address of the LB100 bridge,
    since it polls it periodically, if it's an Auto-select bridge.
    If not, it's an LB100 itself so you've found it.  In order
    to have one tree, it is desireable in such cases to upgrade to
    LB150's.  If it was a non-DEC bridge running in LB100 mode, switch
    it to use 802.1.
    
    If the customer is unwilling to upgrade to LB150, and you have at
    least one bridge in there that can do only 802.1 ST, then you're
    stuck with 2 trees.  This is the only case I can see for using the
    lockdown feature.  (if you had say just a couple LB100, several
    Auto-select bridges and several 802.1 bridges.. if you must
    have two trees, better that one of them be much larger than
    the other)
    
    Note that having other vendors bridges in "dec" mode can be
    quite dangerous in the presence of Auto-select bridges because
    they don't respond to the periodic RBMS poll used to verify
    the presence of LB100's.  As a result they may end up switching
    modes back and forth often.  Look at note 466 in NAC::RBMS_LANBRIDGE100
    for more detail.
    
    Anil

    
    How's this, In my customer's network of 47 bridges, (DECbridge 620's,
    150 & 200s) I have polled them as stated in .6 and all of the bridges
    report back LB100 mode. I have forced a couple of test bridges to
    802.1d Spanning tree and this works. Big question, If all of my bridges
    are 150's or better (I have no 100's) How come I am still getting LB100
    Spanning Tree?  (I have a couple of Vitalinks, do they do LB100?) 
    
    Thanks, Mike 

    	Mike,
    
    As .8 suggested, you can use ELMS or MCC BAM to query the ROOT bridge,
    using the "SHOW BRIDGE bridge_name STATUS" command; note the "Lan
    Bridge 100 being polled" address. This is the address of the LB100
    which is being polled by the root, keeping it in DEC spanning tree
    mode. If it's a "08-00-7c" address, then it's a Vitalink. I _believe_
    that the Translans *do* respond to LB100 polls, since they implement
    the same spanning tree protocol, can be (partially) queried via ELMS,
    and also use the Auto-select feature to determine DEC or 802.1d
    spanning tree in the newer software versions.
    

    
    The Vitalinks do respond to the polls, and they are the culprit running
    LB100 ST.  
    
    Thanks everyone for you help.  Mike Beaulieu
    

        By the way, I happened to have exchanged some mail with someone
    from Vitalink - apparently the way Vitalinks do auto-select is not the
    same as how we do it.  The way they do auto-select differs in that you
    can't force 802.1d if you have any bridges on your LAN which don't
    support 802.1d.  
    
        I.E. the presence of a LB100 will make it impossible to force the
    Vitalink to a 802.1d spanning tree.
    
        Also, although they don't do polling to see if they should switch
    back to 802.1d if the LB100 goes away.  When the root bridge is a
    Vitalink it starts off in 802.1d mode and switches to LB100 spanning
    tree when it sees one, it won't switch back automatically.  Assuming
    the root bridge is a Vitalink, you tell that Vitalink that it should
    switch over, and the rest of the bridges follow.

        I don't have a Vitalink to test this behavior, but that's what the
    guy said...