6.12.4 关于失联问题的解决办法以及相关更新说明

type

status

date

slug

summary

1. 回顾：macvlan call traces 问题是什么

简单来说就是当管理网口 eth0 开启了“桥接”功能，并且“Docker 的自定义网络类型”中使用了 macvlan 之后（如下图），就会有几率造成内核报错并且无法访问 Unraid —— 也就是常说的“失联”问题。

但是也要说明的是，“失联”只是一个表面现象，并不是所有无法访问 unRAID 的情况都是由于这里的 macvlan call traces 问题所造成的。根据官方 6.12.4 版本的更新说明，此 BUG 可能会存在比较长一段时间（文章末尾会加以说明）。

在 6.12.4 版本之前，一般推荐的解决办法是：

方法一：将“Docker 的自定义网络类型”由 macvlan 更换成 ipvlan （这也是为什么从 6.11.5 版本开始，默认“Docker 的自定义网络类型”使用的是 ipvlan ）。但是 ipvlan 也可能会引发其他的问题，比如说有可能你的路由器不兼容这种模式，从而导致 unRAID 无法正常联网或者导致路由器某些功能无法正常使用（如端口转发、其他一些高级网络控制功能等）。

方法二：使用第二个网口来给到 docker 容器使用，更具体的信息可以看我之前写的《unRAID 失联问题解析（以及如何给Docker分配独立网口）》文章。

2. 问题的根本原因

首先，官方是这么描述此问题的：

The root of the problem is that macvlan used for custom Docker networks is unreliable when the parent interface is a bridge (like br0), it works best on a physical interface (like eth0) or a bond (like bond0). We believe this to be a longstanding kernel issue and have posted a bug report.

大意是指，如果 macvlan 用于 Docker 自定义网络，那么：

当 macvlan 是建立在桥接网络（比如说 br0 ）而不是物理网卡（如 eth0 或者绑定接口 bound0 ），那么网络会因此变得不稳定，从而可能会造成现失联的情况。

如果说 macvlan 是建立在物理接口上（如 eth0 或者绑定接口 bound0 ），那么不会有此问题。

这也是为什么先前官方在针对此问题的解决办法中，会建议用户去使用第二个网口给到 Docker 去使用，因为 macvlan 可以建立在第二个物理网口上，而不需要牺牲 eth0 的 br0 网络。

3. 新版本是如何解决的

3.1 方法步骤

解决方法很简单，根据官方的说明，步骤如下：

注意：Unraid 上要修改网络设置需要停止阵列（或者同时在设置中关闭 Docker 与虚拟机服务）。

设置 → 网络设置 → eth0 → 关闭“桥接”功能：

设置 → Docker → 开启“主机访问自定义网络”：

然后在“接口上 IPv4 自定义网络 eth0 (可选)”上配置自定义网络，如下：

注意： 如果你先前通过使用第二个网口的方式来处理此问题，那么在新版本中你可以不再对第二个网口配置 Docker 的自定义网络了。当然，你也可以继续使用第二个网口，但如果你已经对第一个网口配置了自定义网络，比如下图中的 10.0.0.0/24 ，那么第二个网口设置网段时不能使用同样的网段，不然是无法正常使用的。

以上方式就是 6.12.4 版本官方提供的解决办法。

需要额外补充的是，在 6.12.4 版本，当你在 eth0 上关闭了桥接功能之后，“Docker 的自定义网络类型” 会自动设置为 macvlan ，并且“Docker 的自定义网络类型”设置会被隐藏，比如下图：

如果你使用的是 > 6.12.4 版本，则不会隐藏。

关掉了 eth0 的“桥接”功能之后，“Docker 的自定义网络类型”选项就被隐藏了 — 关掉了 `eth0` 的“桥接”功能之后，“Docker 的自定义网络类型”选项就被隐藏了

除非你在第二个网口上开启桥接功能，不然“Docker 的自定义网络类型”不会被展示（自然也就没有 ipvlan 的选项可以设置）。

