MPLS标签交换原理与LDP实战：从概念到排障

聊MPLS之前，先讲一个很多人在机房踩过的场景：业务方报障，说站点间视频会议卡顿、备份流量异常，你切后台看路径监控，发现流量老老实实走在IGP算出来的“最短路径”上，哪怕这条链路已经打满，旁边的低负载链路宁可空着也不会帮忙分担。传统IP网络就是这个脾气——每个路由器只认“路由协议算出来的最优下一跳”，全网没有任何一个节点有全局视角。而MPLS（多协议标签交换）当年把这个问题解决得很彻底，而且这个思路一直影响到现在网络设备、数据中心和广域网里的各种转发优化设计。

这篇文章会把MPLS的完整工作原理拆开讲：标签怎么产生、怎么分发，数据包到了网络里如何一步步被“贴标签、换标签、揭标签”，再配合最小实验配置和现场排障经验，把原理落到能干活的程度。适合三类人看：刚学网络基础准备面试的人、正在搭实验室模拟MPLS组网的人、以及已经在业务网里跟LDP打交道但只停留在“会配不会排障”阶段的工程师。

1. 为什么TCP/IP时代还需要MPLS：传统路由的软肋

1.1 逐跳转发：每个路由器都是一次独立“思考”

经典IP转发有一个很朴素的逻辑：路由器收到一个数据包，剥开二层帧头，取出目的IP地址，然后去路由表里做最长前缀匹配，找到匹配的条目，就把报文从对应接口发出去，再把“接力棒”交给下一台路由器。下一台路由器完全不关心你从哪里来，它只认自己的路由表。

这套机制在互联网早期非常优雅，容错性极强，任何节点都只知道局部信息，也都能正常工作。但到了企业专网和运营商骨干场景，麻烦就来了。问题出在“独立决策”本身：OSPF或者IS-IS这类IGP，本质上是按链路cost选最短路径，所有路由器都用同一套算法，结果就是全网流量几乎都挤在同一条最短路径上。你如果想给语音业务和备份业务规划不同的路径，传统IP协议根本给不出这种粒度控制的手段。

还有一点很现实：如果网络里有几千条路由，每台骨干路由器都要维护全量路由表，而且每一跳都得做一次最长前缀匹配。这个查表动作在硬件上再快，也没有“直接抽一个短标签来查”来得简单。尤其是当网络里还要叠加大量私网路由、隧道、业务优先级时，逐跳IP转发表会膨胀得很难看。

1.2 标签交换：让报文在网络里“走后门”

MPLS拼的是另一套思路：你不需要全网每台设备都路路通晓所有前缀，只需要在网络边缘做好“分类”，然后在网络内部按一个定长的标签来搬运。

我习惯用一个类比来解释——快餐厅流水线。你到柜台点单，收银员把你点的餐归成一个“标准订单”，这就是FEC（转发等价类）；然后把订单编号贴到餐盘上，这就是标签；后厨流水线全程只看编号，不同编号走不同的通道、给不同的厨师（对应不同的设备和路径），最后出餐口再撕掉编号，把菜交到你手里。中间任何一个人都不用重新研究你点了什么。

对应到MPLS网络里，入站边缘路由器就是“收银员”，负责识别流、分类、打标签；中间的核心路由器是“后厨流水线”，只根据标签查找转发表项，不再看IP头；出站边缘路由器负责剥离标签，把报文交还给普通IP网络。这个“边缘分类 + 核心转发”的思想后来也出现在各种overlay方案里，算是计算机网络里一个绕不开的基础设计。

2. MPLS的关键概念：先认清这几类“角色”

2.1 LSR、LER、LSP：人、入口、出口与路径

先记住三个缩写，后面所有讨论都以它们为基础。

第一是LSR，标签交换路由器。凡是启用了MPLS能力、能根据标签做转发的路由器都叫LSR。在网络里，有些LSR负责边缘接入，有些负责核心转发，但它们在MPLS协议栈里的角色都是可配置的。

