From owner-freebsd-hackers Thu Oct 31 12:01:03 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA02960 for hackers-outgoing; Thu, 31 Oct 1996 12:01:03 -0800 (PST) Received: from dyslexic.phoenix.net (root@dyslexic.phoenix.net [199.3.233.7]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id MAA02955 for ; Thu, 31 Oct 1996 12:01:01 -0800 (PST) Received: (from gemohler@localhost) by dyslexic.phoenix.net (8.7.5/8.7.3) id OAA01532; Thu, 31 Oct 1996 14:00:59 -0600 (CST) Date: Thu, 31 Oct 1996 14:00:59 -0600 (CST) From: Geoff Mohler X-Sender: gemohler@dyslexic.phoenix.net To: hackers@freebsd.org Subject: FBSD Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am in need of some development help with FBSD in its NFS client implimentation. Heres a quick summary: I have DEC clustering on my main servers that run our RAID and FDDI network. FBSD machines are clients to that environment.. The DEC mahchines have an actual IP address, and an alias IP address. The alias IP is the hostname/IP that the NFS clients _need_ to use under DEC Safe/Clustering. This is how services are distributed under this environment. If a machine died, then another machine would assume it's alias IP/hostname & services. The client wouldnt notice a thing. Problem is..the FBSD sends a NFS request to mount a filesystem to the alias IP. The DEC responds to this requests over the ACTUAL IP of it's FDDI interface. That is how DEC designed it to work. Only problem is, FBSD refuses to acknowledge the response it gets because it is not from the same host/IP address it send the request to. A plain mount command..will "cleanly" mount a filesystem. It is when you try to modify, or inquire about a FS that your session hangs...like doing a df, or an ls in the mounted FS. The machine runs well overall, just your session hangs because of the broken NFS communication. FBSD is the only OS that reacts in this manner. DEC for obvious reasons, cannot change the implementation of thier DEC Clustering software. We desperately need someone to assist us in working the source code to allow this to work the way it should with the DEC product. Ideas? I am forwarding the Email I asked my DEC rep to send: ***** I've attached below a summary of the problem we were seeing with freebsd nfs clients mounting ASE services. Let me know if I can be of further assistance. Regards, Alan Sherlock Digital Customer Support Center Unix Networking Support 1-800-354-9000 ---- Symptom: Freebsd nfs client mounts hang when mounting a Digital UNIX ASE service. Background: ASE provides for failover of nfs services. It uses two systems with a shared scsi device and an ip alias. While one system has control of the scsi device, it offers the nfs service via an ip alias. If the system goes down, the second system takes over both the shared scsi device and the ip alias, thus offering the nfs client seamless failover capability. Analysis: We found that freebsd nfs client mounts would hang when mounting an ASE service. The same clients could successfully mount filesystems from the same nfs server without using ASE or the ip alias. We eliminated ASE from the equation by configuring an ip alias on the nfs server, and mounting from the alias. This also hung. We next attempted the same scenario between two freebsd systems. We configured one as an nfs server, and configured an ip alias address on the interface. We then configured another freebsd system as an nfs client, and mounted the filesystem from the freebsd server using the ip alias address. This also hung. Summary: It appears that freebsd nfs clients cannot nfs mount from a server using an ip alias. Since this is an integral part of ASE services on Digital UNIX, the same clients cannot mount an ASE service. At this point, it appears to be a problem with the freebsd client implementation. *** Thanks. "Quark & Odo in '96. Law, order, and a tidy profit." Geoff Mohler Operations Engineer Charter Communications/Phoenix Data Net