网络不是我的专长，我已经尽力尝试隔离这个问题，我希望得到一些关于如何进一步缩小问题范围的指点。
服务器：运行 Limetech Unraid 5.0.6 的文件服务器（基于 Slackware 的操作系统，内核为 3.9.11p）
该服务器已可靠运行约 2 年，最近唯一的硬件变化是 RAM 升级（我已经使用内存工具来验证 RAM 是否运行正常）
初始症状：网络上访问网络共享的其他计算机每 3-5 分钟会出现 10-20 秒的间歇性断开连接。
调查使用重复的 ping 测试，我能够确定网络上的所有其他设备都保持了连接，只有文件服务器在短时间内掉线。
对文件服务器的 ping 操作会以半随机间隔失败长达 8 秒，间隔时间从 30 秒到 15 分钟以上，平均间隔约为 3-5 分钟。
重新启动服务器似乎可以让问题消失几个小时。
ifconfig 显示，在连接似乎失败的同时，有少量 (3-7) RX 数据包被丢弃
无论是在启动时还是在故障期间，系统日志都不会报告任何异常情况。
ethtool 显示 Link 始终保持正常
我不是网络工程师，但似乎该问题特定于该设备（连接到同一基础设施的其他设备没有问题）。
这可能是 NIC 本身的硬件问题吗？还是与操作系统或网络配置有关？可能是由用户软件引起的吗？
如能得到关于如何找出根本原因的任何建议，我们将不胜感激。
日志/故障排除输出：
从 Windows 笔记本电脑 Ping 到 Unraid 服务器：
Reply from x.x.x.100: bytes=32 time=3ms TTL=64
Reply from x.x.x.100: bytes=32 time=7ms TTL=64
Reply from x.x.x.100: bytes=32 time=3ms TTL=64
Reply from x.x.x.100: bytes=32 time=3ms TTL=64
Reply from x.x.x.100: bytes=32 time=4ms TTL=64
Reply from x.x.x.100: bytes=32 time=3ms TTL=64
Request timed out.
Request timed out.
Request timed out.
Reply from x.x.x.200: Destination host unreachable.
Request timed out.
Reply from x.x.x.100: bytes=32 time=2ms TTL=64
Reply from x.x.x.100: bytes=32 time=1ms TTL=64
Reply from x.x.x.100: bytes=32 time=4ms TTL=64
Reply from x.x.x.100: bytes=32 time=2ms TTL=64
Reply from x.x.x.100: bytes=32 time=2ms TTL=64
配置文件
eth0 Link encap:Ethernet HWaddr 94:de:80:03:2e:3c
inet addr:x.x.x.100 Bcast:x.x.x.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:35866080 errors:0 dropped:2107 overruns:0 frame:0
TX packets:35139719 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1597778360 (1.4 GiB) TX bytes:1548836243 (1.4 GiB)
Interrupt:49
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1583 errors:0 dropped:0 overruns:0 frame:0
TX packets:1583 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:158298 (154.5 KiB) TX bytes:158298 (154.5 KiB)
网络状态
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 35866360 0 2107 0 35139884 0 0 0 BMRU
lo 65536 0 1583 0 0 0 1583 0 0 0 LRU
消息 | grep r8168
r8168 Gigabit Ethernet driver 8.037.00-NAPI loaded
r8168 0000:02:00.0: irq 49 for MSI/MSI-X
r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
r8168 Copyright (C) 2013 Realtek NIC software team <[email protected]>
猫/ var / log / syslog | grep eth
Jan 10 03:04:03 ServerName logger: /etc/rc.d/rc.inet1: List of interfaces: 'eth0'
Jan 10 03:04:03 ServerName kernel: eth%%d: 0xf8560000, 94:de:80:03:2e:3c, IRQ 49
Jan 10 03:04:03 ServerName logger: /etc/rc.d/rc.inet1: Polling for DHCP server on interface eth0:
Jan 10 03:04:03 ServerName logger: /etc/rc.d/rc.inet1: /sbin/dhcpcd -t 10 -h ServerName -L eth0
Jan 10 03:04:03 ServerName dhcpcd[1203]: eth0: waiting for carrier
Jan 10 03:04:08 ServerName kernel: r8168: eth0: link up
Jan 10 03:04:08 ServerName dhcpcd[1203]: eth0: carrier acquired
Jan 10 03:04:08 ServerName dhcpcd[1203]: eth0: broadcasting for a lease
Jan 10 03:04:11 ServerName dhcpcd[1203]: eth0: offered x.x.x.100 from x.x.x.1
Jan 10 03:04:11 ServerName dhcpcd[1203]: eth0: acknowledged x.x.x.100 from x.x.x.1
Jan 10 03:04:12 ServerName dhcpcd[1203]: eth0: checking for x.x.x.100
Jan 10 03:04:16 ServerName dhcpcd[1203]: eth0: leased x.x.x.100 for 86400 seconds
Jan 10 03:04:31 ServerName logger: # * SSL.Connection objects, wrapping the methods of Python's portable
Jan 10 03:04:36 ServerName avahi-daemon[7491]: Joining mDNS multicast group on interface eth0.IPv4 with address x.x.x.100.
Jan 10 03:04:36 ServerName avahi-daemon[7491]: New relevant interface eth0.IPv4 for mDNS.
Jan 10 03:04:36 ServerName avahi-daemon[7491]: Registering new address record for x.x.x.100 on eth0.IPv4.
Jan 10 03:05:08 ServerName ntpd[1258]: Listen normally on 2 eth0 x.x.x.100 UDP 123
Jan 10 15:04:17 ServerName dhcpcd[1203]: eth0: renewing lease of x.x.x.100
Jan 10 15:04:17 ServerName dhcpcd[1203]: eth0: acknowledged x.x.x.100 from x.x.x.1
Jan 10 15:04:17 ServerName dhcpcd[1203]: eth0: leased x.x.x.100 for 86400 seconds
Jan 11 03:04:18 ServerName dhcpcd[1203]: eth0: renewing lease of x.x.x.100
Jan 11 03:04:18 ServerName dhcpcd[1203]: eth0: acknowledged x.x.x.100 from x.x.x.1
Jan 11 03:04:18 ServerName dhcpcd[1203]: eth0: leased x.x.x.100 for 86400 seconds
Jan 11 15:04:18 ServerName dhcpcd[1203]: eth0: renewing lease of x.x.x.100
Jan 11 15:04:18 ServerName dhcpcd[1203]: eth0: acknowledged x.x.x.100 from x.x.x.1
Jan 11 15:04:18 ServerName dhcpcd[1203]: eth0: leased x.x.x.100 for 86400 seconds
是的，这是选定的输出 - 我已经详细查看了 syslog 和 dmesg，如果需要可以提供更多信息，但我确信其中没有任何有价值的信息。 不这样做的原因是什么？ 我对在公共互联网上设置我的网络提供太多信息感到不安，清理输出很耗时。
答案1
问题解决了——不是 Unraid 服务器的问题，而是出乎意料的是，是一个电涌保护器的问题。
在我的网络设置中，我有一个高端电涌保护器，它将内部网络与外界隔离，因此在发生雷击/电涌时，我的昂贵设备受到保护。
关于为什么所有信息都表明它是文件服务器，说来话长，但简短的回答是：
- 文件服务器和互联网网关位于保护器的一侧，其他所有东西都位于另一侧
- 只有通过保护器的流量才会受到影响（因此，在 SP 同一侧互相 ping 的 2 台设备似乎没有出现任何问题）
- 对于大多数网络应用程序来说，每隔几分钟失去几秒钟的连接几乎是完全无法检测到的 - 只有在使用文件服务器时所需的高数据吞吐量才会使这个问题引人注目。
当我隔离网络硬件以确保问题出在文件服务器时，我从未想过要隔离这个特定组件（我几乎不认为它是网络硬件）。
我不知道它为什么会造成问题，但很明显它造成了问题。我暂时将它从网络中移除，无论如何它对系统来说都不是至关重要的。