linux – 从不同子网上的服务器访问时,NFS挂载“挂起”

前端之家收集整理的这篇文章主要介绍了linux – 从不同子网上的服务器访问时,NFS挂载“挂起”前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
这是一个我无法诊断的问题:

我们的用户主目录通过NFS从运行Mac OS X 10.5.7的Apple XServe提供.通常它们会导出到我们的默认办公室子网“lan”.最近我一直在建立一个新的子网“农场”. “farm”上的计算机运行与“lan”上的计算机相同的操作系统(openSUSE 11.1和Gentoo),软件版本相同.

问题是当我的用户在“farm”上使用一台机器一段时间(5分钟,有时30分钟,有时是整整一小时)时,NFS挂载似乎只是挂起.尝试在目录上执行ls或尝试访问用户主目录的任何其他内容(例如登录等)都会卡住.从“挂起”计算机安装到其他NFS服务器似乎按预期工作.

客户端或服务器的日志中没有任何内容表明存在任何问题.相同类型的客户端可以在默认的“lan”子网中正常工作.

我已经尝试了各种不同的NFS服务器和客户端配置(禁用/启用kerberos,不同的挂载选项),但似乎没有任何区别.

我强烈怀疑这两个子网之间存在一些网络级问题,可能是防火墙/路由器的一些问题(OpenBSD和pf作为数据包过滤器).两组机器之间的连接非常简单:
x服务 – >开关 – >路由器 – >开关 – >客户

关于调试接下来尝试的方法,或者可能的解决方案可能是什么,我几乎不知所措.关于如何从这一点解决这个问题的任何想法?

更新:

仍然无法解决这个问题.当我在内部接口上禁用擦除时,我以为我已经将它扼杀在萌芽状态,但问题再次出现了.奇怪的是,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,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,timestamp 236996593 0,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,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,timestamp 236997343 0,wscale 6> (DF)
09:17:57.164330 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <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,timestamp 236998843 0,wscale 6> (DF)
09:18:03.163732 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 49 win 65535 <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,wscale 6> (DF)
09:17:39.166110 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <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,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,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,wscale 3,timestamp 316702354 236996593,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,timestamp 316702363 236996593,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,timestamp 316702383 236996593,eol> (DF)
09:17:57.164082 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,wscale 6> (DF)
09:17:57.164316 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <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,timestamp 316702423 236997343,eol> (DF)
09:18:03.163483 node001.farm.foo.com.769 > barstar.lan.foo.com.nfsd: S 2887472388:2887472388(0) win 5840 <mss 1460,wscale 6> (DF)
09:18:03.163717 barstar.lan.foo.com.nfsd > node001.farm.foo.com.769: . ack 1 win 65535 <nop,timestamp 316702444 236998843> (DF)

我还应该提一下,我们有其他NFS流量通过同一台机器,但来自不同的NFS服务器.我们多年来一直在使用它,并没有遇到任何问题.同样,这些XServes也在很长一段时间内为自己子网上的Linux客户端提供NFS服务,并继续这样做.

解决方法

只是想更新这个以防万一有人遇到同样的问题.

基本上它归结为Pf中的州规则.默认情况下,Pf保持状态,并使用S / SA作为掩码.但是,似乎OS X上的NFS服务器实现尝试使用非标准的标志集将对话启动回客户端.这导致它失败,因为Pf只是丢弃了数据包.我通过tcpdumping lan和farm接口收集了这个.在调整子网之间的规则的状态标志之后,正确建立了连接.

然而,由于某些其他形式的内部规范化,Pf似乎继续过滤掉一些数据包,并且没有调整我试图使其工作的选项.

最后,我最终在文件服务器上创建了另一个接口并将其直接放在farm vlan上,完全绕过了路由器.

猜你在找的Linux相关文章