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：由于现在工作很忙，时间很紧，写的比较匆忙，主要是做个记录，避免之后遗忘，待后续继续补充。