企业官网建设流程全解析

简介：这份实操资料包围绕MPLS静态LSP隧道配置与抓包验证，面向网络工程师、运维人员及MPLS学习者，重点解决从拓扑搭建、标签分配到故障排查的系列问题。压缩包共11个文件，含6个eNSP相关efz配置、2个pcapng抓包记录（覆盖单向与双向隧道）、1个拓扑截图、1个XML配置及1个topo工程文件，大小仅139KB，轻量易导入，便于快速在eNSP中搭建实验环境。抓包文件可用Wireshark打开，结合拓扑图能直观查看标签栈的添加、交换与移除，也能观察LDP或RSVP-TE信令交互，便于定位标签丢失、值不匹配等故障；对比单向与双向抓包结果，可加深对标签转发路径的理解。资源已有679人学习参考，适合想亲手验证静态LSP联通性、理解MPLS转发机制的学习者。

1. MPLS静态LSP隧道拓扑配置与抓包：一份能让你把标签路径看透的资源

做网络的人都知道，MPLS 最让人头疼的不是概念，而是「标签到底怎么加上去、怎么换、怎么摘掉」这层黑匣子。动态 LSP 有 LDP 帮你跑信令，配完就完事；静态 LSP 则要把 Ingress、Transit、Egress 每一跳的标签动作手工写死，一步错就全线不通。我最早学静态 LSP 时，最缺的就是一套能直接导入模拟器、还能对着抓包文件验证的完整拓扑。这份资源恰好补齐了这个缺口：里面有可直接加载的拓扑文件、设备镜像，以及单向和双向隧道两套抓包结果。你不需要自己从零搭环境，导入后照着配一遍，再用 Wireshark 打开 pcapng 对照标签变化，基本就能把静态 LSP 的转发路径彻底看懂。适合正在学 MPLS、准备网络认证，或者工作中要排查标签转发问题的工程师。

2. 静态 LSP 配置逻辑：Ingress、Transit、Egress 三段标签动作分别怎么定

2.1 为什么选静态 LSP：确定性优先于自动化

动态 LSP 靠 LDP 或 RSVP-TE 自动分发标签，网络大了确实省事，但代价是你对路径的控制是间接的——信令协议说了算，管理员只能通过策略去影响它。静态 LSP 则完全反过来：每一跳的入标签、出标签、下一跳都由管理员显式指定，路径是绝对确定的。

这在两类场景里非常实用。第一类是拓扑简单、节点少的环境，比如只有三四台路由器的园区或分支机构，手工配几条静态 LSP 比部署 LDP 快得多，而且没有信令交互，链路异常时的排查面更小。第二类是对转发路径有强约束的场景，比如流量必须走某条物理链路，不能由动态协议自行选路。静态 LSP 的路径是写死的，只要中间节点不宕，转发路径就不会漂移。

另外还有一层：静态 LSP 不依赖任何标签分发协议，所以数据面和控制面是解耦的。抓包时你只会看到 MPLS 标签的压入、交换和弹出，看不到 LDP 的 Label Mapping 消息——这对学习数据面转发非常有帮助。资源包里摘要提到的「里氏替换原则」，放在网络语境下可以理解为：静态 LSP 作为 LSP 的一种实现，必须在转发功能上完整替代动态 LSP 的能力，标签路径的每个动作都不能缺。这也是我们配置时检查功能完整性的一个视角。

2.2 MPLS 标签动作拆解：Push、Swap、Pop

MPLS 数据面只有三个动作，理解了这三个动作，静态 LSP 的配置就是填空题：

• Push（压入）：发生在 Ingress 节点。IP 包进入 MPLS 域时，根据目的地址匹配转发等价类 FEC，压入一层标签，然后从指定出接口发出。
• Swap（交换）：发生在 Transit 节点。收到带标签的报文后，查找入标签对应的转发表项，把外层标签替换成新的出标签，再从下一跳出接口转发。
• Pop（弹出）：发生在 Egress 节点。倒数第二跳或最后一跳把标签剥掉，还原成纯 IP 报文，继续按 IP 路由转发。

静态 LSP 的配置本质上就是告诉每一台路由器：针对哪个 FEC、从哪个接口收到哪个标签值、应该换成哪个标签值、从哪个接口送出去。三个角色各配一段，连起来就是一条完整的标签路径。

2.3 Ingress 节点配置：FEC、nexthop 与 out-label 的绑定

