Linux工控机双网卡路由优先级冲突？systemd-networkd Metric配置全解析

年前在车间调试一台 Linux 工控机时碰到了一个非常典型的问题机器上同时装了有线无线双网卡板载网口接着 PLCUSB 无线网卡连着现场 Wi-Fi设备看着一切正常可采集程序的上位机偶尔就掉线严重的时候干脆连不上。查到最后问题出在路由表里的两条默认路由在“打架”——系统不知道该优先走哪张网卡出去。这类Linux 工业计算机有线无线双网卡路由优先级冲突在 AGV、机器人控制、边缘网关和产线改造项目里出现频率极高解决办法就是通过systemd-networkd 的 Metric 配置把出站路由按优先级固定到正确的接口上。这篇文章把我当时的排查思路、完整配置过程和踩过的坑整理出来适合搞设备集成、嵌入式 Linux 开发和产线运维的读者参考照着配就能避免大多数双网卡“莫名其妙丢包”的尴尬。1. 双网卡到底哪里冲突了一次现场故障的完整复盘1.1 从“偶尔丢包”到“干脆连不上”的故障曲线那台工控机跑的是 Debian板载千兆网卡连的是工厂骨干网络这个骨干网里有 PLC 的子网也能出外网另一个 USB 无线网卡连的是办公区的无线 AP同样能上外网。设备上的数据采集程序要往 PLC 侧写点位同时又要通过无线网络把数据报到 MES 服务器。现象一开始不明显只是偶尔有几次 ping 外部 IP 会超时后来变成访问 PLC 也时通时断到最后 SSH 远程上去都频繁断连。我先在工控机上执行ip route show一看就明白了路由表里出现了两条默认路由一条走有线一条走无线系统在它们之间来回摇摆。工业协议对链路连续性本来就敏感EtherNet/IP、Modbus TCP 这类连接哪怕出现几百毫秒的抖动都可能导致会话超时。所以这个故障不是“网速变慢”而是连接被反复重置上位机自然会频繁报错。1.2 两条默认路由带来的“访问分裂”用ip route get 目标IP可以很清楚地看到系统选路的实际结果。我当时执行ip route get 192.168.10.2返回的是从无线接口出去可 PLC 的 192.168.10.2 只有有线网口那条链路才通。报文被扔给了无线网关网关查不到 192.168.10.x 的路由直接丢弃怎么可能不丢包。再深入看问题不止“默认路由选错”这么简单。TCP 是双向的出站走了无线回包却从有线回来Linux 看到源地址与预期不符连接就会被当成异常丢掉。这就是为什么程序表现是“时而正常、时而失败”——它取决于当时内核哈希选路的瞬间状态。另一个隐蔽点是很多工业设备发现协议依赖广播比如某些 PLC 的 UDP 广播搜索。双网卡场景下广播包只会从某个接口发出如果控制器和上位机不在同一个广播域设备直接“消失”在工具列表里。1.3 我一开始也试过的“土办法”为什么都不靠谱排查时我顺手试过几种临时措施结果都不理想。第一种是手动删掉无线的那条默认路由ip route del default dev wlan0当时确实立刻恢复了但网卡重启、NetworkManager 或 networkd 重新加载后路由又回来了。第二种是改 DHCP 的获取顺序希望有线先拿到默认路由、无线后拿到。听起来有道理但 USB 无线网卡的驱动探测速度和 DHCP 事务时间都不受控实测结果很不稳定经常这次有效下次失效。还有的人直接拔无线网卡或者ip link set wlan0 down。这在现场调试时是最后的应急手段但它把远程维护通道也断了——真到了设备在产线上跑着需要远程改参数的时候你反而进不去。这些办法都没从根上解决“系统为什么选路错误”所以我才决定认真处理路由优先级。2. 路由优先级的内核逻辑metric 数字才是真正的“裁判”2.1 内核收到一个 IP 包后先做什么一个数据包从应用层发出来内核要做的第一件事是查路由表决定“从哪个接口出去、下一跳是谁”。查表时先做最长前缀匹配比如目标是 192.168.10.2匹配到 192.168.10.0/24 这条直连路由就不会去理会默认路由 0.0.0.0/0。所以直连子网的访问一般不会错真正的竞争发生在两条 0.0.0.0/0 同时存在的时候。默认路由是在没有任何更具体路由命中时才使用的“兜底出口”。如果系统里有多个接口都拿到了默认路由内核不能靠猜它必须有一个明确的规则来决定先后。这个规则就是 metric也叫 priority。2.2 metric 数字越小优先级越高metric 的规则很简单数值越小优先级越高。举个例子有线网卡的默认路由 metric 是 100无线的默认路由 metric 是 600那么访问任何没有更精确路由的目标内核都会优先走有线。这个机制的价值在于你不需要删掉任何一条路由只需要给它们排好优先级。主链路正常工作时的流量全走主链路主链路物理断开时内核删掉对应接口的路由自动落到备用链路上整个过程不需要人为干预。但要注意如果两条默认路由的 metric 完全一样内核可能会启用等价多路径ECMP把流量哈希分散到两条链路上。对于工业场景这通常是灾难性的因为两条链路的延迟、带宽、可达范围都不一样哈希到哪条完全不可控。所以无论如何都要保证 metric 数字不一样。2.3 systemd-networkd 里 Metric 的两个入口位很多人搞混配置 systemd-networkd 时Metric 可以在两个地方出现作用完全不同。第一处是[Network]段的Metric它管的是该接口动态获取到的路由典型就是 DHCP 下发的那条默认路由。第二处是[Route]段里的Metric它管的是你自己手写的静态路由。下面这个表可以帮你快速确认该写在哪里使用场景配置位置作用对象DHCP 自动获取的路由[Network]段Metric该接口通过 DHCP 拿到的默认路由手动指定的默认路由[Route]段Destination0.0.0.0/0Metric本文件里定义的那条静态默认路由普通静态子网路由[Route]段DestinationMetric本文件里定义的具体路由我见过不少同事把 Metric 写在[Network]段结果静态 IP 场景下完全不生效其实是因为静态默认路由要走[Route]段。两种写法本身都不难难的是分清自己正处在哪个场景。3. 稳定复现的 Metric 配置有线优先、无线兜底全流程3.1 开工前必查当前到底是谁在管网卡动手写配置前先确认这台机器上到底是谁在做网络配置。执行下面三条命令systemctl status systemd-networkd systemctl status NetworkManager networkctl list如果systemd-networkd是 active 状态且NetworkManager没有接管网卡那本文的配置方式直接适用。如果系统用的是 NetworkManagernetplan或者ifupdown需要先做一层转换不然配置会被其他服务覆盖。Ubuntu Server 或 Debian 的很多环境默认底层就是 systemd-networkd但桌面版 Ubuntu 默认是 NetworkManager别搞混。你可以在networkctl list看到当前纳管的接口列表确认网络栈归属后再继续。3.2 有线网卡 DHCP 场景配置Metric100假设有线网卡叫enp3s0采用 DHCP 获取地址配置文件放在/etc/systemd/network/10-wired.network[Match] Nameenp3s0 [Network] DHCPyes Metric100这里的Metric100会直接作用于 DHCP 自动获取的默认路由。只要无线侧的 metric 比它大比如 600外网流量就会优先走有线。在纯 systemd-networkd 环境里配置文件加载顺序由文件名前缀决定建议用数字前缀明确顺序方便后续维护时一眼看出优先级。10-wired.network和20-wireless.network这种命名比eth0.network、wlan0.network更容易管理。3.3 有线网卡静态 IP 场景配置关键在[Route]段很多工控机为了离线也能稳定通信会选择给有线网卡配静态 IP。此时不要在[Network]段写Gateway而是明确用[Route]段定义默认路由和 metric[Match] Nameenp3s0 [Network] Address192.168.10.10/24 [Route] Destination0.0.0.0/0 Gateway192.168.10.1 Metric100这么写的理由是对于手写的静态路由[Network]段的Metric管不到它必须把 metric 放在这条路由自己的[Route]段里。如果你同时有有线静态 IP 和无线 DHCP那有线的静态默认路由用上面的写法无线 DHCP 默认路由用[Network] Metric600两者就能正确排序。3.4 无线网卡配合 wpa_supplicant 给出更高的 metricsystemd-networkd 本身不处理 Wi-Fi 的 WPA 认证需要配合 wpa_supplicant。给无线网卡wlan0建配置文件/etc/systemd/network/20-wireless.network[Match] Namewlan0 [Network] DHCPyes Metric600只要 wpa_supplicant 正常关联上 APnetworkd 就会为 wlan0 获取 IP 并生成默认路由这条路由的 metric 是 600。至此有线默认路由 metric 100、无线默认路由 metric 600优先级关系就明确了。如果无线网卡名称在重启后可能变化建议[Match]里用 MAC 地址比如MACAddress00:11:22:33:44:55。原因后面会单独讲这里先记住工业现场网卡名漂移很常见能锁 MAC 就锁 MAC。3.5 应用配置并逐条验证路由行为改完配置执行下面的命令让它生效systemctl daemon-reload networkctl reconfigure enp3s0 networkctl reconfigure wlan0然后逐条验证ip route show ip route get 192.168.10.2 ip route get 8.8.8.8预期结果是目标 8.8.8.8 的默认流量先走有线如果此时把有线网卡 down 掉再查ip route get 8.8.8.8系统应该自动落到无线。这个验证动作能帮你确认 metric 是否真的在起作用而不是只看配置文件写没写对。我在调试时会开两个终端一个不断 ping 目标地址另一个反复执行ip route get 目标地址观察出口是否有跳变。一旦出口稳定指向预期接口说明路由优先级问题已经解决比盲目抓包高效得多。4. 工业现场的高阶玩法策略路由、主备切换与不对称路由4.1 用 RoutingPolicyRule 强制指定子网出口有些场景不满足于“默认走有线”而是要求“某些目的地址必须走某个接口”。比如摄像头子网 10.20.0.0/16 只能从有线侧访问而云平台流量必须从无线侧走。单靠 metric 做不到这种细粒度控制需要策略路由。在 systemd-networkd 里可以用[RoutingPolicyRule]段关联独立路由表。先给有线接口单独维护一张表比如表 100[Match] Nameenp3s0 [Network] DHCPyes Metric100 [RoutingPolicyRule] To10.20.0.0/16 Table100 [Route] Destination10.20.0.0/16 Gateway192.168.10.1 Table100 Metric100这里的意思是凡目的地址落在 10.20.0.0/16 的流量内核先去查找表 100而不是主路由表。表 100 里的那条路由把它交给 192.168.10.1也就是从有线侧出。这样即使主路由表默认走无线也不会影响摄像头子网的访问。策略路由复杂度明显上升排查问题时要记得ip rule show查看规则的匹配优先级。4.2 主备链路切换link down 能切网关故障怎么办默认情况下如果主链路只是物理断开内核会把对应接口的路由删掉自动启用备用链路的默认路由因为 metric 600 的路由还在。但有一种更隐蔽的情况主链路网卡还活着网关却已经不通了。这时内核不会自动切换因为路由条目还在它也感知不到网关的连通性。解决办法是自己做健康检查。简单思路是写一个脚本定时 ping 主网关连续几次失败就把默认路由临时替换到备用链路上恢复后改回。systemd-networkd 本身没有内置这种自动切换所以多数工业网关项目会额外加一个连通性检测服务。我写过一个简化版本供参考#!/bin/bash if ! ping -c 3 -W 1 192.168.10.1 /dev/null 21; then ip route replace default via 192.168.1.1 dev wlan0 metric 50 else ip route replace default via 192.168.10.1 dev enp3s0 metric 100 fi注意 metric 50 是临时的让备用路由比有线默认路由优先级更高。等主链路恢复后再把默认路由拨回 100。这种做法本质是“软件心跳路由切换”适合对成本敏感、没有双机冗余的现场设备。4.3 rp_filter 对双网卡流量的影响双网卡场景下还可能遇到一个隐蔽的丢包原因Linux 的反向路径过滤rp_filter。它的默认逻辑是检查“进来的包源地址是否从同一个接口出去”如果不是就认为包可疑并丢弃。当两个网卡存在不对称路由时——比如出站走无线、回包走有线——rp_filter 就会丢包。很多人在 metric 配对了之后发现仍然不通十有八九是这个原因。如果确认路由本身设计上就可能不对称可以把 rp_filter 调整为宽松模式sysctl -w net.ipv4.conf.all.rp_filter2 sysctl -w net.ipv4.conf.default.rp_filter2一般工业设备访问是“同一个目标始终走同一个接口”不会触发不对称所以默认值也能跑。但如果你改了策略路由、加了备用路径之后开始丢包优先检查一下 rp_filter。5. 实测踩坑清单这些坑我一个个填过5.1 改了配置没有 daemon-reload白忙活一场systemd-networkd 的配置不是改完立即生效的需要先systemctl daemon-reload重新加载服务单元再networkctl reconfigure。我一开始直接在虚拟机上改完就敲systemctl restart systemd-networkd发现路由没变还以为是配置语法错了后来才发现是没 reload 导致旧配置还在缓存里。按这个顺序执行基本不会出错systemctl daemon-reload systemctl restart systemd-networkd或者更精确地只重配某个接口networkctl reconfigure enp3s05.2 用网卡名匹配网卡重启后被 USB 网卡“偷走”工控机经常用 USB 转网口或者 USB 无线网卡这类设备的接口名在重启后可能漂移。今天叫wlan0插拔一次变成wlan1的情况并不少见。如果.network文件里[Match]写的是Namewlan0下次开机它可能就匹配不到正确的物理设备了。解决方法是优先用 MAC 地址匹配[Match] MACAddress00:11:22:33:44:55 [Network] DHCPyes Metric600在写配置前先用ip link把每个接口的 MAC 记下来。这样即使设备名字变了networkd 也能准确对上物理网卡。5.3 NetworkManager 和 systemd-networkd 并存路由被来回改有些精简的工业 Linux 发行版会同时装了两套网络管理工具或者你手工启用了 systemd-networkd但 NetworkManager 还在运行。两套工具都可能管理同一个接口导致配置互相覆盖路由表一会儿按 A 的配置、一会儿按 B 的配置现象特别像“网络抽风”。处理方式很直接选一个负责到底。如果走 systemd-networkd 路线就把 NetworkManager 对相应接口的管理停掉或者直接禁用服务systemctl disable --now NetworkManager如果业务还需要 NetworkManager 管理其他设备至少要确保同一接口不会被两个服务抢占。5.4 Wi-Fi 重新关联后metric 行为“回退”无线网卡在漫游、重启 wpa_supplicant 或重新关联 AP 之后会重新跑一遍 DHCP路由也会重新生成。如果配置里没有显式写 metric系统很可能回到默认值之前设置好的优先级一夜回到解放前。所以无线网卡的.network文件里Metric一定不能漏。这也解释了为什么工业场景下我最推荐把 metric 写进文件而不是依赖工具默认值——默认值会因为版本、DHCP 服务器选项等因素变化显式配置才可预期。5.5 IPv6 的默认路由也有自己的一本账很多人只调 IPv4忘了 IPv6。如果工业系统开启了 IPv6接口收到路由通告RA后也会生成默认路由而且这个路由的优先级是另一套逻辑不直接受[Network] Metric完全控制。在 systemd-networkd 里可以为 IPv6 的路由通告单独设置 metric比如[IPv6AcceptRA]配合RouteMetric。如果你的现场网络需要用 IPv6 访问外部服务建议在验证清单里加一项ip -6 route show别让 IPv4 修好了、IPv6 又出岔子。6. 现场交付时我会顺手做掉的几件小事双网卡路由配置调通之后我一般会顺手把网络配置纳入交付脚本而不是只靠人肉记忆。道理很简单现场的设备不一定只有这一台同一套系统的配置应该可复现。把.network文件和 wpa_supplicant 配置一起放进部署目录下次遇到同样型号的设备直接铺过去就能用。调试过程中ip route get是我用得最多的命令配合watch -n 1 ip route show能实时看到路由表变化。还有一个技巧是改用journalctl -u systemd-networkd -f跟踪 networkd 的日志它会直接告诉你哪个接口 DHCP 什么时候完成、哪条路由什么时候被添加省去很多猜谜时间。最后提醒一下如果这套配置是交付给客户现场的记得把“metric 数值含义”写进维护文档注明哪条是主链路、哪条是备用链路以及“metric 越大优先级越低”这个规则。我见过不止一次后续维护人员把 metric 数字调反结果主备关系颠倒故障排了一整天。配置本身不难难的是让下一个接手的人不至于踩同样的坑。