SRv6 Policy 数据中心跨域流量调度：从配置到落地避坑

简介：面向数据中心规划、建设与运维人员的技术方案文档，聚焦传统架构扩展性差、维护成本高、资源利用率低等痛点，提出以整合能力、虚拟化能力、自动化能力和绿色节能为核心的建设框架。内容从网络架构切入，介绍一体化交换、无丢弃以太网、性能支撑、网络服务虚拟化与服务器虚拟化等关键技术，并结合指挥学院场景给出目录式落地参考，便于读者对照理解设计目标如何转化为实际部署。资源内含1个doc文档，压缩包约2.68MB，目录按总述、技术实现等章节编排，结构清晰；从需求梳理到技术选型均有展开，可直接用于数据中心方案设计、课程设计或项目投标的参考模板。目前已有47人学习下载，适合需要快速搭建方案框架并了解新一代数据中心技术选型的工程与教学人员。

1. 数据中心建设方案为什么先把宝押在 SRv6 Policy 上

一份数据中心建设方案，写到网络部分最容易变成机房平面图和设备清单，但真正决定两年后运维体验的，往往是数据中心之间那几十条跨机房路径怎么被管住。我在IDC和政企DCI项目里反复遇到同一个现象：Underlay路由学得通，业务却“玄学”地绕路、丢包、抖动，查到最后都是策略粒度不够，流量被默认路由带到了不想走的链路上。

这篇笔记围绕一个核心结论展开：数据中心的跨域流量调度需要显式路径能力，而用 SRv6 Policy 做数据中心间 policy 是目前最值得投入的方案。它把“从A到B的流量走哪条链路、故障后切到哪条备选路径”变成一段可配置、可查询、可手动干预的策略，而不是交给IGP和ECMP去猜。适合正在做数据中心间互联规划、被多云出口或双活流量折腾过的网络架构师和运维工程师阅读，下面按“选型—配置—路由联动—避坑—验证”走一遍。

2. 组网规划与 policy 选型：数据中心间流量为什么不能用默认路由打发

2.1 数据中心间互联的三种诉求，哪种才需要引入 SRv6 Policy

先说清楚这个方向值不值得做。数据中心间流量大概逃不出三种诉求：同城双活要求时延可预期，两条物理链路哪怕差 0.5ms，数据库同步都能看出差距；两地三中心关心主备切换能不能在秒级完成，默认路由只能等IGP收敛，收敛时间在故障场景下不可控；多云出口则是大量前缀要按业务打不同的策略路由，纯靠BGP属性堆 community 会复杂到没人敢动。

SRv6 Policy 解决的是这三类场景里的同一个痛点：路径不可编程。传统组网里，头端设备只能看到路由表，看不到“这条流量会经过哪几个节点”，一旦某段链路拥塞，运维没有任何手段把它拨到另一条路上。SRv6 Policy 把整条路径编码成有序 SID 列表，头端设备显式地把流量封装进这条段列表，路径变成了一等公民，可以被查、被比较、被手动切换。如果你只维护一个单机房，那确实用不上；但只要你的建设方案里有第二个机房、第三条专线，或者对外提供跨机房带宽，SRv6 Policy 就不是锦上添花，而是把流量调度从黑匣子变成可操作对象的关键一环。

2.2 从业务诉求到 policy 形态：把需求翻译成配置参数

在敲任何配置之前，我会先逼着自己把业务诉求翻译成一张参数清单。这个习惯帮我避过很多返工，因为 policy 一旦上线，改 endpoint 或 color 往往牵动两个机房的防火墙策略、BFD 配置和监控告警，不是改一行配置那么简单。

下表是我在做跨数据中心互联方案时常用的设计清单，建议在实施方案评审阶段就逐行确认。

把这张表填完，基本就知道这个方案要做到多细了。比如同城双活业务，Color 按业务线划分，每个 Color 下面挂两条 SList，一条走低时延专线，一条走备用链路，SBFD 间隔压到 100ms，故障感知后立刻切到备用 SList；两地三中心则相反，候选路径优先级差异拉到 100 以上，避免轻微抖动就来回往返。

这里特别提醒一点：常见做法是让 Controller 统一计算和下发病程，但很多现网环境的 Controller 还没建起来。我一般会选择先在头端设备上手工配置 policy，把路径状态跑稳定之后，再决定要不要接 Controller。手工配置的优点是每条路径的含义都清清楚楚，排障时不至于对着 Controller 下发的几十条 SList 一脸茫然。

3. 数据中心间 SRv6 Policy 配置落地：单 CP 多 SList 场景如何把两条初始路径写进去