第二是LER，标签边缘路由器。它位于MPLS域的边界，分为入站LER（Ingress）和出站LER（Egress）。入站LER的任务是把普通IP报文“翻译”成带标签的报文；出站LER则相反，把标签剥掉再按普通IP路由转发。可以这样理解：入站LER是流水线的开单台，出站LER是交餐台。

第三是LSP，标签交换路径。一个带有相同标签的报文从入站LER出发，经过若干台中间LSR，最终到达出站LER，这条单向的传输路径就叫一条LSP。注意LSP是有方向的，A到B有路径，不代表B到A有路径，返回方向的路径需要单独建立。这也是初学MPLS时最容易忽略的细节。

2.2 FEC、LIB、LFIB：转发所需的三张“账本”

MPLS的核心工作其实就是在维护几张“账本”。

FEC叫转发等价类。本质上是一组目的相同、转发方式相同的报文集合。传统IP转发里，默认FEC就是“目的IP前缀”；但MPLS的FEC可以更精细，可以绑入接口、绑隧道、绑业务优先级。入站LER决定报文属于哪个FEC，就给它贴哪个标签。同一FEC的报文在网络里走同一条LSP，享受同样的转发待遇。

LIB叫标签信息库。它记录两类东西：本地为每个FEC分配的标签，以及从下游邻居学到的“对方为某FEC分配的标签”。LIB不直接参与转发，它是控制平面的“原材料仓库”。

LFIB叫标签转发信息库，这才是数据平面真正查的表。它把入标签、出标签、出接口、下一跳这些信息整理成一条条可执行的转发条目。报文进来后，查LFIB，匹配“入标签”，直接拿到“出标签”和“出接口”，完成转发。简单说，LIB是“账房先生记的流水账”，LFIB是“柜台上摆的价目表”。

2.3 控制平面与数据平面：两张“地图”的配合

很多人学MPLS学得晕，是因为分不清控制平面和数据平面的工作节奏。

控制平面做的事可以类比成“提前规划路线”：它运行路由协议（比如OSPF搭建底层的IP连通性），运行标签分发协议（比如LDP），在各个LSR之间交换标签绑定信息，最终把数据平面需要的LFIB条目填好。控制平面的更新是缓慢的、按事件触发的，它关心“有没有新的路由”“链路有没有断”“该给哪个邻居重新分配标签”。

数据平面则纯粹是“执行层”：每个数据包到达时，不关心控制平面在干什么，只根据LFIB做“标签查表 + 转发”，也就是Push（压入）、Swap（交换）、Pop（弹出）这几个动作。数据平面追求的是速度，处理延迟越高，吞吐越低。

理解这两个平面，后面排障就好办了——很多MPLS问题，要么是控制平面邻居没建起来、表项没生成，要么是数据平面转发报错、链路MTU不够，定位思路完全不一样。

3. 核心机制：标签怎么发、怎么贴、怎么揭

3.1 标签结构：32位小身材里装了什么

MPLS标签被封装在二层头与IP头之间，标准叫法是MPLS shim header。它总共32位，也就是4字节，用最短的代价把“面向连接”的转发能力塞进原本无连接的网络。

四个字段别死背，理解用途就够了。

标签值占20位。理论上有2的20次方个取值（实际可用范围小一些，前几位有特殊含义），它决定了LFIB表项的索引。EXP占3位，后来改叫TC（Traffic Class），用来标记服务等级，相当于给标签“染色”，交换机可以根据它做队列调度。S占1位，表示“这是不是标签栈的最底层”。这个设计很重要，因为MPLS允许报文同时携带多层标签，最底层的S位为1，解析时就知道还可以继续往下剥7层？实际上标签栈深度理论不限，S位告诉设备“我下面是IP头，还是另一层标签”。TTL占8位，和IP TTL类似，每经过一台LSR减1，防止报文在LSP里打转。

还有一个实际抓包时会看到的知识点：在以太网上，带单播MPLS标签的帧类型字段是0x8847，组播是0x8848。如果你用抓包工具看LDP测试流量，看到这个类型就不用怀疑“为什么二层协议号变了”。

