Path: utzoo!mnetor!uunet!husc6!rutgers!ames!ucbcad!ucbvax!MITVMA.MIT.EDU!KASTEN From: KASTEN@MITVMA.MIT.EDU (Frank Kastenholz) Newsgroups: comp.protocols.tcp-ip Subject: Response to Long Distance NFS Query Message-ID: <8712202159.AA13986@ucbvax.Berkeley.EDU> Date: 20 Dec 87 20:45:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 108 A few months ago I made a general request to the list about running NFS internetwork gateways. The specific configuration that I have to deal with is two Ethernets separated by some physical distance (possibly intercontinental). There would be some kind of gateway/bridge/router/thing at each Ethernet and the things are connected by a medium to high speed serial link (anything from about 38K to 1.544M bits/sec). The responses that I received (minus the "gee, what a great idea's" or "Well, it had to come someday" etc etc responses) are: (I have left the originating party's name on each on - the rest of the SMTP/RFC822 junk has been removed). ====================================================================== From: "James B. VanBokkelen" By default, none of Sun's implementations of NFS use UDP checksums. If you enable them, the last release I heard anything about still had the 4.2 UDP checksum mis-calculation. They assume they're running one hop, on a CRC-protected medium like Ethernet. Accordingly, you're not too likely to catch any situation where the NFS packet is corrupted on the way through a gateway, or over an error-prone link. Instant filesystem corruption. It can certainly be fixed if you have source, but I don't own any Suns (2nd hand info, this), so I can't say exactly what must be done. ======================================================================= From: jas@MONK.PROTEON.COM (John A. Shriver) The nature of the Sun NFS fragmented UDP-grams causes many routers and bridges to have fits. You get 6 back-to-back IP fragments. If ANY of those fragments is lost, the entire UDP-gram must be retranmitted. You can, however, reduce the size of the UDP-gram. In /etc/fstab, you need to add the undocumented rsize & wsize switches. For example: across_gw_machine:/usr /usr nfs rw,noquota,soft,rsize=2048,wsize=2048 This will reduce the size of the UDP-gram to 2048 btyes of data, as opposed to the default 8192. This will cuase only two fragments instead of eight. (Do keep this parameter a multiple of 1024, as all the network code likes page-aligned buffers.) For reference, see bug 135 in Sun Software Technical Bulletin, February 1987, part number 812-8701-01. (The page numbering is botched in this one.) ==================================================================== From: slevy@umn-rei-uc.arpa (Stuart Levy) One problem we've had in NFSing between disparate machines is with naming them. The mount request passes the originating machine -name- rather than having the server use gethostbyaddr(). It's important to check that "hostname" on the client yields a name known to the server and vice versa. That's probably not the whole problem but can cause things to break. A guy from Proteon, Mick Scully (mcs@proteon.com) recently visited here and mentioned that he had mounted NFS filesystems at Berkeley across ARPAnet. ====================================================================== From: hedrick@ATHOS.RUTGERS.EDU (Charles Hedrick) We run NFS over cisco routers, either directly connecting two Ethernets or connecting Ethernets via a T1 line. The only problem is that the Ethernet cards used by cisco (and others) can't handle large numbers of consecutive packets. So you need to specify rsize=nnn,wsize=nnn in the mount. Typically we use 2048, though I think someting a bit closer to 3000 might give better performance. I haven't tried it over anything slower, though we understand that somebody a Univ. of Maryland mounted one of our disks over NSFnet. ===================================================================== From: John Romkey One problem you'll run into is that NFS does not checksum its packets. NFS packets are UDP-based instead of TCP-based, and the UDP checksum is optional. On a single ethernet, the ethernet's CRC is possibly reliable enough to detect bad packets, but through an IP router there is too high a probability of losing (.1% would mean one out of 1000 packets was damaged; you really desparately want 0% errors). The reason is that there are chances for corruption of data in the ethernet interface of the IP router, in the IP router's memory, and in the other interface it routes the NFS packet too. The corruption can be due to hardware errors, electrical noise, memory errors and software problems. In fact, you've got the same problem with just an NFS server and client on the same LAN, but since fewer components are involved, the chances of error are much smaller. I've spoken with people who've used NFS over a router, and they've actually seen files corrupted due to the lack of checksums. I'd recommend against it. BTW, the reason they turn off checksums is to up performance. - john romkey ================================================================= ================================================================= Any further discussion should go to the list, to the original author or directly to me (unfortinately I have recently moved from MIT-Multics to MITVMA but the list has yet to catch up to me (whoever is running the distribution list must be on a verryyyyy loooonnnnggg vacation:-)) Seasons greetings to all Frank Kastenholz