MPLS/LDP原理介绍+报文分析+配置示例

个人认为，理解报文就理解了协议。通过报文中的字段可以理解协议在交互过程中相关传递的信息，更加便于理解协议。

因此本文将在MPLS/LDP协议报文的基础上进行介绍，以详细介绍。

关于MPLS基本原理的相关内容，可参考2001年发布的RFC3031。
关于MPLS标签栈的封装格式的相关内容，可参考2001年发布的RFC3032。
关于BGP传递VPN标签的相关内容，可参考2006年发布的RFC4364。
关于LDP协议基本原理的相关内容，可参考2007年发布的RFC5036。
关于BGP原理相关内容，可参考博客BGPv4-原理介绍+报文分析+配置示例。
关于LDP协议报文的相关参数，可参考IANA的Label Distribution Protocol (LDP) Parameters。
关于BGP/MPLS IP VPN的场景介绍，可参考博客BGP/MPLS虚拟专用网络原理介绍+报文分析+配置示例。

关于MPLS协议在帧中继网络上应用的相关内容，可参考2001年发布的RFC3034。
关于MPLS协议在ATM网络上应用的相关内容，可参考2001年发布的RFC3035。
关于MPLS协议对QOS差分模型的支持情况，可参考2002年发布的RFC3270。
关于BGP在VPLS场景下的自动发现和信令传递，可参考2007年发布的RFC4761。
关于LDP在VPLS场景下的信令实现，可参考2007年发布的RFC4762。
关于LDP在PW建立和维护上的实现，可参考2017年发布的RFC8077。
关于BGP传递特定标签前缀的实现，可参考2017年发布的RFC8277。
关于Label的可用序号分类，可参考2021年发布的RFC9017。
…
MPLS/LDP还存在大量RFC更新，感兴趣者可查阅相关资料。

MPLS（Multiprotocol Label Switching）发展早期，主要用于加快数据包转发。（数据包在路由器之间不在需要根据最长掩码匹配查询路由表转发，而是根据对应的FEC直接转发）。随着转发芯片等硬件水平的发展，MPLS目前主要用于承载多种类型的上层网络满足多种复杂场景的应用。
LDP（Label Distribution Protocol）协议是MPLS概念的一个具体实现协议，是为分发标签而定义的协议。在具体实现上使用UDP/TCP的646端口进行相关协议报文的传输。
其他可以分配标签的协议还有SR场景下的IGP、BGP、MP-BGP和RSVP。
Note：LDP的扩展协议ATOM（Any Transport over MPLS）的介绍和ATM（Asynchronous Transfer Mode）信源等内容超出本文描述内容，感兴趣者可查阅相关文档。（例如Hop Count TLV和Path Vector TLV，下文只做简单说明）
第2和第3.1章节基本描述了MPLS/LDP的相关内容，有基础者可直接阅读相关内容。

目录

1.基础内容

1.1.背景介绍

路由交换原理：
一次路由，多次交换：这一概念主要是在三层交换机上实现的。
对于正常的三层数据转发，不仅要解封装二层 MAC 地址还需要三层解封装根据 DIP 上报 CPU 进行路由查表转发。
三层交换机的一次路由，多次交换指的是对于多个数据包/流指向同一个 DIP 时，仅在第一次进行路由表查找。此后的数据转发根据先前路由的缓存数据，不在上报 CPU 而是直接进行二层交换转发。

CEF交换：Cisco 提出的一种特快交换方案。
CEF主要维护FIB表（Forwarding Information Base，继承于路由表用于存储路由表转发信息的镜像），Adj表（用于存储所有邻居信息维护下一跳和邻居数据链路层信息）和可选的Netflow表现（网络状态监控相关内容）。
当接收到数据流时，TCAM 芯片根据 FIB 表查找数据流所对应的邻居信息，根据邻居表重写下一跳数据。

@需要注意的是CEF的转发信息并非缓存信息，而是仅与拓扑信息/路由信息相关的数据表项。
@CEF相比与一次路由多次交换相比，路由模块与交换模块完全分离不在需要上报CPU的查表过程。因此处理速度更快。
@一次路由多次交换和CEF交换概念的更详细介绍，可查阅相关资料。

在上述路由交换功方案出现之前，MPLS主要用于加快网络数据的转发。随着专用集成电路（Application Specific Integrated Circuit）的发展，MPLS在转发上无明显优势。MPLS的多层标签目前主要应用于VPN、TE流量功能和QOS等方面。

MPLS基本原理：
当数据包进入MPLS网络时，将特定数据包分配给特定 FEC（Forwarding Equivalence Classes，转发等价类），并携带跟该 FEC 相关联的标签从相应的端口进行转发。其他设备收到之后根据携带的标签值进行 SWAP 到达目的地。
MPLS-Multiprotocol Label Switching，也即多协议标签交换。多协议指的是适用于任何网络层协议。
在此重点介绍了以 IP 作为网络层协议的 MPLS 使用。

1.2.相关术语

DLCI：Data Link Connection Identifier，帧中继网络上用于标识电路（VC，Virtual Circuit）的标签。
VPI/VCI：Virtual Path Identifier/Virtual Channel Identifier。ATM把一条物理电路划分为几个虚拟的逻辑通路，称为VPI；然后在每一个VPI中再划分虚拟的信道（Channel），称为VCI。
FEC：Forwarding Equivalence Class，具有相同转发行为的数据包/流。

通常可将特定地址前缀称为FEC。一个特定地址“匹配”一个特定的地址前缀，当且仅当该地址以该前缀开头。

1.2.1.标签

Label：有固定长度用于识别FEC的物理连续标识符，通常具有局部意义。

Label格式：Label在Ethernet帧中的组织：
并且在RFC3032中定义了一些独特的标签值：
Label0=IPv4 Explicit NULL Label，
Label1=Router Alert Label，
Label2=IPv6 Explicit NULL Label，
Label3=Implicit NULL Label(for IPv4 and IPv6)，
Label4-15=Reserved。
显式空标签主要用于端到端的QOS，防止在PE上公网标签的弹出而无法QOS。PE收到空标签处理动作为直接弹出，而PHP可能还需要查表转发。
//显式设备上静态LSP可用标签范围，取决于设备自身设置也与厂家实现上有关。

Label Swap：标签交换。基本的转发操作包括查找传入标签以确定传出标签、封装、端口和其他数据处理信息。
Label Swapping：一种转发范例，允许通过使用标签来识别进行转发。并可允许不可区分地处理的数据分组的类别来简化数据的转发。
Label Switched Hop：标签跳，在两个 MPLS 节点之间上使用标签进行转发。
Label Switched Path：特定 FEC 中的数据包的路径。
Label Switched Router：可以支持3层转发的 MPLS 节点。
Label Stack：一系列标签的有序集合。