3.2 LDP分发标签：下游说“我用这个标签”，你才能用

标签从哪来？在MPLS控制平面里，LDP（标签分发协议）是使用最广泛的“发号员”。

LDP的基本流程是这样：第一，LSR之间通过UDP 646端口的Hello消息发现直连邻居；第二，发现后，双方用TCP 646建立一个会话，为了避免会话被一堆ACL误伤，如果你在某些网络里启用了严格的安全策略，得记得放行646端口的TCP和UDP；第三，会话建立后，进入标签交换阶段，各设备为路由前缀分配标签并通告给邻居。

这里有个关键原则：上一跳路由器使用的标签，永远是由下一跳路由器分配的。比如中间路由器B向入站路由器A通告“你要发往某地址的报文，请用标签45”，A才敢在转发时压入45。为什么要这么做？因为当报文带着标签45到达B时，B只需要在自己的LFIB里找入标签为45的条目，就能确定怎么转发。标签只有在下游分配给上游的时候，转发路径才真正闭环。

LDP还分分配模式和控制方式。分配模式有下游自主分配（DU）和下游按需分配（DoD）；控制方式有独立控制（Independent）和有序控制（Ordered）。工程里最常见的是DU + Independent，也就是每个LSR一看到新的路由前缀，就主动给自己分配标签，然后告诉所有邻居。有序控制则更严格：一个LSR只有在收到了下游针对某个FEC的通告后，才会向上游通告自己的标签，这样可以确保标签链不断裂。

3.3 完整转发流程：压入、交换、弹出

现在我们把整条链路串起来看。假设有三台设备，Device A是入站LER，Device B是中间LSR，Device C是出站LER，目的地址是C上的Loopback地址192.0.2.3/32。

第一步，Device C为192.0.2.3/32这个FEC分配了一个本地标签18，通过LDP通告给B。B收到后，也为同一个FEC分配了本地标签45，再通告给A。第二步，A收到一个目的为192.0.2.3的普通IP报文，查LFIB发现该FEC的出标签是45（这是B通告给它的），于是执行Push动作，把标签45压进二层头和IP头之间，从连接B的接口发出去。第三步，B收到带标签45的报文，查LFIB：入标签45，出标签18，出接口指向C。执行Swap动作，把标签45改成18，报文继续走向C。第四步，C收到带标签18的报文，查LFIB，发现自己是出站LER，不再需要标签，执行Pop动作，剥掉标签，恢复成普通IP报文，再按正常的IP路由把报文送到目的主机或直连网段。

这就是MPLS最经典的“压入—交换—弹出”三步曲。你可以把标签理解成接力赛里的“接力棒”：只有传棒人知道该交给谁，接棒人提前就把手伸出来了。

3.4 PHP机制：为什么要在倒数第二跳把标签揭掉

上一节的四步流程是最基本形态，但真实网络中很大一部分MPLS域都会启用一种叫PHP（倒数第二跳弹出）的优化机制。

逻辑很简单：既然出站LER在收到报文后，一定会执行Pop动作把标签剥掉，那能不能让倒数第二跳提前把标签剥掉，直接以普通IP报文发给出站LER？这样出站LER就不用再做一次“查LFIB + 剥标签”的动作，可以省一次查表，减少转发延迟，也减轻边缘设备的CPU负担。

实现方式是：出站LER在通过LDP向倒数第二跳通告标签时，不分配一个普通标签值，而是分配一个特殊值——隐式空标签（Implicit-Null Label），通常叫标签3。倒数第二跳看到这条绑定信息后，在其LFIB里记录的出标签就不是一个具体数字，而是“Pop”或者“空”。当带标签的报文到达倒数第二跳，它查表后发现出标签是“Pop”，就会直接剥离标签，然后把普通IP包交给出站LER。

这里有一个典型的坑：很多人第一次看到路由器的转发表里出现“Out Label: Pop”会以为配置错了，跑去删配置重配。其实看到“Pop”恰恰说明PHP已经生效。如果出于某些目的需要保留标签一直到出站LER（比如保留QoS标记），则可以用显式空标签（Explicit-Null Label，标签0），那又是另一种场景了。

