MPLS-TE-RSVP-工作原理详解实战手册.doc

在文档开始之前，我认为MPLS TE的信令协议是有必要知道的。RSVP-TE-协议本身比较成熟，已经规模应用。-基于软状态，扩展性比较差。CD-LDP-协议比较新，不太成熟，基本没有应用。-基于硬状态，扩展性比较好。但是，最终还是市场来决定,RSVP因为先把茅坑占了，所以，一说到MPLS TE,大多数厂商都支持RSVP-TE.很少厂商支持CD-LDP协议。貌似，RSVP-TE已经是一个业内的标准了。所以学习MPLS TE有必要了解RSVP的运作。RSVP的相关知识点有下面几点：RSVP基础RSVP分组RSVP操作现实世界中的RSVP.RSVP协议类型是46,虽然把RSVP封装在UDP中是又可能的，但是MPLS TE从来不会把RSVP封装在UDP中。RSVP是拿来做什么的？我们都知道标签分发有几种方式：MPLS LDP/TDP,这个是标准，用来分发mpls标签的协议。RSVP,用于MPLS TE中的标签分发。和LDP工作没有交集。还有一个就是BGP对vrf路由的标签分发。RSVP不是路由协议，任何路由决定都是IGP和CSPF做出的决定.（如果CSPF还有疑问，请参考http:/361531./351531/657115 , MPLS CSPF工作原理详解和相关实验），RSVP唯一的工作就是通告和维护网络中的保留资源。MPLS TE中，RSVP在控制平面层保留带宽，所以没有对流量的转发平面上做任何控制。RSVP有三种基本的功能：路径的建立和维护路径拆除错误通告。RSVP的主要消息类型如下：一共有7类是主要应用。关于RSVP信令的建立，简单说来，就2个步骤，原始节点向目的Router发送 RSVP path消息，然后目的路由器收到path请求以后，向原始节点回复一个RESV.那么，一个TE隧道就建立成功了。根据Eric Osborne CCIE 4122的著作MPLS TE流量工程中所描述的，这里我们来看一个RSVP是如何建立一条通路的。下面就是一条路径建立的详细过程：在隧道首端完成CSPF的路径计算路径计算好了，首端节点向目的节点通过下一跳发送RSVP path请求。收到path请求的下游路由器会首先检查报文格式是否正确，然后检查path消息中的预留申请的带宽。该过程叫准入控制。当准入控制成功以后，那么下游路由器会产生一个新的path请求，然后发送给通往目的路由节点的下一跳again。直到发送到最后一个节点。也就是MPLS TE隧道尾端的最后一个路由器。末节点路由器当收到了上游的path 请求以后会回复RSVP Resv消息进行回应。也是一跳一跳的，逐跳反馈到原始节点。这里再Resv报文中，不仅仅是对上游路由器的一个ACK回应，也包含了上游路由器沿TE LSP向尾端发送分组所用的标签。说了那么多，来两个实际的例子：在这里一共有10个步骤，在这个例子中，假设R1已经完成了CSPF路径的计算，并且知道它需要沿路径R1->R2->R3->R5->R6->R7保留带宽。第一步：R1向R2发送RSVP path请求，R2收到这个报文后，检查报文格式语法上是正确的，然后检查TE链路管理器，确定R1请求的带宽实际可用(实际上就是在R2上面进行比较ip rsvp bandwidth带宽，只要送过来的请求小于物理的rsvp分配的带宽，就算通过.第二步：R2向R3发送path，R3对path消息进行同样的验证。第三步：R3向R5发送path，R5对path消息进行同样的验证。第四步：R5向R6发送path，R6对path消息进行同样的验证。第五步：R6向R7发送path，R7对path消息进行同样的验证。第六步：R7因为是末节点，所以会返回一个显式空标签给R6.第七步：R6发送一个Rsve给R5，分发标签为42.第八步：R5向R3发送Rsve,分发标签100.第九步：R3向R2发送Rsve,分发标签21.第十步：R2向R1发送Rsve,分发标签18.有了上面对于RSVP的说明，那么我们再进行逆向思维思考一下，根据这个原理，请求方发送rsvp path给下游路由器，下游路由器就要比较预留带宽和回应Rsve,进行标签的分发。对应在设备的配置上面，至少应该做下面的事情：在路径上的每台路由器接口上面，都应该把mpls ip, mpls ldp,ip rsvp bandwidth xxx,mpls traffic-eng tunnel都打开。因为每个接口都要进行预留带宽的比较，如果没有配置如何进行比较呢？如果rsvp交互不成功，那么TE隧道如何能建立起来呢？这就是为什么要再所有路由器上把相关流量工程的配置都加上去了。对于mpls TE配置感兴趣的同学可以参考一下：http:/361531./351531/641039MPLS TE 流量工程路径选择原理和配置模板 for CISCO.如果有了上面的原理概念以后，下面就是一个具体的信令交互图了.如果从信令的交互的角度来讲，下面是我整合的信令交互的步骤：这里如果认真阅读报文交互内容，我们会发现，R1发送RSVP path到R3的loopback 0，请求TE的建立。然后R3逐一给R2，R2给R1进行RSVP的标签分配。实际上RSVP分组我没有细看，报文格式比较复杂，而且种类繁多。我只能暂时先坐一个原理性了解。以后有空再慢慢深入。到现在为止，详细的原理已经有一堆了，但是真正的实际动手实验还没有做。下面有一些命令，至少，需要很熟悉的应用，才对得起已经学习的那么久的RSVP的原理：show ip rsvp countersshow ip rsvp interfaceshow ip rsvp neighborshow ip rsvp reservationshow ip rsvp counters,该命令显示了路由器启动时，在每一个接口上已经产生的RSVP消息类型的统计.在这个命令里面我认为主要看path 和Resv报文的收发 情况，就可以判断是否是TE的RSVP出了问题，如果发送了path,也收到了Resv，问题应该不会在RSVP上面至少。还有一个命令，是关于RSVP接口的邻居：也可以显示show ip rsvp neighbor detail进行深度排查，不过进行初步排查，只要x.x.x.x后面显示的是RSVP，那么邻居就没有问题。这里有一个很重要的概念，RSVP是没有显式的邻居发现阶段，意思就是，如果两个直连的接口激活了RSVP，你show ip rsvp neighbor是没有邻居的，邻居的建立，是要他们相互看到对方的RSVP path和Resv消息以后才能建立邻居。通过show ip rsvp interface,可以看到当前R3上面G3/0对于隧道分配的实际带宽是1024K,而预留带宽为4096K.呵呵，最后一个命令，当隧道建立起来，如果有逻辑上的问题，可以用上面的命令进行故障排查。逐跳进行检测。总结：我把上面的四个命令按照逻辑顺序做一个小的总结，如果MPLS TE隧道要正常的建立起来，那么首先按照RSVP的原理，show ip rsvp counters interface xxxx,应该可以看到发送的RSVP path和接收到的RSVP Resv是几乎相等的，否则光发不收，不发不收都不正常，需要沿链路检查所有接口下面的配置是否正确。如果show ip rsvp counters正确，在看show ip rsvp neighbor也是应该有的，然后再来沿途