概述环境

我们将基于如下环境来学习 LDP 的工作过程，包括 标签分发 及 数据转发 两部分；

1）网络互通：在网络中，已经部署 OSPF 协议，且各设备之间能够正常学习到对方的路由信息；
2）开启 MPLS 协议：已在各设备及相应接口上激活 MPLS 及 LDP 协议，且在相邻的设备之间已正常建立本地 LDP 会话；
3）标签发布与管理：所有 LSR 均采用 DU + Ordered + Liberal 方式；

对于从 R1 进入，到达 192.168.4.0/24 的数据，R1 为 Ingress LSR，R4 为 Egress LSR；

标签分发

Egress-LSR

R4 直连网段 192.168.4.0/24，R4 将主动为到达该网段的路由分配标签，如 1041，并主动通过 LDP 协议报文将标签映射通告给 LDP 对等体 R2 和 R3；

Transit-LSR

以 R2 为例，在其路由表中，192.168.4.0/24 路由的下一跳为 R4，当它从 R4 收到关于 192.168.4.0/24 的标签映射通告时，由于该通告来自下游 LDP 邻居，因此这将触发它自己为该路由分配标签 1021，并将标签映射通告给 LDP 邻居（如 R1）。R3 同理；

Ingress-LSR

R1 收到 LDP 邻居 R2 及 R3 通告过来的关于 192.168.4.0/24 路由的标签映射后，将这两个标签都存储起来，
但是由于在自己的路由表中，到达 192.168.4.0/24 的下一跳是 R2，因此当前它只会使用 R2 所通告的标签 1021；

注：当 R2 发生故障时，OSPF 路由将会重新收敛，此时 R1 的路由表中 192.168.4.0/24 路由的下一跳将会切换至 R3，此时 R1 将启用 R3 所通告的、关于 192.168.4.0/24 的标签；

标签转发

Ingress-LSR

R1 作为 Ingress LSR，需要对接收的 IP 报文执行 Push 操作压入标签，并进行标签转发；

当 R1 收到发往 192.168.4.1 的 IP 报文时，首先在其 FIB 表中查询该目的 IP 地址，它发现所匹配的表项的 Tunnel ID 为非 0，
因此继续在 NHLFE 中查询该 Tunnel ID，然后意识到需要将对该 IP 报文压入标签并进行标签转发，出接口为 GE0/0/0、下一跳为 R2、出站标签为 1021，
于是为报文插入标签头部并转发出去；

Transit-LSR

R2 作为 Transit LSR，需要对接收的 IP-Packet 执行 Swap 操作交换标签，并进行标签转发；

当 R2 收到携带 1021 标签的标签报文时，查询 ILM，根据 ILM 对应到 NHLFE 中的表项。于是，R2 对该标签报文通过 swap 操作将标签更换为 1041，并从相应的接口转发出去；

Egress-LSR

R4 作为 Egress LSR，需要对接收的 IP 报文执行 Pop 操作交换标签，并进行 IP 转发；

当 R4 收到携带 1041 标签的标签报文时，查询 ILM，根据 ILM 查询到操作为 Pop；
于是，R4 对该标签报文通过 Pop 操作将最外层标签剥离，此时该报文已经变成了标准 IP 报文，R4 将对该 IP 报文执行标准的 IP 转发流程；

Q：R4 在转发该报文时分别查询了 LFIB 和 FIB 表，作为最后 Egress LSR，其存在转发效率提升的可能性，怎么做？
A：这里没有讨论存在 PHP 或 显示空标签 的场景；