1. PBR 如何处理 ACL 中的 deny 规则？

在你的配置中：

• 如果目的 IP 是 172.20.14.0/24，则匹配 rule 5 deny。

• 在 PBR 的 if-match acl 中，匹配到 ACL 的 deny 规则等同于“不匹配该节点”，即 PBR 节点 node 10 判定为 不命中，继续向下检查下一个节点（node 20）。

2. 空节点 node 20 的预期行为

• node 20 匹配了所有 IP 流量（acl 3003 的 permit ip）。

• 该节点没有 apply 子句，根据 H3C 的 PBR 行为：匹配到没有 apply 的节点时，报文不再继续匹配后续 PBR 节点，直接进入普通路由表转发（即走你配置的默认静态路由）。

• 理论上，去往 172.20.14.0/24 的流量应该先跳过 node 10，然后命中 node 20，最后走默认路由。

3. 为什么实际没有走默认路由？

既然逻辑正确，问题可能出在以下几个方面：

检查点 1：PBR 是否应用到了正确的接口和方向？

• 执行 display current-configuration | include policy-based-route 查看 PBR 的全局或接口应用。

• 常见错误：PBR 应用在了 出接口 或 错误的 VLAN，而不是流量的 入接口。

• 示例正确应用：

  interface GigabitEthernet0/1

  ip policy-based-route fw # 必须配置在流量进入路由器的接口上

 检查点 2：ACL 3000 的 rule 10 是否意外影响了测试流量？

• 你的 rule 10 只允许源 IP 为 172.20.19.0/24 的流量通过。如果你的测试流量源 IP 不属于该网段，则 ACL 3000 整体匹配结果为 不匹配（因为 rule 5 是 deny，rule 10 不满足），那么 node 10 同样会跳过。这没问题，node 20 依然能匹配。

• 但如果你期望 所有去往 172.20.14.0/24 的流量（无论源 IP） 都不走 PBR 强制下一跳，建议将 acl 3000 简化：

  acl advanced 3000

  rule 5 deny ip destination 172.20.14.0 0.0.0.255
   rule 10 permit ip # 允许其他所有流量
• 这样 node 10 会匹配除 172.20.14.0/24 之外的所有流量，并强制下一跳 172.20.9.5。而目的为 172.20.14.0/24 的流量跳过 node 10，再被 node 20 正常转发。

 检查点 3：默认静态路由是否存在且有效？

• 执行 display ip routing-table | include 0.0.0.0 查看是否有默认路由。

• 如果默认路由的下一跳不可达（比如直连链路 down），路由表不会加表，PBR 空节点转发时就会因为没有匹配路由而丢包。

 检查点 4：PBR 统计信息 – 确认节点命中情况

• 清空统计：reset ip policy-based-route statistics

• 触发测试流量，然后执行：

  display ip policy-based-route statistics interface <入接口>
• 查看 node 10 和 node 20 的匹配报文计数。如果 node 20 计数为 0，说明流量根本没进入 PBR 处理流程（检查点1）或 ACL 3003 未匹配。

 推荐解决方案

方案一：修正 ACL 3000 的逻辑（最清晰）

• 去往 172.20.14.0/24 的流量 → 跳过 node 10 → 匹配 node 20 → 正常转发（默认路由）。

• 其他流量 → 匹配 node 10 → 强制下一跳 172.20.9.5。

方案二：合并为一个 PBR 节点（更简洁）

如果你只想让特定目的网段走正常路由，其他走下一跳，可以用一个节点配合高级 ACL：

方案三：去掉空节点，利用 PBR 的默认行为

实际上，如果 node 10 不匹配，且没有后续节点，PBR 会自动让报文走普通路由表。你可以直接删除 node 20，只要确保 node 10 的 ACL 正确区分了需要强制下一跳和不需要的流量即可。