Cisco LDP over RSVP配置指导

Cisco LDP over RSVP 配置指导

                      

 

技术应用背景

随着MPLS TE技术的成熟，在运营商核心网络中部署TE的应用愈来愈多，好比TE FRR、Hot-standby甚至DS-TE。可是在并非网络中的全部设备都支持MPLS TE，可能仅有核心网络设备支持TE，而在网络边缘使用LDP。所以产生了LDP over RSVP的应用场景，即便用TE隧道做为LDP中的一跳。

 

应用场景示例   

 

 

    上图是一个LDP over RSVP的典型拓扑，其中R1和R5表明网络边缘接入路由器，不支持TE功能，而R2、R3和R4表明网络核心部分，部署TE功能，这里采用这个最简单的网络拓扑对于LDP over RSVP的配置以及在整个网络中的标签分配状况以及数据的转发状况进行简单的分析，以达到对LDP over RSVP功能有一个基本的认识。

 

网络分析

    整个网络中部署IGP；

R1和R2、R4和R5之间创建LDP Session，而R2和R4之间经过双向的TE隧道创建LDP Session或者Target LDP Session；

R2、R3和R4之间不使能LDP，只使能RSVP在R2和R4之间创建双向的TE隧道；

因为LDP Session有直连Session和Target Session之分，这样对应对TE隧道的处理略有不一样，在直连Session的方式下，TE隧道配置mpls ip，将其做为一个普通的LDP接口；在Target Session的方式下，TE隧道不用配置mpls ip，只用在全局下创建Target Session的配置便可；

对于TE隧道，使能自动路由宣告，这样可使得标签映射可以和路由下一跳匹配，使LDP标签流量可以经过LDP over RSVP引入TE隧道（这里若是不用自动路由宣告而改用静态路由方式也是能够的）。

 

数据设计

Loopback地址：202.1.1.X/32，X=1、2、3、4、5，即路由器序号；

接口地址：80.X.Y.Z/24，X/Y=路由器序号，Z＝1、2，路由器序号小的为1，大的为2；

IGP：全程部署OSPF，并在R2、R3和R4上使能OSPF支持MPLS TE；

LDP/TE部署：R1-R2、R4-R5部署LDP，R2-R4经过双向TE隧道部署Target LDP，R2-R3-R4部署TE；

 

配置步骤

配置LSR的各接口地址；

配置OSPF保证LSR之间可达；

配置MPLS基本能力；

配置LDP Target Session；

配置MPLS TE隧道；

配置自动路由宣告。

详细配置以及显示信息

参看下面的第一个附件。

标签分配状况

标签分配状况分析

 

在R2上分别查看LDP邻居，能够看到有两个LDP邻居：

 

R2#show mpls ldp neighbor                                                                                                           

    Peer LDP Ident: 202.1.1.1:0; Local LDP Ident 202.1.1.2:0                                                                       

        TCP connection: 202.1.1.1.646 - 202.1.1.2.56248                                                                             

        State: Oper; Msgs sent/rcvd: 28/29; Downstream                                                                             

        Up time: 00:15:17                                                                                                           

        LDP discovery sources:                                                                                                     

          Ethernet4/1, Src IP addr: 80.1.2.1                                                                                        

        Addresses bound to peer LDP Ident:                                                                                         

          80.1.2.1        202.1.1.1                                                                                                 

    Peer LDP Ident: 202.1.1.4:0; Local LDP Ident 202.1.1.2:0                                                                       

        TCP connection: 202.1.1.4.11024 - 202.1.1.2.646                                                                            

        State: Oper; Msgs sent/rcvd: 28/31; Downstream                                                                             

        Up time: 00:15:00                                                                                                          

        LDP discovery sources:                                                                                                     

          Targeted Hello 202.1.1.2 -> 202.1.1.4, active, passive                                                                   

        Addresses bound to peer LDP Ident:                                                                                         

          202.1.1.4       80.3.4.2        80.4.5.1                                                                                  

 

 

其中202.1.1.4为经过TE隧道和202.1.1.4创建的Target LDP Session，若是去掉该TE隧道，那么在R2上只会存在202.1.1.1这一个LDP邻居；R4同理。

这样，经过TE域创建起了一段完整连续的LDP Session。

具体的标签分配状况已经标在上面的拓扑图中，蓝色的数值为LDP标签，红色的数值为RSVP标签，举例而言，在R5上以源地址202.1.1.5 ping 202.1.1.1：

R5上为该报文push标签18发送到R4。

R4收到该报文后，执行swap标签16，因为TE隧道的自动路由宣告，到202.1.1.1的路由指向Tunnel，故在该报文外层继续push隧道的出标签17，走RSVP的标签转发，发送到R3；此时该报文就封装了2层标签，内层为LDP标签，外层为RSVP标签（具体的标签报文详情能够参看下面捕获的R3-R4之间的报文）。

R3为TE域的中间节点，收到R4发来的报文，根据外层RSVP标签执行swap，得到出标签为3，3为隐式空标签，本地执行pop（3标签）后将报文发给R2。

R2收到的报文只带了LDP标签，最外层的RSVP标签已经在TE域的倒数第二跳R3弹出了，此时走LDP域的标签交换，同时因为R2为LDP域的倒数第二跳，故pop（3标签）后，将报文（IP）发给R1。

R1响应报文。

 

    捕获报文验证标签正确性

 

参看下面第二个附件。

 

查看enc文件中的ICMP报文，能够清楚的看到request echo为两层标签，reply echo为一层标签，验证了上面的分析。

 

PS：因为如今工做很忙，时间很紧，写的比较匆忙，主要是作个记录，避免以后遗忘，待后续继续补充。