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

Conference 7.286::fddi

Title:	FDDI - The Next Generation

Moderator:	NETCAD::STEFANI

Created:	Thu Apr 27 1989
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2259
Total number of notes:	8590

702.0. "STP PROCESS TIME ON LB620" by COL01::SCHUERHOLT () Mon Sep 14 1992 04:49

	Hello,

	in quite a big LAN the customer build a ring of bridges
	(LB200, LB6xx) whereby any system has to go over a maximum
	of 3 bridge to reach another system. To have quick responses
	to topology changes (root changes) the customer set the
	'listen timer' to 7 sec.

	After the installation of an additional LB620 (3 hops away from
	the root) spanning tree ran into problems, that meansthat the
	listen timer wasn't big enough. 

	We took 2 LAN-Analyzers and a storage scope an found that the
	spanning tree hello on a LB200 is generated on port B some micro
	seconds after it was received on port A. On the LB6XX it looks
	like that the same scenario takes nearly a second. This would
	explain, why our 7 sec listen timer isn't big enough sometimes.

	We just set the listen timer to 10 sec to solve the problem, but
	anyway can anybody clearify that my meassurements are correct ?
	And what's the reason for it is that slow with the LB6XX?


	LB620 firmware is 2.9.0 ; Software is 1.2

						Peter Schuerholt
						Regional Support
						WEGY - Networks

T.R	Title	User	Date	Lines
702.1		LEVERS::ANIL	`Mon Sep 14 1992 11:02`	7
	> After the installation of an additional LB620 (3 hops away from > the root) spanning tree ran into problems, that meansthat the > listen timer wasn't big enough. Could you explain what these problems, or their symptoms, were? Anil
702.2	SAW THE WRONG ROOT	COL01::SCHUERHOLT	`Wed Sep 16 1992 03:34`	9
	Yes, the 'new' bridges sometimes saw the wrong ROOT-Bridge, that means they saw themself or their neighbour as root. All bridges have the same root-prio(128) exept the bridge outside in the net which we want to be the root. As we've got several loops in the XLAN, the spanning tree got corrupted. /Peter
702.3		LEVERS::ANIL	`Wed Sep 16 1992 12:38`	38
	I'll try to address all of the points you bring up, hopefully without getting into too much into Spanning Tree theory. First, you said you wanted response time to improve which is why you modified listen-time. However, forward-delay needs to be modified as well in this case to speed up topology changes. There is a relationship between hello-time, listen-time, and forward-delay that must be maintained. (in order to derive the last from listen-time, use the equation: forward-delay > listen-time + 2*(extended LAN diameter) where extended LAN diameter is the maximum number of bridges "in series" in the topology) In your particular case, the low listen-time seems to be causing a premature expiration of the root, thus causing instability in the topology. Given what you have said about the LB200 being only 3 hops away from the root, I don't understand why this is so. Hellos are generated by the root, and even if each of the bridges in the path from the root to the new LB200 were taking 1 second to propagate the hello, this still amounts to less than 7 seconds. As far as your experiment on the amount of time required to generate the hello, you are correct - in some cases it will zip through in no time, in others it may take anywhere from 0 to 1 second. This has to do with synchronization of the bridge's clock and the time at which periodic hellos are received. However the guarantee is that a hello is generated by a bridge within one second after it receives one, and things would work fine even in the worst case where every bridge takes one second. So, to conclude: you may want to change the forward-delay as well. And I think that the topology may have more hops in it than you think. (one way to verify this is to use the Spanning Tree auto-topology application in MCC - note this will work only with our bridges right now since it assumes ELMS implementation) Anil