ARP冲突本质是局域网内多设备占用同一IP，导致本机ARP缓存被错误MAC覆盖、发包走错二层路径；排查核心是快速定位冲突源而非仅清缓存，可通过ip neigh show查异常、tcpdump抓多MAC应答、dmesg查duplicate日志5秒确认，再用arping交叉验证、交换机MAC表精确定位，最后清理条目、静态绑定关键IP并启用arp_ignore/arp_announce防护。
ARP 冲突导致 IP 失效，本质是局域网内多个设备用了同一 IP，让本机 ARP 缓存持续被错误 MAC 覆盖，进而发包走错二层路径——表面看是“IP 不通”，实际是“MAC 不对”。排查重点不是清缓存，而是快速定位冲突源并阻断污染。
一眼识别冲突是否存在
执行以下三步，5 秒内确认是否真有冲突：
-
查本地 ARP 表异常：运行
ip neigh show，若同一 IP（如网关或目标服务 IP）反复出现不同 MAC，或状态频繁在REACHABLE/FAILED间跳变，基本可判定冲突 -
抓 ARP 流量验证：用
tcpdump -i eth0 arp -n（替换为实际网卡），观察是否对同一 IP 有多台设备同时应答（如连续收到 “192.168.1.100 is at aa:bb:cc:dd:ee:ff” 和 “192.168.1.100 is at 00:11:22:33:44:55”） -
查内核日志线索：运行
dmesg | grep -i "duplicate\|arp"，若看到IPv4: duplicate address detected!或gratuitous ARP提示，说明内核已捕获冲突事件
精准定位冲突设备（不靠猜）
别在本机上瞎试，用外部视角交叉验证：
-
从另一台同网段 Linux 主机执行 arping：例如
sudo arping -c 3 192.168.1.100。若返回多个不同 MAC 的 reply，说明该 IP 确实被多台设备占用 -
比对本机真实 MAC：在问题主机上运行
ip link show eth0 | grep link/ether，记下本机 MAC；再对比 arping 返回的 MAC，找出那个“多出来的” -
查交换机 MAC 地址表（最可靠）：登录同网段接入交换机，执行
show arp | include 192.168.1.100（华为）或show arp | grep 192.168.1.100（Cisco），再查该 IP 对应的 MAC 所在物理端口，顺藤摸瓜找到物理设备
临时止血 + 防复发设置
定位到冲突源后，先保业务，再防再犯：
-
立即清理污染条目：只删问题 IP，不全清——
sudo ip neigh del 192.168.1.100 dev eth0，再ping -c 1 192.168.1.100触发重新学习 -
关键设备做静态绑定：对网关、DNS 等核心 IP，加永久 ARP 条目：
sudo ip neigh add 192.168.1.1 lladdr 00:11:22:33:44:55 dev eth0 nud permanent -
启用内核防护（尤其多网卡环境）：设
arp_ignore = 1和arp_announce = 2到具体网卡，防止本机响应非本接口的 ARP 请求，避免成为冲突放大器
根治要回溯源头
ARP 冲突只是表象，背后一定是配置失控：
- 检查 DHCP 服务器租约池，确认是否与静态 IP 段重叠
- 排查虚拟机、Docker 容器是否克隆后未重置网络标识（常见于模板部署）
- 核查办公网是否有员工私接无线路由器并开启 DHCP，造成地址池污染
- 若为手动配置 IP，建立 IP 地址分配台账，并在交换机侧启用 DHCP Snooping + DAI 防御
