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

Conference irocz::common_brouters

Title:	Digital Brouters Conference
Notice:	New common-code brouter family: RouteAbout, DECswitch 900
Moderator:	MARVIN::HARTLL

Created:	Mon Jul 17 1995
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	929
Total number of notes:	3736

846.0. "VNSwitch and Spanning Tree" by NQOS01::16.72.128.102::LOVE (Are we having fun yet?) Wed Apr 09 1997 23:32

I have the following network configuration:




	DEChub 900 A			    DEChub 900 B
     --------------------		----------------------
     |		|V|1====|===============|===========|V|1     |
     |		|N|2	|   DAS ring	|	    |N|2     |
     |		|9|3	|		|	    |9|3     |
     |		|0|4	|		|	    |0|4     |
     |		|0|5	|		|	    |0|5     |
     |		|E|6	|		|	    |E|6     |
     |	       *|F|7	|		|	   *|F|7     |
     ----------*---------		-----------*----------
	       *				   * 	
	       *(A)			   	   *(B)
	       *	Thick Wire		   *
   T***********X******X*****************X**********X*******X****T
	              *			*	    	   *
	              *			*	    	   *
	              *			*	    	   *
	  DEChub 90   *		 DEChub	* 90	    	   *
	-----------------	----------------	--------
	|            |B||	|      |B|     |	| LAN  |
	|            |R||	|      |R|     |	| BRDG |
	|            |D||	|      |D|     |	| 150  |
	|            |G||	|      |G|     |	--------
	|            |9||	|      |9|     |	   *
	|            |0||	|      |0|     |	   *
	-----------------       ----------------	   *
							   *
						T**********X*******T

	T - Terminator
	X - Transceiver

	I do not know that much about Spanning tree but in the past it always
seemed to work by default.  After using ClearVISN to configure the hubs,
(There are other modules in the HUBs.) we plugged in cable (A).  Watched
and saw everthing work fine.  The we plugged in cable (B), watched and after
a couple of minutes, ClearVISN showed Port 7 on hub (B) disconnected by 
spanning tree.  We unplugged (A) and (B) became active.  Plugged (A) back in
and watched the ports and one became disabled via spanning tree.  Okay.  Now
unplug both hubs and wait for things to settle down, 15 or 20 minutes, and
neither port would shut down.  Since the first time, we have been unable to
get either ports to disable.  The FDDI ports never were disabled either.
I have suggested that the LAN BRDG 150 have spanning tree disabled or replace
it with a spare standalone Bridge 90.  Could this be the problem, or is there
a problem with the VNswitches?

Norm

T.R	Title	User	Personal Name	Date	Lines
846.1		IROCZ::GUNNER		`Thu Apr 10 1997 10:06`	17
	I can't make out exactly what you think is going wrong from your description. When everything is connected then you should end up with port 7 on one or other of the VNswitches being put into Blocking state by spanning tree - it sounds like that's exactly what did happen - so far so good. Its the next bit I didn't understand when you said you unplugged both hubs... As far as the LB150 goes, I think this only runs LANbridge 100 spanning tree ("DEC" spanning tree). The VNswitch only runs IEEE802.1D spanning tree and the two protocols are not compatible. However, in the network diagram you showed this would not cause a problem because there are no wiring loops through the LB150. But I recommend that you not mix LB100/150 with VNswitches because the incompatible spanning tree algorithms will leave you unprotected against loops being created if you accidentally wire a loop involving LBs and VNswitches. Chris
846.2	From the peanut gallery; LB150 is 802.1D	FOUNDR::OUIMETTE	Zat was Zen, Dis is Dao...	`Thu Apr 10 1997 12:49`	23
	Hi Chris, A correction; the LB150 is 802.1D compliant, so that shouldn't be an issue. However, the default LB150 behaviour is "epoch-2", where it will run in DEC ("LB100") Spanning tree if it hears from a LB100, or DEC Spanning Tree bridge (such as an older Vitalink), somewhere in the topology. I believe that it can be locked down to 802.1D mode, but am not positive. In any case, the default behaviour is the auto-sense mode described above. And as you said, since the 900EF's are 802.1D only bridges, it's important to make sure that all bridges are 802.1D, which means no LB100's/DEC spanning tree bridges in the topology. I'm less sure about the DECbridge90, but my documentation describes them as Epoch II also. In any case, as Chris said, one or the other ethernet port on the 900EF's should be in blocking mode. If that isn't happening, more information (which bridge is the root bridge, what are the port costs, is one of the FDDI ports in blocking?, etc.) would be helpful info. Even with the Bridge90's and LB150's out of the picture, one port on one of the 900EF's must go into blocking to prevent a loop. Is a network meltdown occuring? -Chuck O.
846.3		IROCZ::GUNNER		`Thu Apr 10 1997 14:22`	5
	> A correction; the LB150 is 802.1D compliant, so that shouldn't be an Thanks Chuck, I was just guessing it was the same as the LB100 - sorry. Chris
846.4	How could this happen?	NQOS01::kxodial_port1.kxo.dec.com::LOVE	Are we having fun yet?	`Mon Apr 14 1997 12:20`	12
	After reading my note again I guess I was not to clear on what happened. We installed the VNswitches one at a time, A first and then B. We connected the AUI cables to port 7 on each VN. This caused a loop but ClearVISN showed that VNswitch B had the port 7 disabled via spanning tree. We then disconnected cable A the the port became active. We then connected A back and (I do not recall which one) and it or B became inactive via spanning tree and the other was active. Now we wanted to emulate a power failure, so we unplugged both HUBs and plugged them back in, and waited 15 minutes and both ports were active along with the FDDI link. The customer swears that the aui cables are connect to H4000 tranceivers at opposite ends of a single thickwire cable. Besides that we might not have seen the FDDI link disabled is there any other way that this could happen?
846.5		IROCZ::GUNNER		`Tue Apr 15 1997 10:05`	12
	When you have the port 7 ethernet and the FDDI connected between both VNswitches then one of these ports on one VNswitch should be put into Blocking state regardless of anything else. If you can reproduce the problem where none of the ports is Blocking then you should enter an IPMT and give us as much information as possible - using the CLI, for example, you can "list stp state" and "list stp tree" and "list stp conf" in process 5, protocol bridge. These commands will show the spanning tree states for each port and the bridge. Chris