fnOS升级后有线网口失联

防坑指南：fnOS/Docker 宿主升级换内核后「有线网口失联、备用口正常」（OVS 内部端口丢失）

适用场景：宿主通过 Open vSwitch 桥接物理网口（有线 IP 配在 OVS internal 口上）， 系统升级/换内核重启后，有线 IP 完全不通，但另一张网卡（WiFi/备用口）的管理页和 SSH 一切正常。本文以飞牛 fnOS 为例，适用于任何同构环境。 全部命令与输出均来自真实故障的定位与修复过程，可直接照抄执行。

1. 症状（对照自查）

2. 快速定位（5 分钟五步走）

第 1 步：确认物理链路没坏

1
2
3

cat /sys/class/net/<有线口>/carrier      # 应为 1（有载波）
cat /sys/class/net/<有线口>/speed        # 例如 1000
ethtool -S <有线口> 2>/dev/null | grep -iE 'error|drop' | head -4

载波=1、无错误计数 → 网线/交换机/网卡硬件没问题，问题在软件层，继续往下。

第 2 步：排除防火墙（很多人第一反应是防火墙，先排除掉）

1
2

sudo iptables -S | head -25
sudo nft list ruleset | head -25

判据：INPUT 链 policy 为 ACCEPT、且没有针对本机端口的 DROP/REJECT 规则 （若宿主跑了 Docker，只会看到 DOCKER 系列的 NAT/桥接规则——那是正常的，不拦 INPUT）。 本文案例的规则集里只有 Docker 标准规则，INPUT ACCEPT → 排除防火墙。

第 3 步：看网关 ARP（关键证据）

1

ip neigh show | grep '<有线网关IP>'

问题案例的实际输出：

1

<网关IP> dev <有线口>-ovs INCOMPLETE

网关 ARP 为 INCOMPLETE —— 物理口有载波却连二层都通不了， 说明包根本没从接口发出去/进来。这是「OVS 数据面丢端口」的典型信号。

第 4 步：检查 OVS 数据面（实锤）

1

sudo ovs-dpctl show

问题案例的实际输出：

1
2
3
4
5

system@ovs-system:
  lookups: hit:0 missed:181531 lost:181531
  flows: 0
  port 0: ovs-system (internal)
  port 1: <物理口>

两个异常一目了然：

1. 端口列表里只有物理口，没有 internal 口（本应同时有 port N: <物理口> 和 port M: <有线口>-ovs (internal)）；
2. missed/lost 计数暴涨（18 万+）——物理口收到的包没有去处，直接丢。

第 5 步：对照 OVSDB 配置与守护进程

1
2
3

sudo ovs-vsctl show                 # OVSDB 里的配置（桥和端口都在，看起来"正常"）
ps aux | grep -aE '[o]vs-vswitchd|[o]vsdb-server'
systemctl status openvswitch-switch --no-pager | head -8

问题案例：ovs-vsctl show 里桥和端口配置齐全、ovsdb-server/ovs-vswitchd 进程也在、服务显示 active——配置没丢，是数据面没有随新内核正确重建。

3. 根因

宿主（fnOS）系统更新触发换内核并重启后：

1. OVS 内核数据面（ovs-system）在新内核上重建；
2. 重建时只挂回了物理口，internal 口（有线 IP 所在的口）没有重新挂进数据面；
3. OVSDB 配置还在，所以 ovs-vsctl show 看起来一切正常；
4. 于是「配置正常、数据面缺端口」——有线口收到的包全部 missed → lost，有线 IP 完全失联；备用口不受影响。

触发条件：fnOS 升级 → 换内核版本 → 重启。重启一次未自愈， 再重启一次也未自愈（两次实测），说明是升级遗留的确定性问题， 等待官方修复前需手工恢复。

4. 修复（一条命令）

1

sudo systemctl restart openvswitch-switch

重启服务后 ovs-vswitchd 会把 internal 口重新挂进数据面。验证：

1
2
3
4
5
6
7
8

sudo ovs-dpctl show | grep -aE 'port|flows'
# 期望看到 internal 口出现，且 flows > 0：
#   flows: 19
#   port 1: <物理口>
#   port 2: <有线口>-ovs (internal)
ip neigh flush dev <有线口>-ovs 2>/dev/null; sleep 3
ip neigh show | grep '<网关IP>'      # 应变为 REACHABLE
ping -c 2 <网关IP>                    # 应通

实测：执行后 ARP 立即 REACHABLE，外部 ping/SSH 秒恢复。

5. 若重启服务后仍不通——检查 seed/内部口状态

如果 ovs-dpctl show 里 internal 口依旧缺失，或数据面反复异常：

1
2
3

# 把 OVS 数据面彻底清掉重建（会闪断一次该桥上所有端口，数秒恢复）
sudo ovs-dpctl del-dp ovs-system      # 数据面删除后 vswitchd 会自动重建
sudo systemctl restart openvswitch-switch

再不行，检查 fnOS 自身的网络管理服务是否正常 （fnOS 用 NetworkManager + dispatcher 管理 OVS 接口， journalctl | grep -aiE 'ovs|dispatcher' 可看启动期是否报错）， 必要时在 fnOS 网页管理端「网络」里对该接口做一次「重新配置/重连」。

6. 防复发与应急

1. 应急入口：给宿主保留第二张网卡（WiFi/USB 网卡均可，DHCP 即可）。 有线挂掉时，备用口的管理页/SSH 就是唯一入口——没有它只能接显示器键盘。
2. 每次换内核重启后，先 ping <网关> 验证有线口，不通就执行第 4 节命令。
3. 双默认路由的坑：有线与备用口各有一条默认路由时， 有线路由优先级更高（无 metric 默认最优先）。有线坏了以后系统仍优先走死路由， 这就是「时好时坏」的来源；需要时可在有线恢复后 ip route del default via <有线网关> dev <有线口>（重启失效，仅临时缓解）。
4. 向系统厂商反馈：升级换内核后 OVS 数据面未重新挂载 internal 口， 属于其网络服务在换内核场景下的缺陷。

7. 同宿主上连环踩到的其他坑（简要索引）

在同一台机器排查期间还确认了以下独立问题，详细过程见同目录其他文档：

8. 版本与证据时间线