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

如需技术支持，请点击 👉 联系方式

2023-11-1 补充：博主单独写了一篇如何给 Docker 自定义网络绑定其他物理网口的方法：《新手教程：将 Docker 的自定义网络绑定到第二个网口》，你可以参考这一文章以及本文内容去了解如何给 Docker 使用除了管理口之外的其他物理网卡的方法。

8月31日，Unraid 发布了 6.12.4 版本（更新说明），这个版本新增的内容主要有以下三个部分：

修复 macvlan call traces 问题：也就是因 macvlan 网络所导致的 unRAID 失联问题。

新增 System Drivers page 驱动列表（ “工具 - System Drivers” ）。

BUG 修复以及其他优化。

本文重点说明一下新版本对 macvlan call traces 问题（失联）的修复。

博主在7月初的时候写过一篇《unRAID macvlan 失联问题解析（以及如何给Docker分配独立网口）》，主要介绍了如何使用第二个网口去解决 macvlan call trace 问题，如果你不打算升级到 6.12.4 版本，你可以按照这个文章的方法去解决此问题。

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）”，开启此功能之后就可以解决上述问题：