[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

143.0. "DECagent doesn't like dual DB90s" by CGOS01::DMARLOWE (dsk dsk dsk (tsk tsk tsk)) Tue Feb 02 1993 13:44

    I was just setting up a dual hub for a customer demo.  Have 2 DB90's
    in slots 7 and 8 on the first hub and the DECagent in slot 15 (second
    hub slot 7).  The DECagent discovers the first, ie. active, DB90
    but doesn't see the second, ie. standby bridge.  Using OBM I try
    to add the second DB90 and it says that one exists and a second
    one can't be added.
    
    Will DECagent V1.1 allow a second bridge in the community?
    
    I see this as important as some customers need the redundancy to
    the backbone.

    dave
T.RTitleUserPersonal
Name
DateLines
143.1Response from the trenchesKALI::GAUDETThu Feb 04 1993 17:447
    The DECagent 90 does not currently support more than one bridge in a
    hub (extended hub included), nor is it likely to soon (certainly not in
    V1.1, and I'm not optimistic about V1.2).  Support for multiple bridges
    would require major changes to the DECagent firmware, which is unlikely
    to occur in the near future.
    
    ...Roger...
143.2HANNAH::BUGSBY::COBBWriting from ALPHA AXPFri Feb 05 1993 06:544
    Does this mean that we cannot connect 2 hubs together that have a
    bridge in each of them??
    
    Bill
143.3That's exactly what it meansKALI::GAUDETFri Feb 05 1993 09:498
    All I can say is that it's not supported.  When the DECagent is using
    the work-group bridge to determine the hub configuration, an
    architectural restriction within the bridge prevents the DECagent from
    identifying the location and MAC address(es) of the other bridge(s).
    This restriction is fundamental to the bridge and therefore causes the
    same problems in the DEChub 900.
    
    ...Roger...
143.4one strange exampleCGOS01::DMARLOWEdsk dsk dsk (tsk tsk tsk)Sat Feb 06 1993 00:3826
    But isn't there some restrictions within the DECagent also?  When
    the agent has one known bridge and you try to manually add a bridge
    thru "ADD MODULE" it gives you an error message.  Also how many
    of the bridge restrictions you mentioned are related to which bridge 
    is master of the serial management?
    
    I have found that with dual bridges (slots 7 & 8) and a DECagent 90 (slot
    15) in an extended hub, that many strange things happen.  The agent was
    set for the bridge in slot 8 (bridge B).  Bridge B was the lowest
    Ethernet address so it was active.  Load the extended hub up with
    DECNET mirror packets, maybe up to 70% Ethernet utilization and
    after less than a minute the CRT (OBM port) showed the bridge in
    slot 8 was replaced with a box and the word UNKNOWN in it.  After
    a few more seconds the box in slot 8 disappeared and an inverse
    video bridge showed up in slot 7 (bridge A).  The inverse video
    never did clear which meant that the agent saw the bridge but could
    not communicate with it.  Even removing the active bridge in slot
    8 so that the other bridge became active and eventually serial master
    did not clear the inverse video on the CRT.
    
    I don't know if this expected behaviour but I thought I'd mention
    it.  Redundant bridges in hubs are important to customers to maintain
    high availability.
    

    dave
143.5This is as clear as I can put itKALI::GAUDETMon Feb 08 1993 16:4817
    Let's lay the cards on the table right here...
    
    ***** DO NOT PUT MORE THAN ONE BRIDGE IN THE SAME HUB *****
    
    Extended (daisy-chained, 16-slot, call-it-what-you-want) hubs included.
    
    The architecture of the agent code can't handle it and it's not going
    handle it anytime soon.
    
    Understand, I think that having multiple bridges in a hub is a good
    idea, but the code just can't deal with it at the moment, and we're
    just too darn busy with developing functionality we've already
    committed to for V1.1 (and V1.2).
    
    Sorry folks, but it's one bridge per hub.  Period.
    
    ...Roger...
143.6You can put a standby bridge standalone off the backplane portMEMIT::FORRESTThu Feb 18 1993 10:4619
	For now, if the customer has a single hub, and wants a standby 
	bridge, you can provide a standalone DECbridge 90 off the ThinWire 
	port of the backplane. It will not take over repeater management, 
	but it will take over bridging the hub to a backbone.

	You can manage the standby bridge with the same agent by adding 
	another community, consisting of the standalone bridge.

	I will investigate whether putting a T connector on the ThinWire 
	connecting 2 physically adjacent backplanes could also be supported.
	This would allow a standalone standby bridge for the 16 slot 
	configuration. But don't go selling this solution until I reply 
	back here that it can be supported.

	We also have to understand when we can support multiple bridges in 
	a hub in the DECagent 90.

	jack 
143.7Official and unofficialCGOS01::DMARLOWEdsk dsk dsk (tsk tsk tsk)Thu Feb 18 1993 11:278
    Officially the backplane is 15 stations so daisy chained would give
    you 30 stations.  But you still are allowed 55M of thinwire between
    the 2 hubs.  So even though its not "officially" supported I don't
    see a problem putting a DB90 on the coax between 2 hubs.  That is,
    as long as the 2 hubs are side by each in the wiring closet.  I 
    wouldn't do this if you had 55M of coax between the hubs.

    dave