向下滚动以获取最新更新。
我有一个基础设施，其中包含一个为用户托管家庭的 NFS 服务器。服务器运行 Ubuntu 服务器，并具有 10G 光纤以太网（Myri-10G 双协议网卡）。近两年来一直运行良好。本次网卡过渡期间服务器没有做任何改变，服务器一直都是10G光纤。
基础设施概览：
- 服务器：（10.131.39.114）Ubuntu 16.04.4，Myri-10G双协议网卡，固件1.4.57，nfs-kernel-server 1:1.2.8-9ubuntu12.3，linux内核4.4.0-109-generic
- 交换机：Force 10 S2410，仅限第 2 层，仅限 10G 光纤接口
- 客户端：Linux Mint 18.2、Myri-10G 双协议网卡、固件 1.4.57、运行 autofs、linux 内核 4.8.0-53-generic（所有客户端相同，提醒一下，它们使用 Intel 82579LM 千兆位网络连接在铜以太网上）
客户端工作站是 Dell 工作站级计算机，并且是使用内置 1G 以太网（Intel 82579LM）。我们正在研究大数据，并且获得了更多 Myri-10G 双协议网卡。
我们一半的工作站都升级了新的网卡，并通过光纤连接到 S2410 交换机。这一切似乎重新启动后即可工作。我们关闭 Intel 并配置 Myricom，具有相同的IP地址作为铜网卡（我们关闭了铜网卡）。一切看起来都很好，我们可以 ping、下载文件等，然而，当客户端登录时，它会挂起。经过短暂调查后，我们意识到 NFS 服务器未连接。
注意：我们正在使用 VLAN。一开始我认为这可能是一个 VLAN 路由问题，所以我们将客户端和服务器放在同一个 VLAN 上。我们遇到了同样的问题。
观察/故障排除：
lshw -C network
*-network
description: Ethernet interface
product: Myri-10G Dual-Protocol NIC
vendor: MYRICOM Inc.
physical id: 0
bus info: pci@0000:22:00.0
logical name: enp34s0
version: 00
serial: 00:60:dd:44:96:a8
size: 10Gbit/s
width: 64 bits
clock: 33MHz
capabilities: msi pm pciexpress msix vpd bus_master cap_list rom ethernet physical fibre
configuration: autonegotiation=off broadcast=yes driver=myri10ge driverversion=1.5.3-1.534 duplex=full firmware=1.4.57 -- 2013/10/23 13:58:51 m latency=0 link=yes multicast=yes port=fibre speed=10Gbit/s
resources: irq:62 memory:fa000000-faffffff memory:fbd00000-fbdfffff memory:fbe00000-fbe7ffff
*-network
description: Ethernet interface
physical id: 1
logical name: enp34s0.731
serial: 00:60:dd:44:96:a8
size: 10Gbit/s
capabilities: ethernet physical fibre
configuration: autonegotiation=off broadcast=yes driver=802.1Q VLAN Support driverversion=1.8 duplex=full firmware=N/A ip=10.131.31.181 link=yes multicast=yes port=fibre speed=10Gbit/s
rpcinfo -p 10.131.39.114
program vers proto port service
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100011 1 udp 787 rquotad
100011 2 udp 787 rquotad
100011 1 tcp 787 rquotad
100011 2 tcp 787 rquotad
100005 1 udp 40712 mountd
100005 1 tcp 45016 mountd
100005 2 udp 44618 mountd
100005 2 tcp 49309 mountd
100005 3 udp 43643 mountd
100005 3 tcp 53119 mountd
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs
100003 4 tcp 2049 nfs
100227 2 tcp 2049
100227 3 tcp 2049
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 4 udp 2049 nfs
100227 2 udp 2049
100227 3 udp 2049
100021 1 udp 51511 nlockmgr
100021 3 udp 51511 nlockmgr
100021 4 udp 51511 nlockmgr
100021 1 tcp 43334 nlockmgr
100021 3 tcp 43334 nlockmgr
100021 4 tcp 43334 nlockmgr
rpcinfo -u 10.131.39.114 mount
program 100005 version 1 ready and waiting
program 100005 version 2 ready and waiting
program 100005 version 3 ready and waiting
rpcinfo -u 10.131.39.114 portmap
program 100000 version 2 ready and waiting
program 100000 version 3 ready and waiting
program 100000 version 4 ready and waiting
rpcinfo -u 10.131.39.114 nfs
program 100003 version 2 ready and waiting
program 100003 version 3 ready and waiting
program 100003 version 4 ready and waiting
但是，这失败了：
showmount -e 10.131.39.114
rpc mount export: RPC: Timed out
旁注，在工作客户端（在铜上）上，您通常会看到以下内容：
showmount -e 10.131.39.114
Export list for 10.131.39.114:
/mnt/homes 10.131.84.0/26,10.131.31.187,10.131.31.186,10.131.31.185,10.131.31.184,10.131.31.183,10.131.31.182,10.131.31.181,10.131.31.180
/mnt/clones 10.131.31.0/24,10.131.39.0/24,10.131.84.0/26
（是的，我知道它们位于不同的局域网上，但它已经工作多年了）。
旁注：我们关闭了网络管理器，/etc/network/interfaces 包含：
auto enp34s0.731
iface enp34s0.731 inet static
vlan-raw-device enp34s0
address 10.131.31.181
netmask 255.255.255.0
gateway 10.131.31.1
dns-nameservers 10.131.31.53,10.35.32.15
也许这些信息有帮助：
在具有 10G 的客户端上，如果我创建一个目录来挂载从服务器导出的不同目录，例如 /mnt/clones（我们打开它进行克隆），并且我使用 NFSv4 手动挂载它，那么似乎可以工作，但是你不能 ls 或 cd 到安装的目录。 df 可以工作，但您无法统计目录中的任何文件。我以前见过这个问题，但我不记得为什么。
请注意，客户端默认使用 nfs4（例如，来自启用了 auto.home 的工作铜以太网客户端）：
10.131.39.114:/mnt/homes/usera on /home/usera type nfs4 (rw,nosuid,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.131.31.185,local_lock=none,addr=10.131.39.114)
总共：
- 升级到 10gig 后，NFS 似乎不再在客户端工作...我知道我过去曾使用这些完全相同的网卡（事实上，这些完全相同的网卡是我在 2012 年使用的网卡）另一个集群，我们又把它们放回这些工作站中使用，这意味着这个 nfs 不工作就更没有意义了）。
- 如果您手动挂载 nfs 共享，则会失败。
- 如果你手动挂载一个 nfs 共享，强制使用 v4，它似乎可以工作，但只能挂载。除了 df 命令之外，文件和操作都将失败。
- 如果您尝试登录并自动挂载主目录，则会失败。
- 如果在 10G 客户端上强制 automount 使用 v4，则会似乎挂载，但用户仍然登录失败。家看起来已挂载，但不能对其进行任何操作。
有趣的是，服务器没有客户端尝试身份验证请求的日志。例如，当工作的铜客户端有用户登录时，NFS 服务器上的 syslog 会记录经过身份验证的 nfs 请求。当同一客户端尝试登录10G工作站时，NFS服务器上没有记录挂载请求。就好像请求没有到达服务器一样。
同样，从 10G 工作站开始，网络上的其他一切都可以正常工作。文件传输、访问服务器（甚至是通过 ssh、http 的 NFS 服务器，我尝试的每个端口都有效）。这个问题似乎只影响 NFS。
这篇文章的基本问题是：接下来我要进行什么诊断？我似乎遇到了 RPC 超时，但互联网上的所有帮助/常见问题解答都指向路由或网络。这些主机插入同一个交换机，事实上我已将它们移至同一个 VLAN 进行测试，结果相同。任何想法或见解将不胜感激。
更新：我认为这是非常重要的，也是我的问题的原因，但我不知道如何诊断这一点：
来自拥有 10Gig 光纤卡的客户端：
nmap -sC -p111 10.131.39.114
Starting Nmap 7.80 ( https://nmap.org ) at 2021-03-12 15:20 UTC
Nmap scan report for cmixhyperv03.cmix.louisiana.edu (10.131.39.114)
Host is up (0.00011s latency).
PORT STATE SERVICE
111/tcp open rpcbind
MAC Address: 00:60:DD:46:D6:DE (Myricom)
Nmap done: 1 IP address (1 host up) scanned in 3.79 seconds
来自类似的客户端，但使用 1G 铜以太网：
nmap -sC -p111 10.131.39.114
Starting Nmap 7.01 ( https://nmap.org ) at 2021-03-12 09:21 CST
Nmap scan report for cmixhyperv03.cmix.louisiana.edu (10.131.39.114)
Host is up (0.00044s latency).
PORT STATE SERVICE
111/tcp open rpcbind
| rpcinfo:
| program version port/proto service
| 100000 2,3,4 111/tcp rpcbind
| 100000 2,3,4 111/udp rpcbind
| 100003 2,3,4 2049/tcp nfs
| 100003 2,3,4 2049/udp nfs
| 100005 1,2,3 43643/udp mountd
| 100005 1,2,3 53119/tcp mountd
| 100011 1,2 787/tcp rquotad
| 100011 1,2 787/udp rquotad
| 100021 1,3,4 43334/tcp nlockmgr
| 100021 1,3,4 51511/udp nlockmgr
| 100227 2,3 2049/tcp nfs_acl
|_ 100227 2,3 2049/udp nfs_acl
Nmap done: 1 IP address (1 host up) scanned in 1.21 seconds
更新20210315
tcpdump 到客户端和服务器上的wireshark。我可以看到工作的铜缆客户端和失败的光纤客户端之间唯一的区别是服务器获得连接，并且一切看起来与铜缆客户端连接时相同，但是，在它开始读取主目录文件（. bash_profile 等），服务器似乎开始重新传输并获得虚假的重新传输。一段时间后，NFS 仍在尝试加载目录，然后我看到 TCP RST、ACK 和 RST，然后是 NFS NFSERR_BADSESSION。到目前为止，我无法从wireshark中看出为什么服务器正在重传或为什么客户端失败......
到目前为止，我已经将 10gig 交换机更换为另一个，并且还使用了不同的客户端。没有运气。
答案1
经过一番咬牙切齿后，我突然意识到......如前所述，我有一个同时具有铜缆和光纤的工作站，我正在测试该工作站，但光纤不起作用......但是，我突然想到它们都必须跨越vlan 边界，并且由于我的交换机仅是 L2，因此它们正在与路由器通信。
我在这里得到的答案......是不正确的。将客户端移至 1500MTU 确实“解决”了问题，这导致我和网络团队认为路由器 MTU 也是 1500。这是不正确的。如果我们将工作站移至独立交换机并将每个人的MTU设置为9000，则不起作用。事实证明... NFS 似乎不喜欢 MTU 9000。
我正在参考这些 文章，但这个问题并没有“解决”，因为我使用的是 10Gig 和 Jumbo 帧。如果您将客户端移动到 MTU 为 1500 字节，则该问题可以解决。