4. 当网络“听指挥”：MPLS三大典型应用

4.1 私网专线组网：在同一张物理网络里划出逻辑隔离通道

MPLS最早、最出名的应用场景就是为站点间提供私有专线服务。多家企业、多个部门共享同一张物理骨干网，但各自逻辑上完全隔离，互不可见，这就是用MPLS承载私网路由的做法。

原理上，骨干网设备维护普通路由作为底层传输；在边缘，同一台网络设备上可以划出多个独立的VRF路由表（虚拟路由转发实例，专业说法叫VRF），每个VRF对应一家企业或一个业务。不同VRF里的相同网段允许同时存在，它们被“标签隔离”。在骨干中间，设备只需要根据外层标签转发，根本不需要看内层路由前缀，也不会把A企业的流量串到B企业去。

这种方案的高明之处在于把“转发”和“隔离”解耦。你不用为每个企业单独铺设物理线路，业务扩展时也只需要在边缘设备上配置对应VRF，中间骨干几乎不动。

4.2 流量工程：让带宽可以被“预订”

传统IGP选路只认“最短”，MPLS流量工程（常常缩写为TE）则让链路流量路径变得可控、可预约。

通过RSVP-TE这样的机制，网络管理员可以为某个业务建立一条显式LSP，明确指定“必须经过哪些节点、总共预留多少带宽”。比如A点到B点有两百兆业务，而IGP最短路径经过的链路只剩50兆，另一条绕行链路还有150兆空闲，那么TE就可以把业务安排到绕行路径上，同时预留带宽，保证未来其他流量不会抢占。

这对视频会议、大量备份、远距离同步这类带宽敏感业务很有价值。实际生产环境里，流量工程的另一个杀手级应用是快速重路由（FRR）：提前为一条重要LSP算好备用标签路径，一旦主路径上的链路或节点故障，转发面可以在几十毫秒内切到备用路径，而不是等着整个网络IGP重新收敛。这个数字是很多实时业务可用性的底线，也是MPLS TE至今没有被完全替代的原因之一。

4.3 骨干网收敛与大二层延伸：其他应用

除了专线和流量工程，MPLS还经常承担骨干网的收敛加速任务。比如在某些大型连锁、高校或数据中心场景里，可以在IP骨干网中启用MPLS，让路由收敛依赖LDP或RSVP会话的快速检测机制，配合BFD（双向转发检测），把故障从秒级收敛降到亚秒级。

另一个常见场景是大二层延伸。普通VLAN只能在一个二层域里传递，跨地域时查询、广播会很吵。利用MPLS的标签栈，可以在一条LSP里封装二层帧，把两个远隔千里的站点在逻辑上拉成同一个二层广播域。这样双活数据中心、异地容灾、虚拟机迁移这类业务就能跑起来，而不必关心底层物理拓扑长什么样。

5. 上手实操：最小MPLS域配置与验证

5.1 基础配置：全局、接口、LDP

实际操作部分，我用一个三台设备的拓扑做演示：Device A、Device B、Device C一字排开，A和B互联，B和C互联。三个设备的Loopback地址分别规划为192.0.2.1、192.0.2.2、192.0.2.3，互联地址用198.51.100.0/30和203.0.113.0/30。选择这些地址是因为它们属于文档测试网段，不会和真实业务网冲突，大家在自己实验环境里也建议这么干。

先看Device A的配置。全局启用MPLS，再在接口上启用LDP。

mpls ip mpls label protocol ldp ! interface Loopback0 ip address 192.0.2.1 255.255.255.255 ! interface GigabitEthernet0/0 description Link-to-Device-B ip address 198.51.100.1 255.255.255.252 mpls ip no shutdown ! router ospf 1 router-id 192.0.2.1 network 192.0.2.1 0.0.0.0 area 0 network 198.51.100.0 0.0.0.3 area 0