3.2 如果我需要在 `eth0` 上保留桥接功能

在上面介绍的解决办法中，我们需要去关闭 eth0 网口上的桥接功能，但如果说我日常使用中必须要用到 eth0 的桥接网络，那么你依然可以按照之前的的解决办法去应对 macvlan call traces 问题，即：

将 macvlan 改为 ipvlan；

或者使用第二个网口给到 Docker 去使用，即我博客另一篇文章的解决办法。

3.3 `vhostX` 虚拟网卡信息

需要在补充的是，当 eth0 关闭了桥接功能之后，虚拟机可用的虚拟网卡就变为 vhost0 。

在先前的版本中，如果网络设置中没有开启桥接功能，那么虚拟机就没有虚拟网络设备（ brX ）可以使用，如下图所示：

关闭桥接功能后，虚拟机的虚拟网络只剩下 virbr0 可以使用 — 关闭桥接功能后，虚拟机的虚拟网络只剩下 `virbr0` 可以使用

但在 6.12.4 版本中关闭了桥接功能之后，unRAID 会自动创建一个叫做 vhostX 的虚拟网络设备网，如下图所示：

我有两个网口可供 Unraid 使用，所以会有两个 vhost 虚拟网卡。 — 我有两个网口可供 Unraid 使用，所以会有两个 `vhost` 虚拟网卡。

根据官方的说明，当关闭网络设置中网卡的桥接功能之后，unRAID 会自动创建一个 macvtap 虚拟网络给到 Docker 和虚拟机使用，vhostX 虚拟网卡所使用的网络也就是 macvtap 。

由于 macvtap 是基于物理的 ethX 接口（而不是 brX ），因此并不会存在 macvlan call traces 问题，并且官方还说明 macvtap 网络要比 bridge（ brX ）网络速度更快，换句话说你与 Docker 或虚拟机的连接速度更快了。

macvtap 基于 macvlan，是对 macvlan 的改进。
参考：网络虚拟化技术（二）: TUN/TAP MACVLAN MACVTAP ，Using the MacVTap driver

你可以通过 ethtool 命令可以查看 vhostX 虚拟网卡的信息，可以看到这个虚拟网卡是使用 macvtap 驱动（ macvlan ）创建出来的：

3.4 使用 `vhost0` 网络的虚拟机无法访问 Unraid 情况的说明

图片里面的 vhost0 对应物理网卡 eth0 ，为了方便说明一律认为 eth0 是 unRAID 的管理网口。

如图所示，在虚拟机使用 vhost0 网络的情况下你会发现虚拟机里面无法访问 Unraid，其实这个情况是可预料到的。

前面说过 vhost 网络基于 macvlan ，而之所以虚拟机无法访问 unRAID 就是由于 macvlan 的底层安全机制所导致，而这一机制在设计之初就是这么有意而为之，因此使用 vhost0 的虚拟机无法访问 unRAID 是意料之中。

如果希望虚拟机也可以访问 unRAID 宿主机，那么你可以采取以下两个方法的其中一个：

对于只有一个网卡的情况：如果你希望虚拟机也能够访问 unRAID，那么需要开启 eth0 网卡的桥接功能，不然的话就会有上面说到的无法访问 unRAID 的情况。开启桥接功能之后，虚拟机使用 br0 网络的情况下就会与 unRAID 同处内部的同一个虚拟交换机上（vSwitch），此时虚拟机就可以正常访问 unRAID 宿主机。

如果你有两个网卡或两个以上的网卡：那么你可以使用除了 eth0 之外的 vhost 网络（例如 vhost1 ），而此时由于不存在 macvlan 的安全机制限制，所以可以正常访问 unRAID 。

再啰嗦一句，实际上 macvlan 这一安全机制也会导致使用了 macvlan 网络的那些 docker 容器出现和 unRAID 无法互相访问的情况：