3.1 配置骨架：policy、endpoint 与候选路径

我在很多机房割接时见过完全具名的配置风格，这里先用一段贴近商用设备 CLI 的示例把骨架搭出来。不同厂商的字段名会有些差异，但 SRv6 Policy 的模型是一致的，照着这份配置能对照到自家设备上。

segment-routing ipv6 traffic-engineer policy DC1_TO_DC2 color 100 endpoint 2001:db8:0:100::1 binding-sid 10001 candidate-path preference 100 segment-list SLIST_A segment-list SLIST_B segment-list SLIST_A index 10 sid ipv6 2001:db8:0:100::1 index 20 sid ipv6 2001:db8:0:200::2 segment-list SLIST_B index 10 sid ipv6 2001:db8:0:100::1 index 20 sid ipv6 2001:db8:0:300::2 sbfd enable sbfd remote-discriminator 10001

这段配置表示头端设备建立了一条名叫 DC1_TO_DC2 的 SRv6 Policy，本端通过 BGP 或 IGP 学到远端 2001:db8:0:100::1 的可达性，color 100 用来标识“这是一组同城双活路径”。binding-sid 10001 是本端设备给这条 policy 的本地索引，后续引流和封装都靠它。candidate-path preference 100 定义了候选路径的优先级，preference 值越大的路径越优先成为活跃路径，现网建议主备路径之间拉开一定数值差距，避免两条路径的优先级过于接近导致故障恢复时反复横跳。

3.2 单 CP 多 SList 的语义与“初始两条 SList”的选路策略

再看候选路径下面挂着的两条 SList：SLIST_A 和 SLIST_B。这就是热词场景里反复出现的“单 CP 多 list 场景”——一个候选路径（Candidate Path）下挂多个段列表（Segment List），初始两条 SList 分别编码了不同的转发路径。SLIST_A 经过 2001:db8:0:200::2，走的是低时延专线；SLIST_B 经过 2001:db8:0:300::2，走的是带保护的备用链路。两条 SList 都挂在同一个候选路径下，意味着它们共享同一个 policy、同一个 color，通过权重或主备机制决定流量怎么分配。

要是把两条 SList 拆到两个 candidate-path 里，语义就变了，它们会变成两条互相竞争选优的独立候选路径，preference 高的那个当选，另一个只在故障时接管。单 CP 多 SList 的好处是：当主备切换发生时，policy 自身依然是 Active 状态，头端设备不需要重新选候选人，只需在内部完成 SList 的重新优选，切换粒度更细，状态机也更干净。初始两条 SList 的意义就在于此，一条为主、一条为辅，SBFD 快速探测到 SLIST_A 的路径断了之后，流量被切到 SLIST_B，中间不需要等 IGP 重新收敛。

3.3 参数怎么调：SBFD、回切与 SID 校验

配置能跑通只是第一步，参数不调好，割接当晚就容易翻车。我先说 SBFD，它决定了设备多快能感知到 SRv6 Policy 的路径故障。SRv6 Policy 在转发路径断开时，底层链路可能还通着，尤其是光模块故障或中间节点 CPU 异常时，普通 BFD 探测不到，流量会持续打到黑洞里。SBFD 是带内双向转发检测，直接复用 SRv6 数据面做探测，开销更小、发现故障更快。我通常会先把 SBFD 的探测间隔从默认值压到 100ms~150ms，侦测乘数保持默认 3，这样能在 300ms~450ms 内完成故障发现和路径切换。间隔再低会增加头端和目的节点的 CPU 压力，在现网没有特别强的低时延要求时我不建议低于 50ms。

然后是回切。故障恢复后，如果配置了自动回切，SLIST_A 一恢复，流量会自动回到原主用路径。这个行为在双活场景下会导致一次瞬断，因为回切本身是一次转发切换，状态需要重新同步。我的习惯是：第一阶段全部关闭自动回切，由运维确认 SList 状态稳定后手动回切；等上线三个月、路径质量全部摸透后，再把自动回切打开。调试期间如果觉得流量去向难判断，可以临时把主用 SList 的 preference 调高或调低，观察流量是否跟着切换，验证完再改回来，这是最直接的对照实验。

4. 大型数据中心用 BGP 承载路由时，policy 怎么跟路由表联动

4.1 BGP 在数据中心里的双重职责：Underlay 通互联，Overlay 通租户

