半夜两点多被叫到机房这种事碰上过一次就够记一辈子。当时核心链路上一个业务流量突发拥塞三个系统同时告警群里第一反应是“动态路由会自动绕路不用管”。我一边往机房赶一边盯着监控结果抖动整整持续了一刻钟。事后查转发路径发现路由协议确实“绕”了但绕去的那条下一跳链路本身也堵着等于从一个坑跳进了另一个坑。就是从那次之后我开始对“让路由协议自己决定一切”这件事产生了根本性的怀疑。后来我们花了小半年时间落地了一套内部代号为MRC的方案全称是Multi-plane Routing Control多平面路由控制。它的技术底座由两部分组成静态SRv6路径编排和多平面网络拓扑。这篇文章我会把整套逻辑完整拆开——它到底解决什么问题、静态SRv6的Segment List怎么设计、多平面拓扑怎么切、上线后踩了哪些坑以及我们能复现的排错链路。适合正在做骨干网、数据中心核心网络或园区关键链路改造的朋友参考。1. 叫它“协议”有点勉强MRC本质是一套路由编排玩法1.1 动态路由的“自由选路”为什么不让人放心先说个扎心的现实传统网络里流量走哪条路不是运维说了算而是IGP和BGP的算法说了算。OSPF算代价、BGP比AS路径哪个指标优就往哪走。听起来很智能可一旦遇到故障问题就暴露了。举个例子。某条链路中断OSPF要重新洪泛LSA、重新跑SPF骨干路由器几百条路由全部重算。这个过程短则几百毫秒长则几秒。BGP就更夸张路由撤销要一层层传路径切换可能要几十秒。对视频会议、实时交易这类业务来说这几十秒就是事故。动态路由还有一个老毛病——ECMP发散。一组等价路径里有一条链路轻微抖动流量被哈希打散后可能全挤到剩下的路径上把原本正常的链路打爆。你查监控会看到“拥塞点莫名其妙转移了”跟捉迷藏一样。作为运维我最受不了的不是故障本身而是路径不可预测上一秒好好的下一秒转发就走了一条你根本没想到的路。1.2 MRC怎么把“自由路由”变成“按轨行驶”MRC的设计思路并不复杂核心就四个字确定性与隔离。我们承认动态路由协议在网络基础可达性上有价值但在关键业务路径上不再把选择权完全交给动态算法而是用静态SRv6把路径“钉死”。同时用多平面拓扑把不同等级、不同风险的业务拆到相互独立的转发平面上让故障一个平面一个平面地来而不是所有业务一起陪葬。这个方案之所以叫“协议”其实是当时项目起的代号。它并不是新发明一个报文头也没有改动SRH框架而是利用SRv6现有的Segment Routing扩展头、IPv6可达性机制以及多路由实例技术把它们组合成一套覆盖转发面、控制面和运维流程的方法。打个比方动态路由像一群私家车在高速公路上自己选路导航说走哪就走哪能绕路但也会堵车MRC方案则像地铁系统——轨道是固定铺设的每列地铁按既定线路运行不同线路之间物理隔离一条线故障不会影响另一条。付出的代价是轨道建设成本和人工维护成本换来的是可预期的到达时间和故障边界。1.3 适合与不适合的场景提前把丑话说在前面任何方案都有适用范围MRC也不例外。我在推广这套做法时吃过不少“不可用”的闭门羹原因是他们在不合适的场景里硬套。适合的场景大概有这几类数据中心核心东西向流量占比高路径需要稳定可预测尤其跨AZ或跨园区互联园区骨干/城域承载业务模式相对固定流量模型变化不大适合静态编排关键业务专线金融、政务、视频会议这类对SLA极敏感的流量需要明确知道流量走了哪条链路多租户或多业务承载网各业务安全域本就该隔离多平面拓扑顺理成章。不推荐的场景海量动态接入的边缘网终端上下线频繁路径频繁变化手工静态SID策略会变成运维噩梦严重依赖自动化弹性的云原生场景容器级调度每秒钟都在变流量静态编排跟不上没有专职网络团队的场景MRC维护门槛不低没人懂SRv6就不要急着上。说得直白点MRC是用“运维人员的确定性”置换“协议的自我调整能力”你的团队能不能把这个确定性地维护下去决定了方案上限。2. 静态SRv6凭什么值得“手工”确定性路径的朴素力量2.1 动态SRv6策略 vs 静态SRv6编排一场返璞归真市面上聊SRv6很多方案都是配合SDN控制器动态下发策略。控制器集中计算路径下发Segment List网络设备只管执行。这种模式灵活、智能、自动但有一个隐含前提控制器必须高可用、路径计算必须正确、下发通道必须稳定。我们内部实际试点过动态SRv6后来放弃了不是因为功能不行而是每次控制器升级、版本迭代或者网络割接都要做大量回归验证。一次控制器上加载了新拓扑结果某条业务路径被重新计算到一条MTU不达标的链路上大包全丢排查了整整一个下午。当时我就想与其信任一台“大脑”不如把关键路径牢牢攥在自己手里。静态SRv6的好处非常直白零控制器依赖没有“控制面不可用导致全网策略失效”的隐患排障直观路径就是配置文件里写好的Segment List出问题一眼就能看到是哪个节点不对确定性SLA业务路径固定不变容量规划、带宽预留都能按固定链路来做灰度可控一条策略一条策略上出问题回退只要删配置。当然静态也有代价。网络规模一上来手工配置量指数级增长路径每增加一条就要人工确认一遍。所以我们在MRC里用多平面拓扑把规模“切碎”——每个平面内的节点数和业务路径数量控制在可人工维护范围内。这是静态SRv6和多平面能共存的前提。2.2 Segment List怎么设计从接入到核心的路径表达静态SRv6的核心工作是设计出从源到宿的Segment List简化版路径栈。理解它之前有一组概念必须清楚。SIDSegment Identifier在SRv6里是一个128位IPv6地址通常分成Locator和Function两部分。Locator指明该SID所在节点/实例Function表示具体行为如转发到某邻居。End SID节点的“终点”SID表示到该节点即可相当于站台。End.X SID节点上绑定了指定出接口的邻接SID相当于“从某个出站口继续走”。一条业务路径在SRv6头里就是一组有序SID列表。例如从接入设备CE1到汇聚层PE1再到核心P1最后到P2和PE2SRH里依次填充对应节点的SID就是1→2→3→4→5。静态的意思就是这个列表是我们人工定义的不交给控制器。我们内部做SID规划时有一套铁律Locator前缀按平面分配节点SID全网唯一邻接SID只加在关键出接口上。平面A用一段地址空间平面B用另一段从头上就杜绝SID跨平面串扰。下面是我们常用的一张规划示意表节点角色所在平面Locator前缀节点SID用途接入设备P-101平面A2001:db8:a001::/480:1业务入口转发汇聚设备-01平面A2001:db8:a002::/480:5汇聚节点转发核心设备-02平面A2001:db8:a003::/480:9核心节点转发接入设备P-201平面B2001:db8:b001::/480:1平面B业务入口汇聚设备-05平面B2001:db8:b002::/480:5平面B汇聚转发注意表格里的细节两个平面的接入节点虽然Function部分可能重叠0:1但Locator前缀完全不同所以最终SID地址是全网唯一的。这件事在配置静态策略时极其重要——SID冲突往往不是Function冲突而是Locator规划重叠。2.3 一份可以直接抄的静态SRv6配置骨架考虑到不同厂商设备的命令行有差异我尽量用配置文法的角度展示不绑定具体品牌。真实落地时请对照你手头设备版本的命令参考语法调整。下面是一个接入设备上让“指定业务VRF的流量封装SRv6头并走固定路径”的核心配置片段# 全局使能SRv6 segment-routing srv6 enable locator MRC-PLANE-A prefix 2001:db8:a001::/48 enable # 为本节点定义End SID代表节点本身 sid-local fc00:0:a001:: behave end # 为关键下行接口定义End.X SID sid-local fc00:0:a001::5 behave end-x interface GigabitEthernet0/0/5 next-hop 2001:db8:a002::1然后是静态SRv6策略的定义。假设业务流量要从接入层走到核心设备-02再进入汇聚设备-01Segment List是这个顺序# 静态SRv6策略 static-srv6-policy MRC_POLICY_A_TO_CORE color 100 endpoint 2001:db8:a003::9 segment-list 2001:db8:a002::5 2001:db8:a003::9 bind-sid 2001:db8:a001::b100这段配置的意思很直白源设备在收到携带对应颜色/目的地址的业务流量后封装SRv6头先压入汇聚设备-01的邻接SID再压入核心设备-02的节点SID。流量就会严格按这个顺序穿过网络。最后bind-sid是在源节点上放一个本地绑定的SID方便业务VRF直接引用这条策略。业务割接时最稳的验证命令是看SRH里实际压入的SID列表和配置的Segment List是否一致。如果粘贴配置时手滑把顺序写反了traceroute的结果会非常诚实——流量会绕地球一圈。3. 多平面网络拓扑把物理网络“切成”几条并行轨道3.1 平面是怎么切出来的物理隔离还是逻辑隔离前面反复提到“多平面”现在说清楚它到底是怎么落地的。多平面拓扑的核心目标是把一张物理网络切成多个相互独立“转发域”。切法有两种风格。第一种物理隔离。每个平面用独立的设备、独立的板卡、独立的链路。好处是故障域彻底隔离坏处是成本翻倍设备利用率低。我们只在最核心的那层用了这个方案——真正承担关键业务的那几张设备用独立硬件跑一个平面谁也不跟谁抢资源。第二种逻辑隔离。在同一个物理设备上通过接口分组、独立路由实例、独立转发表来切分平面。接口A组属于平面甲接口B组属于平面乙两台设备间跑多个逻辑实例控制面各走各的通道。成本低、灵活性高大多数场景用这个方案就够了。在实际的MRC网络里我们主要用逻辑隔离但会在关键节点预留物理冗余。比如汇聚层两台设备一台故障另一台接管平面A的业务平面B不受影响。故障域控制的边界是靠“路由表隔离”和“控制面隔离”实现的而不是靠设备数量。3.2 每个平面独立转发表背后的三件事逻辑隔离看起来容易做扎实了需要三方面配合。接口层面给每个物理或逻辑接口打上平面标签。接入业务时流量从哪个接口进来就归属到哪个平面。这一步如果配置错了后面全白搭。我们在每台设备上都会做接口-平面的映射表割接时逐条核对。路由实例层面每个平面有独立的VRF虚拟路由转发实例或独立路由表。平面A跑一张表平面B跑另一张表两张表里的路由彼此不互通除非显式写import策略做跨平面互访。注意不是所有跨平面流量都得禁掉比如管理平面的监控流量就需要访问其他平面的网元所以“隔离”指的是默认隔离需要打通时走明确的策略通道。控制面层面BGP进程、IGP进程、SRv6的Locator通告按平面独立运行。拿BGP来说平面A一个BGP进程只对平面A的邻居发路由平面B同样如此。这样即使一个平面内出现了路由震荡、路由洪泛另一个平面的控制面也不受牵连。这三件事缺一不可。接口分错流量归属就错了路由实例没隔离前缀就会串控制面没隔离一个平面抖动会拖垮全网。我们第一版MRC就吃了一亏接口和转发表都切好了但控制面的BGP没有按平面拆开结果平面A一次路由撤销导致BGP重新收敛平面B的所有会话超时整个网络抖了十秒。3.3 多平面带来的附加收益从被动救火到主动灰度多平面切分完成之后除了故障隔离还有一个很“香”的收益——运维上的灰度能力。以前改核心配置所有业务都在一张网里一次误操作就是全网事故。现在不同业务落在不同平面上新版本、新策略可以先在某个非关键平面灰度测试验证没问题再逐步推广到其他平面。我们甚至可以利用这个特性做“配置预演”在平面A上把整条静态SRv6路径配置完整验证通过后再同步到平面B大大降低了割接风险。另外一个额外收益是容量规划更清晰。每个平面有独立转发表和链路配额流量模型相对固定扩容时能准确算出哪个平面缺带宽、哪个平面有多余容量。之前混在一张网里容量规划靠拍脑袋用了多平面之后直接看各平面的计数器就能定位瓶颈。4. 拼装完整链路静态SRv6指令如何穿过多个平面4.1 平面映射到SRv6Locator前缀就是平面的“车票”当静态SRv6和多平面拓扑要合体时第一步是解决“如何从SRv6的路由视角识别平面”。我们的做法是在Locator规划阶段就给每个平面分配独立的前缀段让SID天然携带平面身份。比如平面A使用2001:db8:a000::/40平面B使用2001:db8:b000::/40。那么看到任何一个SID地址中的/40位段立刻能判断出它属于哪个平面。这个设计带来的最大好处是SID查找不会跨平面误匹配静态策略的Segment List天然不会混用两个平面的SID可观测性增强抓包看到SID就能定位平面归属。关键点在于承载平面A流量的接口、VRF、SRv6策略必须只关联平面A的Locator前缀。如果在平面B的接口上引用了一个平面A的SID流量会直接封装错误——这不是路由问题是配置层面的“串台”。4.2 完整配置链路从接口接入到SRH封装再到业务VRF绑定我们实际操作中把一个新业务接入MRC需要四步每一步都很关键。第一步把业务接口划入目标平面。假设平面A要承载新业务的接入流量在接入设备上把对应口加入平面A的VRFvrf instance PLANE_A rd 100:1 interface GigabitEthernet0/0/3 vrf FORWARDING PLANE_A ipv6 enable第二步启用SRv6并引用目标平面的Locator。这个Locator就是平面A的SID前缀。segment-routing srv6 locator MRC_PLANE_A prefix 2001:db8:a001::/48 enable第三步针对业务目的IP绑定一条静态SRv6策略。把业务流量指向核心设备的端点SID中间穿过已定义好的Segment List。这一步就是前面“2.3”配置骨架的实际运用。这里我特别提醒一点策略里的endpoint必须是最终目的节点的End SID地址而不能是中间节点的否则流量到达中间节点后SRH处理会提前结束导致丢包。第四步把策略和业务VRF关联起来。最简单的方式是在VRF的路由表中加一条静态路由路由的下一跳指向SRv6策略绑定的SIDipv6 route vrf PLANE_A 2001:db8:5::/64 srv6-policy MRC_POLICY_A_TO_CORE这样流量进入VRF后命中静态路由查找发现是SRv6策略指定路径就会自动封装。验证是否真正走通了有两个关键手段。第一个是查策略状态确认静态策略是Up状态而不是失活第二个是traceroute看返回的每个跳是否按我们设计好的SID顺序而不是按传统路由的下一跳。如果中间某跳显示的地址不在规划里大概率是邻接SID绑定错了接口。4.3 故障切换实测BFD打到静态路径的最后一公里静态SRv6策略最让人担心的问题就是“路径钉死了断了怎么办”。这也是我们必须配合BFD和备份路径的原因。我们在每个静态SRv6策略上都会挂一个针对端到端路径的BFD会话。它的作用是持续探测整条策略的可达性而不是只探测本段直连链路。一旦远端不可达BFD快速翻转设备立刻把流量切到备份Segment List——这条备份路径在配置时人工设计通常是另一条物理拓扑完全不同的链路用来避免“两个备胎在同一根管子里”。下面是我们在一套模拟骨干环境下测到的故障切换数据虽然不是生产环境的绝对参考但趋势很有说服力切换场景检测机制收敛时间实测丢包数参考IGP链路中断OSPF重算1.2s ~ 3s数百个动态SRv6策略控制器重新下发控制器感知下发1.8s ~ 4.5s数百个静态SRv6 BFD联动切换备份路径BFD快速检测50ms ~ 120ms0 ~ 1个同一台设备上静态SRv6配合BFD的快速感知与切换比单纯的IGP收敛快一个数量级以上比动态控制器干预更是快得多。重要的不是数字而是切换行为的确定性BFD检测到故障立刻切走中途没有算法等待、没有路由重算风暴。在我们看来静态路径的“备用路径”不是可选项而是强制项。没有备份Segment List的静态SRv6策略等同于把业务架在独木桥上一断就全黑。5. 上线踩坑记录从“黑洞”到“串台”的排查链路5.1 第一坑静态SRv6的策略还活着但流量已经掉进黑洞上线后第一个周末就出问题。某业务的备份流量忽然从监控里消失持续丢包但设备上的SRv6策略状态一直是Up。一开始所有人都懵了——策略没Down怎么转发没了排查链路是这样的看策略状态Up静态策略确认没有问题。看SRH封装抓包发现SID列表还是旧的路径没有变化。查路径上每一跳的可达性策略Up不代表路径底层链路都活着。问题终于浮现路径上某台汇聚设备的端到端链路故障但静态SRv6策略本身只认“下一跳的Endpoint是否可达”没有及时感知底层这个节点已经丧失转发能力。策略还挂着路由表里那台节点的SID也确实存在于路由表可实际流量到了它就再也出不去。这就是典型的“黑洞”——配置没有消失能力却已经消失。这就暴露了一个本质问题静态SRv6的“静态”不等于“不做活性检测”。和动态路由不同SRv6静态策略不会每天自己重新认识拓扑。于是我们后来补齐了两层防护第一层策略节点关联BFD沿路径探测每跳活度第二层针对关键策略加配备份Segment List故障后自动切换。补上之后这类黑洞问题再没出现过。5.2 第二坑平面A流量的转发路径“串台”到了平面B某天接到用户反馈平面A承载的一套管理业务访问某网段的延迟忽高忽低像坐过山车。先怀疑链路拥塞查了一圈没有异常。后来做traceroute才发现流量居然先跳到了一个属于平面B的汇聚设备上绕了一大圈才回来。排查链路对比SID与Locator前缀抓到数据包里的SID前缀属于平面B确认策略引用错了SID。查配置来源发现某台设备的静态路由下一跳错误地引用了平面B的Locator前缀。追溯变更记录原来是割接时复制配置忘了改前缀段。“串台”的本质就是路由泄漏或者配置引用错误。多平面网络的隔离设计再好配置一旦把平面B的SID写进平面A的策略物理隔离就形同虚设。后来我们针对这个问题上线了两道保险一是配置审计脚本批量检测每台设备上跨平面的SID引用二是在Locator前缀上做了路由过滤平面A的IGP/BGP进程只收平面A的前缀其他前缀一律丢弃。这类问题从“靠人盯”变成了“靠系统守”。5.3 第三坑MTU没核准大包踩中了SRH的隐形边界第三个坑是SRv6环境下非常经典、但很容易被忽视的MTU问题。SRH区域头增加了12到16字节左右等于每个IPv6数据包在最外层多了约20字节开销。如果链路MTU本身就是1500封装后实际载荷超过链路能力大包在中间节点就会被静默丢弃。我们当时最典型的故障现象是ping小包100字节正常ping大包1400字节不通。一开始怀疑路径上某台设备配置错了折腾了半天最后抓包才发现是MTU踩线。运维习惯了传统网络“1500 MTU够用”的经验忽略了SRv6外层的额外开销。排查与修复思路也很明确ping 带df-bit和指定包长从 1500 往下逐级减定位丢弃的包长边界快速确认是MTU问题逐跳检查接口MTU看SRH封装后是否超过设备出接口MTU调整端到端MTU规划要么业务侧统一降低应用报文尺寸要么在骨干接口上调整MTU预留SRH空间。吃了这次亏之后我们把“每张业务链路表里永远多留20字节余量”写进了设计规范后续再没因为MTU翻车里。5.4 第四坑SID撞车全网流量乱跳的排查回顾这个坑规模不大但很有意思。某天一条业务路径上忽然出现一个不属于路径规划的节点地址流量到了它那里又原路跳回来。第一反应是静态策略配置错误逐段对照SID却发现配置完全正确。后来抓包梳理SRH发现流量在某个核心节点上被压入了一个“看起来正确但实际是别人家的SID”。追根溯源两个节点在配置Locator时用了重复的Function部分导致全网某段SID解析冲突。传统网络里IP地址冲突会造成路由混乱SRv6的SID冲突危害更大因为它直接干预SRH解析。修复方式也很直接全网扫描SID的唯一性。我们把所有网络设备的SRv6 Locator和SID清单统一汇总按前缀和Function逐条查重定位到冲突的两个节点后给其中一个重新分配SID段。把这个检查固化到上线的标准流程里后来配置新设备前都会先查一遍SID可用表彻底把这个坑填掉了。6. 上线半年后的实际体会与后面想走的路6.1 最值钱的不是技术而是“可解释性”复盘整套MRC落地我最大的体会不是SRv6多高级也不是多平面多能扛而是整张网络变得“可解释”了。以前排查一个端到端问题从路由表查起追着动态协议的行为跑经常要靠猜。现在每条业务流量走了哪条路径、经过哪些节点、在哪一跳切换配置文件里写得清清楚楚抓包一看SRH就都明白了。频发的故障里七成以上不是技术不行而是配置或者操作不规范。静态SRv6的好处是把路径选择权从算法的手里拿回来放回到人的规范里。规范能做到什么程度网络就稳定到什么程度。多平面拓扑在这个基础上再添一层保险故障边界被提前划分好任何一个平面出问题都不会像以前那样全网一起抖。6.2 下一步从“全静态”走向“半自动化”当然静态方案也有天花板。网络规模继续扩大后几千条静态SRv6策略会变成新的运维负担。我们现在规划的方向是**“静态为主、半自动化辅助”**用配置生成器批量生成Segment List和静态策略人工只做审核而不是逐条手敲引入轻量级配置校验工具做预检查重点查SID冲突、跨平面串扰、MTU余量三类高危项未来再考虑加一层集中控制器但它的角色不是动态计算路径而是静态策略的校验与审计所有的路径变更仍然经过人工审批后下发。从我个人的实际维护经验出发不建议一开始就上全动态的SRv6自动化体系。先把静态路径跑熟把故障预案和排查链路打磨清楚再逐步引入自动化工具踩的坑会少很多。网络架构演进这事儿步子迈大了容易扯到很多配置文件的蛋稳扎稳打反而更快。MRC这套方案走到今天算不上什么开创性的新技术但它把一个朴素的道理重新拉了回来网络稳定性的根基从来不是追求最聪明的算法而是把每一步转发路径都变成可控、可查、可预期的存在。如果你正在头疼“动态路由到底把流量送到哪去了”不妨从静态SRv6配一条确定性路径开始试试。