Conference netcad::hub_mgnt

2479.0. "DECswitch is hanging" by BERFS4::NORD () Thu Jul 06 1995 12:53

	Hello you,

out there in the world of magic:

***************is crossposted to UPSAR::FDDI and KALI::HUB_MGMT*****************

	- four DECswitches 900 MX
	- connected all together to a fantastic FDDI-ring with fiber-optic
	- among these bridges a DECconcentrator 900, with A- and B-port
	  connected to this FDDI-ring with fiber-optic, port 2 till 5 have 
	  TP-PMDs, which are connected to Windows NT-Servers and one SCO-Unix-
	  Server

before you ask:

	- all DECswitch 900 MX have their own docking-station
	- the DECconcentrator has it's own docking-station
	- for the DECswitch 900, all have the same:
		+ HW: V1/2
		+ RO: V0.4
		+ Firmware: V1.5.0 (was V1.4.4 befor, done an upgrade)
	- managed all this with Hubwatch V4.0.1
	- all these systems, talked above, have their own IP-address for mana-
	  gement with Hubwatch.



Now the problem:

	My client is connected to the segment on port 2 of the switch.
	I start a backup from my PC, running Windows NT, to one of the servers,
	connected to the concentrator.
	All is well, for me.
	I get a connection to the server and do my backup.
	In the meantime, the connections of all other clients, which are con-
	nected to the same switch as my client, but on the other Ethernet-
	ports, are dropped, independently whether the connection is local (same
	segment) or between the segments on the same switch. The connections
	are closed, the only one connection, which was not dropped, is the one,
	that I own. It is not possible, to bring up a new connection, neither
	in the same segment to another client nor to another segment on the
	same switch. The onliest thing I can do, is a ping to one of the server.
	I haven't checked whether I'm able to ping a client, connected to a
	segment on another switch.
	
	To analyze this problem I connected a Wandel and Goltermann DA-30 to
	the FDDI-ring. At first I do a "RING MAP" and saw all the systems,
	connected to the FDDI-ring as DAS or SAS (servers). I start my backup.
	Some times later, the downstream neighbour of the bridge, to which my
	client is connected to, declares, the upstream neighbour address is
	lost and it is unable to get it back (seen on the DA-30 screen). With
	Hubwatch, I get a "agent is not responding". With our LAN-analyzer IRIS,
	connected to another segment of this bridge, I can only see the local
	traffic on this segment, and the MOP-sysid-broadcast of all the bridges
	in this ring and the connected servers on the concentrator. The local
	traffic is only NETBIOS-broadcast. On the DA-30 I see NIF request from
	my downstream neighbour, but my bridge don't answer to this request.

	I have checked this problem on all the installed bridges, all bridges
	have the same symptom. After my connection is released (my backup is
	done) I have to reset these bridge to make new connections possible.

	This scenario is seen at customer side since this FDDI-ring is estab-
	lished, which was done three weeks ago. And this scenario can also be
	seen, if someone at customer side is doing large database requests.


	With this problem, the customer is asking us, whether we are able to
	fix this problem in the next time, or we have to deinstall our equip-
	ment and he will buy briges and concentrator of another vendor.


	Do you have ever seen such a problem???


	Thanks for replies

	Wolfgang Nord @BEO at Germany

    During the time that the backup procedure is causing this problem could
    you check the size of the forwarding database on the DECswitch?  Is the
    size of the fwdb consistent with the number of known addresses on the
    customer's net?  Are any of the NT systems directly connected to the FDDI?  
    
    I suggest that you escalate this problem by opening an IPMT case  against 
    the DEFBA so that we can track it within engineering.
    
    Bill Wade
    Network Product Support
    
                                         

	Hello Bill,

	I have had a small problem to connect to the bridge at the time it is
	only realising the connection between my NT-client and the server con-
	nected to the DECconcentrator, I think I've mentioned in my request.

	I'm unable to connect to the bridge, I'm connected on with my NT-
	client, since Hubwatch reports a "...Agent is not responding..." or so,
	it's the onliest answer from my Hubwatch-window. And I'm not connected
	to the same bridge, the same segment as my NT-client is. All the seg-
	ments and all the bridges, I'm connected to, are different.
	So I can't give you the answer, you espected.

	There are two NT-systems directly connected to the FDDI-ring, using
	the DECconcentrator, and one SCO-UNIX-system, likewise connected to
	the DECconcentrator, all these systems are server for the NT-clients.

	All the NT-clients and SCO-clients, connected to the FDDI-ring, are
	using the DECswitch 900 Ethernet interface, no direct connection.

	Bill, can you explain, how to "...open a IPMT..." 'cause I haven't
	done it befor, I've never had such a problem.


	Thanks from the so called "Wrapped Reichstag" in Berlin


	Wolfgang Nord

	at Berlin at Germany

    This discussion is continuing offline.
    
    Bill