Device B两侧接口都要启用MPLS，并且把连接A的接口地址放在198.51.100.2，连接C的接口地址放在203.0.113.1。

mpls ip mpls label protocol ldp ! interface Loopback0 ip address 192.0.2.2 255.255.255.255 ! interface GigabitEthernet0/0 description Link-to-Device-A ip address 198.51.100.2 255.255.255.252 mpls ip no shutdown ! interface GigabitEthernet0/1 description Link-to-Device-C ip address 203.0.113.1 255.255.255.252 mpls ip no shutdown ! router ospf 1 router-id 192.0.2.2 network 192.0.2.2 0.0.0.0 area 0 network 198.51.100.0 0.0.0.3 area 0 network 203.0.113.0 0.0.0.3 area 0

Device C的配置和A基本对称，只需要把Loopback地址改成192.0.2.3，互联接口配置成203.0.113.2即可。不同厂商的命令语法会有点差异，但“全局开启MPLS，接口下开启LDP，IGP保证底层路由可达”这三件事是通用的。

多说一句：为什么Loopback地址这么重要？因为LDP会话的传输地址通常用Router-ID也就是Loopback地址，而且底层IGP要保证这些Loopback地址互相可达，LDP的邻居才会进入Operational状态。如果Loopback地址没建立路由，后面的标签交换根本起不来。

5.2 验证命令与输出解读

配置完成后，最直观的验证是先看LDP邻居。

show mpls ldp neighbor

如果输出里显示两个Peer都是Oper状态，说明控制平面邻居已经建立。状态卡在NonOper或者长时间在Init时，就要去查底层IGP路由和防火墙放行策略了。

接下来看标签绑定信息。

show mpls ldp bindings

你能看到类似：目的前缀192.0.2.3/32，本机分配标签18，来自下游邻居192.0.2.2标签45。这一条信息就会驱动Device B为这个FEC生成转发条目。

最关键的是看转发平面的表项。

show mpls forwarding-table

在Device B上，你应该能看到类似这样的条目：

In Label Out Label Out Interface Next Hop 45 18 GigabitEthernet0/1 203.0.113.2

如果Device C启用了PHP，那么Device B的Out Label这一列大概率显示的是“Pop”，而不是具体数字。看到“Pop”不要慌，那正说明倒数第二跳弹出的机制已经生效。

从Device A去ping Device C，比如ping 192.0.2.3 size 1400，正常情况下应该通。如果大包丢、小包通，基本可以怀疑MTU问题，下一节会说。

5.3 完整小实验设计与抓包验证

如果想更深入理解原理，建议在实验环境里加一台抓包设备或者在中继链路上做镜像，看看报文在A与B之间到底长什么样。抓包时找不到IP头？别奇怪，IP头被标签头往前“推”了。标签头的EtherType是0x8847，Data里能看到标签值20位。从A发出的报文，解出的标签应该是45；从B发往C的报文，标签已经是18（除非PHP已在倒数第二跳弹出）。这个“标签从45变成18”的过程，就是Swap在现实里的样子。

实验做到这个程度，比单纯看十遍文档都管用。我当年就是把这三台设备的实验环境反复搭和拆，才真正把控制面和转发面分清楚的。

6. 常见问题与排查技巧：现场踩过的坑

6.1 LDP邻居会话迟迟建不起来

这是最容易遇到、也最容易排查不出的问题。表现就是show mpls ldp neighbor里看不到对端，或者看到了但一直不是Oper状态。

常见原因有三个。第一，底层IGP路由不通，尤其Loopback地址之间不可达。LDP会话是基于TCP的，传输地址通常是Loopback，如果TCP连接建立方到对端Loopback的路由不存在，会话就握手失败。第二，防火墙或ACL把UDP 646或TCP 646给拦了。很多网络默认策略只放行OSPF/BGP/permit ip any，结果LDP的Hello发不出去。第三，Hello参数不一致，比如Hello保持时间和间隔不匹配，邻居会反复震荡。

