在H3C Cloud Lab里折腾SRv6 TE Policy：一个网络工程师的踩坑实录与配置复盘-程序员充电站

在H3C Cloud Lab里折腾SRv6 TE Policy：一个网络工程师的踩坑实录与配置复盘

第一次在H3C Cloud Lab里配置SRv6 TE Policy时，我本以为按照文档步骤操作就能轻松实现流量工程，结果却遭遇了各种意想不到的问题。这篇文章不是一份标准化的配置指南，而是一个真实的技术探索过程记录——从最初的拓扑规划到最终的问题诊断，我想分享那些官方手册里不会写的"坑"和排查思路。如果你也正在学习SRv6技术，或许这些经验能帮你少走些弯路。

1. 实验环境搭建与前期规划

在开始敲命令之前，合理的拓扑设计是成功的一半。我选择了五台VSR设备组成核心-边缘架构，模拟典型的企业骨干网场景。这个规模既能体现SRv6 TE Policy的价值，又不会让实验过于复杂。

关键规划点包括：

所有设备配置OSPFv3作为IGP协议，区域0统一采用0.0.0.0
每个节点分配/128的环回口地址（2001::X/128）作为Router-ID和SRv6封装源
物理接口使用/124的IPv6地址段，遵循X.Y.Z::N的编址规则（如2013::/124表示1-3号设备间的链路）

提示：在模拟器环境中，建议先保存基础配置快照，这样当SRv6部分出现问题时可以快速回退到已知正常状态。

配置OSPFv3时遇到第一个小插曲——不同设备对接口模式的默认处理方式不同。例如在VSR-88_2上需要显式配置：

[VSR-88_2]interface GigabitEthernet0/0/0 [VSR-88_2-GigabitEthernet0/0/0] port link-mode route

而其他设备可能默认就是路由模式。这个细节如果不注意，会导致邻居关系无法建立，但错误提示并不直观。

2. SRv6基础配置与Locator设计

SRv6的核心在于SID（Segment ID）的分配策略。我采用了"A+B"的Locator命名方案：

A100::/96 → VSR-88_1
A200::/96 → VSR-88_2
...
A500::/96 → VSR-88_5

这种命名方式在查看路由表时特别有用，一眼就能识别SID归属。每个Locator的静态部分分配16位，为后续可能的扩展留出空间。

节点SID配置示例：

[VSR-88_1]segment-routing ipv6 [VSR-88_1-segment-routing-ipv6] locator h3c ipv6-prefix A100:: 96 static 16 [VSR-88_1-segment-routing-ipv6-locator-h3c] opcode 1 end

这里有个容易混淆的点：opcode后面的数字只是本地标识符，实际的SID由Locator前缀+Function Value构成。比如上述配置生成的完整End SID是A100::1。

3. TE Policy配置中的"陷阱"

当基础SRv6 BE（Best Effort）工作正常后，开始配置TE Policy。我的目标是让VSR1到VSR5的流量走特定路径：VSR1→VSR3→VSR2→VSR4→VSR5。

关键配置步骤：

创建Segment List定义路径
建立Policy绑定color和end-point
设置候选路径优先级

[VSR-88_1-srv6-te] segment-list 1 [VSR-88_1-srv6-te-sl-1] index 10 ipv6 A300::1 # VSR3的End SID [VSR-88_1-srv6-te-sl-1] index 20 ipv6 A200::1 # VSR2的End SID [VSR-88_1-srv6-te-sl-1] index 30 ipv6 A400::1 # VSR4的End SID [VSR-88_1-srv6-te-sl-1] index 40 ipv6 A500::1 # VSR5的End SID

查看Policy状态显示为UP，路由表也显示路径有效，但实际ping测试却完全不通。这是整个实验中最令人困惑的部分——所有配置看起来都正确，为什么流量就是过不去？

4. 故障排查与问题定位

通过系统日志和抓包分析，发现问题出在几个关键环节：

抓包发现：

出方向设备确实生成了ICMP请求
路径中的中间设备没有收到任何报文
没有明显的错误计数器增加

最终定位到两个核心问题：

H3C设备默认不会将私网路由迭代到End.DT4 SID，需要额外命令：
```
[VSR-88_1-bgp-default-ipv4-h3c] segment-routing ipv6 traffic-engineering
```
VRF实例的RD值必须两端一致，否则路由会被视为无效

现象	可能原因	解决方案
Policy UP但无流量	路由未迭代	检查BGP VPNv4配置
部分节点不通	SID分配冲突	验证Locator唯一性
偶发性丢包	模拟器限制	降低测试频率