策略路由翻车实录：当ARP代理遇上接口策略路由时为何ping不通？-CSDN博客

策略路由实战排错：当流量路径与ARP机制“打架”时，如何精准定位与修复？

那天下午，机房里的告警灯没亮，但我的直觉告诉我，网络有点不对劲。一个原本设计用于实现精细流量引导的策略路由（Policy-Based-Route）配置上线后，核心路由器R1对特定目的地的ping测试全部失败。控制台上一串串的“Request timed out”格外刺眼，路由表看似正确，策略也已生效，但数据包就像撞上了一堵无形的墙。这不是简单的配置错误，而是一场典型的、由底层协议交互引发的“静默故障”。对于追求网络确定性的工程师而言，这种问题远比链路中断更让人头疼——它挑战的是我们对数据包转发全流程的深层理解。今天，我们就来彻底复盘这个案例，不仅解决“ping不通”的问题，更要挖出策略路由与ARP代理在协同工作时，那些容易被忽略的“魔鬼细节”。

1. 故障现场还原：一个“完美”配置下的连通性谜团

我们的实验拓扑很简单，却足以复现经典问题。路由器R1有两个上行接口：G0/0/0（1.0.0.1/24）连接ISP1，G0/0/1（2.0.0.1/24）连接ISP2。下游路由器R2则相应地用G0/0/0（1.0.0.2）和G0/0/1（2.0.0.2）与R1互联，并在R2上创建了两个环回地址用于测试：6.6.6.6/32 和 7.7.7.7/32。

初始路由配置非常直观：

# 在R1上的静态路由配置
ip route-static 6.6.6.6 32 1.0.0.2
ip route-static 7.7.7.7 32 2.0.0.2

这意味着，去往6.6.6.6的流量默认走左侧链路（下一跳1.0.0.2），去往7.7.7.7的流量走右侧链路（下一跳2.0.0.2）。

业务部门提出了新需求：希望所有从内部特定服务器发往7.7.7.7的流量，也能从左侧的G0/0/0接口送出，以实现流量聚合和策略审计。于是，我们在R1上部署了接口策略路由。

# 定义ACL匹配去往7.7.7.7的流量
acl number 3000
 rule 5 permit ip destination 7.7.7.7 0

# 创建流行为，指定出接口为G0/0/0
traffic behavior b1
 redirect interface GigabitEthernet0/0/0

# 创建流分类与流策略
traffic classifier c1 operator or
 if-match acl 3000

traffic policy p1
 classifier c1 behavior b1

# 将策略应用到接收流量的入接口（例如连接内部服务器的接口）
interface GigabitEthernet0/0/2
 traffic-policy p1 inbound

配置完成后，信心满满地在R1上执行 ping -a 1.0.0.1 7.7.7.7。结果却是持续的失败。更令人困惑的是，ping 6.6.6.6 也失败了。这不对劲——策略只影响了去往7.7.7.7的流量，为什么连默认路由指向的6.6.6.6也不通了？