目录
- 基础
- 术语
- 报文
- 整体看
- 细节看
- 衔接
- 报文转发
- 静态LDP
- 基本概念
- 静态LDP
- 标签和统一性
基础
MPLS的来历？
MPLS：多协议标签交换
随着互联网的发展，最长前缀匹配原则对于大量路由的查询路由变慢，这时出现了ATM的技术，创新性的提出了通过标签转发的机制，不再使用路由表，极大的提高了转发效率，后又出现MPLS协议，MPLS结合了传统的、通过最长前缀匹配原则匹配路由表的方式和最新的标签转发机制，一跃成为热门技术。
这里有句话需要注意，MPLS结合了传统的路由转发技术和标签转发是什么意思？我们可以将两者看做逻辑上的先后关系，建立MPLS的“连接”使用标签之前，必须先通过路由转发技术，使将要建立MPLS“连接”的设备能够正常通过路由转发通信；从这个角度来看，要做MPLS之前，先通过传统静态、OSPF、ISIS等路由协议把想要建立MPLS的设备之间的路打通是必不可少的。
我们还可以通过“提升”的角度来看，原本报文只是通过路由表进行转发，因为触发某种机制，就“提升”了维度，由原来的路由转发维度提升为MPLS标签转发维度，到达目的地之后，再还原为路由转发维度。这和我们做飞机很相似，我们打车去飞机场，这是地面空间，然后上了飞机就转换了空间到天上，然后下了飞机又转换回地面空间，我们也可以将路由转发和标签转发结合理解为两者的衔接与配合。
MPLS的真正优势？
ATM的早期的设计目的是为了解决路由转发效率过慢的问题，而MPLS包含了ATM这方面的优势，但是在当前社会这方式的优势并不明显，因为我们集成电路技术发展迅猛，实现了让硬件加速数据转发的效果，使得MPLS在高速转发这方面的优势并不明显了，那MPLS技术依然大火的原因是什么呢？原因起码有这么几点：
- 可以使用标签转发，弥补了高层路由协议，比如BGP路由协议的不足之处，比如黑洞路由。
- 位于2.5层，偏底层，拥有强大的兼容性，全面兼容各种协议，给自己赢得了“多协议”的美名，有点SSL、TSL的感觉，位于层与层之间。
- 由于其良好的兼容性，与路由协议当中的BGP协议相得益彰，与之搭配，又形成了BGP的另一个变种，MP-BGP，而MP-BGP与MPLS搭配形成了天然的VPN技术，解决了传输VPN技术的缺点，名为MPLS-VPN。
MPLS是如何解决黑洞路由的：
其实MPLS看着也挺简单，就在在原来的IP报文与链路层协议之间夹上一层MPLS层，在沿途的路由器转发的时候，拆封装只拆到MPLS层，也就是拆完链路层之后，再拆MPLS层，不再继续向上拆IP层了，所以沿途的路由器并不要求知道目标IP地址如何转发，只要求沿途的路由器也配置MPLS能看懂MPLS这一层当中的标签，然后查MPLS专用的转发表，知道某个标签该如何转发就行了，根本都不查路由表，这不就把黑洞路由给解决了嘛！
MPLS的问题：
我们先看效率问题。你看哈，数据转发是拆完链路层拆IP层，得到目标IP，然后再根据目标IP查路由表，要卖路由表的指示进行封装报文并转发。现在呢，是数据转发是拆完链路层拆MPLS层，得到目标标签，然后根据目标标签查标签转发表，根据标签转发表进行封装和转发，呃，怎么说呢，确实不查路由表了，但是现在是查标签表，感觉这TM效率差不多呀！
再来看一个场景：
老婆：你炒的这盘炒鸡蛋没有放盐呀，一点滋味都没有！
正常的老公：那我下法想办法提醒一下自己，做炒鸡蛋要放盐~
不正常的老公：那我们以后再也不吃炒鸡蛋了！MPLS其实是通过一个取巧的办法解决了黑洞路由路由，黑洞路由不就是因为少路由表导致黑洞的嘛，MPLS的解决思路很奇特哈，并没有直接解决缺少路由的问题，路由还是没有呀，它是从根本上解决了问题，那就是以后的转发再也不依赖路由表了！！还能这样，有点意思，有点像上面这个场景哈，MPLS就特别像是那个不正常的老公。
MPLS的典型应用:
- MPLS VPN
- 流量工程
术语
- MPLS：multi-porotol label swiching 多协议标签交换
- LSR：label swiching router 标签转发路由器，配置了MPLS的路由器都是LSR。
- ingress LSR：入站的LSR，对应的动作是标签压入，对流感兴趣。
- transit LSR：中转MPLS的LSR，对应的动作是标签转换，对流不感兴趣。
- egress LSR：出站的LSR，对应的动作是标签移除，对流感兴趣。
- ILM表：incoming label map：入标签映射表，只有中转LSR和出站LSR可能会存在，里面最重要的信息其实只有两个：标签和tunnel-id，标签先被查找，然后获得tunnel-id，而tunnel-id指向下一张表
- LNHFE表：next hop label forwarding entry 下一跳标签转发表项，tunnel-id指向的就是这张表，这张表里面明确确定了对数据包采取哪种操作，是压入、是转换，还是弹出，从动作当中我们推断出，这个表无论哪种角色都必须存在，只不过执行的动作不动罢了。
- LSP并不是某种角色，而是指MPLS在转发时经过的路径，注意LSP就在数据转发之前就要建立完成，而且LSP是单向的
- LDP（标签分发协议），想要建立LSP有两种方法，手动配置和动态生成，LDP是用来动态生成LSP的协议，BP-BGP也可以的。
我们在这里可以谈一谈感兴趣这个词的含义：
我们先来看一个vlan里面的tag，数据报文在始发时，比如PC向发出来的时候根据就没有标签呀，就像vlan的tag一样，一个普通的主机，如果没有进行特殊的配置，发出来的标签都不带标签的，像是vlan 的tag呀，MPLS的tag呀都是后来才添加的。vlan的tag是硬性添加，什么意思呢？比如我把2号接口划分成为vlan2，那从2号接口上来的数据包交换机会先检查报文当中的tag字段，如果字段为空，采取某个动作，如果不为空，然后再采取另一个动作，从这里来看，vlan技术是对报文里面的vlan 字段感兴趣，程序大概类似这样：
if tag_field == NULL: # 而这里的tag_filed的就是vlan技术的感兴趣点~
action ……
elif:
action ……
else：
action……我们于来看MPLS当中的感兴趣，这里面的感兴趣其实与vlan当中的感兴趣差别不大，只是感兴趣的点变了，
入站LSR感兴趣的点有两个（递进关系）：
- 目标IP地址
- tunnel_ID
入站LSR：
拆报文的链路层，得到type类型字段，得知此报文一个传统IP报文，继续向上拆包
拆报文的IP层，获得目标IP地址
根据目标IP查看，找FIB，看FIB的tunnel ID是否为0
if tunnel_ID == 0
1. 进入路由转发操作
2. 执行最长前缀匹配
else：
1. 此报文==MPLS报文
2. 进入MPLS转发表（LNHFE）
3. 根据MPLS转发表在IP层与链路层中间执行插入MPLS层，主要就是压入一个标签
4. 更改链路层当中的type类型字段，将原本的传输报文类型更改为MPLS报文中转LSR感兴趣的点有（递进关系）：
- 链路层的type
- 标签
- tunnel-id
中转LSR：
1. 拆报文的链路层，得到type类型字段，得知此报文是一个MPLS报文
2. 直接拆掉MPLS层，获取下一关最重要的线索：标签
3. 拿着标签去ILM表（入标签转发表），根据标签找到下一关重要的线索：tunnel_ID
4. 拿着tunnel_ID再去找MPLS转发表，根据MPLS转发表置换标签，并执行转发操作出站LSR感兴趣的点有（递进关系），与中转LSR差不多，只不过执行的操作不一样
- 链路层的type
- 标签
- tunnel-id
出站LSR：
1. 拆报文的链路层，得到type类型字段，得知此报文是一个MPLS报文
2. 直接拆掉MPLS层，获取下一关最重要的线索：标签
3. 拿着标签去ILM表（入标签转发表），根据标签找到下一关重要的线索：tunnel_ID
4. 拿着tunnel_ID再去找MPLS转发表，根据MPLS转发表弹出标签
5. 弹出标签之后，继续拆包，匹配路由表，执行转发操作好吧，我们总结一下，其实无论是哪种MPLS角色，他们最需要的东西，才是他们最兴趣的，三者的共同点，都对tunnel-id感兴趣。
对一个人感兴趣，我想也是这样吧，你对某个事物感兴趣，可能也是因为他身上存在了你所需要的因素。
报文
整体看
MPLS与OSPF都比较重要，甚至比OSPF更重要，MPLS也是检验之前的路由协议学的好与不好的关键指标，如果前面的ospf、bgp，vlan等协议学的不错，你会发现理解MPLS也不难，因为很多知识都是与之相关联的，mpls里面的最关键的地方在于标签，标签我们在vlan当中学过，所以在这里面的理解也会很容易；在mpls后续的学习当中我们会用于bgp，bgp的团体属性，而bgp又依赖于igp，如果你bgp学的不错，那MP-BGP也不在话下，从这里面来看，前面的路由协议你可以学的慢一点，学精一点，这样MPLS才会学的快。
贯穿MPLS的标签结构我们肯定要了解的，MPLS的标签你要注意呀，这里面的标签并不是指一个字段，也不是指某某首部，这里面的标签其实就是MPLS层，我们讨论mpls的标签，其实就是在讨论mpls报文，在wireshark上看就是单独的一层，这一层当中有一个关键的字段叫标签字段。这里与vlan 当中的tag标签做一个区分呀，vlan tag虽然也是做为一个字段，但是它可并没有做为单独的一层，而仅仅是做为一个单元，融入到二层报文当中。
细节看
细节来看，你会发现结构并不复杂，区区四个字段，但这里面还有点东西的。
我们先来看标签字段好了，这里的字段好长呀，整整20个比特，而vlan tag只有12比特，12比特能表示的最大数是4096，而标签里面最大能表示的数是1048576，是不是没必要搞这么大？能用的上吗？没必要搞成100多万吧！vlanid字段只能存一个数字，而mpls报文当中的这个地方表示并不一个数字，而是可以存在多个数字，也就是说mpls的标签其实是可以有多个的！标签是可以嵌套的！
好，那问题来了，当一个中转路由器收到带有多个标签，它应该拆哪个呢？这一点与GRE当中的IP首部嵌套差不多，都只会拆最外层的那一个，那怎样确定这一个标签就是最外层的那一个呢？就是看这里面的BOS位（bottom of stack位），如果这一位是0，说明这个标签就最外层的标签，拆了之后里面还有，如果这一位是1，说明这就是是后一个标签了，拆了之后就没标签了，后面就是IP报文了。从这里面我们大概就可以猜测一下，中间的传输LSR可能会收到有多个标签的报文，但后了最后一跳LSR，这一层报文很有可能就剩最后一层了，被最后一跳拆掉之后直接就该进入到路由转发了。
好了，最关键的标签字段和BOS字段看完了，还有一个字段比较重要呀，那就是TTL字段，看完熟悉吧，IP报文里面其实也有这么一个字段，每个MPLS都带有IP报文，为什么多此一举，再搞一个TTL字段呢？其实还真不是多些一举，你看哈，中转LSR只看MPLS层，根据都不看IP层，那IP报文当中TTL是不生效的，所以会把TTL值给放到MPLS层，这样每一个中间的LSR都会看到了，就能够达到TTL防环的作用了。
其实TTL根据都不能算做是防环，它根本不防环，其实它的作用是让环路有限度，不能一直环，环一阵子就把数据包扔掉。那MPLS的防环机制是不是有点单薄了，像是BGP都有多个字段用来防环，像是防环的PATH字段就有四种类型，还有各种防环的机制，其实不用担心的，为什么呢？因为MPLS本如果依赖于IGP协议，OSPF有防环机制吧，那MPLS就是建立在OSPF之上的，OSPF的防环其实就等于是BGP的防环呀！所以说，不用担心的。
关于EXP这是关于服务质量的，这里面就不多做解释了，在学习QOS章节的时候自然就会知道了，非常简单的。
衔接
衔接问题往往出现在层与层之间速度不同步的时候，而速度不同步往往是串行启动造成的。
我理解的衔接，理解为先后，为什么谈一下衔接呢？因为MPLS这种应用需要多协议之间的配合才能最终完成数据转发的任务，这里面不可避免会有衔接的问题。
我们前面谈到一个提升的操作，这就一个衔接，通过tunnel-id，将原来该走路由转发的操作做为接力棒交给了MPLS，让MPLS接着去完成任务，这个衔接其实是危险的，为什么这么说，我们来一步步的看一下。
tunnel-id存在于FIB表当中，而FID是从全局路由表当中得来，而全局路由表是从各种路由协议的路由表当中得来，这里面本身就存在了先后关系，我们拿OSPF来举例子：ospf 路由表和RIP都学到去往同一个目标的条目，对比优选，OSPF胜利进入到全局路由表，在全局路由表当中可能还要递归一下，才能形成完整的路由器，最后根据全局的路由表再生成FIB表；通过配置MPLS，在FIB当中标示出tunnel-id，再生成标签转发表，最终通过标签转发表进行转发。
这当中涉及到多个进程，而这些进程与进程之间是串行关系，不是并行关系，很有出现某个数据包，我们希望他走MPLS，结果呢？因为路由器断电刚重启，MPLS进程还没起来，但FIB已经有了，这时候数据就会通过路由转发，数据肯定要丢弃了……，衔接与衔接之间有漏洞，归根到底其实是速度不同步造成的，所以说，MPLS最好有某种机制来保证不会出现这种问题，其实是有的，这是不同的协议之间配合导致的这种问题。
那同种同种协议会出现这种问题吗？其实也会的，比如说OSPF，OSPF当中有一个FRR的机制，就是在链路有冗余时提前计算出冗余链路，为什么这么做？其实就是担心会出现衔接的问题，OSPF当中的层与层之间实际指硬中断与软中断之间的不匹配，A路由的OSPF接口down掉了，由于硬中断A路由器立马就反应过来要改变路由，但是A路由器的下一跳路由器就反应没这么快了，因为断的又不是它，它往往要等到A完全反应过来之后，A告诉它我这条路由走不通了才行……，那在下一跳路由器没有反应过来之后，数据已经发给它了，那数据就面临丢弃的风险了。
OSPF与ISIS都有FRR这种机制，这种机制其实是被动的，必须得满足某种公式，其实很简单，就是一个开销公式，FRR机制才会启动，其实如果满足了这种公式，就算衔接不好，那也问题不大，FRR仅仅是加快一下这个过程，锦上添花而已。
那MPLS怎样解决这个问题呢？MPLS解决这个问题的方式其实也是通过开销，只不过他这里面计算方式比FRR要巧妙许多，既然因为衔接问题出现的丢包是由于不同步造成的，那我同步不就行了吗？这就是MPLS解决这个问题的思路，就是将MPLS进程与IGP进程绑定，说来也简单，就是路由表不能在MPLS进程还没有启动完之前就进入到转发状态，必须要等到MPLS进程完全启动起来，这样再进入到转发状态，就不会出现丢包的情况了。
那这个思路你能不能运用到OSPF当中呢？不好搞，为什么？因为路由表生效和MPLS说到底都是程序或进程之间的配合，而OSPF因断电造成的衔接问题不是进程与进程之间，而硬件与软件之间，所以说这种思路，OSPF和ISIS想要借鉴，恐怕不容易的，那BGP呢？BGP其实是可以的，因为BGP依赖于IGP，BGP完全可以绑定BGP进程，在BGP完全启动之前，不让IGP的路由率先进行转发状态，但是我在BGP没有发现这种机制，也可能是我还没有学到。
报文转发
报文从开始被插入标签到后面被拆掉标签，这个报文转发过程是数据层面的转发流程。你要知道，在数据真正开始转发之之前LSP（转发路径）就要提前形成，也就是说在公路开始真正跑车之前，必须先把铁轨铺好。你可以从终点到源点开始铺好，也可以反过来，或是两头一起个铺，无所谓呀，但是MPLS的铺铁轨必须得是从数据转发的终点开始向源铺，这一特性有点类似于OPSF的开销的开销，是从目的地址到源路由器的的方式开始计算，这个铺路的过程，是控制层面的流程，两者的方向正好是相反的，如果数据转发的流程是从左到右，那控制层面的转发就是从右到左。
在控制层面，源是在MPLS真正完全运行时数据包最终要到达的地方; 在数据层面，源是在MPLS真正完全运行时数据包刚出发的地方。
补充一点，这种将数据层面与控制层面分开的协议并不仅仅有MPLS，FTP也是这样呀，只不过FTP还要更为复杂一点，它还加入到主动与被动的概念，好在MPLS当中没有主动与被动的概念。
值得一提的是，形成控制层面的的协议并不是MPLS协议，而是一个叫LDP的协议，LDP其实是MPLS一个组件，LDP协议就负责控制层面，MPLS的数据像是火车一样，火车不能在任何一种道路上跑，必须得在铁轨上跑，路其实早就有了，重点来了，LDP不是路由协议，它不会形成路由转发路径，LDP还得依赖于IGP，ospf，isis这些IGP路由协议，在此基础上铺好铁轨（形成标签转发表），画个图吧，如下所示：
通过这个图我们也应该联想到，我们配置MPLS的时候，要从底层向上层进行配置，先配置IGP，然后再配置LDP。
那我们对于MPLS的学习大体也是这三层，最底层建立路由表早就学过了，OSPF、ISIS、RIP甚至是静态都可以承载，我们要学的其实是就是控制层面的LSP，以及数据转发层面的相关知识点。
静态LDP
基本概念
LDP是标签分发协议，好，问题来了？给谁分发标签？数据来源在哪里？
LDP工作的大概过程：
这与普通的IGP协议不同，在普通的IGP协议当中，我们想宣告谁，或是对谁附加某某属性，需要宣告或通过acl匹配，而LDP则不同，它默认在启动完成之后，就自动去路由表当中寻找主机路由，给主机路由分发标签并告知它的上游路由器，上游路由器看到有人给它通告标签，它会做两个动作，第一个动作把标签存起来，第二个动作是是它自己也对此路由分配一个标签，并且把自己给这个路由以及给这个路由分配的标签信息告诉给上游路由器，这就是LDP工作大概过程，大家注意方向呀，是从下游向上游进行传递，也就是从MPLS最终完成之后的数据报文的目的地向数据报文的出发地的方向进行传递。
静态LDP
tunnel-id
每个路由器都维护有tunnel id，tunnel id只具有本地标识，这种字段在配置各种VPN的时候比较常见，比如GRE-VPN，但在此处出现了，tunnel id的含义本身就是隧道ID，可以理解为某一条隧道的名字，在FIB表当中出现意味着当有报文的目标IP地址能够匹配互条路由路由，那么就将此条报文转到另一个隧道当中去，其实就转发到MPLS的层面，让MPLS进行处理。只要FID不为0，那就交给MPLS，如果为0，那就执行路由转发操作，如下所示：
从上图当中可以看出来，tunnel-id相当重要，它是进入到MPLS进程的入口，只有tunnel-id非0时，接下来的操作才会交给MPLSF进程进行处理。从这个场面来看，报文从传统路由转发到MPLS转发与GRE VPN非常相似，都是先匹配到路由条目，通过路由条目的指向跳转到另一个层面。
那MPLS层面有什么东西呢？其实里面也有一个表，只不过不是路由表，而是叫NHLFE下一跳标签转发表，既然转发动作不能根据路由表进行转发，进入到MPLS进程之后就得根据NHLFE表进行转发，我们可以根据路由表来猜测一下NHLFE表里面都有哪些字段？
协议字段？应该没有，因为MPLS协议里面不再分了，设置这个字段没啥用处，下一跳IP得有吧，下一跳出接口得有吧，动作得有吧到底是要插入标签还是转换标签，还是弹出标签，标签得有吧，也就是动作操作的对象，它还有字段非常重要，那就是tunnel-id字段，这个字段用来关联FIB当中的路由表，此字段的内容就等于FIB表条目当中的tunnel-id字段，有标志的作用，因为NHLFE里面的条目有很多，每一个条目都关联不同的出接口、标签、动作等字段。如下所示：
现在你再想一下，如果我们通过手工静态的方式建立LDP的话，要准备哪些字段呢？其实无法也就是上图当中所描述的NHLFE表当中的各种字段而已，但这个手工建立比静态路由要复杂一些，静态路由的建立你只需要指定目标IP、掩码和下一跳IP就可以了，其它的字段路由器会自动计算并填充的，而手工的MPLS的话，也大概是这样，只需要把关键的信息写上就好了，如下所示：
# 这只是单方向的，LSP是双向的，所以还有一个方向的没有配置
static-lsp ingress 1to2 destination 192.168.20.0 24 nexthop 10.0.12.2 out-lab 10021to2是名字，没啥实际含义，好像没看到动作、tunnel-id呀，其实destination 192.168.20.0 24写完之后，ldp进程就会自动去路由表当中找与之相匹配的路由了，进而生成tunnel-id了， ingress代表角色，这个角色是 ingress LSR，入站就是要压入标签的，所以ingress就隐含了压入标签动作的意思了，所以你最终看到NHLFE信息应该是这样的：
[R1]dis mpls static-?
static-cr-lsp Static CR-LSP configuration
static-l2vc Static layer 2 virtual circuit over MPLS
static-lsp Static LSP configuration
[R1]dis mpls static-lsp
TOTAL : 2 STATIC LSP(S)
UP : 2 STATIC LSP(S)
DOWN : 0 STATIC LSP(S)
Name FEC I/O Label I/O If Status
1to2 192.168.20.0/24 NULL/1002 -/GE0/0/0 Up
# 注意看TunnelID，被static-lsp匹配的路由条目TunnelID是非0的
# 值得一提的是，Destination/Mask Nexthop 这两个字段，无论在LDP当中指定的时候必须与路由表里面一样，只有这样，tunnel-id才能被正常的关联到NHLFE表当中。
[R1]dis fib 192.168.20.0
Route Entry Count: 1
Destination/Mask Nexthop Flag TimeStamp Interface TunnelID
192.168.20.0/24 10.0.12.2 GSU t[81] GE0/0/0 0x1至于具体的场景配置，可以去查看这个博客呀：javascript:void(0)
上述是入站时我们要准备信息，我们是手工准备的，你也可以通过动态LDP，让LDP自动准备，动态LDP下一节我们再谈，我们还是接着谈静态LDP。
上面我们描述完了，在入站的时候压入标签，其实还有一个地方没有体现出来，那就是当数据包从入站路由器出来之后，不仅仅会多了一个MPLS层，而且二层类型字段也会发生变化 ，二层有一个字段叫类型字段，用来表示上层是什么协议，这个字段也非常重要，如下图所示：
当二层承载普通的IP报文时，就如上图所示，此字段的值是0x0800，但当承载一些特殊的协议，就比如MPLS时，此字段会发生变化，像在MPLS当中，此字段的值为0x8847。那对于入站LSR来说，当数据包当进入的时候此字段的值为0x0800，在经过MPLS进程处理过发出来之后，此字段就变成0x8847了。
所以当中转LSR收到一个报文之后，拆到第二层就已经知道了此报文是MPLS报文，而不是一个普通的IP报文，那中转LSR接下来呢？做什么操作呢？
中转的LSR意识到此报文是一个MPLS报文，也会继续向下拆封装，然后获取标签地址，再然后呢？再然后就得找ILM表，通过ILM表再去找NHLFE表，NHLFE我们已经知道了是标签转发表，那ILM表是什么表？它是怎么生成的？
ILM（incoming label map入标签映射表），就相当于入站LSR当中的路由表，但是中转LSR并不需要看路由表，ILM表就充当路由表的角色，最关键信息其实还一个tunnel-id，此外ILM只是一个临时表，表项也非常简单，就三个字段：label、tunnel-id、入接口，这个表怎么形成的呢？当路由条目从下游发送到上游路由表，路由表要存一份，存的这一份最终会形成NHLFE表，而向上游的发送的信息就会形成LIM表，向上游发送的信息当中有一个字段特别重要，那就是label字段。当中转LSR收到一个MPLS报文，解封装后发现标签，会用这个标签去ILM表当中比对，看哪一条能比对上，这个比对有两个指标。label是否一致，这是最关键的，还有就是收到此报文的接口是否是我发出去时的出接口，如果这两条都满足了，就会通过tunnel-id的指针找到NHLFE表，NHLFE表就是最终表了，按照NHLFE表中的指示处理报文并转发即可了，大概是这样：
好了，以上中转LSR要做的操作，我们接下来再来看最后一跳LSR要做的操作。
最后一跳路由器，同样也是有ILM表和NHLFE表，只不过NHLFE表中的动作是弹出，它怎么知道是弹出呢？因为在形成LDP路径的时候，此条路由就是它第一个发出去的，数据包从本路由器出去的时候执行的压入的操作，寻那当现在回来之后，执行的操作就是弹出了，弹出之后就还原成普通的报文，然后直接交给路由表处理。
标签和统一性
ILM和NHLFE表里面都有标签字段，这两个字段一样吗？
不一样。
ILM是LSR在收到下游的LSR发送的通告存起来之后，本地分配一个标签然后继续向上游通告的，所以ILM表当中存的标签是本地自己的，而NHLFE表当中存的标签是此LSR下游的，因为在数据包发出去的时候，要替换成下游LSR能识别的标签。有种，我告诉你我识别某某标签，你发送给我的时候，就得用这个标签的感觉。
通过标签和标签我们也能大概猜到，在入站LSR的时候我们只需要配置outlab（出站标签），告诉上游路器，我用这个标签，不用配置入站标签，为什么呢？因为入站LSR收到的报文不是MPLS报文，经过入站LSR加工之后才会变成MPLS报文。
同样的，在出站的时候，肯定是只有入站标签，没有出站标签，因为出站的时候不用携带标签了，如下所示：
static-lsp ingress 1to2 destination 192.168.20.0 24 nexthop 10.0.12.2 out-lab 1002
static-lsp egress 2to1 incoming-inter g0/0/0 in-label 1011在配置静态LDP的时候，有两个统一性的问题需要重点强调一下：
第一点：入站时通过路由关联到路由表的目标网段和下一跳非常重要，一定要写的一模一样，否则关联不上的，一旦关联上了FIB表当中就会有标识，通过这个标识其实也可以判断是否关联成功。
第二点：上游路由器的出站标签就等出我的入站标签，这个得提前规划一下，统一起来，否则容易搞混。换句话说，我自己的出站标签，就等于下游路由器的入站标签。
