SR8808-X PBR未生效

从你提供的配置来看，策略路由（PBR）未生效，问题可能出在ACL匹配、下一跳可达性，或是SR8808-X这款高端设备特有的转发逻辑上。

可以按照以下步骤系统地排查一下：

1. 检查策略路由的匹配统计 (第一优先)

这是最直接的验证方法，可以确认流量是否真的命中了PBR规则。

• 执行命令：display policy-based-route policy name pbr_test

• 查看关键信息：重点看 node 10 和 node 20 的 Matched 字段（匹配次数）。

  • 如果 Matched 计数为 0：说明流量根本没匹配上你定义的ACL，问题出在第二步。

  • 如果 Matched 计数在增长：说明ACL匹配成功了，但转发没按预期执行，问题出在第三步。

2. 验证ACL规则是否精确匹配了流量

从配置看，你的ACL规则匹配的是源IP为单个主机、目的IP为单个主机的流量。这本身没问题，但需要注意以下几点：

• 确认流量特征：务必在发起访问的设备上确认，其发出的数据包源IP和目的IP是否与ACL中定义的完全一致。例如，源IP是否为 10.43.7.245。

• 检查ACL规则顺序：在SR8808-X等硬件设备上，PBR处理ACL的方式与软件设备不同。它会顺序匹配ACL内的规则。即使先匹配到 deny 规则，如果后面有 permit 规则，流量仍可能被 permit 规则匹配并执行PBR动作。因此，建议先简化ACL，只保留一条 permit 规则进行测试。

• 查看规则总数：执行 display acl 3100，确认你期望的 permit 规则确实存在于ACL中。

3. 确认PBR应用在正确的方向和接口上

策略路由必须在流量的“入接口”上应用。

• 检查应用接口：你是在 Vlan-interface40 和 Vlan-interface109 上应用的 PBR。请确认客户端流量确实是从这些VLAN接口进入SR8808-X的。如果流量是从其他接口进入的，PBR就不会生效。

• 避免接口类型限制：虽然你用的是VLAN接口，但需注意，PBR在某些平台（如SCP板）上不支持在聚合口下配置，需要到对应的物理成员口或VLAN接口下配置。

4. 排查下一跳可达性与Track关联

你的配置中，PBR的下一跳关联了Track项。虽然 display track all 显示状态为 Positive，但这只代表NQA探测成功，不代表PBR能成功转发。

• 关键点：当PBR关联Track时，如果Track状态为 Positive，PBR会尝试将报文转发给下一跳。但如果因ARP解析失败等原因导致转发失败，PBR就会失效，流量会回退到普通路由转发。

• 检查ARP：执行 display arp | include 10.43.5.31 和 display arp | include 10.43.6.31，确认下一跳IP的ARP表项是否已成功学习到。

• 检查路由：执行 display ip routing-table 10.43.5.31 和 display ip routing-table 10.43.6.31，确认设备有到达下一跳的路由

• 
  

  undo ip fast-forwarding enable执行这个，如果你要用PBR的话

配置问题，检查下吧