以华为 AR 系列的命令风格为例。假设拓扑是 R1—R2—R3，链路地址 10.0.12.0/24 和 10.0.23.0/24，业务网段 192.168.3.0/24 挂在 R3 后面。R1 作为 Ingress，需要把所有去往 192.168.3.0/24 的流量压入标签进入隧道。配置如下：

# R1 上配置静态 LSP 的 Ingress 段 static-lsp ingress LSP1 destination 192.168.3.0 24 nexthop 10.0.12.2 out-label 100

这段命令的核心是三条绑定关系。destination 192.168.3.0 24定义了 FEC，即哪些目的地址的流量会进入这条 LSP；nexthop 10.0.12.2指定了标签报文的下一跳，必须和去往 FEC 的 IP 路由下一跳一致；out-label 100是压入的标签值，这个值会原样出现在 R1 发往 R2 的报文上。配置完成后可以用display mpls static-lsp查看，状态为 Active 才说明表项下发成功。

这里有个关键点：Ingress 的 nexthop 必须与 IP 路由表一致。如果去往 192.168.3.0/24 的路由下一跳是 10.0.12.2，但静态 LSP 里 nexthop 写成了 10.0.12.1，那么流量会先查 IP 路由找到正确的出接口，再按 LSP 表项压标签，两个下一跳不一致时表现得很诡异——有的报文裸 IP 转发、有的报文带标签转发。

2.4 Transit 和 Egress 节点配置：入标签到出标签的映射

R2 作为 Transit 节点，职责是收到标签 100 的报文，换成标签 200 发给 R3。配置如下：

# R2 上配置静态 LSP 的 Transit 段 static-lsp transit LSP1 incoming-interface GigabitEthernet0/0/0 in-label 100 nexthop 10.0.23.3 out-label 200

注意incoming-interface和in-label是绑定的，意思是「从 Gi0/0/0 进来、标签值为 100 的报文才匹配这条表项」。如果同样的标签值从别的接口进来，不会命中这条表项，报文会被丢弃。这是静态 LSP 与动态 LSP 的一个显著差别——动态 LSP 的标签由信令全局分配，有唯一性保证；静态 LSP 的标签值是本地概念，只要求在同一个节点的入方向唯一即可。所以同一条 LSP 的不同节点，标签值完全没有必要一致，甚至故意不一致更方便排查。

R3 作为 Egress，收到标签 200 的报文后要把标签弹掉：

# R3 上配置静态 LSP 的 Egress 段 static-lsp egress LSP1 incoming-interface GigabitEthernet0/0/0 in-label 200

Egress 段不需要配 out-label，因为它不再压标签，而是把 MPLS 标签剥掉后走普通 IP 转发。这里有一个常见的理解偏差：Egress 节点的作用是「收到带标签的报文并弹掉标签」，它的下游接口如果还连着其他设备，弹掉标签后的报文是普通 IP 包，继续走 IP 路由，不会再进入任何 MPLS 隧道。

2.5 三段配置合起来看：一条 LSP 的完整数据流

把三段配置连起来，R1 收到一个目的地址为 192.168.3.10 的 IP 报文，处理过程是这样的：

你会发现静态 LSP 的配置完全没有「协商」的过程，每台路由器只知道自己负责的那一段。所以配置顺序也很重要：先配 Egress，再配 Transit，最后配 Ingress。虽然静态配置不依赖信令，但表项下发的依赖关系是隐式的——如果 Ingress 先配好了，而 Transit 还没配，去往 R3 的报文会在 R2 上因为没有入标签表项而被丢弃。实际配置时养成「从尾到头」的习惯，能少踩不少坑。

3. 在模拟器里还原拓扑：双向静态 LSP 的配置顺序与验证

3.1 资源包内容与导入方式：.topo、flash.efz 和 pcapng 各是什么

解压资源包后，核心文件分为三类。.topo文件是 EVE-NG 的拓扑工程文件，里面记录了设备的摆放位置、互联线缆和启动配置；flash.efz是设备镜像的压缩包，EVE-NG 在导入拓扑时会自动关联；.pcapng是 Wireshark 标准的抓包文件，记录了实验过程中捕获的 MPLS 报文。另外还有两张拓扑截图，可以直接对照查看设备接口编号。

在 EVE-NG 里导入的步骤很直接：把整个资源包解压到本地，打开 EVE-NG 的 Web 界面，点击左上角的「Folder」图标，选择导入.topo文件。EVE-NG 会提示关联镜像，如果资源包里带的 flash.efz 与你本地的镜像版本不匹配，需要把 flash.efz 放到 EVE-NG 的镜像目录里。放好后回到拓扑界面，设备节点应该能正常启动，端口状态从红色变成绿色就说明链路通了。

