Conference netcad::hub_mgnt

    Buzzt! fuzzzt! buzzzzz! hisssssss!
    
    Uh, we seem to have a bad connection. These video radios keep
    fading in & out.
    Would you mind "explaining" it again? :-)
    
    Bob :-)
    

yeah.  Let me try this again.  I was in a hurry this morning when I enetered
.0 and did not bother to re-read it.

I was at a customer's site yesterday specifically to upgrade his DH900 with
the lateest firmware and insure that his hub config was correct.

This customer site has a file server connected to an FDDI port of the 900EF 
switch, four DH900MS backplane switching domains (ports 2, 3, 4, & 7 of 
the 900EF), and two external Enet switching domains (port 5 & 6) connected to 
900EF front bezel.  The backplane LAN segments being switched by ports 2 & 3
of the 900EF connect end-users by the 900TM repeaters (one in slot 4 and one 
in slot 5).  There are approximately 30 users on each segment.  The backplane
LAN segment being switched by port 4 of the 900EF represents a remote 
engineering workgroup of approx 30 engineers.  The users are connected to
a remote DH90 with 90T repeaters, and the DH90 is connected via fiber to 
port 1 of a portswitch 900FP.  The backplane LAN segment being switched by
port 7 of the 900EF represents a remote shiiping workgroup of 10 users.
These users are also connected to DH90 hubs and the DH90 is connected via 
fiber to port 5 of the portswitch in slot 7.  Port 1/2 of the portswitch is a
dedicated port group connected to LAN 4 of the backplane, and port 5/6 of 
the portswitch is a dedicated port group connected to LAN 7 of the backplane.
Ports 5 & 6 of the 900EF connect directly to a database server and router
respectively.

After setting up this config, we were reviewing the status of the ports on
the 900EF switch with HUBwatch, and noticed that port 7 of the 900EF was in
the "backup" or "blocking" state depending on which view we were looking at.
This would indicate to me that there was a loop in the network some where and
spanning tree automatically shut down forwarding on this port.  However, I 
reviewed this config over and over, and could not discern a loop anywhere in
the network. (I also failed to mention that the thinwire connections to ALL
modules were discinnected from the backplane.)

After trying to figure this out for more that two hours, and just looking at
 - not changing -  the config, port 7 suddenly went into the forwarding state.

Can anyone offer any plausible explanation as to why or how this might have 
happened?

I owe the customer an explanantion, and some assurance that mission critical
user segments will not arbitrarily be shut down by spanning tree running on
the 900EF.

Thanks.

Merlin
 

    If all modules are up to rev then there shouldn't be too many problems
    with spanning tree.  Did port 7 show up as status red or yellow or have
    a little ear (listening/learning)?
    
    Maybe the users are trickier that you suspect??
    
    dave

    I'm baffled. However Dave has an interesting point. Sometimes
    people will share drops in adjacent cubicles, and sometimes 
    merge connections inadvertently.
    
    Bob

    Hi,
    
    Merlin was telling me the story today and the 900EF had the "yellow
    ear", listening state.
    
    Ed

    If it can't be re-created, there isn't much to tell the customer
    other than the quite plasible explanation that a loop was created
    somewhere, whether it was inadvertant or not. Where there are
    Engineers, there will be "tinkering" :-). The DECswitch was doing what
    a bridge is intended to do, detect loops. 
    Heck, here in LKG the other day, we found someone was using the IRIS
    packet generator on a PC on a live backbone. We had a small broadcast 
    storm, because someone was "tinkering". Tinkering is an ingrained nature 
    of Engineering types. 
    Even I like to "tinker", but I do it intelligently.
    
    Bob

RE: .3 & .5

>>    If all modules are up to rev then there shouldn't be too many problems
>>    with spanning tree.  Did port 7 show up as status red or yellow or have
>>    a little ear (listening/learning)?

All modules are up to rev - did that first.

Port 7 showed yellow broken arrows which is defined as the "backup" state 
according to on-line help.

The engineers that we're talking about here are not software or network 
engineers.  They use CAD/CAM to design wheels for cars and trucks.  It's 
not too likely that anyone was tinkering.
    
I though possibly that someone connected the two remote DH90 workgroup hubs
with a duplex fiber jumper to create a redundant backup path (they are using
the four port fiber repeater in the DH90).  However, our wiring subcontractor
assures me that that is not the case.  (I have not seen it with my own eyes
though.)

Any other thoughts?

Merlin

    A reseller of ours here has reported a very similar problem - he has a
    DECswitch 900EE (v1.1) in a DEChub 900 (v4.1) with a PORTswitch,
    DECrepeater and DECserver.
    
    On port 5 of the DECswitch (pointing into the backplane), the port state
    LED stayed on flashing green, indicating a blocking state, though the
    reseller is sure that that were no loops in the network.  (Apparently
    there were no problems with traffic going through port 5 though.)
    
    After a couple of hours trying to work it out, he re-configured the
    DECswitch (swapped port 1 which was pointing in with port 3 which was
    pointing out) and the problem with port 5 disappeared (its port state LED
    went on green).
    
    ???                                                      
    Jeannie