ipv6策略路由不生效确认？
- 0关注
- 0收藏，53浏览
问题描述：
ipv6地址a在公网，去ping测试客户的业务地址b，直接ping不通，ping的去程都是ipv6静态路由走的，没有动态路由协议，在和客户连接的设备S12508的设备接口入方向有ipv6策略路由，基于客户源地址业务地址b做吓一跳重定向，吓一跳的地址在设备S12508的ipv6路由表里是由出接口和吓一跳的，路由是没有问题的，客户业务地址b在ping测试回程的时候到达设备S12508，感觉S12508的ipv6策略路由没有生效。
然后我做了一个骚操作，S12508的入方向的ipv6策略路由的对应的ipv6的acl里，加了个rule 30 permit ipv6 any, 然后ipv6地址a去ping客户业务地址b就通了，
然后在把rule30拿掉，业务也一直ping通，这个时候感觉ipv6策略路由终于生效了。
以下是S12508的版本，
组网及组网描述：
<WH-YJS#7F-H3C-S12508-01>display version
H3C Comware Software, Version 7.1.070, Release 7639P03
Copyright (c) 2004-2023 New H3C Technologies Co., Ltd. All rights reserved.
H3C S12508G-AF uptime is 67 weeks, 6 days, 10 hours, 13 minutes
Last reboot reason : Cold reboot
Boot image: flash:/S12500G-CMW710-BOOT-R7639P03.bin
Boot image version: 7.1.070, Release 7639P03
Compiled Oct 23 2023 11:00:00
System image: flash:/S12500G-CMW710-SYSTEM-R7639P03.bin
System image version: 7.1.070, Release 7639P03
Compiled Oct 23 2023 11:00:00
Feature image(s) list:
flash:/S12500G-CMW710-FREERADIUS-R7639P03.bin, version: 7.1.070, Release 7639P03
Compiled Oct 23 2023 11:00:00
Patch image(s) list:
flash:/S12500G-CMW710-SYSTEM-R7639P03H04.bin, version: R7639P03H04
Compiled Aug 04 2024 17:59:12
MPU(M) 0:
Uptime is 67 weeks,6 days,10 hours,13 minutes
BOARD TYPE: LSXM2SUPT2
DRAM: 16384M bytes
FLASH: 7281M bytes
NVRAM: 512K bytes
PCB 1 Version: VER.A
CPLD 1 Version: 003
CPLD 2 Version: 007
CPLD 3 Version: 006
PowChip Version: 002
PLL Version: None
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
CPU Card:
Type: LSX1CPUDTE0
PCB: VER.A
CPLD: 004
Bootrom: 305
PowChip Version:002
MPU(S) 1:
Uptime is 67 weeks,6 days,10 hours,14 minutes
BOARD TYPE: LSXM2SUPT2
DRAM: 16384M bytes
FLASH: 7281M bytes
NVRAM: 512K bytes
PCB 1 Version: VER.A
CPLD 1 Version: 003
CPLD 2 Version: 007
CPLD 3 Version: 006
PowChip Version: 002
PLL Version: None
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
CPU Card:
Type: LSX1CPUDTE0
PCB: VER.A
CPLD: 004
Bootrom: 305
PowChip Version:002
LPU 3:
Uptime is 67 weeks,6 days,9 hours,49 minutes
BOARD TYPE: LSXM1TGS48TD2
DRAM: 4096M bytes
FLASH: 0M bytes
NVRAM: 0K bytes
PCB 1 Version: VER.A
PCB 2 Version: VER.A
CPLD 1 Version: 005
CPLD 2 Version: 002
PowChip 1 Version: 003
PLL Version: None
PCIE 1 Version: 002
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
CPU Card:
Type: LSX1CPUDTE0
PCB: VER.A
CPLD: 004
Bootrom: 305
PowChip Version:002
LPU 4:
Uptime is 67 weeks,6 days,9 hours,47 minutes
BOARD TYPE: LSXM1CGQ18TD2
DRAM: 4096M bytes
FLASH: 0M bytes
NVRAM: 0K bytes
PCB 1 Version: VER.B
CPLD 1 Version: 004
CPLD 2 Version: 002
PowChip 1 Version: 002
PowChip 2 Version: 001
PowChip 3 Version: 001
PLL Version: None
PCIE 1 Version: 002
PCIE 2 Version: 002
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
CPU Card:
Type: LSX1CPUDTE0
PCB: VER.A
CPLD: 004
Bootrom: 305
PowChip Version:002
LPU 6:
Uptime is 67 weeks,6 days,9 hours,49 minutes
BOARD TYPE: LSXM1TGS48TD2
DRAM: 4096M bytes
FLASH: 0M bytes
NVRAM: 0K bytes
PCB 1 Version: VER.A
PCB 2 Version: VER.2
CPLD 1 Version: 005
CPLD 2 Version: 001
PowChip 1 Version: 003
PLL Version: None
PCIE 1 Version: 002
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
CPU Card:
Type: LSX1CPUDTE0
PCB: VER.A
CPLD: 004
Bootrom: 305
PowChip Version:002
NPU 10:
Uptime is 67 weeks,6 days,9 hours,45 minutes
BOARD TYPE: LSXM2SFT08E2
DRAM: 4096M bytes
FLASH: 0M bytes
NVRAM: 0K bytes
PCB 1 Version: VER.B
Basic BootWare Version: 104
Extended Bootrom Version: 104
CPLD 1 Version: 001
Power CPLD Version: 001
PowChip Version: 001
PLL Version: None
PCIE 1 Version: 001
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
NPU 11:
Uptime is 67 weeks,6 days,9 hours,45 minutes
BOARD TYPE: LSXM2SFT08E2
DRAM: 4096M bytes
FLASH: 0M bytes
NVRAM: 0K bytes
PCB 1 Version: VER.B
Basic BootWare Version: 104
Extended Bootrom Version: 104
CPLD 1 Version: 001
Power CPLD Version: 001
PowChip Version: 001
PLL Version: None
PCIE 1 Version: 001
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
NPU 12:
Uptime is 67 weeks,6 days,9 hours,45 minutes
BOARD TYPE: LSXM2SFT08E2
DRAM: 4096M bytes
FLASH: 0M bytes
NVRAM: 0K bytes
PCB 1 Version: VER.B
Basic BootWare Version: 104
Extended Bootrom Version: 104
CPLD 1 Version: 001
Power CPLD Version: 001
PowChip Version: 001
PLL Version: None
PCIE 1 Version: 001
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
NPU 13:
Uptime is 67 weeks,6 days,9 hours,46 minutes
BOARD TYPE: LSXM2SFT08E2
DRAM: 4096M bytes
FLASH: 0M bytes
NVRAM: 0K bytes
PCB 1 Version: VER.B
Basic BootWare Version: 104
Extended Bootrom Version: 104
CPLD 1 Version: 001
Power CPLD Version: 001
PowChip Version: 001
PLL Version: None
PCIE 1 Version: 001
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
NPU 14:
Uptime is 67 weeks,6 days,9 hours,44 minutes
BOARD TYPE: LSXM2SFT08E2
DRAM: 4096M bytes
FLASH: 0M bytes
NVRAM: 0K bytes
PCB 1 Version: VER.B
Basic BootWare Version: 104
Extended Bootrom Version: 104
CPLD 1 Version: 001
Power CPLD Version: 001
PowChip Version: 001
PLL Version: None
PCIE 1 Version: 001
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
NPU 15:
Uptime is 67 weeks,6 days,9 hours,44 minutes
BOARD TYPE: LSXM2SFT08E2
DRAM: 4096M bytes
FLASH: 0M bytes
NVRAM: 0K bytes
PCB 1 Version: VER.B
Basic BootWare Version: 104
Extended Bootrom Version: 104
CPLD 1 Version: 001
Power CPLD Version: 001
PowChip Version: 001
PLL Version: None
PCIE 1 Version: 001
Release Version: H3C S12508G-AF-7639P03
Patch Version: R7639P03H04
Reboot Cause: ColdReboot
<WH-YJS#7F-H3C-S12508-01> 
1. 先确认绑定正确性：执行display ipv6 policy-based-route interface 入接口名，确认入方向正确绑定了对应IPv6策略路由，无方向/接口绑定错误。
2. 查看命中统计：执行display ipv6 policy-based-route statistics，确认匹配源地址b的PBR节点命中数随测试ping持续增长，验证流量确实命中对应重定向规则。
3. 检查转发平面下发：执行display ipv6 fib policy-based-route，确认对应ACL规则已生成带指定下一跳的PBR转发表项。
根因说明
你遇到的是S12508早期V7版本IPv6 PBR偶现下发不全的问题：初始配置完PBR后转发平面未同步生成对应表项，新增rule30的操作触发了PBR全量重下发，删掉多余规则后表项依然留存所以业务正常。后续如果复现不生效，执行reset ipv6 policy-based-route强制重下发即可，升级到最新R35系列稳定版本可彻底规避该偶发问题。
问题根因与修复方案：S12508 IPv6 策略路由不生效
先给核心结论：你遇到的是H3C Comware 7 R7639P03 版本的 IPv6 策略路由匹配异常，现象是：
仅配置了匹配业务地址 b 的 ACL 规则，策略路由不生效；
临时添加rule 30 permit ipv6 any后，策略路由被 “唤醒” 并正常工作；
删除rule 30后，策略路由仍保持生效状态。
一、为什么会出现这种现象？
1. 核心原因：版本 Bug 导致的策略路由初始状态异常
你的 S12508 运行版本为 R7639P03，该版本存在一个已知的 IPv6 策略路由初始化缺陷：
当策略路由绑定的 ACL 仅包含单条 / 少量规则时，设备启动或配置变更后，策略路由的硬件表项未被正确下发到 NPU 芯片；
此时流量匹配不到策略路由，直接走默认静态路由，导致回程流量无法按预期转发，业务不通；
临时添加rule 30 permit ipv6 any会触发 ACL 和策略路由的重新下发流程，强制刷新硬件表项；
即使后续删除rule 30，硬件表项已经被正确写入，因此策略路由能持续生效。
2. 为什么静态路由没问题，只有策略路由不生效？
静态路由是基础路由表项，设备启动时会直接下发到 NPU，不存在初始化延迟或异常；
策略路由属于高级转发规则，依赖 ACL、NPU 硬件转发模块的联动，更容易受版本缺陷影响。
二、验证方法（确认是否命中 Bug）
在 S12508 上执行以下命令，对比添加rule 30前后的输出差异：
bash
运行
# 查看策略路由的配置和状态
display ipv6 policy-based-route
# 查看NPU上的策略路由硬件表项
display ipv6 policy-based-route hardware
# 查看ACL规则的硬件下发状态
display acl ipv6 all hardware
异常状态（未添加rule 30）：display ipv6 policy-based-route hardware中看不到业务地址 b 对应的表项；
正常状态（添加 / 删除rule 30后）：表项已正常下发，流量匹配成功。
三、根治方案（按优先级排序）
方案 1：升级到修复后的稳定版本（推荐，彻底解决）
R7639P03 存在多个 IPv6 策略路由相关缺陷，建议升级到官方修复版本：
推荐版本：R7639P05H01 或 R7650 系列稳定版
升级后，策略路由初始化流程正常，无需再通过添加rule 30“唤醒”。
升级注意事项（双机环境）：
两台 S12508 主备堆叠，必须同步升级到同版本；
升级前备份配置，避免业务中断；
升级过程中 NPU 芯片会重启，业务会短暂中断（约 5-10 分钟），需在维护窗口操作。
方案 2：临时规避方案（不升级版本，仅临时生效）
如果暂时无法升级版本，可通过以下两种方式规避：
方式 A：在 ACL 中保留一条 “占位规则”
在业务地址 b 的 ACL 中，保留一条不影响业务的规则，触发表项下发：
bash
运行
acl ipv6 basic 3000
rule 10 permit source 业务地址b 128
# 添加一条占位规则，不影响业务，仅触发表项下发
rule 99 permit source ::1 128
::1是 IPv6 环回地址，不会出现在业务流量中，不会影响正常转发。
方式 B：重新绑定策略路由
每次修改策略路由后，执行以下命令强制刷新表项：
bash
运行
system-view
interface 入接口
undo ipv6 policy-based-route pbr-b
ipv6 policy-based-route pbr-b
重新绑定会触发策略路由的重新下发，强制写入 NPU 硬件表项。
四、关键验证步骤（升级 / 配置后）
执行display ipv6 policy-based-route hardware，确认业务地址 b 的表项已正常下发；
从公网 IP 地址 a ping 业务地址 b，同时在 S12508 上开启 debug：
bash
运行
debugging ipv6 policy-based-route all
terminal debugging
terminal monitor
查看流量是否匹配策略路由的下一跳地址，确认转发路径正确；
验证流量是否按预期转发，无丢包、无延迟。
五、总结
你的问题不是配置错误，而是 R7639P03 版本的 IPv6 策略路由初始化 Bug；
添加rule 30 permit ipv6 any只是临时触发了硬件表项下发，并未修复根本问题；
长期稳定的解决方案是升级到修复后的版本，临时方案仅能维持业务正常，无法避免后续重启或配置变更后再次出现问题。
暂无评论
你遇到的这个问题，确实很像一个经典的ACL规则变更触发了PBR硬件表项刷新的案例。你添加rule 30这个操作，很可能恰好“唤醒”了设备，让它重新下发了一遍策略。
原因分析：为什么策略最初会“感觉没生效”？
你的策略最初不生效，很可能不是配置有误，而是因为它没有从控制层面成功下发到接口板卡的转发芯片（硬件）里去执行。
分层转发架构：S12508这类高端交换机是控制层面（CPU负责路由协议、生成PBR表项）与转发层面（硬件芯片专责高速转发）分离的。只有当路由表、PBR表项等信息成功“下发”到转发芯片后，数据包才能按策略转发。
下发失败的诱因：根据S12508的已知案例，以下几种情况都可能导致PBR无法正确下发到硬件，软件版本
R7639P03也可能存在相关的潜在问题：PBR下一跳路由不可达：这是最常见的原因。你之前的操作已确认路由没问题，所以可以排除。
硬件资源耗尽：接口板的ACL或PBR硬件表项资源不足。
软件Bug：特定版本的软件，可能存在因ACL变更（如
rule 30的添加和删除操作）才触发PBR正确下发的情况，这通常是版本已知问题。
为什么加了rule 30又删除后，策略又能“持续生效”？
你添加rule 30 permit ipv6 any这个操作，改变了PBR所引用的ACL。ACL规则的变化（增删条目）会触发设备重新进行计算和下发，这个过程相当于对PBR规则进行了一次“强制刷新”。
关键点在于：一旦ACL/PBR策略被成功触发更新并下发到了硬件表项中，短期内（只要没有新变更）就不会自动失效。因此，你删除rule 30后，之前已经被“纠正”并固化在芯片里的PBR表项依然在生效。
排查与预防措施
为了彻底解决这个隐患，建议你按以下步骤操作：
检查PBR硬件下发状态
连接设备，执行以下命令，重点观察对应槽位的IPv6 PBR信息，看display ipv6 policy-based-route的详细输出中是否出现not support或no resource等异常提示。display ipv6 policy-based-route slot <入接口所在槽位号>检查硬件ACL资源消耗
此命令可查看当前ACL资源的分配和使用情况，帮助你判断是否是资源耗尽导致下发失败。display qos-acl resource slot <入接口所在槽位号>检验并优化现有ACL配置
执行display acl ipv6 all，检查规则中是否包含某些复杂或不支持的匹配项（如object-group）。尽量用精确的地址或前缀列表来匹配，减少不必要的复杂性。考虑升级软件版本（最重要的一步）
你当前的R7639P03版本，很可能存在PBR刷新或下发的软件缺陷。这是最根本的解决方案。升级前：务必做好配置备份，并在维护窗口期操作。
升级后：确保系统镜像和Bootrom都升级到H3C官方推荐的目标版本。
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论