如果你用的是 GNS3 或华为 eNSP，思路也是一样的——只看接口 IP 和互联关系，把拓扑手动搭一遍。.topo文件的核心价值在于省去了记录接口连线的麻烦，三台路由器之间哪两个接口互连，打开拓扑拖一根线就能确认。

3.2 三节点拓扑的地址规划：接口、Loopback 与业务网段

资源包里的拓扑是三台路由器串行连接，每台路由器之间用两个接口做物理互联。为了让 MPLS 报文在抓包里看起来干净，接口地址全部用点到点网段，避免广播流量干扰。我自己做实验时会加一条 Loopback 地址，但静态 LSP 的 FEC 匹配通常用业务网段，不一定要用 Loopback——destination只要和实际转发的目的地址匹配即可。

物理接口配置好之后，别忘了检查接口状态。EVE-NG 里设备启动慢是常态，端口从 down 到 up 可能要等几十秒。接口没起来就配 LSP，即使配置命令没报错，display mpls static-lsp看到的也是 Inactive——因为下一跳不可达，表项无法下发。

3.3 正向 LSP 配置：从 Egress 到 Ingress 逐段下发

按照第 2.5 节说的「从尾到头」顺序，先在 R3 上配置 Egress 段：

# R3：Egress 节点，收到标签 200 的报文直接弹出 interface GigabitEthernet0/0/0 ip address 10.0.23.3 255.255.255.0 # 确保业务网段接口已开启 interface GigabitEthernet0/0/1 ip address 192.168.3.1 255.255.255.0 static-lsp egress LSP1 incoming-interface GigabitEthernet0/0/0 in-label 200

接着在 R2 上配置 Transit 段。注意入接口是面向 R1 的 Gi0/0/0，出下一跳是 10.0.23.3，对应出接口 Gi0/0/1：

# R2：Transit 节点，入标签 100，出标签 200，下一跳 R3 interface GigabitEthernet0/0/0 ip address 10.0.12.2 255.255.255.0 interface GigabitEthernet0/0/1 ip address 10.0.23.2 255.255.255.0 static-lsp transit LSP1 incoming-interface GigabitEthernet0/0/0 in-label 100 nexthop 10.0.23.3 out-label 200

最后在 R1 上配置 Ingress 段：

# R1：Ingress 节点，去往 192.168.3.0/24 的流量压入标签 100 interface GigabitEthernet0/0/0 ip address 10.0.12.1 255.255.255.0 static-lsp ingress LSP1 destination 192.168.3.0 24 nexthop 10.0.12.2 out-label 100

配置完成后，在三台设备上分别执行display mpls static-lsp，确认 LSP1 的状态都是 Active。如果某一段显示 Inactive，优先检查下一跳是否可达、入接口是否 up。这是静态 LSP 排障的第一条铁律：表项状态比 ping 结果更早暴露问题。

3.4 反向 LSP 配置：双向隧道不能只做一半

资源包里同时提供了「单向隧道抓包」和「双向隧道抓包」两份 pcapng 文件，这说明实验里的 LSP 是双向的。反向 LSP 的配置逻辑完全一样，只是角色互换：原来的 Egress R3 变成了 Ingress，原来的 Ingress R1 变成了 Egress。

# R3：反向 Ingress，去往 192.168.1.0/24（R1 侧业务网段）的流量压入标签 300 static-lsp ingress LSP2 destination 192.168.1.0 24 nexthop 10.0.23.2 out-label 300 # R2：反向 Transit，入标签 300，出标签 400，下一跳 R1 static-lsp transit LSP2 incoming-interface GigabitEthernet0/0/1 in-label 300 nexthop 10.0.12.1 out-label 400 # R1：反向 Egress，收到标签 400 的报文弹出 static-lsp egress LSP2 incoming-interface GigabitEthernet0/0/0 in-label 400

这里有个很容易忽略的细节：R2 上同时存在 LSP1 和 LSP2 两条表项，一条面向 R1、一条面向 R3。它们的入标签分别是 100 和 300，互不冲突；出标签分别是 200 和 400。静态 LSP 的标签值不需要全局规划，每台设备只保证「入方向唯一」就够了，这种设计大大降低了配置复杂度。

双向配置完成后，在 R1 上 ping 192.168.3.1、在 R3 上 ping 192.168.1.1，两个方向都能通，说明双向 LSP 工作正常。

4. Wireshark 抓包分析：从标签栈看懂数据面转发路径

4.1 打开 pcapng 的正确姿势：先过滤再分析

