0

I have an NFS server (server1) that works fine with TCP, but when a client mounts it with UDP, while the mount point works, it can only list folder with no files in it. If there's a file in that folder, it will keep the "ls" command open forever.

tcpdump shows logs like:

NFS 4078 [RPC duplicate of #28]V3 READDIRPLUS Reply (Call In 27)

and a list of the first files in that folder, but the client will just hang on the "ls" command.

Firewall is disabled SElinux is disabled

I have another server (server2) that has the same NFS configuration (including /etc/exports) and works fine both with TCP/UDP. nmap/rpcinfo/nfsstat/rpcdebug/etc all show the same (or similar) output.

Both are CentOS 7, and one of the differences is that server1 is also a kvm (libvirt/qemu) server.

Does any one have an idea what could be the issue or where (else) to look?

5
  • 1
    Have you tried with a directory with a single file? The problem could be that long UDP messages are systematically dropped. Try also a UDP ping or netcat with packets of various lengths to see what goes through. Sep 27, 2021 at 12:38
  • yes, I tried different amount of files in subfolders, and for some having 5 files will list the content. When it doesn't, tcpdump will show that the server keeps sending the list, because the client keeps asking (the client never gets the list, except when files are between 1 and 5). So who is dropping the UDP msg and why? and why on this server? (the other one, in a different network, works)
    – joovunir
    Sep 29, 2021 at 9:17
  • 1
    So it does look like there's a router/firewall/… between the client and the server that's dropping large UDP packets. You should be able to find out where it's happening by using traceroute to list the route between the client and the server, and a UDP ping with large packets to each intermediate hop and see which ones reply. As for fixing or working around the problem, I don't know. Maybe reducing the MTU somewhere, but I don't know how. Sep 29, 2021 at 10:08
  • Thanks, I tried sending files via UDP (using netcat) and found out that can't send file larger than 1472 bits or, in fact, that the server won't pass fragmented UDP packets. Now I need to find why...
    – joovunir
    Sep 30, 2021 at 9:36
  • I think 1472 bytes is a plausible limit given the MTU on Ethernet, so indeed larger packets should be fragmented, and there's probably a misconfiguration on the server. Sep 30, 2021 at 12:17

1 Answer 1

0

In my case it was that Jumbo frames were enabled on the interfaces of this server. After disabling it, UDP packets are now being fragmented and all works.

Although I still don't understand why it only affected UDP packets... and why Jumbo frames didn't work even when they were enabled in all affected server and switch/router.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .