网络接口卡升级后NFS停止工作

Question

向下滚动以获得最新更新。

我有一个基础设施，其中包含一个NFS服务器，为用户托管家庭。服务器正在运行Ubuntu服务器，并且有10G光纤以太网(Myri-10G双协议nic)。大约两年来，它一直运行良好。在此网卡转换过程中，没有对服务器进行任何更改，而且服务器始终具有10G光纤。

基础设施概述：

• 服务器：(10.131.39.114) Ubuntu 16.04.4，Myri-10G双协议NIC，固件1.4.57，nfs-内核-服务器1:1.2.8-9 ubuntu12.3，linux内核4.4.0-109-泛型
• 开关:强制10 S2410，层2只，10G光纤接口
• 客户端: linux 18.2，Myri-10G双协议NIC，固件1.4.57，运行autofs，Linux内核4.8.0-53-泛型(所有客户端相同，提醒您，它们使用Intel 82579LM Gigabit网络连接在铜以太网上)

客户端工作站是戴尔工作站类机器，使用的是内置的1G以太网(Intel 82579 1G)。我们正在致力于大数据，并得到了更多的Myri-10G双协议nics。

我们一半的工作站通过新的nics进行升级，并通过光纤连接到S2410交换机。当重新启动时，这一切似乎都奏效了。我们关闭了Intel并配置了Myricom，其IP地址与铜nic相同(并且我们关闭了铜nic )。一切看起来都很好，我们可以点击，下载文件等，然而，当客户端登录时，它挂起。经过简短的调查，我们意识到NFS服务器没有连接。

注意:我们正在使用VLANS。在一开始，我认为这可能是一个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/网络/接口包含：

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的客户机上，如果我创建一个dir来从服务器挂载一个不同的导出dir，比如/mnt/克隆(我们打开它进行克隆)，而我使用NFSv4手动挂载它，它似乎可以工作，但是您不能将ls或cd挂载到挂载的dir。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)

总括而言：

• NFS在升级到10 an后似乎不再从客户端工作了.我知道我过去做过这样的事情，用这些完全相同的网卡(事实上，这些完全相同的网卡是我在2012年在另一个集群上使用的卡，我们被送回这些工作站使用，这意味着这个nfs不工作就更没有意义了)。
• 如果您手工挂载一个nfs共享，它将失败。
• 如果您手动挂载一个nfs共享，强制v4，它似乎可以工作，但只有挂载。除df命令外，文件和操作都将失败。
• 如果您尝试登录，并有自动挂载的家庭，它将失败。
• 如果您强迫automount在10G客户机上使用v4，它似乎会挂载，但用户仍然无法登录。家看上去是装的，但你不能对它做任何操作。

有趣的是，服务器没有客户端尝试身份验证请求的日志。例如，当一个正常工作的铜客户机有一个用户登录时，NFS服务器上的syslog记录一个经过身份验证的nfs请求。当同一个客户端尝试登录到10G工作站时，在装入请求的NFS服务器上没有日志。就好像请求没有到达服务器一样。

同样，在10G工作站上，网络上的其他一切都可以工作。文件传输，命中服务器(甚至NFS服务器通过ssh，http，我尝试的每一个端口工作)。这个问题似乎只影响NFS。

这篇文章的基本问题是:接下来我要做什么诊断？似乎我得到RPC超时，但所有的帮助/FAQ在互联网上指向路由或联网。这些主机被插入到同一个交换机中，实际上，我已经将它们转移到同一个VLAN进行测试，结果也是一样的。如有任何想法或见解，将不胜感激。

更新:我认为这是非常重要的，也是我问题的原因，但我不知道如何诊断：

来自一个拥有10G光纤卡的客户端：

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。我唯一能看到的铜客户端和失败的光纤客户端之间的不同之处是，服务器获得连接，并且所有看起来都与铜客户端连接时相同，但是，在它开始读取主dir文件(.bash_profile等)之后，服务器似乎开始重传并获得虚假的重传。过了一段时间，NFS仍然试图加载dir，然后我看到一个TCP、ACK和RST，然后是NFS NFSERR_BADSESSION。到目前为止，我无法从wireshark知道服务器为什么要重新传输或者客户端为什么失败.

到目前为止，我已经与另一个用户交换了10 far开关，并且使用了不同的客户端。不走运。

Answer 1

咬牙切齿之后，我突然意识到.如前所述，我有一个带铜和纤维的工作站，我正在测试，而纤维不起作用。然而，我想到，他们都必须跨越vlan边界，而且由于我的交换机仅为L2，他们正在与路由器交谈。

我在这里得到的答案..。是不对的。移动客户端到1500 MTU可以“解决”问题，这使我和网络团队认为路由器MTU也在1500。这是错误的。如果我们将工作站移动到一个独立的开关，并将每个人的MTU设置为9000，它就不能工作。事实证明..。似乎NFS不喜欢MTU 9000。

我指的是这些 文章，但这个问题并没有“解决”，因为我在Jumbo框架中使用10 with。它的解决办法是，如果您移动一个客户端有一个1500个字节的MTU，它可以工作。