资源包里有两份 pcapng 文件，直接用 Wireshark 打开就能看到完整的 MPLS 报文。但直接看全部报文会很乱——实验环境里除了 MPLS 流量，还有 ARP、ICMP 等杂讯。第一步先过滤：

mpls

这个过滤器会显示所有带 MPLS 标签的报文，IP 包被自动过滤掉。如果想只看某个方向的隧道，再加上标签值条件：

mpls.label == 100

显示过滤器和抓包过滤器不同，它不会丢弃报文，只是隐藏不匹配的。用mpls.label == 100能快速定位 R1 压入的标签 100 出现在哪些报文中，对比双向隧道和单向隧道的差异。

提示：如果打开 pcapng 后没有看到 MPLS 的列，检查 Wireshark 的「Protocol Preferences」里 MPLS 协议是否被禁用。新版 Wireshark 默认启用，但某些精简版本可能关闭了解析。

4.2 标签栈结构：label、EXP、S、TTL 四个字段的含义

在 Wireshark 中展开一个 MPLS 报文，能看到完整的标签栈结构。每一层标签由四个字段组成，它们各自的含义和排查价值不同：

抓包里看到的标签值，应该和第 2 节的配置完全对应。R1 发出的报文标签值一定是 100（或反向的 400），R2 发出的报文标签值一定是 200（或反向的 300）。如果抓到的标签值和配置对不上，说明要么抓包位置不对，要么转发表项和配置不同步。

4.3 单向与双向隧道抓包对比：标签变化的位置不同

对照资源包里的两份 pcapng，最直观的差异是报文方向的数量。单向隧道的抓包里，MPLS 报文只出现在一个方向——从 R1 到 R3；双向隧道的抓包里，两个方向的报文都有，且标签值明显不同。

X 方向（R1→R3）：R1 发出的报文 Label=100、S=1，到 R2 后交换为 Label=200、S=1，R3 收到后弹出并转成 ICMP Echo Reply 的 IP 包。

Y 方向（R3→R1）：R3 发出的报文 Label=300、S=1，R2 交换为 Label=400、S=1，R1 弹出还原为 IP 包。

两个方向共享 R2 这台 Transit，但 R2 的转发表能区分——它根据入标签值决定走哪条表项。这也解释了为什么上一节强调「入标签 + 入接口绑定」：两个方向的报文可能从不同接口进来，但标签值本身已经足够区分。

4.4 抓包位置对观察结果的影响：链路中间看到的永远是被交换后的标签

这是很多人刚开始分析 MPLS 抓包时会困惑的点。同一份 pcapng 里只抓了一个位置，但如果你在真实环境中把抓包位置放在 R1—R2 链路上，看到的永远是 Label=100；放在 R2—R3 链路上，看到的永远是 Label=200。原因是标签交换发生在 R2 的内部转发过程中，链路中间截获的报文是交换完成后的结果。

所以做抓包实验时，如果条件允许，最好在两段链路上各抓一次。R1—R2 的抓包能验证 Ingress 是否正确压入标签，R2—R3 的抓包能验证 Transit 是否正确交换标签。资源包里的单向抓包主要在 R1—R2 段捕获，重点观察 Push 动作；双向抓包则覆盖了更多报文，适合对照两个方向的标签变化。

5. 静态 LSP 配置与抓包避坑：五个高频翻车点排查

5.1 现象：FEC 掩码写错，流量走了 IP 路由而不是 MPLS

配置static-lsp ingress时 destination 写成192.168.3.0 24，但业务网段实际是192.168.3.0 27。结果是部分 IP 报文匹配 FEC 进入 MPLS 隧道，另一部分走了普通 IP 转发，抓包里既有带标签的报文又有裸 IP 报文，看起来毫无规律。

原因：静态 LSP 的 FEC 匹配是精确匹配，掩码不同就是不同的 FEC。IP 路由的最长前缀匹配和 LSP 表项的最长前缀匹配是独立的两套逻辑，路由能通不代表 LSP 能匹配。

解决：把destination的掩码改成和实际业务网段严格一致。如果不确定业务网段掩码，在 Egress 设备上查看接口地址和掩码是最直接的办法。

5.2 现象：Ingress 设备 ping 不通对端，但 display mpls static-lsp 显示 Active

这种情况最容易让人怀疑配置没问题。R1 上 ping 192.168.3.1，Reply 能收到，但延迟比普通 IP 转发高，且抓包里看到 MPLS 报文后紧跟一个 ICMP 报文——实际上是 R3 弹掉标签后回的包丢了标签。