基本来说Label有三种动作：Push、Swap和POP。
Push表示流量在进入MPLS隧道时压入标签。
Swap表示标签流量途径每个MPLS节点时进行标签迭代/标签交换。
POP表示标签流量脱去标签。

MPLS domain： 处理MPLS路由和转发的一组连续节点。
MPLS Edge Node：MPLS域与域外的节点连接的MPLS节点。
MPLS Egress Node：离开MPLS域时处理流量的MPLS Edge Node。
MPLS Ingress Node：进入MPLS域时处理流量的MPLS Edge Node。
Upstream/Downstream LSR：如果两台LSR建立了关于某FEC的标签。就数据发送的角度来看，发送数据流的一方为Upstream LSR而接收数据流的一方为Downstream。

在MPLS体系结构中，将特定标签L绑定到特定FEC F的决定由相对于该绑定处于下游的LSR做出。然后，下游LSR向上游LSR通知进行该绑定关系。
因此，标签是“下游分配的”，标签绑定是在“从下游到上游”的方向上分布的。

NHLFE：The Next Hop Label Forwarding Entry，下一跳标签转发条目。

NHLFE主要指携带标签数据报文的下一跳处理动作：最主要的动作是顶层标签的SWAP和POP弹出标签。其他动作还可能有标签的层叠和进一步封装等，此处不在做说明。
SWAP指的是顶层标签的替换，例如收到上游发送的标签数据报文根据所在FEC确定NHLFE的下一跳。使用下一跳的标签替换接收到报文的顶层标签进行转发。
POP 则指的是顶层标签的弹出。一个 POP 场景是 NHLFE 下一跳为设备自身。

ILM：Incoming Label Map，将每个传入标签映射到一组NHLFE。它用于转发携带标签到达的数据包。
FTN：FEC-to-NHLFE，将每个 FEC 映射到一组 NHLFE。它用于转发未携带标签但要在转发之前进行标记的数据包。

点击此处回到目录

1.3.协议基本原理

MPLS/LDP基本原理：
Label Distribution Protocols 标签分发协议是一组过程，通过这些过程，一个LSR通知另一个它已经进行的 标签/FEC 绑定。使用标签分发协议来交换 标签/FEC 绑定信息的两个 LSR 就其交换的绑定信息而言被称为“标签分发对等体”。如果两个 LSR 是标签分发对等体，我们将谈到它们之间存在“标签分发邻接”。

1.3.1.标签通告DU+标签保留Liberal+标签分配Ordered

标签分配方式：下游按需（Downstream-on-Demand）和不经请求的下游（Unsolicited Downstream，下游自主）
下游按需：MPLS 体系结构允许 LSR 从其特定 FEC 的下一跳显式请求该 FEC 的标签绑定。
下游自主：MPLS体系结构允许 LSR 将绑定分发到尚未明确请求它们的 LSR。

//标签分配基于接口进行DOD下游按需还是DU下游自主。

标签保留模式：自由标签保留模式（Liberal Label Retention Mode）和保守标签保留方式（Conservative Label Retention Mode）
自由标签保留模式：从邻居 LSR 收到的标签映射，无论邻居 LSR 是不是自己FEC的下一跳都保留。
保守标签保持方式：从邻居 LSR 收到的标签映射，只有当邻居 LSR 是自己FEC的下一跳时才保留。

自由标签保留模式允许更快地适应路由更改，但保守标签保留模式需要LSR来维护更少的标签。
//AR系列设备：如果标签分配方式为 DU，则标签保持模式为 Liberal； 如果标签分配方式为DOD，则标签保持模式为Conservative。相关模式与设备相关。
自动换行
//label-retention conservative命令模式，设备不支持。

标签栈：RFC3031指出MPLS标签允许多层标签，也即标签栈。而栈深指的是标签层叠数，并且堆栈底部的标签称为1级标签，将其上方的标签（如果存在）称为2级标签，并将栈深M的顶部的标签称为m级标签。
标签的基本处理原则为先进后出，也即先处理顶层标签。

Penultimate Hop Popping：PHP次末跳弹出/倒数第二跳弹出。标签堆栈可以在LSP的倒数第二个LSR处弹出，而不是在LSP出口处弹出。

PHP实施的一个可能是，如果已经可以确认倒数第一跳LSR就是目的节点就没必要在倒数第一跳LSR进行判定。
并且对于层叠标签，倒数第一跳LSR很可能需要进行两次弹出。PHP的提前弹出将很大减轻倒数第一跳LSR的数据处理压力。

标签控制模式：有序（Ordered）和独立（Independent）
LSP的有序控制：如果LSR是特定FEC的出口LSR，或者如果它已经从该FEC的下一跳接收到该FEC的标签绑定，则LSR仅将标签绑定到该FEC。
LSP的独立控制：每个LSR在注意到它识别特定的FEC时，做出将标签绑定到该FEC并将该绑定关系传递出去的独立决定。

//华为设备有些只支持 Ordered。
//label distribution control-mode 用于设置标签分配控制方式。使用独立模式的结果是，可以在接收到下游标签之前为上游通告标签。

MPLS聚合：
MPLS体系支持聚合功能，但是应考虑设备之间的标签控制模式不同。在将标签绑定到FEC时，应该考虑将FEC全部聚合到单个FEC，还是基于每条信息单独建立FEC。在使用有序控制的情况下，这要求每个节点只知道在该节点离开MPLS网络的FEC的粒度。对于独立控制，可以通过确保所有LSR一致地配置为知道每个FEC的粒度来获得最佳结果。

路由选择：逐跳路由（hop by hop routing）和显式路由（explicit routing）。
逐跳路由：允许每个节点为每个FEC独立选择下一跳。这是目前现有IP网络中的常见模式。“逐跳路由LSP”是一种LSP，其路由是使用逐跳路由选择的。
显式路由：通常是LSP入口或LSP出口的LSR指定LSP中的几个LSR作为路由路径。

显式路由又可进行区分–如果指定了整个LSP，则称为严格显示路由，反之称为松散显示路由。
目前显式路由主要用于Traffic Engineering (TE)

标签有效性：
对于收到不可用的入标签和无出标签的流量，一般将其丢弃用于放置环路产生。

TTL处理：
在 MPLS 定义的标签中有类似 IPv4 报头中的 TTL 字段用于路由追踪和防环。MPLS 对 TTL 字段的处理有两种方式，一种是复制报头中的相应字段另一种是从255开始计数倒数查看。

