策略路由的奇怪问题

图片有误，以下面为准

策略路由应该应用在接受报文的接口，不是在2.2.2.2互联的口。

另外SW7做的策略路由没必要在这里做。

一、先解释现象：为什么去程不走设备 6，回程反而走了？

1. 去程（PC5→PC3）

• 包从 PC5 10.176.83.3 发出，进入设备 7的 Vlan83 接口，触发了策略路由，被强制发给设备 2（2.2.2.2）。
• 设备 2 收到后，根据策略路由发给设备 1（1.1.1.1）。
• 设备 1 上的问题来了：
  你在设备 1 的 Vlan1706 接口下配置了 ip policy-based-route smt，但这个接口是出站接口！
  策略路由只对入站包生效，对从设备 1 路由出去的包（出站）不生效。
• 于是设备 1 直接查 OSPF 路由表，发现10.1.6.2的最优路径是直连 PC3，绕过了设备 6。

2. 回程（PC3→PC5）

• 包从 PC3 10.1.6.2 发出，进入设备 1 的 Vlan1706 接口（入站）。
• 设备 1 查路由表，10.176.83.0/24 的下一跳是设备 2。
• 但此时，包在设备 1 的入接口触发了策略路由，if-match acl 3000 匹配 destination 10.176.83.0，被强制发给了设备 6（3.3.3.1）。
• 所以回程包经过了设备 6，再到设备 2、设备 7，回到 PC5。

二、核心配置错误点

1. 设备 1 的策略路由配置错误

• 你把 ip policy-based-route smt 绑定在了出站接口 Vlan1706，这对 PC5→PC3 的去程包完全无效。
• 策略路由必须绑定在包进入设备的入接口上。
• 设备 1 上的策略路由现在只对从 PC3 发往 PC5 的回程包生效，所以回程走了设备 6，去程没走。

2. 策略路由的 ACL 方向搞反了

• 设备 1 的 acl advanced 3000 写的是 permit ip destination 10.176.83.0，这是为了匹配回程包（PC3→PC5），而不是去程包（PC5→PC3）。
• 去程包的目的地址是 10.1.6.2，根本不会被这个 ACL 匹配。

三、一步到位的修复方案

设备 1 修正配置

验证配置后效果

• 去程（PC5→PC3）：包到设备 1 后，被 Vlan1706 入接口的策略路由匹配，强制发给设备 6。
• 回程（PC3→PC5）：设备 1 根据 OSPF 路由发给设备 2，设备 2/7 再转发回 PC5。

四、额外优化建议

1. 检查设备 6 是否有回程路由：确保设备 6 能把10.1.6.0的包回传给设备 1，否则会断网。
2. 调整策略路由优先级：如果 OSPF 路由和策略路由冲突，可在设备 1 上对10.1.6.0网段配置静态路由，强制下一跳指向设备 6：
   bash

   运行

   ip route-static 10.1.6.0 255.255.255.0 3.3.3.1 preference 5
   静态路由优先级比 OSPF 高，能确保去程包优先走设备 6。

五、总结

你的问题现象很典型：策略路由（PBR）在去程（PC3→PC5）失效，回程（PC5→PC3）却生效了，最终导致往返路径不一致。这通常是“应用位置错误”和“PBR本身特性限制”共同导致的。

 根因分析：为什么去程PBR不生效？

问题的根源在于“接口策略路由” (ip policy-based-route) 的工作机制。

• 它只对“第一个”到达该接口的报文生效。
  当你在一个接口上应用PBR时，它仅仅会检查和处理该接口从外部接收到的流量。对于设备本身主动发出的数据包（例如，响应Ping的回复包），它是不起作用的。

• 去程报文的真实路径是第一跳。
  当PC3发出报文，第一个接收到这个报文的设备是它的网关设备7。因此，必须在设备7连接PC3的入接口上应用PBR，才能引导去程流量。

• 你的配置问题：把PBR用错了地方。
  你提供的配置清晰地展示了问题所在：

  • 设备7：在 Vlan-interface83（连接PC3的网关接口）上配置了PBR，这里是正确的。

  • 设备1：在 Vlan-interface1706 上配置了PBR，这个接口看起来是连接PC5的，此处应用位置不对。

  • 设备2：在 Vlan-interface2000 上配置了PBR，这个接口是连接路由器/交换机的传输接口，此处应用位置也不对。

  所以，当PC3发出的去程报文到达设备7时，虽然接口配置了PBR，但如果配置有误（比如ACL匹配错误），报文就不会命中PBR，而是按照OSPF路由表直接转发给设备1或设备2，从而绕过了设备6。而PC5的回程报文到达设备1时，设备1上的PBR又对它进行了干预，将其发往设备6，这就形成了你看到的现象。

 解决方案：两种修复方法

找到根因后，解决起来就清晰了。这里有两种方法，你可以根据需求选择：

方案一：在原地修复PBR规则（可实现双向引流）

如果你坚持使用PBR来精细控制，请按以下步骤操作：

1. 纠正PBR应用位置：

   • 核心原则：确保引导PC3→PC5去程流量的PBR，只能应用在设备7的入接口 Vlan-interface83 上。

   • 请立即从设备1和设备2的接口上移除错误的PBR配置，以免干扰：

     interface Vlan-interface1706

     undo ip policy-based-route smt interface Vlan-interface2000 undo ip policy-based-route smt

2. 重写设备7的ACL和PBR：

   • 设备7上的ACL 3000 规则必须同时精确匹配源和目的IP。

     acl advanced 3000

     undo rule 0 rule 0 permit ip source 10.176.83.3 0 destination 10.1.6.2 0

   • 策略路由下一跳必须路由可达，必要时可配置一条静态路由。

完成以上两步后，可以在设备7上使用命令 display ip policy-based-route statistics 查看PBR的命中计数是否增加，以确认去程流量已正确匹配并转发给设备。

 方案二：改用动态路由，一劳永逸（更推荐）

如果只是为了引导流量经过设备6，一个更简单、稳定且能天然保证路径对称的方案是：将设备6作为OSPF网络的一部分，通过调整开销（Cost）值来引导流量。

• 如果设备6是网络内的新设备，无需任何PBR，直接在OSPF进程里宣告“6.2”所在的网段，并为其设置一个比其他路径更小的Cost值。

启用OSPF后，全网所有路由器都会自动将去往“6.2”网段的流量优先发往设备6，实现双向路径完全一致，且没有PBR的兼容性问题。