Date: Thu, 31 Oct 1996 14:33:00 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gemohler@c-com.net (Geoff Mohler) Cc: hackers@FreeBSD.org Subject: Re: FBSD Message-ID: <199610312133.OAA26279@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.961031140040.536K-100000@dyslexic.phoenix.net> from "Geoff Mohler" at Oct 31, 96 02:00:59 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. This is a "security feature" to prevent NFS cookie spoofing based attacks. You can turn it off by disabling the check. There is a patch posted to the -current list archives (www.freebsd.org) which turns it off. > DEC for obvious reasons, cannot change the implementation of thier DEC > Clustering software. DEC *should* snd the reponse on the interface where the request was received. That they do not indicated that they are reallocating the packet header to turn the packet around (not a crime, but not very efficient). Probably because they are passing buffer references instead of pointer to buffer referneces in a streams stack. Bletch. In any case, it would save you the overhead of reexamining the route if you used the request interface for the response. Something to consider for your next release. This is a general fix for most IP aliasing problems. Regards. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610312133.OAA26279>