在 H3C 设备上配置策略路由（PBR）时，遇到“业务实际生效但 ACL 命中计数为 0”的情况非常典型。这通常是因为硬件转发机制与软件统计机制的差异导致的。
以下是导致该现象的核心原因及排查调整方案：
一、 核心原因：硬件转发不触发软件计数
H3C 交换机和防火墙的底层数据转发主要依赖硬件芯片（如 TCAM）。当流量匹配到策略路由并在硬件层面直接完成转发时，报文不会上送 CPU 处理，因此无法产生软件层面的 ACL 匹配计数。
- 特征表现：只有那些需要 CPU 介入处理的报文（例如配合包过滤下发的 ACL），才能在
display acl等命令中看到匹配计数。
二、 如何正确验证策略路由是否生效？
既然页面能确认出口地址一致，说明策略路由本身已经生效。建议通过以下更准确的方式验证，而不是单纯依赖 ACL 计数：
- 查看会话表：使用
display session table ipv4 source-ip [源IP] destination-ip [目的IP] verbose命令，观察生成的会话表中出接口和下一跳是否与策略路由的预期一致。 - 开启 Debug 抓包：若需确认报文是否触发了策略路由规则，可开启安全策略或 IP 报文的调试开关进行实时抓包分析（测试完成后务必及时关闭 debug）。
三、 如果确实需要看到 ACL 统计数据，如何调整？
如果您出于审计需求必须看到具体的命中计数，可以尝试以下调整：
1. 显式启用 QoS 统计功能
默认情况下多数 H3C 设备不自动启用接口级统计。即便 ACL 已应用，仍需在对应的接口视图下显式开启统计功能：
interface GigabitEthernet X/X/X
qos-statistic enable开启后，可通过
display qos-acl statistics 查看是否有增量数据。2. 检查并调整 ACL 规则顺序
H3C 设备的 ACL 遵循“自上而下、首条命中即停止”的原则。如果上方存在宽泛的规则（如
permit ip any any）提前匹配了流量，下方的精确统计规则将永远不会被触发。请确保用于统计的精确规则优先级更高。3. 清除旧会话重新测试
如果修改了配置或开启了统计功能，之前已经建立的长连接会直接走旧的会话表，不会重新匹配新的策略或产生新计数。
- 操作：执行
reset session table清除会话表，然后重新发起业务访问，再观察统计数据是否更新。
4. 确认应用方向是否正确
策略路由绑定的 ACL 必须与实际流量的路径方向严格对应。如果方向（inbound/outbound）选择错误，即使有流量经过也无法匹配统计。
暂无评论
一、为什么 “PBR 生效、ACL 统计 0”
1）你看的是 ACL 本身统计，不是 PBR 里的匹配统计（最常见）
- ACL 默认不计数：ACL rule 不加
count，display acl永远 0。 - PBR 有自己的统计：流量匹配 ACL → 匹配 PBR 节点 → 走指定下一跳；ACL 计数和 PBR 计数是分开的H3C。
2）NAT 在 PBR 之前执行，ACL 匹配的是 “转换后地址”
H3C 默认顺序：入接口→NAT→PBR→路由转发
- 内网源 IP 10.0.0.1 → 做源 NAT → 公网 IP 202.x.x.x
- 你的 ACL 写的是 10.0.0.1，但 PBR 看到的是 202.x.x.x → ACL 不匹配、计数 0，但PBR 可能匹配了其他条件或走了默认，看起来生效。
3）ACL 规则本身没匹配上（但 PBR “看起来生效”）
- 反掩码写错（如 255.255.255.0 写成 0.0.0.255 反）
- 协议 / 端口写错（TCP 写成 IP，端口范围错）
- 流量分片：带端口的 ACL 无法匹配分片包
- 规则顺序错：前面 deny 把流量拦了，后面 permit 永远不命中
4）PBR 只绑定在入接口，你在出接口看统计
PBR仅对入方向流量生效；出方向不处理 PBR。
5）全局没开 “包过滤统计”，ACL count 不计数
V7 默认可能关闭，需手动开启。
二、逐条排查（直接复制命令）
1）先确认 PBR 统计（看 PBR 有没有命中）
bash
运行
display ip policy-based-route # 全局PBR统计，看node的Matches
display ip policy-based-route local # 本地PBR（发往设备自身）
display firewall session table verbose # 看会话的源/目的、出接口、NAT前后
- Matches > 0：PBR 确实命中，问题在 ACL 统计；
- Matches = 0：PBR 没命中，流量走了普通路由。
2）检查 ACL 是否开启 count、规则是否正确
bash
运行
display acl all # 看rule末尾有没有count，源/目的/协议是否正确
示例（必须加 count）：
bash
运行
acl number 3000
rule permit ip source 192.168.1.0 0.0.0.255 count # 加count才会计数
3）开启全局包过滤统计（关键）
bash
运行
system-view
packet-filter statistics enable # 全局开启ACL统计
4）检查 NAT 与 PBR 顺序
bash
运行
display nat outbound # 看源NAT是否在入接口方向
- 若 NAT 在 PBR 前：ACL 要匹配NAT 后的地址，或把 PBR 移到 NAT 前（用安全域策略调整顺序）。
5）确认 PBR 绑定在入接口
bash
运行
display ip policy-based-route interface # 看哪个接口绑定了PBR，方向是inbound
三、快速整改（一次搞定）
-
ACL 每条规则加 countbash运行
acl 3000 rule 10 permit ip source 192.168.1.0 0.0.0.255 count -
全局开启统计bash运行
system-view packet-filter statistics enable -
调整 NAT 与 PBR 顺序（核心）
- 方案 A（推荐）：PBR 在 NAT 前 → 安全域内配置 PBR，NAT 放后；
- 方案 B：ACL 匹配NAT 后的公网 IP。
-
绑定 PBR 到入接口bash运行
interface GigabitEthernet1/0/1 ip policy-based-route PBR_NAME -
用 PBR 统计验证，别只看 ACLbash运行
display ip policy-based-route # 看node的Matches是否增长
四、一句话总结
PBR 生效但 ACL 计数 0，是因为 ACL 没开 count、NAT 先改了地址、你看错了统计对象。先开全局统计、ACL 加 count、核对 NAT 与 PBR 顺序、用
display ip policy-based-route看真实命中，即可解决。暂无评论
编辑答案
➤
✖
亲~登录后才可以操作哦!
确定
✖
✖
你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
✖
举报
×
侵犯我的权益
>
对根叔社区有害的内容
>
辱骂、歧视、挑衅等（不友善）
侵犯我的权益
×
侵犯了我企业的权益
>
抄袭了我的内容
>
诽谤我
>
辱骂、歧视、挑衅等（不友善）
骚扰我
侵犯了我企业的权益
×
您好，当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱，我们会在审核后尽快给您答复。
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
抄袭了我的内容
×
原文链接或出处
诽谤我
×
您好，当您发现根叔知了上有诽谤您的内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱，我们会尽快处理。
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
对根叔社区有害的内容
×
垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载
>
辱骂、歧视、挑衅等（不友善）
骚扰我
诱导投票
不规范转载
×
举报说明
暂无评论