Custom：br0 也是基于 macvlan — `Custom：br0` 也是基于 macvlan

所以不少刚开始使用 unRAID 的朋友会发现，unRAID 上其他没有使用 Custom：br0 网络的 docker 无法访问使用了 Custom：br0 的 docker ，那么其中的原理与上面的虚拟机案例是一样的 —— 都是由于 macvlan 的底层安全机制所导致。而 unRAID 为了解决此问题专门提供了一项 docker 设置 —— “主机访问自定义网络（Host access to custom networks）”，开启此功能之后就可以解决上述问题：

只不过虚拟机服务并没有类似的设置，所以这种情况下虚拟机无法访问 unRAID 。

3.5 问题排查

上述的解决办法由于对 Docker 和虚拟机的网络有了变更，因此可能会对原有的 Docker 容器或者虚拟机产生一些影响。

根据官方的说明，如果你遇到以下问题，可以根据以下办法解决：

如果使用了固定 IP 地址的容器无法启动，那么你可以尝试修改 Docker 容器的自定义网络为 Custome : eth0 并填写上原先的 IP 地址，然后重新创建容器。

如果原有的虚拟机无法启动，那么请将虚拟机的“网络资源”修改为 vhostX ，并保证虚拟机分配有 MAC 地址：

如果 WireGuard 没有启动，那么你可以随意改一下参数然后再还原修改了的配置（dummy change），最后重新应用即可。

如果遇到转发给 Docker 容器的端口不生效，那么你需要在路由器上在删掉原来的端口转发再重新创建。

4. 新增：System Drivers（系统驱动）页面

新版本增加了一个系统驱动显示界面，用于显示目前 unRAID 系统可用/正在使用的驱动。

除了系统自身的驱动之外，System Drivers 页面还会显示通过第三方插件安装的驱动（例如 Nvidia 插件或者Realtek 插件等所安装的显卡驱动或者 Realtek 网卡驱动），并且这一类驱动会有一个小图标用于跳转到插件对应的支持页面。

此页面的作用在于，除了提供信息展示之外，还可以直接对此驱动的相关参数进行修改。

5. 补充：macvlan call traces 问题可能会长期存在

macvlan call traces 问题被用户诟病已久，但此问题或许并不是 unRAID 独有，官方也已经在8月8日的时候向 bugzilla 提交了内核 BUG ：

We believe this to be a longstanding kernel issue and have posted a bug report.

6. 最后：失联问题是复杂的

最后再啰嗦几句，造成 unRAID 失联的原因在不同的硬件和系统环境下会有所不同，并没有一个统一的解决办法。失联问题是挺恼人的，但也希望大家辩证的看待此问题，毕竟你可以通过论坛或者我来寻找帮助。

7. 2023-09-21：因 IPV6 导致的“失联”问题

在博主的《unRAID macvlan 失联问题解析（以及如何给Docker分配独立网口）》文章中，作者还补充了一个关于 IPV6 导致的“失联”问题。

但实际上并不是失联，而是因 IPV6 导致了 unRAID 的 Nginx 服务运行不正常从而无法访问 WebUI 界面，但其他服务例如 Docker、虚拟机等运行是正常的，具体的问题现象和解决过程的详细说明请查看上面的文章链接。

除了我上面这个文章里面的这个案例，unRAID 官方论坛中也出现了因 IPV6 而出现无法访问 WebUI 的情况：

解决办法也是选择关闭 IPV6 或者重启 Nginx 服务。

unraid竟然失联了

一直用的好好的，庆幸我的4125兼容真的好，网说的什么问题都没碰到，今天想看看unraid状态，webui竟然进不去……，一切服务都没问题，也能ping通，机器倒是好久没重启过，难道是没有ecc，积累性错误导致？？？？我倒要看看就是不重启，最后能不能死机！unraid6.12.3

https://forums.unraid.net/topic/145261-unraid竟然失联了

1. 回顾：macvlan call traces 问题是什么

2. 问题的根本原因