At 02:03 AM 5/8/2009, Frank Steiner wrote: >Tom Talpey wrote > > >> In particular, if you do NLM file locking, there is a server callback (NLM >> "granted") which the server may choose to issue via UDP. If this callback >> is not seen by the client due to firewall blocking, there may be a 30-second >> pause before a client retry unblocks the caller. >> >> Also, the NSM (status monitor) exchanges are often performed via UDP. >> Again, if you are using NLM and the server reboots, the client may not >> become aware of this promptly, and lock reclaim will be affected. >> >> OTOH, if your applications don't use locking on the NFS mounts, you'll >> probably be fine. > >We do use locking on nfs mounts, so I wonder what that would mean for the >firewall. Currently I see connections from the NFS server *from* port 700 >and 111 (we've fixed mountd port to 700) to (it seems) arbitrary udp >ports on the NFS clients. > >Would that be enough to allow those? Or could the source ports be arbitrary >with NLM, too? I.e., would we have to open all udp traffic from the NFS >servers to all the NFS clients? The calls from the server to client port 111 are portmapper lookups, very likely while setting up the NSM callback that the server performs when it boots up. If the portmap call succeeds, then a second NSM call will occur, to whatever port the client NSM is using (700 sounds reasonable, but it's not guaranteed). NLM callbacks on blocking lock collision will be similar, but will happen any time not just at server reboot. The server will resolve the client NLM daemon using port 111, then perform a call to the result on whatever port is returned. There are very likely many ways to make these calls work through a firewall, but unfortunately not very many ways to guarantee it. The big problem is that the callbacks will be nearly silent on failure, so success is hard to detect! Depending on how criticial the application is, I would make different recommendations. But the safest option from a reliability standpoint might be to, yes, open up all UDP traffic. Ouch. There are other ways, but they're likely to be more fragile, and not all server/client combinations might work with a single solution. You might want to think through the DNS issues of this firewall, too. Are all the clients using hostnames in the same DNS domain as the server? And, do any of them use DHCP or other dynamic assignment? You want to be sure to use FQDNs as the client hostname(2), to ensure the server can always resolve them properly. I made a presentation on some of the NSM issues a few years back for Connectathon, if you're brave :-) you can check out: http://www.connectathon.org/talks06/talpey-cthon06-nsm.pdf The very best solution, by the way, would be to use NFSv4. It has no side protocols, and therefore no UDP issue. It does have a callback connection from the server to the client, but is done with TCP and is configurable. Tom. ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ NFS maillist - NFS@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/nfs _______________________________________________ Please note that nfs@xxxxxxxxxxxxxxxxxxxxx is being discontinued. Please subscribe to linux-nfs@xxxxxxxxxxxxxxx instead. http://vger.kernel.org/vger-lists.html#linux-nfs -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