一、先梳理你的配置现状
入接口：Vlanif40（源 10.43.7.245）、Vlanif109（源 10.43.9.174/175），接口绑定ip policy-based-route pbr_test（入方向 PBR，匹配进入接口的流量）
PBR 逻辑：
node10：匹配 ACL3100（7 段→9 段两台服务器），下一跳 10.43.5.31 track1，Track 状态 Positive 可达
node20：匹配 ACL3101（9 段→7 段两台服务器），下一跳 10.43.6.31 track2，Track 状态 Positive 可达
NQA、Track 全部正常，下一跳路由可达，但流量依旧走普通路由，PBR 未命中。
二、六大核心故障点（按优先级排查）
故障 1：PBR 仅对入接口流量生效，同网段互访不经过接口转发，直接二层交换跳过 PBR（最高概率，你的场景完全命中）
关键原理：
10.43.7.0/25（Vlan40）和 10.43.9.0/24（Vlan109）是两个不同三层 VLAN，正常跨 VLAN 流量会进三层转发，触发入接口 PBR；
但如果两台服务器网关是 VRRP 虚拟 IP（10.43.7.254 / 10.43.9.254），存在两种情况会跳过 PBR：
流量走对端 VRRP Master 转发：当前设备是 VRRP Backup（priority 120，对端主设备优先级更高），服务器网关指向虚拟 IP，流量被对端 Master 接收转发，根本不经过本机 Vlanif40/Vlanif109 入接口，本机 PBR 完全不处理；
本机是 VRRP Master，但服务器 ARP 解析到本机物理接口 MAC，跨 VLAN 三层转发本应触发 PBR，但存在转发优先匹配问题。
验证命令：
bash
运行
# 查看VRRP主备状态，确认本机是否为Master
display vrrp brief
如果 State 是 Backup，所有服务器网关流量都会去往对端主设备，本机 PBR 完全不会匹配任何流量，表现为 PBR 完全不生效。
故障 2：ACL 源 / 目的掩码书写错误，匹配不到流量
ACL 配置：
plaintext
rule 10 permit ip source 10.43.7.245 0 destination 10.43.9.175 0
0代表反掩码 = 主机精确匹配，语法本身没问题，但需要确认：
服务器真实 IP 是否完全是10.43.7.245、10.43.9.174/175，无写错；
抓包确认流量源目 IP 是否和 ACL 完全一致；
统计 ACL 命中计数，判断有没有流量匹配 ACL：
bash
运行
display acl 3100
display acl 3101
若 rule 计数始终为 0，说明流量根本没匹配 ACL，PBR 自然不执行。
故障 3：PBR 下发硬件转发失败，流量走软件转发 / 硬件路由表
SR88 高端框式设备 PBR 默认下发芯片硬件转发，版本 R7951P10 存在硬件 PBR 下发兼容 bug：
多 VLANIF 同时绑定同一条 PBR 策略，硬件表项冲突；
Track 联动下一跳场景，硬件转发失效，流量 fallback 查普通路由表；
查看 PBR 硬件下发状态：
bash
运行
display policy-based-route hardware
若表项缺失、状态 Failed，代表硬件 PBR 未生效，流量走普通路由。
临时规避：接口开启软件优先处理 PBR
bash
运行
interface Vlan-interface 40
ip policy-based-route pbr_test software-first
interface Vlan-interface 109
ip policy-based-route pbr_test software-first
故障 4：PBR 的 apply next-hop 出接口路由不存在，仅 Track 可达无静态 / 动态路由
Track 仅探测 NQA 连通性，但设备必须存在去往10.43.5.31、10.43.6.31的路由（静态 / OSPF/BGP），否则 PBR 匹配后无法转发，回退到普通路由转发。
核查路由：
bash
运行
display ip routing-table 10.43.5.31
display ip routing-table 10.43.6.31
无路由条目则 PBR 不生效，流量回退查目的路由。
故障 5：入方向 PBR 仅处理经过本接口进入设备的流量，本地始发流量不匹配
测试时如果在交换机本机 ping 服务器，属于本地始发流量，不会匹配接口 PBR；必须从终端服务器发起流量测试。
故障 6：VRRP 双机 PBR 配置不同步，主备策略不一致
对端 Backup 设备未配置相同 PBR，流量切换到对端后无策略路由，同时本机 Backup 状态不接收流量。
三、标准化排查步骤（现场逐条执行）
步骤 1：确认 VRRP 主备（最关键，你的场景首要排查）
bash
运行
display vrrp brief
本机 State 为 Backup：
所有服务器网关流量去往对端主设备，本机 PBR 不会收到任何流量；
解决：① 切换本机为 VRRP Master 测试；② 两台 VRRP 设备完整同步 PBR、ACL、NQA、Track 全套配置。
本机是 Master，继续往下排查。
步骤 2：校验 ACL 是否命中流量
bash
运行
display acl 3100
display acl 3101
rule 计数 = 0：流量源目 IP 与 ACL 不匹配，核对服务器真实 IP、抓包确认流量；
rule 计数 > 0：流量匹配 ACL，问题出在 PBR 转发逻辑。
步骤 3：验证下一跳路由存在
bash
运行
display ip routing-table 10.43.5.31
display ip routing-table 10.43.6.31
无路由则补充静态路由，否则 PBR 匹配后无法转发。
步骤 4：查看 PBR 匹配计数，确认策略是否命中流量
bash
运行
display policy-based-route pbr_test statistics
node10/node20 数据包计数为 0：流量没匹配到 PBR（VRRP Backup/ACL 不匹配）；
计数持续增长但流量不走下一跳：硬件下发失败，配置software-first。
步骤 5：修复硬件 PBR 下发问题（R7951P10 版本 bug 规避）
bash
运行
system-view
interface Vlan-interface 40
ip policy-based-route pbr_test software-first
interface Vlan-interface 109
ip policy-based-route pbr_test software-first
该命令强制匹配 PBR 的流量上 CPU 软件转发，绕过芯片硬件表项 bug，保证 PBR 优先执行。
步骤 6：验证 Track 与 NQA 可用性
bash
运行
display track all
display nqa results admin in
display nqa results admin out
当前 Track 全为 Positive，此步仅做确认，无问题。
步骤 7：流量测试验证
服务器端长 ping 对端服务器，同时观察 PBR 统计计数上涨；
设备端 tracert 目标 IP，查看下一跳是否为 PBR 指定的 10.43.5.31/10.43.6.31；
若 tracert 仍走原始路由，说明 PBR 未生效。
四、分场景根治方案
场景 1：本机是 VRRP Backup（90% 概率你的故障）
方案 A（测试）：修改本机 VRRP 优先级高于对端，抢占为 Master，流量进入本机触发 PBR；
bash
运行
interface Vlan-interface 40
vrrp vrid 40 priority 130
interface Vlan-interface 109
vrrp vrid 109 priority 130
方案 B（生产稳定）：两台 VRRP 设备完整复制全套 PBR 配置（ACL、PBR 策略、NQA、Track、接口绑定），无论哪台为主，流量都能匹配策略路由。
场景 2：ACL 无命中计数
核对服务器 IP，修正 ACL 源目地址，重新测试流量。
场景 3：PBR 有计数但不跳转下一跳（硬件下发 bug）
接口添加software-first强制软件处理 PBR，彻底规避 R7951P10 硬件转发缺陷。
场景 4：下一跳无路由
添加静态路由指向下一跳出接口：
bash
运行
ip route-static 10.43.5.31 255.255.255.255 Vlan-interface 105
ip route-static 10.43.6.31 255.255.255.255 Vlan-interface 106
五、关键补充避坑
入接口 PBR 只处理入站流量：服务器从 Vlan40 进来的流量才匹配，从其他接口进入的流量不生效；
VRRP 双机环境必须两端同步全套 PBR 相关配置，否则切换后策略失效；
R7951P10 早期补丁存在多 VLAN 绑定同 PBR 硬件转发异常，software-first是官方临时规避手段，长期可升级至 R7951P15 + 稳定补丁；
PBR 优先级高于普通路由，只要匹配 ACL、下一跳可达、硬件正常，一定会优先转发至指定下一跳。
六、快速验证命令汇总
bash
运行
# 1. 查看VRRP主备
display vrrp brief
# 2. ACL命中统计
display acl 3100
# 3. PBR匹配计数
display policy-based-route pbr_test statistics
# 4. 下一跳路由
display ip routing-table 10.43.5.31
# 5. PBR硬件下发状态
display policy-based-route hardware
# 6. Track状态
display track all