Conference netcad::hub_mgnt

    
    I hate to sound like a broken record, but this won't work the way
    you'd like.
    
    First, the DECbridge 90FL is not a 'redundant responder' - what that
    means is that it will not turn off it's transmit light when it detects
    a receive fiber link failure.  That means that the failover on the
    900FP would only operate if it detected the failure - that is, if the
    failure were on the bridge->repeater half of the fiber pair.  So you'd
    only get half of the redundancy on that link.
    
    Second: the DECbridge 90FL whose link was broken (because the repeater
    had it as the backup) would be seeing all the addresses on the wrong
    port - its Spanning Tree would be all messed up as to which port each
    source address was on.  Since it learns addresses only on one port, it
    would be all messed up if the link did switch over.
    
    The simple rule still applies:
    
       DO NOT USE MORE THAN ONE DECBRIDGE 90 IN A SINGLE HUB.
    
    Sorry - nice try.
    
    If the field believes that we need to produce a replacement for the
    DB90 that removes this restriction (by implementing a full bridge), you
    need to express that belief to product management.  Nothing is being
    done about this now.  Given the current state of resources in
    engineering, be prepared to tell them which things we _are_ working on
    that you don't want to get in order to get this.
    

I appreciate the explanation.

This helps, THANKS!	

    
>    a receive fiber link failure.  That means that the failover on the
>    900FP would only operate if it detected the failure - that is, if the
>    failure were on the bridge->repeater half of the fiber pair.  So you'd
>    only get half of the redundancy on that link.
    
    I understood that the 900FP will do active/backup only when it
    detects a 'responder' at the other end.  If there is no responder
    then both ports of a "redundant pair" just act like a 2 port fiber
    repeater sharing the same 10Mb.
    
    So going to 2 different DB 90's whether in the same hub or not, should
    not cause the 900FP to do active/backup redundant links.
    
    Scott's comments about not putting 2 DB 90's in the same hub are
    valid as spanning tree in these units is not as robust as in a
    LB 100 for instance.  But I have some customers that have done it
    because the need for redundancy to a "single" thickwire backbone 
    overrode any possible bugs in spanning tree.
    
    Why not put a DECrepeater 900FS into the DEChub 90?  That would
    give you full redundancy in the fiber link.
    
>    Second: the DECbridge 90FL whose link was broken (because the repeater
>    had it as the backup) would be seeing all the addresses on the wrong
>    port - its Spanning Tree would be all messed up as to which port each
>    source address was on.  Since it learns addresses only on one port, it
>    would be all messed up if the link did switch over.

    Having done things like this in the lab I have found that the standby
    DB 90 has no entries in it's address table.  If it was active and
    then switched to standby, then any addresses in the table would AGE
    out until it was empty.  The active bridge would have all the entries
    from the work group.
    
    Where you would get into trouble big time is if only one
    transmit/receive line in the active pair broke.  Spanning tree with
    the DB 90's would get real messed up and maybe failover to the
    alternate link would not occur.  Your best bet will still be the 
    DR 900FP with a DR 900FS in the HUB 90.
    
    dave

Thanks to Scott and Dave for the replies.

I take it from your comments that the only modules that can provide "redundant 
responder" functionality are the DECrepeater 900FP and 90FS. (This sounds like 
the "slave mode" referred to the the repeater documentation.) So, the only way
to configure a workable redundant fiber pair is to use either DECrepeater
900FPs or 90FS' on both ends of the links?  

We're going to recommend the DECrepeater 90FS in the DEChub90, with the 
required bridging provided by mapping the redundant pairs on the 900FP to an 
IMB in the DEChub900, and using a DECbridge 900MX to do the bridging in the 
back plane.

Regards,
Rick

    
    The combination of the DECbridge900MX and a DECrepeater900FS in a
    DEChub 900 makes a very good ethernet fiber distribution; that is how
    we have our lab wired here in hubs engineering (we don't use the
    redundancy - the fibers fan out to 9 DEChub 90FAs to provide network to
    different work areas in the lab).
    
    We also have a DECpacketprobe in the hub on the thinwire - by attaching
    the thinwire to different internal lans (port groups) in the DEFMM, I
    can, in effect, lan hop the packetprobe from one lab area to another.
    I do the same trick in our office hub, where I use DETMMs for each
    block of offices and a packet probe on the thinwire; whichever 900
    repeater I connect to the thinwire is the one I can monitor.

That's a great trick with the DECpacketprobe. I never visualized using it that
way. For some reason, I always assumed that you would have to carry it around
to the various LANs. We're going to suggest it to customers, and use it as a
sample configuration when training the TCC reps.

This stuff keeps getting better!

Rick

	Although the DECpacketprobe 90 can't be LAN-hopped, other things 
	can be LAN-hopped to it. Just be aware that this is only useful 
	if you don't have other traffic generating devices already on the 	
	ThinWire.