//ttl propagate public 用于指定进行公网 TTL 字段复制（默认处理）
//ttl-mode 用于指定在PE设备上对私网 TTL 的映射处理方式。
uniform 模式：IP包 经过 MPLS 网络时，在入节点，IP TTL -1 映射到 MPLS TTL 字段，此后报文在 MPLS 网络中按照标准的 TTL 处理方式处理。
Pipe模式：IP包 经过 MPLS 网络时，在入节点，IP TTL -1，MPLS TTL 字段为固定值，此后报文在 MPLS 网络中按照标准的 TTL 处理方式处理。在出节点会将 IP TTL -1。即 IP包 经过 MPLS 网络时，无论经过多少跳，IP TTL 只在 PE 入节点和 PE 出节点分别减 -1。
因此在实际使用时需要注意厂家 IP TTL、公网标签 TTL 和私网标签 TTL 所具体使用的模式。

网络层协议确认：
从标签栈中弹出最后一个标签的LSR必须能够识别数据包的网络层协议。然而，从标签字段中不包含任何明确标识网络层协议的字段。这意味着必须可以从栈底弹出的标签的值中推断出来网络层协议，可能还有网络层报头本身的内容。因此在压入标签的第一个LSR应当为网络层协议压入特定可识别的标签。

MTU/IP MTU与分片：
与标准Ethernet帧相比，携带标签的数据包至少增加了4字节。这种现象在PPP和ATM网络下同样存在。因此有必要进行某种MTU发现机制，以减少携带标签的数据包的分片。

为了介绍其机制有必要先进行某些概念的说明
帧载荷：指除去数据链路层，CRC，帧检查序列，PPP头，802.1Q头，802.1P头的载荷。对于标准Ethernet的IP包来说指的是包含了IP头的IP数据字段大小。
常规最大帧载荷大小：数据链路标准允许的最大帧有效载荷大小。对于Ethernet来说是1500。在此可以简单说明下这个1500值的出处：IEEE802.3定义最小64byte，最大1518byte(不考虑VLAN的4字节等其他情况)。在1518的基础上排除数据链路层的8*2+2就是1500。
真实最大帧载荷大小：接口硬件可以正确处理的大小。通常认为真实最大帧载荷大小大于常规最大帧载荷大小。
携带标签的有效最大帧载荷大小：这是常规最大帧有效负载大小或真实最大帧有效负荷大小。
初始被标签IP包：在特定的LSR处接收到未进行标签标记并将要进行标签标记并转发的IP包。
先前被标签IP包：在被特定的LSR接收之前已经被标记的IP包。

1@：设置了非0的初始被标签 IP 包大小后，应当对接收超过该值需要标签转发的包进行分片。该值的设置不受 IP 包中 DF 分片标识的影响，Path MTU 的结果也不受该值影响。
2@：数据包超过了常规最大帧载荷大小时，可认为其“包太大”；数据包超过了真实最大帧载荷大小时，必须认为其“包太大”。
3@：如果包太大，可根据相关DF设置的情况做丢包和返回ICMP目的地不可达消息给丢弃数据报的源。此外还可进行相应的Path MTU的发现机制，从而在源头进行相应的分片。在这种情况下，一般会将DF位置位。

IP头部的DF位：分片标识。置0表示可以分片，置1表示不可以分片。

其他RFC3031-MPLS相关内容：
1@：PPP网络上的标签要求此处不做相关介绍
2@：在局域网上运行时，标签栈位于网络层头部之前在任何数据链路层报头之后，包括例如可能存在的任何 802.1Q 报头之后

标签空间：
RFC5036中定义了两种标签空间：每接口每标签（Per interface label space）和每平台每标签（Per platform label space）。
1@-每接口标签：接口特定的传入标签用于使用接口资源作为标签的接口。例如，使用VCI作为标签用于ATM接口，使用DCLI作为标签用于Frame Relay接口。
2@-每平台标签：传入标签用于可以共享相同标签的接口。

取每平台标签模式时，整个LSR使用一个标签空间。此时对特定前缀，设备向其他LDP对等体分配相同的标签。一般默认使用该模式
取每接口标签时，基于接口设备向其他LDP对等体分配不同标签。

LDP标识（LDP Identifiers）：
用于标识LSR标签空间的6字节整数=4字节的LSR标识+2字节的的特定标签空间。

//LSR 标识应当全局唯一，一般取的是路由器 Router-ID。

此外，使用基于平台标签时，最后2字节取0。目前默认使用每平台每标签。

LDP的环路检测：
LDP 协议利用 Label Request 和 Label Mapping messages 携带的 Path Vector TLV 和 Hop Count TLV，实现防止 Label Request messages 在存在不支持合并的 LSR 时循环。
关于 Path Vector TLV 和 Hop Count TLV 的应用和实现逻辑内容，有意者可查阅相关资料。

点击此处回到目录

2.MPLS/LDP报文格式

LDP是一种为分发标签而定义的协议。它是一组过程和消息，标签交换路由器（LSR）通过将网络层路由信息直接映射到数据链路层交换路径来通过网络建立标签交换路径（LSP）.

LDP协议的基本逻辑在于：
首先发送UDP的Discovery messages宣告自己在网络中的存在。随后通过TCP建立传输的会话。在完成初始化后由LSR做出请求标签或公布标签映射的决定。

2.1.LDP报文基本格式

LDP报文的基本组织是在最外层携带协议基本类型，例如版本报文长和LDP标识。随后携带每种具体的报文，而每种具体报文中又携带相应的TLV进行信息交互。
//接下来依次进行相关介绍。

2.1.1.LDP PDU（Protocol Data Units）

Version：2字节，LDP的版本，目前固定为1。
PDU Length：2字节，除去Version和PDU Length字段后整个PDU的长度。
LDP Identifier：6字节，前文已介绍过=LSR-ID（4字节）+Label Space（2字节）。
其余为LDP PDU数据字段。

LDP报文举例：
//Hello Message：使用UDP，组播发送给所有路由器组播地址224.0.0.2。
//Keepalive Message：使用TCP，单播发送
从图中可以发现一个LDP PDU报文可以携带多种消息类型。此处就同时携带了Keepalive Message和Address Message。

2.1.2.LDP Messages–主要有4类

U-bit：Unknown message bit。如果U-bit未置位，则必须向消息发起方返回通知，并且必须忽略整个消息；如果设置了U-bit，则必须静默地忽略未知TLV。
Message Type：14bits。消息类型。
Message Length：2字节。Message ID+Mandatory Parameters+Optional Parameters的长度。
Message ID：4字节。用于识别可能应用于此消息的Notification message。
Mandatory Parameters：强制参数。所需参数需依照相关顺序进行排列。
Optional Parameters：可选参数。所需参数无顺序。

LDP（Label Distribution Protocol）主要有4类LDP消息：
Discovery messages：宣告和维护LSP关系/进程；
Session messages：建立，维护和中止LDP对等体会话；
Advertisement messages：创建，改变和删除FEC和Label映射；
Notification messages：传递咨询（Advisory Notifications）和错误消息（Error Notifications）。

而每种Message又可细分出如下几种Message：

Categories of LDP	Message Name	Note	Number
Discovery messages	Hello	0x0100	D1
Session messages	Initialization	0x0200	S1
	KeepAlive	0x0201	S2
