LXD 桥接容器单节点网络时断时续排查实录：隐形 IP 冲突的坑-马春杰杰

故障现象

环境说明：Ubuntu 宿主机，LXD 容器采用 br0 桥接模式，接入10.170.0.0/16局域网，由上游网关提供 DHCP 服务。
核心现象：
- 容器autodl-150-2网络完全正常，能正常访问外网、解析 DNS；
- 容器autodl-150-1网络间歇性抽风，时通时断，表现为wget卡在Resolving解析阶段，ping 网关周期性丢包；
- 后续故障加重，容器完全 ping 不通网关，100% 丢包，但lxc ls偶尔能看到它获取到了 IP。
第一反应：之前踩过bridge-nf-call-iptables的坑：桥接模式下 iptables 会拦截二层广播导致 DHCP 失败，一开始以为是同类问题。可以看当时那篇文章：https://www.machunjie.com/linux/1883.html

排查过程

1. 排除全局桥接防火墙问题

首先按照之前的经验，关闭桥接层面的 iptables 钩子。执行的时候先遇到了第一个小问题：

1	sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-iptables: No such file or directory

原因是br_netfilter内核模块没有加载，先加载模块再设置：

modprobe br_netfilter

sysctl -w net.bridge.bridge-nf-call-iptables=0

sysctl -w net.bridge.bridge-nf-call-ip6tables=0

设置完成后测试，故障容器依然无法联网。

这里得到第一个关键结论：bridge-nf导致的是全量故障，所有接在 br0 上的容器都会拿不到 DHCP、完全断网。现在一个容器正常一个异常，说明网桥本身、物理链路、上游网关都是好的，问题 100% 集中在故障容器自身的链路上，可以直接排除全局配置问题。

2. 三层路由正常，定位到二层链路

进入故障容器，先检查最基础的 IP 和路由配置：

ip route

输出完全正常：默认网关指向10.170.255.254，走 eth0 网卡，同网段直连路由也存在。但 ping 网关 100% 丢包，ping 同网段其他设备也不通。

这说明三层 IP 配置没有问题，故障出在二层数据链路层 —— 也就是 ARP 解析、虚拟网卡、网桥端口这一段。

3. 虚拟链路检查：veth 和网桥都正常

LXD 容器通过 veth 虚拟对端接口接到网桥上，先确认这一段有没有问题。

首先通过容器 PID 找到对应的宿主机侧 veth 接口，查看接口状态：

1	ip -s link show vethfea7bc5c

接口状态为UP，收发数据包正常，没有 errors、dropped 错误包。再确认网桥端口状态：

1	bridge link show master br0

对应的 veth 接口已经加入 br0，状态为forwarding，网桥转发正常。

到这里，虚拟网卡链路、网桥转发都排除了故障。

4. ARP 与 IP 冲突：最容易误判的环节

首先用常规方法检测 IP 冲突，在宿主机 br0 网桥上执行 arping：

1	arping -I br0 10.170.1.97 -c 5

只返回了容器自身的 MAC 地址，和lxc config show查到的容器 MAC 完全一致。当时初步判断：没有 IP 冲突。

接着用 tcpdump 抓包验证：

1	tcpdump -i br0 -nn host 10.170.1.97 and \(arp or icmp\)

抓包结果很有意思：能看到容器发出的 ARP 请求、ICMP echo 请求，也能看到网关的 ARP 回应，但完全看不到网关的 ICMP echo 回应。

ARP 能通，说明二层可达；ICMP 发出去没回应，说明网关的回包没发到容器这里。结合「时断时续」的初始现象，矛头又指向了 IP 冲突。

5. 关键验证：换 IP 一步定位

常规 arping 没查出冲突，不代表真的没有冲突。很多设备会屏蔽 ARP 广播请求，但依然会发送免费 ARP 篡改网关的 ARP 缓存。

直接用替换法验证：给容器临时换一个全新的 IP，测试连通性。

# 容器内执行

ip addr add 10.170.1.200/16 dev eth0

ip addr del 10.170.1.97/16 dev eth0

ping 10.170.255.254 -c 3

换 IP 之后，ping 网关立刻 100% 通，网络完全恢复。

实锤结论：原 IP 10.170.1.97存在隐性 IP 冲突。局域网内有另一台设备也在使用这个 IP，它不响应 arping 探测，但会周期性更新网关的 ARP 表，导致网关的回包时而发到容器、时而发到冲突设备，表现为「网络一会有一会没有」。

6. 静态 IP 持久化：又踩了 netplan 的坑

为了避免容器重启后重新拿到冲突 IP，需要配置静态 IP 持久化。容器是 Ubuntu 系统，默认用 netplan 管理网络

进入容器，编辑 netplan 配置文件：

cd /etc/netplan

ls # 查看配置文件名，通常是 00-installer-config.yaml 或 50-cloud-init.yaml

nano 00-installer-config.yaml

写入静态 IP 配置（替换为你的网段参数）：

network:

ethernets:

eth0:

addresses:

- 10.170.1.200/16

routes:

- to: default

via: 10.170.255.254

nameservers:

addresses:

- 10.170.255.254

- 114.114.114.114

version: 2

应用配置并验证：

netplan apply

ip addr show eth0

ping 10.170.255.254 -c 3

编辑好配置执行netplan apply时出现报错：

1 2	Failed to send reload request: No such file or directory subprocess.CalledProcessError: Command '['udevadm', 'control', '--reload']' returned non-zero exit status 1.