Linux ip neigh 怎样判断邻居表中的 FAILED 状态

如果 Linux 的 ip neigh show 里出现 FAILED，先不要把它直接等同于“远端主机宕机”。这个状态更准确的含义是：内核为邻居地址发起解析和探测后，仍没有得到成功确认。排障重点应放在目标路由、实际网卡、网关或同网段链路，而不是先清空整张邻居表。

这篇文章用一个具体场景拆开判断：服务访问失败时，先确认目标由谁承载，再看邻居状态属于暂时未解析还是最终失败，最后用网关和同网段主机的对照结果缩小范围。

FAILED 和 INCOMPLETE 分别说明什么

ip neigh 管的是协议地址与链路层地址之间的邻居绑定。IPv4 场景通常对应 ARP，IPv6 场景则对应邻居发现。FAILED 不是应用层返回码，而是 NUD 状态：探测次数达到上限仍未成功；INCOMPLETE 则表示解析尚未完成。

# 先看当前内核邻居表，确认目标地址、网卡和状态
ip neigh show

# 只筛选已经判定为失败的邻居条目
ip neigh show nud failed

# 把观察范围限制到实际承载流量的网卡
ip neigh show dev eth0 nud failed

排障时可以把状态先分成三类：INCOMPLETE 表示仍在解析，PROBE 表示正在探测，FAILED 表示本轮验证最终失败。看到 REACHABLE 说明邻居曾经被成功解析，但不代表应用服务一定正常。

先确认路由，再判断是不是二层问题

同一个目标地址可能因为策略路由、多个网卡或多个网络命名空间而走不同出口。先用 ip route get 看内核选择的路径和设备，再把 ip neigh 的结果限定到这张网卡；否则很容易拿错接口上的邻居记录。

# 用示例目标查询内核实际选择的路由和设备
ip route get 192.0.2.10

# 只查询该目标在指定网卡上的邻居记录
ip neigh get 192.0.2.10 dev eth0

# 对同一网关做有限次数探测，避免把一次性抖动当成结论
ping -c 3 -I eth0 192.0.2.1

如果 ip route get 已经提示没有可用路由，问题还没到邻居解析层；如果路由和设备都合理，但网关条目持续 FAILED，应优先检查本机接口、VLAN、交换链路以及网关是否能在本地网段回应。若网关正常、只有某个同网段主机失败，范围更接近对端主机或该端口；若同一接口下多个邻居同时失败，则更像本地链路或二层网络问题。

不要把 flush 当成默认修复

清理邻居缓存有时会触发重新解析，但它只是改变当前内核状态，不能修复网卡未连接、VLAN 错配、网关不回应或对端离线。更稳妥的做法是保留目标地址、设备名、状态变化时间，以及网关和同网段主机的对照结果。

如果问题只出现几秒，建议在故障窗口连续记录 ip neigh show dev eth0 和 ip route get 目标地址，再结合接口统计判断是单个邻居失败还是整段邻居解析失败。这样复盘时能区分“路由没有选出来”“邻居没有解析成功”和“邻居已解析但远端服务不通”。

常见问题

看到 FAILED 就一定是 ARP 坏了吗？ 不一定。IPv4 常见是 ARP，IPv6 使用邻居发现；共同点是链路层地址没有在探测后得到成功确认。

为什么清空邻居表后暂时恢复？ 清空会让内核重新发起解析，可能掩盖短暂的链路或网关问题；它不能证明根因已经消失。

ip neigh 正常但业务仍然超时怎么办？ 邻居表只说明本地链路层绑定，仍需继续看传输层、应用端口、服务监听和远端返回。

记住一个顺序：先看 ip route get 确认出口，再看指定设备上的 ip neigh 状态，最后用网关与同网段主机做对照。这样处理 FAILED，排查范围会比直接反复 flush 更稳定。