这是一个我无法诊断的问题：
我们的用户主目录通过运行Mac OS X 10.5.7的Apple XServe上的NFS提供。 通常他们被导出到我们默认的办公室子网“lan”。 最近我一直在build立一个新的子网，“农场”。 “农场”上的电脑与“lan”上的电脑运行相同的操作系统（openSUSE 11.1和Gentoo），软件版本相同。
问题是，当我的用户在“农场”上使用计算机一段时间（5分钟，有时30分钟，有时一个小时），NFS挂载似乎只是挂起。 尝试在目录上执行ls或尝试访问用户主目录的其他任何内容（例如login等）都会卡住。 从“挂起”机器挂载到其他NFS服务器似乎按预期工作。
客户端或服务器的日志中没有任何内容表示任何问题。 相同types的客户端在默认的“局域网”子网上工作得很好。
我已经尝试了NFS服务器和客户端的各种不同的configuration（禁用/启用kerberos，不同的挂载选项），但没有任何显示有任何区别。
我强烈怀疑这两个子网之间的一些networking级别的问题，可能是一些由防火墙/路由器（使用pf作为数据包filter的OpenBSD）造成的。 两套机器之间的连接相当简单： x serve --> switch --> router --> switch --> clients
对于debugging下一个尝试的方法，或者可能的解决scheme，我几乎不知所措。 关于如何从这个angular度来解决这个问题的任何想法？
更新：
仍然无法解决这个问题。 当我禁止在内部界面上scrub时，我认为我已经把它扼杀在萌芽状态，但是问题又一次显现出来了。 奇怪的是，pf似乎仍然在修改一些数据包。
在vlan 场的一个例子中，
09:17:39.165860 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF) 09:17:39.166124 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 43 win 65535 <nop,nop,timestamp 316702204 236992843> (DF) 09:17:54.164490 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF) 09:17:54.164760 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1441270809:1441270809(0) ack 43 win 65535 (DF) 09:17:54.164776 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 4243886205:4243886205(0) ack 46 win 0 (DF) 09:17:54.164989 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF) 09:17:57.164066 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF) 09:17:57.164330 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702384 236997343> (DF) 09:18:03.163468 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF) 09:18:03.163732 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)
和lan vlan上的一样：
09:17:39.165876 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472382:2887472382(0) win 5840 <mss 1460,sackOK,timestamp 236992843 0,nop,wscale 6> (DF) 09:17:39.166110 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702204 236992843> (DF) 09:17:54.164505 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472385:2887472385(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF) 09:17:54.164740 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 1:1(0) ack 1 win 65535 (DF) 09:17:54.164745 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: R 2802615397:2802615397(0) ack 4 win 0 (DF) 09:17:54.165003 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236996593 0,nop,wscale 6> (DF) 09:17:54.165239 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702354 236996593,sackOK,eol> (DF) 09:17:55.123665 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702363 236996593,sackOK,eol> (DF) 09:17:57.124839 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702383 236996593,sackOK,eol> (DF) 09:17:57.164082 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236997343 0,nop,wscale 6> (DF) 09:17:57.164316 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702384 236997343> (DF) 09:18:01.126690 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: S 449458819:449458819(0) ack 2887472389 win 65535 <mss 1460,nop,wscale 3,nop,nop,timestamp 316702423 236997343,sackOK,eol> (DF) 09:18:03.163483 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,sackOK,timestamp 236998843 0,nop,wscale 6> (DF) 09:18:03.163717 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,nop,timestamp 316702444 236998843> (DF)
我还应该提到，我们有其他的NFSstream量通过同一台机器，但是来自不同的NFS服务器。 我们已经使用了多年，在那里没有任何问题。 同样，这些X服务器也一直在自己的子网上为Linux客户端提供NFS服务，并继续这样做。
只是想更新这个情况下，任何人遇到同样的问题。
基本上，这归结于Pf的州法规。 默认情况下Pf保持状态，并使用S / SA作为掩码。 但是，OS X上的NFS服务器实现似乎尝试使用非标准的标志集来启动对话回客户端。 这导致它失败，因为Pf只是丢弃了数据包。 我通过tcpdump lan和farm接口收集了这个信息。 调整子网之间规则的状态标志后，连接已正确build立。
但是，由于其他forms的内部规范化，似乎Pf继续过滤掉一些数据包，并且没有调整我尝试设置的选项来使其工作。
最后，我最终在文件服务器上创build了另一个接口，并将其直接放在场vlan上，完全绕过路由器。
我没有用过pf ; 但我认为这是第一个有史以来最好的filter之一。 也许它是在考虑“连接”并放弃它们？
我会寻找任何状态相关的过滤规则。 在Linux的iptables通常filter以a开头
ACCEPT all state RELATED,ESTABLISHED
因为这样就不必在第一个包之后重新检查每个包的所有相关规则。 但是由于NFS是基于UDP的，并不关心很长时间（甚至是几个小时）的静默期，所以路由器可能正在失去ESTABLISHED状态，新的数据包无法启动。
检查是否有任何“keepalive”参数使客户端在静默一分钟后发送心跳包。 如果没有，请尝试通过TCP的NFS。 （它有心跳包）。
首先要做的是确保防火墙实际上是罪魁祸首。
为此，请将您的默认阻止规则设置为日志。 在我的防火墙上，这是过滤规则顶部的两行：
block in log block out log
等待NFS挂载再次挂起并检查您的日志界面：
tcpdump -eeni pflog0 'host <client ip> and host <nfs server ip>'
如果您看到这些数据包在防火墙被阻止，请发布您的pf.conf。 如果不是的话，我们需要开始在防火墙之外寻找。