路由表和arp表是排查linux网络故障的首要环节，分别决定数据转发路径和下一跳mac地址；需用ip route show和ip neigh show检查默认路由、网段匹配、策略路由及arp状态，联动分析常见于vip配置错误、多网卡选路异常等场景。
当Linux主机出现网络不通、延迟高或间歇性掉线时，route（路由表）和ARP（地址解析协议）往往是第一排查环节。它们分别决定“数据往哪发”和“下一跳MAC怎么找”，出错后常表现为能ping通网关但无法访问外网、同一网段内互ping失败、连接突然中断等现象。
查路由表：确认出口路径是否正确
执行 ip route show（推荐）或 route -n 查看当前生效的路由规则。重点核对以下几点：
-
默认路由是否存在且指向正确网关：如
default via 192.168.1.1 dev eth0，需确认192.168.1.1确实是你的网关IP，且eth0是实际使用的网卡； - 目标网段路由是否冲突或缺失：例如访问10.20.0.0/16时，若存在两条匹配路由（如一条是10.0.0.0/8，另一条是10.20.0.0/16），优先级高的更精确路由应生效；
-
策略路由或多表路由被误启用：运行
ip rule show，若看到非默认规则（如from 192.168.2.100 lookup table 100），需同步检查对应表内容ip route show table 100； - 路由被静态添加但网关不可达：即使路由存在，若网关本身不响应ARP或未开机，数据包仍会丢弃——此时需结合ARP表进一步验证。
查ARP缓存：验证二层可达性
执行 ip neigh show（或 arp -n）查看本机已学习的IP-MAC映射。关键观察点：
- 网关IP对应条目状态是否为 REACHABLE 或 STALE：若显示 FAILED 或直接缺失，说明无法通过ARP获取网关MAC，常见于网关宕机、VLAN配置错误、防火墙禁用ARP响应、或物理链路异常；
- 同网段其他主机条目是否频繁变为 STALE：可能因交换机端口安全限制、ARP限速、或对方主机禁用了ARP响应；
-
存在大量 INCOMPLETE 条目：表示ARP请求已发出但无响应，可配合
tcpdump -i eth0 arp抓包确认是否发出请求、是否有reply返回； -
手动刷新ARP缓存：删除异常条目
ip neigh del 192.168.1.1 dev eth0，再触发一次ping，观察是否重新学习成功。
联动分析：路由+ARP典型故障场景
单独看路由或ARP可能都“看起来正常”，但组合起来就出问题：
- 路由指向虚拟网关（如VIP），但ARP学到的是真实服务器MAC：常见于LVS或Keepalived环境，需确认ARP通告模式（arp_ignore/arp_announce）和VIP绑定方式；
- 多网卡主机路由选错出口，导致ARP在错误网段发起：例如eth0配192.168.1.10/24，eth1配10.0.0.10/24，访问10.0.0.100时路由走eth1，但ARP请求却从eth0发出（因源地址选择逻辑），结果收不到reply；
-
DHCP更新后路由未刷新，旧网关仍在ARP表中：重启网络服务后，建议清空ARP缓存
ip neigh flush all并重新测试； -
容器或命名空间内网络异常：需进入对应netns执行
ip route和ip neigh，宿主机的ARP表不能代表容器视角。
快速验证与临时修复
在定位到具体问题后，可尝试以下操作快速验证：
- 临时添加静态ARP：
ip neigh replace 192.168.1.1 lladdr 00:11:22:33:44:55 dev eth0，绕过ARP过程直连网关（仅用于测试）； - 强制触发ARP请求：
ping -c1 192.168.1.1 && ip neigh show 192.168.1.1； - 对比不同路径：用
traceroute -n -i eth0 8.8.8.8指定出口网卡，确认是否真走预期路由； - 检查反向路径过滤：
sysctl net.ipv4.conf.all.rp_filter若为1，可能丢弃非对称路由的包，测试时可临时设为0。
