[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

1906.0. "DECbridge 90/human error caused network to fail" by STRWRS::KOCH_P (It never hurts to ask...) Wed Jan 18 1995 18:14

    I'm looking for help from a DECbridge 90 engineer. I have a customer
    who has 15 DECbridge 90s in 15 different cities. The original intent of
    the devices was to provide management support for DECagent 90s when the
    customer was ready to deploy network management.
    
    Each of the sites is connected to a Cicso 2501 which is then attached
    to a Cisco 7000 at the main site. What happened was that a DECbridge
    configuration was created which caused all DECbridge 90s across the
    network to go into a spanning tree loop which knocked their network
    down for 2 hours idling 1000 people. So, even thought the solution
    might be "Don't do that", I still need an explanation for the CEO of
    this company.
    
    The customer had their DEChub 90 moved from one location to another.
    Originally, the customer had the DEChub 90 populated with a DECbridge
    90 and multiple DECrepeater 90T repeaters. Their LAN consisted of the
    Cisco 2501 and a server at the site all connected using thinwire.
    Originally, the thinwire port was connected to the front of the
    DECbridge 90 where it should be in my opinion with a terminator on the
    side of the DEChub 90. 
    
    Then, a field service tech moved the DEChub 90 and connected the
    thinwire to the side of the DEChub 90 instead of to the DECbridge 90 as
    before. The customer saw this and the tech said this was a better way
    to connect it. The tech put a T-connector with 2 terminators on the
    DECbridge 90 and for 3 weeks all worked well. However, the customer was
    doing some re-wiring and needed a T-connector to couple 2 thinwire
    cables and proceeded to take the T-connector off the DECbridge 90 and
    all he** broke out with all 15 DECbridge 90s going into spanning tree
    for nearly 2 hours until they figured out it was the bridge with the
    missing T-connector. 
    
    However, this problem can be reproduced very easily. If your simply
    create a configuration as described above, you can cause the DECbridge
    to go into spanning tree mode. 
    
    Can an engineer offer an explanation as to why this happens?

T.R	Title	User	Personal Name	Date	Lines
1906.1	I've seen that happen too...	MSDOA::REED	John Reed @CBO, (803) 781-9571 NIS Networker	`Thu Jan 19 1995 09:51`	26
	A bridge with an improper termination will fail it's self test, and after a while, reboot and try again. IMHO, the poor DECbridge 90 with an improperly terminated port was entering and leaving the spanning tree as it rebooted. That alone should not have affected your network, except that perhaps it was the root bridge. Also hard to imaginge, since the bridge90's by default have the absolute minimum priority (FF-FF I think). There must not be any other bridges with higher priority in this network, and he could have been unluckily the guy with the lowest physical address. That would cause repeated spanning tree reconfigs, (which last 30 seconds), but which is just about the amount of time the DECBridge90 would need to fail self test, and reboot again.... Use the AUI port, and stick the little square loopback on it. It's no different than using the ThinWire, but less likely that the customer will need one. Even better, throw away the DECbridge90's. The new DECAgent firmware does not need a bridge to be Bus Master. You can use the CISCO on the ThinWire as you planned, and plug the Agent into slot 7 or 8, and it will be able to manage your hubs. (Except for address finding, which is not too helpful anyway, till they get that repeater chip fixed.) JR
1906.2		STRWRS::KOCH_P	It never hurts to ask...	`Thu Jan 19 1995 16:45`	8
	Interesting explanation. However, I can reproduce this in a standalone situation. So, the question is if the device should be failing self-test, why is it going into spanning tree mode? Should it just stop working and not affect the network. Could this possibly be a bug in the firmware that's it's passing self test and then going into spanning tree? Are they any DECbridge 90 engineers who can enter this discussion?
1906.3		NPSS::RAUHALA		`Fri Jan 20 1995 16:08`	21
	> a DECbridge > configuration was created which caused all DECbridge 90s across the > network to go into a spanning tree loop which knocked their network > down for 2 hours idling 1000 people. "spanning tree loop" do you mean there was a loop in the network and the DB90 was in the loop? This is an illegal configuration according to DB90 manual. > create a configuration as described above, you can cause the DECbridge > to go into spanning tree mode. What do you mean by "go into spanning tree"? The DB90 is always running spanning tree. I'm guessing you mean it does a reconfigure and goes out of forwarding mode for 30 seconds. But since the other side of the DB90 is just a loopback I don't see what the problem is. If you connect using NCP and enter a SHOW BRIDGE command what is the "bridge state"? If the DB90 is not in a loop (since the other end has a loopback connector) as a test you can SET BRIDGE SPANNING DISABLE to see if you still have the problem when spanning tree is turned off.
1906.4		STRWRS::KOCH_P	It never hurts to ask...	`Fri Jan 20 1995 16:30`	12
	I can't answer these questions yet. I'll be getting the bridge from the customer and then should be able to re-create the situation. The problem is that the DECbridge 90 is connected to the DEChub and there is NO terminator on the front panel, but the bridge is hooked into the hub which has a system connected to via the DEChub side thinwire port. The customer is trying to understand why if the network was invalid (no terminator on the front of the DECbridge why it then went into spanning tree instead of just "halting".
1906.5		NETCAD::WALTER		`Fri Jan 20 1995 18:17`	24
	I don't know why the bridge upset the spanning tree, but I do know you can't leave the unused front panel port unterminated, as was mentioned in an earlier note. If the bridge is in the hub strictly for managing repeaters, then by all means take it out and upgrade the DECagent 90 with latest code (V2.1.3 is most recent). The algorithm in the agent for learning port addresses doesn't work as well as the one in the bridge, but it's really not the agent's fault. The bridge learns addresses automatically, and can ask the repeater "have you seen this address on this port?". The denma can't learn addresses on the ethernet, so it has to ask the repeater "what's the most recent address seen on this port?". It can miss some of the addresses, depending on the nature of the traffic. By the way, the bridge only learns addresses seen on the workgroup side (ie the backplane), and it's limited to 200 addresses. I don't know what your network looks like, but if you connect it into the hub thinwire connector instead of the bridge front panel, the bridge may see more than 200 addresses on the workgroup side and its a crap shoot regarding which addresses get into the database. Dave
1906.6	could this be a spanning tree mode problem?	NAC::FORREST		`Thu Feb 23 1995 10:51`	12
	No one has mentioned it here, and I don't remember the specifics, but I seem to recall that there was a problem where a DECbridge 90 and a DECbrouter 90 had different Spanning Tree mode defaults. I think the DECbridge 90 went into 802 mode by default and the DECbrouter went into LANbridge 100 mode by default. Since this customer had numerous Cisco routers (brouters?), maybe a similar problem occurred. Could the missing terminator have caused the DECbridge 90 to send out Spanning Tree messages with just the right frequency to keep every spanning tree device on the network changing modes? jack