Conference irocz::common_brouters

729.0. "VNswitch 900EE problem seen at Germany Cust site..." by NETCAD::BATTERSBY () Fri Jan 24 1997 09:50

    This note was originally posted in the hub_mgnt notes file, but
    it probably will get better response in here.
    I've notified Wolfgang that I have posted it over here.
    
    Bob
    ------------------------------------------------------------------------
    
            <<< NETCAD::KALI$USER3:[NOTES$LIBRARY]HUB_MGNT.NOTE;1 >>>
                   -< DEChub/HUBwatch/PROBEwatch CONFERENCE >-
================================================================================
Note 4185.0             problem with VNswitch 900 EE ...              No replies
BERFS4::NORD                                         81 lines  24-JAN-1997 09:09
--------------------------------------------------------------------------------


	Good morning, good afternoon, good evening and all the times between
	in this nice world.


	Yesterday I had the luck, that I can do some testing with our new
	VNswitch 900 EE. The config was:
		Port 1 - 6 and 13 - 18 are full-duplex configured, all the
		others are simplex, port 11 goes the attached doking station
		DEChub ONE.
	We connected five systems to port 1 - 5, these systems where connected
	before to a DECswitch 900 EE. Two systems are a Digital UNIX server,
	the three others are clients, which boot from these servers and then
	mount via NFS their file systems. This configuration where running with
	our DECswitch 900 EE, but the customer wants more thruput, so we deci-
	ded, to use our new VNswitch. We connected the systems, changed
	EWA0_MODE to Twisted Pair, Full-Duplex, ifconfig tu0 spped 20, and star-	
	ted the servers. All is fine. Now we booted the first client. We saw
	the bootp request for the first image named ".vmunix", the client got
	it. Then there was a second bootp request for the "real" vmunix of this
	client. I don't know, what is going on, the client wants to mount the
	root file system, but
		Error-Message:
		panic (cpu0): vfs_mountroot: cannot mount root
		syncing disk ... done

		DUMP: No primary swap, no explicit dumpdev.
			Nowhere to put header, giving up
	The same result is seen with a connection of the client to one of the
	simplex ports. (Changed EWA0 to "simplex")

	The link state led of the port, where the client is connected, gets off,
	just befor the client wants to mount the root file system, so as when
	there is no link available. This can be seen with the full-duplex
	connection and with the simplex connection. We then connected the client
	to a LANNETswitch the customer is also using, booted the client, all is
	fine, the clients came up with no problem. We then connected this run-
	ning client to one of the simplex ports of the VNswitch, after a while
	the link state led lits (stady on), but we saw the following console
	message:
		NFS 3 server a4 not responding, till trying
		NFS 3 server a4 ok
                NFS 3 server a4 not responding, till trying
                NFS 3 server a4 ok
	and sometimes:
		dtfile: broken pipe in PipeRead
		Internal error in ReaddirPipeCallback: bad msg -1

	The first problem is, what's going on with our VNswitch, we are not	
	able to have a connection via NFS between a client and a server. We
	are unable to boot a client thru this switch without having problems.
	I don't know where to look to solve this problem.

	So we wanted to verify, if there are more problems and mounted the file
	systems of the two servers to each other, both with EWA0 full-duplex,
	speed 20 (mount a5/usr /mnt, mount a3/usr /mnt). We then opened two
	windows on each of these servers and do a "tar -cvf /dec/null /mnt"
	(about 300 MB) in all the windows we have opened. We have started four
	"tar"s and there is no problem with NFS between these two servers,
	there is no packet loss, no collision, nothing, siwtching is nice!!!

	So is there someone out there, who is able to lend me a helping hand
	with this problem? The switch is send back to the German NPBU, so I'm
	not able to do some reproducing here in the office or at customer side.

	Some technical information:

		VNswitch 900 EE, DNVEE-MA, Rev. A01, S/N KA640SEESJ
				HW=06E1E1, RO=1.5.4, #=1645, SW=T1.0-011
		DEChub ONE, no information available, is used by the DECswitch
				900 EE with out any problem
		Port 3 and port 5 are full-duplex and there are the two servers
				connected to, an AS400 and an A0250
		Port 1, 2 and 5 are full-duplex and there are the clients
				connected to, two A0250 and one A0200

	Thanks in advance

	Wolfgang Nord
	MCS@BEO@GERMANY

I'm guessing here, but one thing to be aware of is that when the
physical link (ethernet twisted pair in this case) comes up, it
takes a further 30 seconds (by default) until you can send and
receive data through that link. This is because the spanning tree
protocol runs on all ports by default and it must wait for this time
before putting the port in "forwarding" state at which point it can
bridge packets on this port.

It may be that as your client boots, it either sends the boot request
before this interval has expired, or it drops the link after the intial
boot request and again does not wait long enough before sending the
second request. Normally this would not be a problem because clients
keep trying BootP requests indefinitely, but maybe your client doesn't
retry ?

You could experiment by turning off spanning tree on the port to which
the client is attached. I would not recommend doing this unless you
really have to because you will have no protection against creating
a bridging loop if you should connect that port some other time into
another bridge.

If this is the problem then I don't understand why the LANNET switch
works ok unless that is not running spanning tree on the client ports
for some reason - otherwise that should have the same problem.

You can turn spanning tree off for a port through the CLI (and through
hubwatch when it is supported). Through the CLI go to the config process:-

*config
Config> protocol bridge
Bridge Config> disable stp port x

This is another W.A.G. based on my experiences running an EX 
that was running a pre-V1 release (T1-???) where it would 
not map to backplane LANS and it could not parse "monitor" 
or "config" (I had to use T 5 and T 6 instead).

Once I upgraded to V1.0, the EX worked properly.  It's worth 
upgrading just so the CLI commands match the documentation.
The V1.0 firmware for both the EE and EX is on both the 
internal and external web sites; call the TAC for the 
correct pointer and username/password (dtn 226-6789).  V1.1 
firmware is due this week.

Tom Herendeen
NPB SE