排查顺序建议是：先在两端ping通对端Loopback，再检查接口状态，再抓包看UDP 646的组播Hello有没有到达对端，最后才看TCP 646连接能不能建起来。

6.2 小包通、大包断：MTU那4字节的学费

MPLS标签是4字节，这个看似很小的开销在MPLS网络中经常成为“隐形杀手”。原因很简单：你的物理链路或接口MTU通常还是按1500配置的，而报文进入MPLS域后会在二层头和IP头之间多一个4字节的标签头。最坏情况下，一个长度为1500字节的IP包，压上标签后到达1504字节，如果设备不支持分片（比如出接口DF位被设置）或者下游设备MTU还是1500，就会被静默丢弃，或者丢掉后触发ICMP分片需要而不返回报文。

这类故障的典型特征就是：小Ping通，大Ping不通；普通流量没异常，但FTP传输、视频、大包同步业务间歇性卡顿。

解决办法有两种。一是把MPLS域内所有中间链路的接口MTU调到1504或更高，很多企业链路支持到9000字节更是毫无压力；二是压低边缘设备的MTU，例如把客户侧接入接口的IP MTU改成1492，给标签预留空间。平时运维网络时，给链路留一点点富余量，能省掉无数半夜被叫醒的烦恼。

6.3 转发路径和预期不一致：标签错绑与黑洞

有时候LDP邻居都正常，标签也刷出来了，但流量走的路径跟你预期的不一样，甚至有些目的地根本不通。先检查LFIB里对应前缀的入标签和出标签是否连续，再看Out Interface是否指向了正确的下一跳。

一个常见的回滚场景是：你在一台设备上改了静态路由或调整了OSPF的cost，导致某个前缀的下一跳发生变化，但LDP还没有来得及给新的下一跳分配标签，或者老表项没清干净。此时可以用清LDP邻居和清转发表的命令把它强制重建。配置变更前先想清楚依赖关系，是生产环境里更稳妥的习惯。

还有一种“黑洞”情况是标签栈里的层次不匹配。比如业务流量需要两层标签，一层隧道标签、一层内层标签，但其中一台设备只弹了一层就往出扔，到了下一跳设备，它发现入标签对应不上，就直接丢弃。这种问题在跨域互联、多厂商设备混组时更容易出现，排查时要多抓几个点的报文，对比标签栈深度。

6.4 TTL那个“数字游戏”

MPLS标签头里的TTL行为，在跨域监控和路径可视化时非常让人头疼。默认情况下，入站LER会把IP TTL复制到标签TTL，每经过一台LSR，标签TTL减1，出站LER把标签TTL复制回IP TTL。这样从路径追踪工具（比如traceroute）的角度看，中间LSR完全透明，你只能看到入口和出口，中间走了哪几台设备一概不知。

这不是错误，而是MPLS的默认行为。如果你做网络监控时希望路径追踪能看到每一跳，就需要调整TTL传播策略，让LSR在复制TTL时不保留原有值而是递减，或者在出站时不做复制。反过来，如果担心MPLS透明暴露内部拓扑，默认行为反而是更安全的。要不要调，取决于你的运维需求。

6.5 问题定位速查表

把现场最常见的MPLS故障整理成一张表，排查时对着顺序看，能省不少时间。

写在最后的一些经验

带了几年的网络项目，MPLS相关的问题绕不开一句话：控制平面决定“能不能走”，数据平面决定“走得快不快”。排查时先把这两个平面分开，问题范围就能砍掉一半。

我个人还有个习惯：无论配置多简单，都会先抓一次两层报文，亲眼看一看标签从Push到Swap再到Pop的全过程。不要嫌抓包麻烦，抓过一次之后，你再看任何讲MPLS原理的文章都会觉得通透了。实验环境首选软件模拟器，地址规划就用测试网段，老老实实从三台设备跑起来，比背一百个命令都有效。

这套“边缘分类、中间查表、出口还原”的标签思想，后来在VXLAN、SR、各种overlay技术里都能看到影子。基础打牢了，遇到新名词上手会快得多。