1. 为什么企业多分支组网最后都会摸到 MPLS 这道门1.1 从一次典型的组网翻车说起去年帮一家做连锁零售的朋友梳理网络六十多个门店最早为了省钱用的是普通宽带加自建隧道。刚开始二十个店还行到了四十个店问题就集中爆发了门店收银系统和后台 ERP 之间的对账请求经常超时监控画面隔三差五卡成幻灯片最要命的是各门店的网段规划完全靠拍脑袋一半以上的门店都是 192.168.1.0/24一旦要统一做集中管理地址冲突直接把人逼疯。这种场景下你去跟老板解释“是公网抖动”老板只会回你一句换个能稳的方案。后来这套网络换成了运营商提供的 MPLS 承载专网也就是行业里常说的 MPLS 虚拟专用网络。换完之后最直观的变化不是速度变快而是“不可预期的抖动”消失了跨省门店到总部的往返时延稳定在一个区间内波动不超过几毫秒排障时可以直接按运营商的责任段切开来看问题定位从“猜”变成了“测”。这篇文章我想把 MPLS 这套东西从头到尾捋一遍包括它为什么能解决地址复用和时延抖动、标签交换在数据面到底做了什么、CE 和 PE 对接时哪些参数必须提前算清楚以及现场最容易踩的那几个坑。适合正在做多分支组网选型的运维、正在被专网故障折磨的网络工程师以及需要向管理层解释“为什么这笔钱必须花”的技术负责人。说明本文讨论的是企业级广域承载网络技术全部内容围绕企业内网互联、运营商专线承载展开与任何个人上网行为无关。1.2 MPLS 到底解决了什么别人解决不了的问题要理解 MPLS 的价值先要理解企业广域网的三个原始矛盾。第一个矛盾是私网地址必须复用。任何一家有一定规模的企业都不可能给六十个门店各申请一段公网地址私网地址是必然选择但私网地址一旦跨广域传输就天然存在重叠和不可路由的问题。第二个矛盾是路径必须可控。公网的路由选路是“最短最优”它不管你这条链路是不是拥塞、是不是绕了半个国家而企业的核心交易流量恰恰需要“稳定优先于最短”。第三个矛盾是故障必须能定界。跨运营商、跨省份的链路出了问题如果没有清晰的责任边界甲乙双方就只能互相甩锅。MPLS 的解法很直接它在运营商的骨干网内部用一层“标签”代替了传统的逐跳 IP 查表转发同时在 PE 设备上为每个企业客户维护独立的虚拟路由转发表实例。前者解决了转发效率和流量工程的问题后者解决了地址空间隔离的问题。这两件事组合起来就形成了“一张物理骨干网承载无数张逻辑上完全独立的客户专网”的效果。你在自己门店里用 192.168.1.0/24隔壁那家公司在他们门店里也用 192.168.1.0/24两边在骨干网上跑得互不干扰这就是虚拟专网最核心的魔法。我经常用小区来类比物理骨干网是城市里的道路标签是快递单上的分拣码VRF 是每栋楼里独立的信箱系统。快递员在主干道上只看分拣码决定下一站往哪送不需要知道包裹最终属于哪一户而到了楼下才由楼里的信箱系统去区分这是 3 单元 501 还是 2 单元 302。分拣码让运输变快信箱系统让地址可以重复。少了任何一半这套体系都跑不起来。1.3 四种主流方案的正面对比钱花在哪一目了然选型这件事最怕的是拿单一维度做决定。我整理了一张对比表把企业最常遇到的四种广域互联方案放在一起维度选了实际决策中最容易产生分歧的几项对比维度普通宽带 自建隧道软件定义的广域互联数字专线 / 裸光纤MPLS 承载专网私网地址复用需自行规划易冲突支持靠叠加层实现天然隔离天然隔离PE 侧 VRF 独立时延稳定性差受公网拥塞影响中等可多路径选优最好好可做流量工程开通周期几天几天到两周一个月以上受施工制约两到六周成本模型极低按月宽带费中低含许可与带宽高按里程与带宽计中高按端口与带宽计故障定界能力弱端到端黑盒中等需自建监控强段内清晰强运营商分段负责适合规模十节点以内、非核心业务分支多、业务上云为主两点之间超大流量分支多、核心业务、跨国或跨省这张表里最容易被忽略的是“开通周期”和“故障定界”这两行。很多团队在 POC 阶段只测带宽和时延测完觉得自建方案也能跑就上了。结果真出问题的时候发现公网抖动你没法要求任何人负责而专网抖动你可以直接拿着运营商的 SLA 指标去要说法。对于收银、生产控制、视频会议这类对抖动敏感的业务这个“说法”本身就是成本的一部分。还有一点值得单独说MPLS 承载专网并不排斥其他方案。我经手的项目中比较常见的做法是“核心站点走 MPLS 专网保证稳定边缘非关键站点走普通宽带做备份”用路由策略控制主备切换。这样既控制了成本又保住了核心业务的体验。选型不是站队是分层。2. 核心机制拆解标签、隔离、控制面这三层逻辑2.1 标签交换为什么比逐跳查表更适合骨干承载传统 IP 转发每台路由器收到一个包都要拿目的地址去路由表里做最长前缀匹配。这个动作在核心设备上每秒要做几百万次虽然有硬件加速但表项规模一大、路由震荡一频繁性能压力和收敛时间都会成为问题。MPLS 的思路是在数据包进入骨干网的第一台设备上一次性把“后续怎么走”这件事决定好压成一个固定长度的标签贴在包前面后面的设备只看标签查一张定长的标签转发表直接换标签转发。标签本身的结构值得记一下它是 32 位20 位标签值、3 位实验位常被用作优先级标记、1 位栈底标志、8 位 TTL。20 位意味着单台设备理论上能支持上百万个标签实际部署中远远够用。栈底标志这一位是很多人忽略的关键——它支持标签栈也就是一个包可以贴多个标签外层标签负责骨干网转发内层标签负责标识这个包属于哪个客户、哪条业务。这种“外层走骨干、内层认客户”的分层设计正是虚拟专网能在同一张物理网上承载多客户的技术根基。还有一个细节在倒数第二跳设备上通常会把外层标签弹掉只把内层标签或者原始 IP 包交给最后一跳的 PE。这个动作叫次末跳弹出。它的目的是减轻出口 PE 的负担——出口 PE 不需要再为每个目的网段维护一份外层标签直接按内层信息或 IP 头做最终投递即可。刚接触这套体系的人经常在抓包时看到“最后一跳收到的包没有外层标签”以为是配置错了其实这是设计如此。2.2 VRF、RD、RT三个容易混淆但职责完全不同的东西这三个概念是 MPLS 三层专网的核心也是最容易在面试和排障中被混淆的地方。我用一句话先把它们分开VRF 是容器RD 是身份证前缀RT 是门禁规则。VRF虚拟路由转发实例本质上是把一台物理 PE 设备切成了多台逻辑路由器。每个 VRF 里有一套独立的路由表和转发表还有独立的接口集合。客户 A 的接口绑进 VRF-A客户 B 的接口绑进 VRF-B两边的路由在设备内部根本不碰面。这是隔离的物理基础。RD路由区分符解决的是另一个问题客户 A 和客户 B 都宣告了 10.0.0.0/8PE 之间用 BGP 传递路由时这两个前缀完全一样BGP 会认为是同一条路由。RD 的做法是给每条路由加一个 64 位的前缀变成“RD-A:10.0.0.0/8”和“RD-B:10.0.0.0/8”这样在控制平面上它们就是两条不同的路由了。注意 RD 只影响控制平面不参与数据转发包在转发时不会带上 RD。这一点非常重要很多人误以为 RD 是转发标识结果排查方向完全跑偏。RT路由目标才是决定“这条路由该进哪个 VRF”的开关。它作为 BGP 扩展团体属性随路由一起传递PE 收到路由后拿路由携带的 RT 去比对本地各个 VRF 配置的导入 RT匹配上就导入匹配不上就丢弃。导出 RT 和导入 RT 是分开配置的这个分离设计带来了很强的灵活性——比如总部需要看到所有分支的路由那就让所有分支的导出 RT 都被总部的导入 RT 包含而分支之间不需要互访就只让分支导入总部的 RT。这种基于 RT 的拓扑控制比传统的 ACL 过滤要清晰得多。2.3 控制平面和数据平面必须分开看排障时我有个习惯先把控制平面和数据平面彻底分开问自己两个问题——路由有没有传到标签有没有分配这两个问题能定位掉八成的故障。控制平面负责“告诉 everyone 谁在哪”在 MPLS 三层专网里通常是两条腿走路一条是 PE 和 CE 之间的路由协议静态、OSPF、BGP 都有负责把客户侧网段学进来另一条是 PE 和 PE 之间的多协议 BGP负责把学到的网段加上 RD 和 RT 之后在骨干网内传播。数据平面负责“包实际怎么走”依赖的是标签分发协议或者 BGP 自己携带的标签以及 IGP 提供的底层可达性。这里有个非常经典的故障模式PE 之间的 BGP 邻居是 Up 的路由也收到了但业务就是不通。原因往往在数据平面——底层 IGP 路由被过滤掉了导致标签转发路径断了。表现是show命令看路由表一切正常但 traceroute 在骨干网内某一跳之后就没了回音。这种情况下控制平面看起来“健康”实际上数据平面的转发链条已经断了。所以我的排查顺序永远是先看 IGP 可达性再看标签绑定再看 BGP 路由最后看 VRF 导入导出。顺序反了就容易在错误的方向上浪费时间。2.4 二层形态和三层形态别选错了再返工MPLS 承载有两种主流形态三层形态PE 参与客户路由和二层形态PE 只透传客户自己管路由。三层形态的好处是运营商帮你分担了一部分路由管理工作客户侧配置简单适合分支多、IT 人力有限的企业。二层形态的好处是客户完全掌控自己的路由域适合有复杂内部路由策略、或者需要承载非 IP 协议的场景。选择逻辑其实很朴素你的 IT 团队有没有能力自己维护一套跨广域的路由域如果有二层形态给你更大的自由度如果没有三层形态让运营商帮你兜住一部分复杂度。我见过一些企业一开始为了“掌控感”选了二层形态结果因为内部没有专职网络工程师一次路由变更就导致全网中断最后又改回三层。这个决策不该由技术偏好决定该由运维能力决定。3. 落地实操从需求测算到 CE-PE 对接的完整流程3.1 上线之前必须算清楚的几个数MPLS 专网项目最容易出问题的阶段不是上线后而是需求梳理阶段。带宽算少了上线三个月就得扩容扩容又要走一遍审批流程RD 和 RT 规划乱了后期新增站点会非常痛苦。我一般会带着客户把下面这几个数先定死。带宽测算。不要用“平均带宽”去做规划要用“峰值并发”。以零售门店为例收银交易本身流量很小真正的带宽消耗来自监控回传和商品图片同步。一个门店如果有 16 路 1080P 监控按每路 4Mbps 计算就是 64Mbps再加上收银、办公、客用 Wi-Fi峰值很容易到 100Mbps 以上。规划时我通常会在峰值基础上留 30% 余量再考虑未来两年的增长。所以这个门店报 150Mbps 是比较合理的。六十个门店如果都往总部汇聚总部侧的端口带宽要考虑收敛比通常按 1:4 到 1:8 收敛不能简单相加。时延预算。跨省链路的单程时延通常在 10 到 30 毫秒区间具体取决于物理距离和运营商骨干路径。业务侧能接受的端到端时延要提前问清楚比如收银交易一般要求 200 毫秒以内完成视频会议要求单向 150 毫秒以内。把这些数字列成表作为验收依据。RD 与 RT 的命名规划。这一项最容易被忽略但后期返工成本最高。我的建议是建立一套固定规则比如用“自治系统号:站点编号”作为 RD用“自治系统号:业务类型编号”作为 RT。这样新增站点时直接套规则不需要每次重新讨论。RT 的规划要提前想清楚访问矩阵哪些站点之间需要互访哪些只需要访问总部把这个矩阵画出来RT 的设计自然就出来了。3.2 CE 与 PE 对接的关键配置逻辑下面这段是示意配置只表达逻辑关系具体命令语法各家设备差异很大实际落地请对照设备手册。! 在 PE 侧创建客户虚拟路由实例 ip vrf BRANCH_A rd 65000:1001 route-target export 65000:100 route-target import 65000:100 route-target import 65000:200 ! 把面向客户的接口绑进该实例注意顺序先绑 VRF 再配地址 interface GigabitEthernet0/0/1 description to-CE-BRANCH-A ip vrf forwarding BRANCH_A ip address 10.255.1.1 255.255.255.252这段配置里有两个顺序问题必须强调。第一必须先执行 VRF 绑定再配 IP 地址。如果顺序反了地址会先落到全局路由表里绑定 VRF 的瞬间地址会被清除接口短暂 down 一下虽然不影响最终结果但在生产环境的变更窗口里会造成不必要的告警。第二接口掩码推荐用 /30 或 /31。点对点互联用 /30 是传统做法浪费两个地址但兼容性最好/31 能省地址但部分老设备不支持。我在实际项目里倾向于 /30因为地址不缺兼容性优先。CE 侧的配置相对简单核心是把默认路由指向 PE同时把内部网段宣告出去! CE 侧示意 ip route 0.0.0.0 0.0.0.0 10.255.1.1 ! 如果 CE 与 PE 之间跑 BGP router bgp 65100 neighbor 10.255.1.1 remote-as 65000 network 192.168.10.0 mask 255.255.255.0这里有个经验CE 与 PE 之间跑静态路由还是 BGP取决于分支数量和拓扑变化频率。如果分支是纯星型、网段基本不变静态路由最稳配置简单、故障面小。如果有几十个分支、网段经常调整、还涉及双线备份那就必须上 BGP用 BGP 来做自动收敛和主备切换。我见过用静态路由硬扛五十个分支的项目每次新增网段都要在总部的汇聚设备上手工加一条运维台账一乱就出错。3.3 路由宣告与标签分发的实操要点PE 之间的路由传递依赖多协议 BGP。配置上有几个参数必须显式检查否则会埋雷。最大前缀数限制。一定要在 BGP 邻居上配置最大可接收前缀数并设置告警阈值。这不是防攻击是防配置错误。曾经有一个项目某分支的 CE 误配了一条汇总路由把整个 10.0.0.0/8 宣告了上来结果总部 PE 把这个前缀导入了所有 VRF全网路由瞬间被污染。如果当时配了前缀数限制邻居会在超过阈值时直接断开故障影响面能缩小到单个分支。允许本地 AS 重复。如果客户各分支使用相同的私有自治系统号这在简化管理的场景下很常见PE 在传递路由时会做 AS 路径环路检测导致分支之间学不到对方路由。这时候需要在 PE 的 BGP 配置里允许 AS 号重复。这个参数的副作用是削弱了环路防护所以只在明确知道拓扑结构的情况下开启。标签分发。如果骨干网内部使用标签分发协议需要注意它和 IGP 的联动关系。标签分发的会话建立不依赖 IGP但标签的实际使用依赖 IGP 路由存在。也就是说会话 Up 不代表标签可用必须是“IGP 有这条路由 标签分发协议为这条路由分配了标签”两个条件同时满足。抓包时如果看到 MPLS 标签值为 0 或 3说明是显式空标签或者隐式空标签属于正常行为不是故障。MTU 提前确认。这一条我要单独拎出来说因为它是现场最常见的隐形杀手。骨干网内部因为要压标签接口 MTU 通常要放大到 1500 以上常见的是 1526 或更高。而 CE 侧接口往往是标准 1500。如果端到端路径上有一台设备的 MTU 没对齐大包就会被丢弃表现是 ping 小包通、ping 大包不通或者业务能登录但传不了文件。上线前一定要用不分片标志做一次大包探测从 1472 字节开始往上试找到实际可通的最大值。3.4 服务质量保障怎么落到配置上专网之所以“稳”很大一部分功劳在服务质量策略上。做法是把业务分类打上不同的优先级标记然后在拥塞时按优先级调度。分类的粒度不用太细我通常分四类就够了实时类语音、视频会议、交互类收银、生产控制指令、业务类ERP、文件同步、尽力而为类普通上网、软件更新。分类之后在 CE 的出口方向做标记PE 侧根据标记映射到队列拥塞时优先保证实时类。这里有个实操细节标记要在尽可能靠近源的地方做但限速要在尽可能靠近瓶颈的地方做。很多项目只在 PE 侧做限速结果分支内部先拥塞了包在到达 PE 之前就被丢了标记做得再好也没用。正确做法是 CE 出口做分类标记和入口限速PE 侧做队列调度和出口整形两层配合才有效果。另一个容易忽略的点是上行和下行的不对称。分支到总部的链路下行往往比上行大得多但视频监控回传恰恰是上行吃紧。做策略时要分别看两个方向的流量模型不要想当然地按对称链路去配。4. 现场排查实录那些不报错但就是不通的问题4.1 常见故障速查表这张表是我这些年攒下来的按“现象”索引比按技术原理索引更好用现象最可能的原因第一步查什么小包通、大包不通路径 MTU 不一致或未对齐用不分片标志逐级探测包大小BGP 邻居 Up 但学不到路由导入导出 RT 不匹配对比两端 RT 配置与路由携带的扩展团体路由表正常但业务不通数据面标签转发链断裂沿路径逐跳检查标签绑定与 IGP 可达性单向通、回程丢包路由不对称回程走了另一条路径两端分别做去程和回程的路径追踪新增站点后老站点异常RD 重复导致路由混入同一实例全量核对 RD 分配台账某类业务偶发超时队列调度或限速策略误伤检查分类标记是否被中间设备重置双线切换后长时间不恢复BGP 收敛参数过于保守检查保持时间与路由抖动抑制配置4.2 几个印象深刻的坑坑一MTU 对齐只做了一半。有个项目上线后所有门店的收银都正常但总部的报表下发功能一直失败报的是连接超时。排查了两天最后发现是报表文件比较大走的是大包而某一段链路的 MTU 是 1500 没放大。诡异的地方在于这段链路不是主路径是备份路径正常情况下流量不会走它。但那天主路径做了一次例行维护流量切到备份路径问题就暴露了。教训是备份路径的 MTU 必须和主路径一样验证过不能因为“平时不走”就跳过。坑二RD 重复引发的路由污染。新增第 37 个站点的时候实施人员图省事直接复制了第 12 个站点的配置模板RD 忘了改。结果这个新站点的路由被导入到了老站点的实例里老站点的员工突然能访问一个新站点的内部系统。这个故障没有任何告警是业务侧反馈“怎么多出来一个不认识的网段”才发现的。后来我们建立了强制流程RD 和 RT 由系统统一分配实施人员不能手工填从流程上堵住这类错误。坑三标签分发会话正常但转发不通。这个坑最迷惑人。设备上标签分发会话显示 Established标签也分配了但业务不通。原因是骨干网内部有一条 IGP 路由被路由策略过滤掉了导致某台设备的标签转发表里缺少对应的下一跳。控制平面看起来一切正常数据平面实际存在断点。从那以后我的检查清单里加了一条新增或变更路由策略后必须做一次端到端的大包连通性验证不能只看邻居状态。坑四不对称路由导致的“半边通”。双线接入的站点很容易遇到。去程走 A 线回程走 B 线而 B 线的防火墙策略只放行了特定源地址于是回程被丢。表现是分支能 ping 通总部但总部访问不了分支的服务。排查时容易陷入“为什么 ping 通但服务不通”的困惑。正确的做法是两端分别做去程和回程的路径追踪把两条路径都画出来再看策略在哪一段拦截了。一个通用建议专网故障排查一定要建立“分段”思维。把端到端路径切成 CE 到 PE、PE 到 PE、PE 到对端 CE 三段逐段验证比端到端瞎试效率高一个数量级。5. 选型、成本与长期运维的边界感5.1 什么规模该上什么规模不该上这个问题我被问过太多次我的回答通常不太受欢迎节点数不是决定因素业务对抖动的敏感度才是。十个节点但如果都是核心生产系统、跨省分布、对时延和丢包零容忍那该上。反过来两百个节点但如果全是门店上网、后台只是同步一些非实时的数据那用普通宽带加策略路由完全够把省下来的钱投在分支侧的设备和监控上收益更高。中间地带是最难判断的。我的经验参考是当出现下面三个信号中的两个就值得认真考虑 MPLS 专网了。第一跨省访问的核心业务开始出现无法用“偶发”解释的失败率第二IT 团队每月花在“排查网络抖动”上的时间超过总工时的两成第三公司开始有合规或审计要求需要明确的链路责任边界和数据隔离证明。反过来的信号也很清晰如果业务主要在同一个城市、如果流量模型是纯粹的互联网访问、如果预算连专线端口费都覆盖不了那硬上专网只会带来运维负担。技术选型最怕的是“因为别人有所以我也要有”。5.2 长期运维中最值钱的三件事第一件是台账。RD、RT、各站点网段、互联地址、带宽、SLA 等级、责任接口人这些东西必须有一份持续维护的台账而且要放在所有人都能查的地方。我见过太多项目实施完成之后配置文档散落在各个工程师的本地电脑里两年后有人离职新来的人面对一堆配置只能靠猜。台账这件事听起来很土但它决定了这个网络三年后还能不能改得动。第二件是监控的粒度。只在总部做端到端拨测是不够的那只告诉你“不通”不告诉你“哪里不通”。至少要采三类数据各站点 CE 到 PE 的接口状态与流量、核心业务的端到端时延与丢包、关键链路的队列丢弃计数。第三类最容易被忽略但它是判断“拥塞是否已经影响业务”的最直接证据。第三件是变更纪律。专网的变更风险比普通网络高因为一次误操作可能影响几十个站点。我们的做法是所有涉及 RD、RT、路由策略的变更必须两人复核必须准备回退脚本必须在业务低峰窗口执行必须变更后做连通性验证。这四条听起来啰嗦但真正救过场。有一次一次看似简单的 RT 新增因为漏了一个导入方向导致三个站点的备份链路失效好在当天就做了验证第二天业务高峰前修好了。最后分享一个我自己在用的小技巧每次新增站点前先在测试环境把完整的配置跑一遍然后用两台设备模拟一次“拔线重启”看看路由收敛需要多久、会不会出现短暂的环路。这个过程大概花二十分钟但能提前发现八成以上的配置问题。比起上线后半夜被叫起来排查这二十分钟是我认为投入产出比最高的时间。