[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

2986.0. "Topology Changes when PC's are booted" by SCASS1::TERPENING () Mon Nov 20 1995 14:00

    I have a situation at a large site in Dallas TX,
    
    The customer has 15 DEChub 900's and they are using the PEswitch, 1 per
    hub, the Port switch 900 and up to 3 DECswitch 900EF's in each hub,
    they also have 3 Gigaswitch's fully loaded and the DEChubs are dual
    homed to 2 of the three Gigaswitch's. There are 3 applications running
    on the network all client / server based, 1 is PC based client server,
    1 is HP servers and PC's the 3'rd is PC clients and a SUN Sparc farm
    servers.
    
    When ever they turn on a PC that is plugged into a PEswitch port or a
    DS900 port it invokes Spanning Tree which takes about 30 seconds to
    resolve it self and always goes to Gigaswitch #3 as the root(which is
    what it is supposed to do)
    
    With the PC turned off the port status is "broken", when the PC boots
    up the port goes into "listening" mode, then into "fowarding" mode.
    Thats when the topology change occurs, across the entire network, every
    bridge port, both GIGA ports and DS/PE switch ports. This does not
    happen to PC's that are connected to the Port switch 900 T.
    
    Help please.
T.RTitleUserPersonal
Name		DateLines
2986.1What brand PC & NIC cards are involved here?NETCAD::BATTERSBYMon Nov 20 1995 15:425
    What kind of PC's are they and what brand NIC card is installed
    in them? I've heard tales of PC's with some kinds of NIC cards
    that will send out garbage packets when they are powered up.
    
    Bob
2986.2Now that I re-read base note, it's all perfectly normalNETCAD::BATTERSBYMon Nov 20 1995 17:1510
    Wait a minute! I had to go back and read the base note again.
    You're not complaining about any network disconnections etc.
    Spanning tree topology changes in of themselves are harmless
    and yes turning PC'S on/off will cause topology changes. But
    they are a normal thing to occur on an extended LAN. When a new
    MAC address is seen by a bridge port, that address is propagated
    through the rest of the extended lan. A Portswitch 900T is a repeater,
    not a bridge, and as such does not perform STP.
    
    Bob
2986.3SCAS02::TERPENINGTue Nov 21 1995 09:116
    I realise what you mentioned in .2 but it is taking 20-30 seconds to
    resolve and that causes all the clients to get knocked off the network,
    thats the problem. Spanning tree cost values are set up correctly also.
    
    When we disable spanning tree in the PE switch's enet's the problem goes
    away and all seems to work fine, But that is not right.
2986.4RE: More on topology change etc.NETCAD::BATTERSBYTue Nov 21 1995 09:4022
    Has there been any "tuning" of bridge parameters away from the
    defaults?? The act of turning on PC's connected to a PEswitch
    10baseT port at the start of the day should not be "knocking"
    clients off the network. If the PEswitches and the rest of the
    extended LAN devices (DECswitch 900EF's, Gigaswitches etc.) are
    all using default parameters, things should be normal and no one
    should be getting "knocked off the network". Please double check to
    see if anyone has been "tuning" the network components, and if so
    have them reset back to defaults. You mention cost values. Who
    has determined what is considered "correct"? 
    You should determine what the topology looks like. IE: how many
    bridges are present in the worst case path? The recommended number
    is 7 bridges. However, most of the time, things will work ok with as 
    many as 12-14 bridges in a worst case logical path. Beyond this 
    approximate number, the time it takes for hello's to propagate throughout 
    the whole extended LAN runs the high risk of exceeding the hello interval.
    This would likely result in excessive time to do a topology change
    computation. So the problem could very likely be a result of how the 
    overall network is currently configured.
    
    Bob