在大型数据中心使用 BGP 进行路由是当前的主流形态，但它承担的职责要拆成两层看。Underlay 层用 iBGP/eBGP 建立设备间的 IPv6 可达性，把每个节点的 SRv6 回环地址和 SID 信息传播到全网，SRv6 Policy 的 endpoint 地址正是通过这层 BGP 学到的。Overlay 层则承载租户或业务的真实路由，常见做法是 EVPN-VXLAN 叠加在 IPv6 Underlay 上，或者用 BGP IPv6 前缀路由直接传递业务流量。二者分开的原因是收敛域不同：Underlay 的变化要尽快让全网知道，Overlay 的路由量往往大得多，混在一张表里会把 Underlay 的收敛速度拖垮。

数据中心间 policy 在这个体系里的位置，像是给 BGP 学习到的顶层前缀加了一层“路径偏好”。BGP 路由表只能告诉设备“下一跳是谁”，SRv6 Policy 则告诉设备“去这个下一跳要走哪条显式路径”。两者联动起来，流量才能既选得对路由，也走得好路径。

4.2 让 BGP 发布 SRv6 相关路由：BGP-LS 与 SID 传播

先把 BGP 侧的关键配置放出来，这段配置的意义在于把 SRv6 Policy 需要的路径信息托底。

router bgp 65001 address-family ipv6 network 2001:db8:0:100::1/128 exit-address-family address-family link-state link-state segment-routing ipv6 traffic-engineer advertise dae srv6-policy exit-address-family

第一段 address-family ipv6 发布的是本端设备的 SRv6 回环地址，保证全网 BGP 都能学到对端 PE 的可达性；第二段是 BGP-LS 地址族，它负责把本端 SRv6 Policy 的 TEA（Traffic Engineering Attributes）信息上送给 Controller 或邻居设备。这里的逻辑要理解清楚：SRv6 Policy 是头端本地的转发状态，BGP-LS 上报它，是为了让 Controller 能收集全网 policy 状态，并据此计算跨数据中心的优化路径。如果只是手工配置 policy 不上报 BGP-LS，policy 也能工作，只是少了全网视角的调度能力。

4.3 引流与过滤：哪些流量走 policy，哪些流量必须绕过

路由和 policy 都通了，最后的问题是“流量怎么走进 policy”。常见做法是引流路由，把匹配特定下一跳或特定 color 的 BGP 路由显式绑定到 policy 上。动作一般分两类：一类是按下一跳引流，所有去往 endpoint 地址的流量都自动走对应 policy；另一类是按业务前缀引流，比如只让 10.1.0.0/16 这条业务段的流量走 policy，其余流量继续查普通路由表。过虑同样重要，语音、视频会议这类交互性强的流量我会故意绕过 policy，让它们直接走 Underlay 原生路径，避免 SRv6 隧道封装带来的额外时延抖动。

在大型数据中心用 BGP 进行路由联动时，最容易被忽略的一个点是把 BGP 下一条与 policy endpoint 做一致性校验。很多排障现场出现“policy 是 Active 的，但业务流量没走它”的怪象，追下去就是引流条件没匹配上：BGP 路由的下一跳是环回地址的 IPv4 形式，而 policy endpoint 用的是 IPv6 地址，两者对不上，流量自然走不进 policy。记住一个口诀：先看路由表下一跳，再看 policy endpoint，最后看引流规则，三者一致，流量才会进隧道。

5. SRv6 Policy 落地避坑：5 个高频坑的现象、根因与解法

5.1 主路径闪断后切不回来，业务长时间悬在备路上

现象：SBFD 检测到主路径故障，流量成功切到备用 SList。主路径几分钟后恢复，policy 状态也显示 Active，但流量一直不回切，业务持续走在次优路径上。

原因：多半是关闭了自动回切但没有配置手动回切路径，或者手动回切时目标 SList 的 SBFD 状态还没完全恢复，设备判定它不满足回切条件。另一种可能是主备路径的 preference 差值没有拉开，设备在阈值边界反复比较导致回切判断失败。

解决：配置回切前加一条前置校验，确认目标 SList 连续三个探测周期无丢包再执行；把主备 preference 差值保持在 50 以上。割接前在维护窗口里实际演练一次“手动关主路径→观察切换→恢复主路径→手动回切”，这一步省不掉。

5.2 policy 显示 Active，业务流量却完全不进隧道

现象：policy 状态正常，SBFD 也在 UP 状态，但抓包看到业务流量还是裸路由转发，完全没有 SRv6 头封装。

原因：引流规则没有真正命中业务前缀，或者 BGP 路由的下一跳与 policy endpoint 不匹配。这种问题隐蔽在路由表里，光看 policy 状态根本发现不了，我把它叫作“黑匣子式陷阱”。