Advertisement messages	Address	0x0300	A1
	Address Withdraw	0x0301	A2
	Label Mapping	0x0400	A3
	Label Request	0x0401	A4
	Label Abort Request	0x0404	A5
	Label Withdraw	0x0402	A6
	Label Release	0x0403	A7
Notification messages	Notification	0x0001	N1

需要注意的是这里给出的11种LDP消息类型仅仅是其中的常用消息类型。实际上到目前为止LDP的Message Type Name Space一共有18种消息类型

Message Type Name Space主要是分为如下几类：

Range	Registration Procedures	Note
0x0001-0x00FF	IETF Review	LDP base protocol通用
0x0100-0x01FF	IETF Review	LDP base protocol邻居发现
0x0200-0x02FF	IETF Review	LDP base protocol初始化
0x0300-0x03FF	IETF Review	LDP base protocol地址分配
0x0400-0x04FF	IETF Review	LDP base protocol标签分配
0x0500-0x05FF	IETF Review	LDP base protocol联系相关
0x0600-0x3DFF	IETF Review	LDP base protocol
0x3E00-0x3EFF	厂商私有扩展	IANA未指定
0x3F00-0x3FFF	LDP实验私有扩展	IANA未指定

其他的消息类型可查阅相关资料。

2.1.3.LDP TLV（Type-Length-Value）

U-bit：Unknown TLV bit。如果U-bit未置位，则必须向消息发起方返回通知，并且必须忽略整个消息；如果设置了U-bit，则必须静默地忽略未知TLV。
F-bit：Forward unknown TLV bit。仅当设置了U-bit，F-bit该比特才适用。如果F-bit未置位，则未知TLV不与包含的消息一起转发；如果设置F-bit，则未知TLV与包含消息一起被转发。
Type：14bits，TLV的类型。0x0001-0x3FFF。
Length：2字节，Value字段的长度。
Value：可变长。

TLV Type Name Space主要是分为如下几类TLV Type：

Range	Registration Procedures	Note
0x0001-0x07FF	IETF Review	LDP base protocol
0x0800-0x08FF (CR-LDP)	IETF Review	LDP base protocol
0x0900-0x3DFF	IETF Review	LDP base protocol
0x3E00-0x3EFF	厂商私有扩展	IANA未指定-RFC5036
0x3F00-0x3FFF	LDP实验扩展	IANA未指定-RFC5036

CR-LDP指的是Constraint-based Routing Label Distribution Protocol，约束路由LDP。旨在使路由表以外的其他信息能够被用于影响LSP的建立。目前CR-LDP和RSVP-TE作为控制信令主要用于显示路由确认，可以实现类似于SR相关功能。

这里有必要提前介绍下比较重要的TLV
FEC TLV：TLV Type Code=0x100
FEC TLV的Value字段主要由多个FEC Element组成，RFC5036定义了Wildcard FEC和Prefix FEC。Wildcard FEC仅在Label Withdraw和Label Release Message中使用。这里携带的是Prefix FEC。
Element Type和Element Length各自占据了1个字节。
Element Type的0-127用于IETF Review而128-191主要用于First Come First Served。关于FEC Type Name Space的详细分类可查阅相关资料。

Status TLV：TLV Type Code=0x300

E-bit：也即Fatal error bit标识发送的是否是差错消息（置1表示差错消息，置0表示咨询消息）；
F-bit：必须与Status TLV的Forward unknown TLV bit相同；
Status Data：30 bits用于具体表示传递的消息类型；
Message ID：非0时表示引用其他相对应的Message；
Message Type：如果非零，则为状态TLV所引用的对等消息的类型。如果为零，则状态TLV不会引用任何特定的消息类型。
需要注意Status TLV并不仅限Notification Message携带。其他消息携带时应将U-bit置1以便对端可在无准备情况下丢弃。

Status Data字段占据30 bits，有Status Code Name Space分类取值0x00000000-0x3FFFFFFF：

Range	Registration Procedures	Note
0x00000000-0x1FFFFFFF	IETF Review	CR-LDP: 0x04000000-0x040000FF
0x20000000-0x3EFFFFFF	First Come First Served
0x3F000000-0x3FFFFFFF	Private Use

关于Status Code Name Space的详细分类可查阅相关资料。

自动换行
其他需要注意的内容
1@：除了上文提到了Message Type Name Space、TLV Type Name Space、FEC (Element) Type Name Space和Status Code Name Space外还有一种分类：Experiment ID Name Space。

Experiment ID Name Space共4字节分为两种：
0x00000000-0xefffffff为First Come First Served模型；
0xf0000000-0xffffffff为Experiment Ids - Reserved for Private Use。

2@：与ISIS和BGP相同，LDP协议也采用TLV的架构进行报文格式的搭建。这样的一个好处是可以很方便的进行协议扩展以支持更多更丰富的内容。因此后续可能会出现更多的Message Type Name Space分类和更多的TLV Type Name Space分类。
3@：关于LDP协议报文的相关参数，可参考Label Distribution Protocol (LDP) Parameters。

点击此处回到目录

2.2.Notification和Discovery messages

Notification Message–Message Type取0x0001：
并且其Mandatory Parameters只含Status TLV，RFC5036中表明其Optional Parameters中可选的TLV有Extended Status，Returned PDU和Returned Message。

Status TLV：Type Code=0x300

E-bit：也即Fatal error bit标识发送的是否是差错消息（置1表示差错消息，置0表示咨询消息）；
F-bit：必须与Status TLV的Forward unknown TLV bit相同；
Status Data：30 bits用于具体表示传递的消息类型；
Message ID：非0时表示引用其他相对应的Message；
Message Type：如果非零，则为状态TLV所引用的对等消息的类型。如果为零，则状态TLV不会引用任何特定的消息类型。
需要注意Status TLV并不仅限Notification Message携带。其他消息携带时应将U-bit置1以便对端可在无准备情况下丢弃。
自动换行
Extended Status TLV：Type Code=0x0301，对Status Information的额外补充。
Returned PDU：Type Code=0x0302，与Notification对应的一部分PDU报文。
Returned Message：Type Code=0x0303，与Notification对应的一部分Message报文。

当发生致命错误则在Notification Messag中携带的状态代码将指示该情况。并在发出该报文后关闭TCP会话，并丢弃与会话相关联的状态。包括通过会话学习的所有标签FEC绑定。
对端接收到后同样关闭TCP会话，并丢弃与会话相关联的状态。包括通过会话学习的所有标签FEC绑定。
自动换行

Hello Message–Message Type取0x0100：
并且其Mandatory Parameters只含Common Hello Parameters TLV，RFC5036中表明其Optional Parameters中可选的TLV有Extended Status，Returned PDU和Returned Message。

Common Hello Parameters TLV：Type Code=0x400
Hold Time：2字节。类似于OSPF和ISIS的Deadtime。
和//这里是分别配置LDP的本地会话和远端会话Hold Time间隔默认15s，并在取65535s时表示永不超时。实际生效的定时器值等于LDP对等体两端所配置的Hello保持定时器的较小值，如果这个值小于9，则Hello保持定时器的值等于9。
此外还可根据设备自身情况自行决定发送LDP Hello PDU的间隔。
和//默认取Hold的1/3，如果配置值超过Hold的1/3以Hold的1/3为准。
自动换行
T-bit：Targeted Hello bit。置1表示为发往目标的Hello包，置0表示为链路Hello。
R-bit：Request Send Targeted Hellos bit。置1表示请求接收器向此Hello的源发送周期性的目标Hello，置1时不会发出请求。接收者如果接收到R-bit置1的的Hello则检查自己是否配置了发往这个报文源地址的Hello请求，如果没有配置则忽略该请求。
GTSM-bit：Generalized TTL Security Mechanism bit。该Bit位由RFC6720所定义，感兴趣者可阅读相关资料。
其他为保留bit。
//设置LDP的GTSM功能，当LDP对等体发来报文的TTL值在[255–hops+1，255]范围内，则接收该报文。否则丢弃该LDP报文。
自动换行
IPv4 Transport Address TLV：Type Code=0x401，指定在打开LDP会话TCP连接时用于发送LSR的IPv4地址。不携带本TLV则使用Hello包的源地址。
//指定建立LDP的session会话的接口，接口未配置地址则使用0.0.0.0。缺省情况下，公网的LDP传输地址等于节点的LSR ID，私网的传输地址等于接口的主IP地址。如果将接口配置为传输地址时，有可能Hello包中不出现IPv4 Transport Address TLV。此时默认以源地址作为传输地址。
自动换行
Configuration Sequence Number TLV：Type Code=0x402，指定一个4个八位字节的无符号配置序列号，用于标识发送LSR的配置状态。当在LDP会话建立过程中扮演主动角色的接收LSR检测到发送LSR的配置发生变化时，可以清除与发送LSR相关的会话建立回退延迟
自动换行
IPv6 Transport Address TLV：Type Code=0x403，指定在打开LDP会话TCP连接时用于发送LSR的IPv6地址。不携带本TLV则使用Hello包的源地址。
与IPv4 Transport Address TLV作用相同。

需要注意
1@：Hello Message使用所有路由器组播地址224.0.0.2发送，并且传输层使用UDP的646端口作为SPort和Dport。
2@：在可用前提下刷新相应的Hello邻接Hold 定时器，并根据Hello PDU头部的LDP Identifier（LSR-ID+Label Space）开始建立相应的Session会话。
3@：LSR ID（这里指的排除了标签空间的2字节）用于邻居发现和会话建立。因此即使两台设备有多条链路启用LDP也仅仅建立一个peer一个session。如果指定接口建立情况不变，而且都是与BGP相同仅保留IP地址大的会话并且TCP的主动端为IP地址大的一方。

自动换行
点击此处回到目录

2.3.Session messages

Categories of LDP	Message Name	Note	Number
Session messages	Initialization	0x0200	S1
	KeepAlive	0x0201	S2

Session messages又可分为Initialization和KeepAlive报文，在此进行相关介绍。

Initialization–Message Type取0x0200：
并且其Mandatory Parameters只含Common Session Parameters TLV，RFC5036中表明其Optional Parameters中可选的TLV有ATM Session Parameters TLV和Frame Relay Session Parameters TLV。

Common Session Parameters TLV：Type Code=0x500Protocol Version：2字节，定义当前LDP协议的版本。
KeepAlive Time：2字节，定义Keepalive报文的保活时间间隔。默认45s。
两端协商不一致时，实际使用两端配置的较小值。
和//这里分别用于配置LDP的本地会话和远端会话。
与Hello Message类似，Keepalive Message也可基于设备自身定义发送Keeaplive Message的间隔。
和//分别配置LDP本地会话和远端会话的Keepalive Message发送间隔，默认取Keepalive Hold的1/3，如果配置值超过Keepalive Hold的1/3以Hold的1/3为准。
于Keepalive Message发送间隔不在报文中体现，因此发送间隔由每个LSR来决定。
自动换行
A-bit，Label Advertisement Discipline：标签通告原则。置0表示下游未经请求；值1表示下游按需。
2007年的RFC5036对该bit的协商进行了说明。当两端协商值不一样时有如下情况：如果会话用于标签控制的ATM链路或标签控制的帧中继链路时，则必须使用下游按需传输。否则，必须使用未经请求的下游。如果LSR无法接受则必须发送Notification message通知对端并关闭Session会话。
D-bit，Loop Detection：标识是否启用基于路径向量的循环检测。置0表示环路检测被禁用；置1意味着环路检测被启用。
Path Vector Limit：1字节。配置的最大路径向量长度。如果环路检测被禁用（D=0），则必须为0。如果环路检测过程将要求LSR发送超过该限制的路径向量，则LSR的行为将如同针对所讨论的FEC检测到环路一样。
Max PDU Length：2字节。会话的LDP PDU的最大允许长度。255或以下的值表示默认使用默认最大长度4096。接收LSR必须通过使用其和其对等方对最大PDU长度的建议中较小的一个来计算会话的最大PDU长度。
Receiver LDP Identifier：6字节=LSR-ID+Label Space。携带对端的LDP标识，用于和本地进行匹配。
ATM Session Parameters TLV：Type Code=0x0501，当LDP会话在ATM链路上进行标签交换需要定义特定ATM参数时使用。有意者可查阅相关资料。
Frame Relay Session Parameters TLV：Type Code=0x0502，当LDP会话在帧中继链路上进行标签交换需要定义特定帧中继参数时使用。有意者可查阅相关资料。

自动换行
KeepAlive–Message Type取0x0201：
//仅含PDU头部，不携带Mandatory Parameters和Optional Parameters。
@LDP的TCP会话Keepalive Hold定时器可被任意LDP PDU刷新重置。
@因此，LDP协议不要求强制发送Keepalive Message消息。
而实际上这里说明的保活机制只是一个参考，定时器的刷新可由厂家自行决定。

LDP Hello Message和LDP Keepalive Message的区别：
两者的定时器一个发送定时器默认分别为5s和15s，而保活定时器默认分别为15s和45s。
并且Hello是为了维护邻居发现的存在或者邻居/邻接表的存在，Keepalive更多是维护TCP会话的需要。两者是独立进行的！！！

2.4.Advertisement messages

Categories of LDP	Message Name	Note	Number
Advertisement messages	Address	0x0300	A1
	Address Withdraw	0x0301	A2
	Label Mapping	0x0400	A3
	Label Request	0x0401	A4
	Label Abort Request	0x0404	A5
	Label Withdraw	0x0402	A6
	Label Release	0x0403	A7

2.4.1.Address和Address Withdraw消息

Address–Message Type取0x0300：A1
并且其Mandatory Parameters只含Address List TLV，RFC5036中表明其不含Optional Parameters。

Address List TLV：Type Code=0x101Address Family：2字节。描述传递的地址族类型。
Addresses：不定长。与地址族对应的地址。
自动换行

@接收Address Message的LSR使用其所学习的地址来维护用于在对等LDP标识符和下一跳地址之间映射的数据库。
@如果LSR不支持地址列表TLV中指定的地址族，则应向其LDP发送不支持的地址族通知，以发出错误信号并中止处理该消息。

自动换行
Address Withdraw–Message Type取0x0301：A2
并且其Mandatory Parameters只含Address List TLV，RFC5036中表明其不含Optional Parameters。从报文上看Address Message和Address Withdraw Message除Message Type不同外，其他完全相同。

自动换行

2.4.2.Label Mapping、Label Request和Label Abort Request消息

Label Mapping–Message Type取0x0400：A3
并且其Mandatory Parameters只含FEC TLV和Label TLV，RFC5036中表明其Optional Parameters中可选的TLV有Label Request Message ID TLV、Hop Count TLV和Path Vector TLV。

FEC TLV：Type Code=0x100
FEC TLV的Value字段主要由多个FEC Element组成，RFC5036定义了Wildcard FEC和Prefix FEC。Wildcard FEC仅在Label Withdraw和Label Release Message中使用。这里携带的是Prefix FEC。
自动换行
Label TLV–又可分为Generic Label TLV、ATM Label TLV和Frame Relay Label TLV。这里仅介绍Generic Label TLV。：Type Code=0x200
Label：20 bits。
自动换行
Label Request Message ID TLV：Type Code=0x600如果这个Label Mapping Message是对Label Request Message的响应，它必须包含Label Request Message ID TLV。该可选参数的值是对应标签请求消息的Message ID。
自动换行
Hop Count TLV：Type Code=0x103
每台LSR指定相应的HC值，Hop Count TLV在传递时每经过一台LSR就加1。如果HC Value超过LSR的限制就将其丢弃从而防环。
自动换行
Path Vector TLV：Type Code=0x104
每经过一台LSR就填充其LSR ID，如果有相同LSR ID就说明出现环路从而将其丢弃。
自动换行
Hop Count TLV和Path Vector TLV主要用在非帧场景的信源模式。由于信源模式无IGP/TTL防环，因此使用这两种模式进行LDP的防环。

Label Mapping Message的发送事件与LSR的相关设置相关：
1@独立控制映射

1@LSR通过转发表识别新的FEC，并且标签通告模式是DU下行主动模式。
2@LSR从上游对等体收到针对存在于LSR的转发表中的FEC的请求消息。
3@FEC的下一跳改变到另一LDP对等体，并且配置环路检测。
4@映射的属性发生变化。
5@收到来自下游下一跳映射并且满足如下条件之一。没有创建上游映射或配置循环检测或映射的属性已经改变。

2@有序控制映射

1@LSR通过转发表识别新的FEC，并且是FEC出接口。
2@LSR从上游对等端接收针对存在于LSR的转发表中的FEC的请求消息，并且LSR是该FEC的出口，或者具有该FEC下游映射。
3@FEC的下一跳改变到另一LDP对等体，并且配置环路检测。
4@映射的属性发生变化。
5@收到来自下游下一跳映射并且满足如下条件之一。没有创建上游映射或配置循环检测或映射的属性已经改变。

3@DOD下游按需标签通告模式
不应期望在下游按需模式下运行的LSR发送未经请求的映射广告。

4@DU下游主动标签通告模式
只有当Rd（下游LSR）是该FEC的下一跳，而Ru（上游LSR）没有来自Rd的标签，并且该FEC的LSP是可以用本文档定义的tlv建立的LSP时，Ru才知道自己需要来自Rd的FEC标签。。

自动换行
Label Request–Message Type取0x0401：A4
并且其Mandatory Parameters只含FEC TLV，RFC5036中表明其Optional Parameters中可选的TLV有Label Request Message ID TLV、Hop Count TLV和Path Vector TLV。
上游LSR使用Request消息显式地请求下游LSR为FEC分配和发布标签。LSR可以在下列任何一种情况下发送请求消息：

1. LSR通过转发表识别新的FEC，下一跳是LDP对等体，并且LSR还没有下一跳到给定FEC的映射。

2. 到FEC的下一跳发生了变化，并且LSR还没有从该下一跳到给定FEC的映射。注意，如果LSR已经有一个新的下一跳的标签请求消息，它不应该发出额外的标签请求来响应下一跳的变化。

3. LSR收到上游对等体对FEC的标签请求，FEC的下一跳是LDP对等体，并且LSR还没有下一跳的映射。

Label Request Message的Message ID用作Label Request的标识符。当接收LSR以Label Mapping Message响应时，Label Mapping Message必须包含Label Request Message ID TLV。注意，由于LSR使用Label Request Message ID 作为标识符，LSR不应该重用Label Request Message的Message ID，直到相应的事务完成。

自动换行
Label Abort Request-Message Type取0x0404：A5
并且其Mandatory Parameters只含FEC TLV和Label Request Message ID TLV，RFC5036中表明其不含Optional Parameters。
在以下情况下，上游LSR Ru可以发送Label Abort Request消息，以终止发送给下游LSR Rd中FEC未完成的Label Request消息：
1@Ru的FEC下一站已经从LSR Rd改为LSR X。
2@Ru是一个非合并、非入接口的LSR，从上游peer y收到FEC的Label Abort Request。
3@Ru是一个合并的、非入口的LSR，并且收到了来自上游对等体Y的FEC的标签中止请求，Y是唯一(最后一个)为FEC请求标签的上游LSR。

还需要注意的是
1@当LSR接收到Label Abort Request Message时，如果它之前没有用Label Mapping message或其他Notification message响应被中止的Label Request，它必须通过响应Label Request Aborted Notification message来确认该中止。Notification message必须包含Label Request Message ID TLV，该TLV携带被终止的标签请求消息的消息ID。
2@如果LSR在使用Label Mapping或Notification message响应Label Request之后收到Label Abort Request Message，则忽略该中止请求。
3@如果LSR在发送Label Abort Request丢弃请求后，收到Label Mapping message作为Label Request message的响应，则该Label Mapping message中的标签是有效的。LSR可以选择使用该标签，也可以使用Label Release message释放该标签。
4@对Label Abort Request消息的响应永远不会是“有序的”。也就是说，响应不依赖于LSP建立过程的下游状态。LSR收到Label Abort Request消息后，无论LSP的下游状态如何，都必须立即处理该消息，根据需要响应一个Label Request Aborted Notification或忽略它。

自动换行

2.4.3.Label Withdraw和Label Release消息

Label Withdraw-Message Type取0x0402：A6
并且其Mandatory Parameters只含FEC TLV，RFC5036中表明其Optional Parameters中可选的TLV有Label Request Message ID TLV、Hop Count TLV和Path Vector TLV。
在以下情况下，LSR发送对应的Label Withdraw Message：
1@LSR不再承认以前已知的FEC，因为它已经为其打了标签。
2@LSR单方面决定(例如，通过配置)不再标记切换FEC(或FEC)，并撤回标签映射。
需要注意的是当LSR收到Label Withdraw消息时，必须发送Label Release消息。

自动换行
Label Release-Message Type取0x0403：A7

并且其Mandatory Parameters只含FEC TLV和Label TLV，RFC5036中表明其Optional Parameters中可选的TLV有Label TLV。
在以下情况下，LSR发送对应的Label Release Message：
1@发送标签映射的LSR不再是被映射FEC的下一跳，并且配置为保守模式。
2@LSR收到非FEC下一跳LSR的标签映射，配置为保守操作。
3@LSR收到Label Withdraw message。

还需要注意的是，如果LSR配置为“自由模式”，则在上述条件(1)和(2)的情况下，将永远不会发送释放消息。在这种情况下，上游LSR保留每个未使用的标签，以便当下游对等体成为FEC的下一跳时，可以立即使用它。

点击此处回到目录

3.LDP协议基本原理

3.1.LDP协议状态机

LDP的协议状态机主要有5种：NonExistent、Initialized、OpenSent、OpenRec和Operational。
状态机的切换伴随着相应的事件，这里仅作粗糙的进行相关介绍。详细的事件及其切换原理可查阅相关资料。

(1)：Session建立；
(2)：收到Notification Message或相应定时器超时；
(3)：Active端发送Initialization Message；
(4)：Active端收到Initialization Message发送Keepalive Message；
(5)：Passive端收到Initialization Message发送Initialization和Keepalive Message；

注意区分主动端和被动端，有IP地址大的一端承担Active端角色。

(6)：收到Keepalive Message；
(7)：收到Notification Message或相应定时器超时；
(8)：收到Notification Message或相应定时器超时；
(9)：收到Notification Message或相应定时器超时。

报文交互过程，可参考下图：
//首先发送UDP Hello组播包进行发现；随后TCP三次握手开始建立Session，Active端和Passive端互相初始化和Keepalive保活确认；完成之后可开始进行标签交互。

BGP也需要借助Keepalive来实现最终Established状态切换。
此时还未完成最终稳定表项的确认。

和//LDP协议状态机

3.2.LDP协议原理

标签分发过程：无条件推送PushUnconditional
1@：下游主动独立控制Downstream Unsolicited Independent Control；
2@：下游主动有序控制Downstream Unsolicited Ordered Control；
3@：下游按需独立控制Downstream On Demand Independent Control；
4@：下游按需有序控制Downstream On Demand Ordered Control。

需要注意的是：
1@：尽管在上文介绍Initialization Message中Common Session Parameters TLV提到标签的通告bit位可以进行相应协商。但是实际使用时还是尽量保持上下游一致。厂家实现有关。
2@：标签的通告的一个前提是本地已经为上游创建了相应标签。也即已经创建IN方向标签。
3@：厂家在分配标签建立LSP的策略上可能存在不同。//缺省情况下，根据32位的host IP路由触发LDP建立LSP。
4@：标签控制/标签分配方式为Order模式，指的是收到下游特定FEC分配的标签后才为上游分配相应标签。
通常使用该模式，以避免LSP的不完整而导致的流量黑洞。

标签撤销过程：
由下游LSR决定何时撤销先前分发给LDP对等体的FEC标签映射。

标签请求过程：
由上游LSR决定何时显式请求下游LSR将标签绑定到FEC，并将相应的标签映射发送给下游LSR。
主要可分为从不请求（Request Never）、按需请求（Request When Needed）和请求时请求（Request On Request）。请求时请求指的是收到标签请求时进行标签请求。

设备通常是DU下游主动通告标签，因此几乎不会使用到这一过程。

标签释放过程：
由上游LSR执行，决定何时释放FEC之前收到的标签映射。
1@：保守标签保留（Conservative Label retention或ReleaseOnChange）；
2@：自由标签保留（Liberal Label retention或NoReleaseOnChange）。

标签保留指的是对标签进行相应的保留。保守模式指的是仅保留下一跳设备分配的标签。
通常LDP针对FEC分配标签是基于路由表/转发表来实现，在不考虑负载均衡等情况下只选择最优路径最优下一跳进行标签分配。
1@如果配置了保守方式则只保留或请求了最优下一跳。在下一跳不可达情况等情况下会导致标签释放或标签无效。此时就需要等待FEC对应的下一跳收敛完成，然后重新进行标签请求。
2@如果配置为自由模式就可保留非最优下一跳的标签。此时就可进行转发。

标签无路由过程：
由上游LSR执行，以确定如何响应下游LSR响应FEC标签映射请求产生的No Route notification。
主要可分为请求重试（Request Retry）和不请求重试（No Request Retry）。除非LSR在FEC LSP中检测到环路，否则未探测到环路时使用过程与立即使用相同。

默认情况使用标签通告-下游主动DU+标签保留-自由模式Liberal+标签分配-有序模式Ordered。详情可查看上文。

TTL处理：
在 MPLS 定义的标签中有类似 IPv4 报头中的 TTL 字段用于路由追踪和防环。MPLS 对 TTL 字段的处理有两种方式，一种是复制报头中的相应字段另一种是从255开始计数倒数查看。

//ttl propagate public 用于指定进行公网 TTL 字段复制（默认处理）
//ttl-mode 用于指定在PE设备上对私网 TTL 的映射处理方式。
uniform 模式：IP包 经过 MPLS 网络时，在入节点，IP TTL -1 映射到 MPLS TTL 字段，此后报文在 MPLS 网络中按照标准的 TTL 处理方式处理。
Pipe模式：IP包 经过 MPLS 网络时，在入节点，IP TTL -1，MPLS TTL 字段为固定值，此后报文在 MPLS 网络中按照标准的 TTL 处理方式处理。在出节点会将 IP TTL -1。即 IP包 经过 MPLS 网络时，无论经过多少跳，IP TTL 只在 PE 入节点和 PE 出节点分别减 -1。
因此在实际使用时需要注意厂家 IP TTL、公网标签 TTL 和私网标签 TTL 所具体使用的模式。
自动换行
私网上进行路径Tracert时的场景分析：
通常情况下公网无私网路由，因此公网LSR无法向私网中设备正常发送IP形式的ICMP应答。
//缺省情况下，对于一层标签的 MPLS TTL 超时报文，将根据本地IP路由返回 ICMP 报文。将该命令 undo 之后如果 LSR 上不存在到达报文发送者的路由，则 ICMP 响应报文将按照 LSP 继续传送，到达 LSP Egress 节点后，由 Egress 节点将该消息以 TTL=255 返回给发送者。

MTU/IP MTU与分片：
与标准Ethernet帧相比，携带标签的数据包至少增加了4字节。这种现象在PPP和ATM网络下同样存在。因此又必要进行某种MTU发现机制，以减少携带标签的数据包的分片。

为了介绍其机制有必要先进行某些概念的说明
帧载荷：指除去数据链路层，CRC，帧检查序列，PPP头，802.1Q头，802.1P头的载荷。对于标准Ethernet的IP包来说指的是包含了IP头的IP数据字段大小。
常规最大帧载荷大小：数据链路标准允许的最大帧有效载荷大小。对于Ethernet来说是1500。在此可以简单说明下这个1500值的出处：IEEE802.3定义最小64byte，最大1518byte(不考虑VLAN的4字节等其他情况)。在1518的基础上排除数据链路层的8*2+2就是1500。
真实最大帧载荷大小：接口硬件可以正确处理的大小。通常认为真实最大帧载荷大小大于常规最大帧载荷大小。
携带标签的有效最大帧载荷大小：这是常规最大帧有效负载大小或真实最大帧有效负荷大小。
初始被标签IP包：在特定的LSR处接收到未进行标签标记并将要进行标签标记并转发的IP包。
先前被标签IP包：在被特定的LSR接收之前已经被标记的IP包。

1@：设置了非0的初始被标签IP包大小后，应当对接收超过该值需要标签转发的包进行分片。该值的设置不受IP包中DF分片标识的影响，Path MTU的结果也不受该值影响。
2@：数据包超过了常规最大帧载荷大小时，可认为其“包太大”；数据包超过了真实最大帧载荷大小时，必须认为其“包太大”。
3@：如果包太大，可根据相关DF设置的情况做丢包和返回ICMP目的地不可达消息给丢弃数据报的源。此外还可进行相应的Path MTU的发现机制，从而在源头进行相应的分片。在这种情况下，一般会将DF位置位。

IP头部的DF位：分片标识。置0表示可以分片，置1表示不可以分片。
//更改MPLS的MTU值，该值与接口自身MTU相关。实际选择两者较小的一个。HW只支持更改默认1500的三层MTU，而CISCO可更改二层和三层MTU。

点击此处回到目录

4.LDP协议配置实例

4.1.静态MPLS LSP传递流量

有如上图场景：
1@：AR1和AR4之间建立IGP协议，并在AR1上进行BGP和IGP协议的双向重分发以便引入和导出AR4和AR5上的32位主机路由；
2@：AR3和AR5之间建立IGP协议，并在AR1上进行BGP和IGP协议的双向重分发以便引入和导出AR4和AR5上的32位主机路由；
3@：AR1和AR3之间建立IBGP协议用于传递AR4和AR5上的主机路由。

要求在AR1和AR3之间建立静态LSP完成AR4和AR5上的32位主机路由4.4.4.4和5.5.5.5的通信。

场景分析：
根据如上情况可以发现私网部分下可以正常获取到相关路由，而公网部分AR2由于缺少私网主机路由而导致无法通信。
可以通过MPLS 静态LSP和GRE隧道解决，也可以通过路由引入将私网路由导入到AR2的本地路由表项中，这里要求使用MPLS 静态LSP。

AR1关键配置实例：

mpls lsr-id 1.1.1.1
mpls
#
static-lsp ingress To_AR3 destination 3.3.3.3 32 nexthop 10.1.2.2 out-label 102
static-lsp egress To_AR1 incoming-interface GigabitEthernet0/0/0 in-label 201
#
这里只提供了PE设备配置，有能力者可自行进行其他P和PE设备的配置。
有需要者可私信联系提供模拟器源文件及配置。

流量模型：
AR4的4.4.4.4 -----> AR5的5.5.5.5
1@：AR4查询路由表发现存在IGP路由指向AR5，请求下一跳ARP信息。封装IP和MAC进行三层转发。
2@：AR1接收到数据流校验正确，发现数据包应当发往3.3.3.3。同时发向3.3.3.3的数据流在转发表中可迭代到隧道–静态LSP中，因此插入相应的标签字段102。
3@：AR2接收到数据流校验入方向标签，依照FEC将标签102进行SWAP操作替换为标签103向AR3转发。
4@：AR3接收到数据流校验入方向标签正确，发现出标签为Null进行标签弹出。进行IP转发，查询相应路由表转发。
5@：AR5接收到数据流校验正确进行相应处理。

回程流量处理过程与该部分一致。
流量相应封装：

配置要点：
1@：启用MPLS，静态LSP也需在全局和需要执行标签转发的端口使能MPLS功能。
2@：建立静态LSP的目前节点选择。因为此处通过IBGP建立邻居传递路由，下一跳地址位AR1和AR3的各自Loop地址。所以在指定静态LSP的源目的地址时应当以路由表中下一跳地址进行MPLS隧道的迭代。

这里就是因为AR1上到私网下一跳地址为3.3.3.3才指定其为目的地址。如果AR1和AR3建立的是EBGP，默认就是使用接口地址就应指定为接口地址。

3@：要使得路径可以正常迭代，还需在AR1和AR3上使能隧道有限迭代功能。否则PE节点上无法压入相应标签进行标签转发。

//缺省情况下，非标签公网BGP IPv4路由、IPv4静态路由（BGP标签路由和动态路由可以）只能迭代到出接口和下一跳，不会迭代到隧道。可以通过配置此命令使上述路由优先迭代到隧道，如果没有隧道，上述路由也可以迭代到出接口和下一跳。

4@：AR1到AR3之间实际上也需要建立IGP协议，注意重分发路由时的准确性。并且HW默认不允许将公网IBGP引入到IGP中。

//公网实例下import-route bgp命令时默认只能引入EBGP路由，不能引入IBGP路由。

4.2.MPLS/LDP相关命令

//显示设备的转发表，并在TunnelID中指示是否进行隧道迭代。此处0x1表示发往3.3.3.3的数据可进行隧道迭代。

//显示建立的MPLS LSP路径信息，相当于一个最终的LSP。
//LDP协议动态建立的LSP信息

//查看LDP参数信息

//查看LDP对等体信息
//查看LDP会话信息。注意会话和对等体区别，通常session表示已经建立TCP连接，而peer可能仅完成了邻居发现。

//MPLS的LSP建立使用的路由信息。

关于LDP协议其他参数的配置，已在上文进行介绍。此处不在进行赘述。
//LDP协议的默认参数信息。
//LDP协议的接口参数信息。

更新

点击此处回到目录