原因：反向路径没有配置。静态 LSP 是单向的，R1 到 R3 走了 MPLS，但 R3 回包时没有对应的反向 LSP，只能走 IP 路由。如果 R2 上没有到 R1 的回程路由，回包在 R2 就被丢弃了。

解决：配置反向 LSP（LSP2），或者确保中间节点有完整的 IP 路由。做 MPLS 实验时，建议同时配好正反两个方向的静态 LSP，避免「通一半」的假象。

5.3 现象：Transit 节点收到带标签报文但直接丢弃，抓包显示 No response

在 R2 的入接口抓包能看到 MPLS 报文，但报文没有继续转发到 R3。检查display mpls static-lsp发现 Transit 表项状态是 Active，但入接口状态是 down。

原因：入接口绑定错误。Transit 的incoming-interface写成了面向 R3 的接口，实际报文从面向 R1 的接口进来，不匹配任何入标签表项。

解决：核对物理接口的连线方向。一个实用的检查方法是看报文实际从哪个接口到达，display mpls static-lsp verbose会显示表项匹配的接口信息，和抓包的接口对比一下就能发现问题。

5.4 现象：Wireshark 里能看到报文，但 MPLS 层显示为「Malformed Packet」

抓包里能看到数据帧，但 Wireshark 解析 MPLS 时报 Malformed，展开后标签值异常，S 位和 TTL 位置也乱。

原因：抓包位置不在链路上，而是在虚拟机的虚拟交换机上。某些模拟器的抓包接口会额外插入 VLAN 标签，Wireshark 把 VLAN 头误判为 MPLS 头。

解决：先看 Ethernet 层的 Type 字段。如果显示 0x8100（VLAN）而 MPLS 的 EtherType 是 0x8847，说明报文带了 VLAN 标签。在 Wireshark 里右键选择「Decode As」，把该链路类型强制解析为 MPLS，或者调整模拟器的抓包接口设置，去掉 VLAN 封装。

5.5 现象：Egress 节点弹掉标签后，报文在设备内部被丢弃

R3 上配置了 Egress 段，抓包也看到标签被弹出，但业务报文没有到达最终的服务器，display ip routing-table里目的网段的路由状态异常。

原因：Egress 弹出的标签只是数据面的动作，控制面的 IP 路由必须完整。如果 R3 没有到目的网段的路由，弹掉标签后的报文无处转发。

解决：检查 Egress 设备的路由表，确认去往业务网段的路由存在且生效。静态 LSP 只管标签路径，它不负责 IP 路由——这是新手最容易混淆的分层概念。

6. 进阶验证：用 traceroute 与连续抓包确认双向标签路径

静态 LSP 配置完成、双向 ping 通之后，实验并没有结束。ping 通只能说明数据能到达，但没法证明数据确实走了你配置的标签路径。我在做这个实验时，发现两个方法能更扎实地验证转发路径：traceroute 观察每跳地址，以及分段抓包对照标签值。

先看 traceroute。在 R1 上执行tracert 192.168.3.1（华为命令行是tracert，思科是traceroute），注意观察每一跳返回的地址。如果 MPLS 路径生效，traceroute 默认显示的中间跳地址是 MPLS 域内的设备接口地址——通常会看到 R2 的接口地址 10.0.12.2 和 R3 的接口地址 10.0.23.3。如果第一跳就直接显示 192.168.3.1，说明报文没有进隧道或者隧道在 R2 就被弹掉了。

再看分段抓包。在 R1—R2 链路和 R2—R3 链路各抓一次，然后从 R1 ping 192.168.3.1，导出两次抓包的 MPLS 标签：

# 第一次抓包（R1—R2 链路） mpls.label == 100 # 第二次抓包（R2—R3 链路） mpls.label == 200

如果两段链路的标签值如上面所示，说明 R2 正确地执行了 Swap。反向验证则看标签 300→400 的变化。还有一个细节值得关注：MPLS 报文的 TTL 字段。R1 压标签时 TTL 默认继承 IP TTL，每经过一个 LSR 递减 1。如果在两段抓包里看到 label 100 的报文 TTL 是 63、label 200 的报文 TTL 是 62，说明 MPLS TTL 在逐跳递减，转发是健康的。

从那以后，我每次配置完静态 LSP 都会强制走一遍这套验证流程：先display mpls static-lsp看表项状态，再 ping 看两端连通性，最后分段抓包对照标签变化。前面三步只能证明「通」，最后一步才能证明「按我配的路径通」。希望这份资源和这套验证思路能帮你在 MPLS 这条路上少走弯路。

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