解决：按三条线排查。先查 BGP 路由表里业务前缀的下一跳地址，确认和 endpoint 一致；再查引流策略的匹配顺序，看是否有更靠前的 deny 规则把流量放过了；最后在头端设备上用 packet-tracer 模拟一条业务报文，看它实际匹配到的是 policy 还是普通路由。

5.3 单 CP 多 SList 场景下，第二条 SList 永远只在配置里“存在”

现象：单候选路径下配置了两条 SList，SLIST_A 和 SLIST_B 都写在配置里，但设备一直只用 SLIST_A 转发，SLIST_B 连 SBFD 都不建立。

原因：单 CP 多 SList 的语义不等于裸的负载分担。如果两条 SList 没有配置 weights 或 loadshare 参数，设备默认只选择 preference 最高的那条 SList 作为活跃路径，另一条只在活跃路径故障后才启用，平时完全是冷备状态。

解决：想让两条 SList 同时承载流量，需要为每条 SList 配置转发权重，比如权重 1:1 就是均分。想让一条为主、一条为辅，则不配权重，保持现在的冷备逻辑。设计阶段把这个语义定清楚，别等到流量分布和预期不符才开始猜。

5.4 新增一条 SList 导致全网 policy 抖动

现象：在某个数据中心间 policy 里新增了一条 SList，结果不只是这条 policy，相邻机房的几条 policy 也相继报错，控制平面日志里全是 SID 异常告警。

原因：SRv6 的 Locator 和 SID 在规划时没有严格区分，新加的 SList 里用了和其他 policy 重叠的 Binding SID 或节点 SID，头端设备索引 policy 时发生了冲突。

解决：给每个数据中心规划独立的 SRv6 Locator 段，Binding SID 使用专门保留的区间，在新增 SList 前用命令查一下目标 SID 已经被哪些 policy 占用。这个坑在多个 controller 同时下发时最常出现，人工配置时反而容易注意到。

5.5 Underlay ECMP 与 Policy 叠加，时延抖动呈锯齿状

现象：业务流量明明走了 policy，但时延曲线一抖一抖的，没有规律，像是在两条链路之间随机跳。网络团队查了两天，最后发现 Underlay 的等价多路径一直开着。

原因：Policy 显式指定了一条 SList，但这条 SList 里的某些节点之间仍存在 ECMP 等价路径，流量在隧道里被 ECMP 二次打散，导致同一条业务流的两个报文可能走不同物理路径，时延当然只能跳动。

解决：两个方向。要么把 policy 的 SList 写得更深，把每一跳都改成显式 SID，彻底掉 ECMP 的阴影；要么把该段链路的 ECMP 收敛为单路径。一般我会倾向后者，因为显式逐跳 SID 会吃不少 SID 资源。判断标准很简单：抖动段的物理路径是否只有两条，如果是，直接收敛 ECMP 见效最快。

6. 割接前把结论一条条验证进去：查路径、看 BFD、再回切

6.1 三张命令表把状态钉死

进入维护窗口前，我习惯先做一轮静态体检。以下三条命令对应三张表：policy 总表看路径状态，BFD 表看故障探测，流量统计表看实际转发情况。

display segment-routing ipv6 traffic-engineer policy name DC1_TO_DC2 display srv6-policy sbfd brief display segment-routing ipv6 traffic-engineer statistics

第一条看 policy 是否 Active、当前活跃的 SList 是哪条；第二条看 SBFD 的探测间隔和状态，间隔在不在预设值；第三条看走 policy 的报文计数是否持续增长。这三张表要连续观察十分钟，确认计数单调增长而不是原地抖动。

6.2 割接验证步骤：手动故障注入与回切

拿到稳定基线后，再做一次故障注入演练。第一轮，手工把主用 SList 的 preference 调低，观察流量是否在几个探测周期内切到备用 SList，统计切换耗时；第二轮恢复主用 SList 的 preference，确认回切正常；第三轮模拟中间节点宕机，观察 SBFD 在指定间隔内是否完成故障上报。

这套流程做完，policy 的可靠性才算真正立在数据上，而不是立在“配置看着没什么问题”的直觉上。回切动作如果是手动的，我一般会把回切命令写在运维脚本里，而不是现切现场敲，敲错一个字段在割接窗口里没有任何后悔药。

SRv6 Policy 在数据中心间的建设方案里不是银弹，它解决的是路径可控问题，解决不了带宽不足和链路质量问题。我踩过的教训是：方案里给 policy 预留的状态监控点位越多，上线后半夜的电话就越少。希望帮到你。

本文还有配套的精品资源，点击获取