您好,欢迎访问三七文档
当前位置:首页 > 财经/贸易 > 资产评估/会计 > MPLSLDP学习实验笔记(完整版)
MPLSLDP学习实验笔记(一)本实验环境是通过华为路由器搭建的,目的是为了了解MPLSLDP最基本的一些概念:(1)LDP如何建立邻居关系?(2)LDP邻居之间如何交换LSP信息?(3)哪些路由信息可以被映射得到标签?所以设计得较为简单,拓扑图如下:实验预配置:(1)配置所有设备的接口IP地址;(2)配置R1和R2的LSRID为LoopBack0地址,并在全局和接口下使能MPLS和MPLSLDP;(3)未配置任何动态和静态路由问题一:两台设备如何建立MPLSLDP的邻居关系?在完成实验的预配置内容后,对R1和R2的互联链路抓包,截图如下。通过抓包发现,两台设备在配置了MPLSLDP功能的链路上向组播地址224.0.0.2发送Hello包,这样两台设备可以通过从组播地址收到的Hello包来知道该链路上有哪些LDP邻居。在设备上通过命令displaymplsldppeer来查看LDP邻居。值得注意的是,建立邻居关系并不像BGP那样要建立TCP连接,而是通过UDP发Hello包,而且在Hello包里面,包含了发送方的LSRID,所以虽然抓的Hello包的源地址是链路接口地址,但LDP邻居表中的邻居确能显示出LSRID。这点跟OSPF的Hello包机制是相似的,OSPF也是通过接口地址在互联链路上向组播地址224.0.0.5中发送Hello,其中包含了OSPFrouter-id,AreaID,HelloInterval等消息。不同的地方在于,OSPF的Hello包不是封装在UDP中,也不是封装在TCP中,而是在IP之上有自己独立的报文格式,协议号为89。OSPF的通信消息全部都是封装在自己独有的OSPF报文格式中的。问题二:两台设备如何交换路由标签?接着之前的步骤往下做,已确定发现了LDP邻居,在设备上查看是否存在跟邻居交互的LSP信息。查看命令displaymplsldplspall。可以看到,即使已发现邻居,但是却没有进行任何LSP标签信息的交互,这是为什么?别急,我们先来查看R1当前的LDPsession,因为2台设备进行LSP信息交互之前,需要先使用可靠连接TCP来建立LDP会话,然后才能放心传LSP信息。使用命令displaymplsldpsession,发现当前会话状态为NonExistent,会话并未建立成功。继续找原因,LDPsession是基于路由器的LSRID来建立的。R1的LSRID为1.1.1.1,R2的LSRID为2.2.2.2;而此刻两台路由器未运行任何动态路由协议,也未配置任何静态路由,所以路由表中都没有对方的LSRID的路由。例如,R1中没有去往2.2.2.2的路由。在R1和R2上都添加相应路由并生效后,通过抓包可以看到R2通过LSRID(2.2.2.2)向R1(1.1.1.1)发起TCP连接(3步握手),即地址大的一方主动发起;然后开始协商相关初始化的参数,发送Init消息,发送keepalive信息,使LDP会话成功建立;最后才交互LSP信息。抓包截图如下,序号19之前抓到的都是LDP的Hello包,配通路由后(序号20)开始有TCP初始化[SYN]和[SYNACK],之后(序号29~33)是参数协商之类,然后(序号35~39)出现LabelMappingMessage即为LSP信息。查看从R1发出的1个LabelMappingMessage包,里面包含了2个标签映射信息。查看该数据包LDP部分详细映射信息如下,在FEC(转发等价类)中,注明的是Ipv4地址信息,此处FECElementLength表示的是掩码长度为32位掩码,IP前缀为1.1.1.1(InterfaceLoopBack0)和11.11.11.11(InterfaceLoopBack11)。R2上的LSP表如下,通过命令displaymplslsp可以查看当前用在转发表中的LSP信息。还是在R2上,通过命令displaymplsldplsp可以查看所有收到但不一定处于转发状态的LSP信息。如11.11.11.11这条LSP,前面标注了*号,说明这条LSP暂未进入转发表中,因为R2的路由表中没有11.11.11.11这条路由。R1上的LSP表如下:问题三:哪些路由信息可以映射到标签?接着之前的步骤往下做,我们在R1的LSP表中发现,并没有收到R2直连的23.23.23.0/24网段的标签信息。再看仔细一点,我们发现R1和R2的LSP表中,所有路由信息都是32位掩码。华为设备的缺省行为是,处理直连主机路由(一般为LSR的LOOPBACK端口地址)的标签分配工作。这里需要注意,其处理对象是直连的、主机路由,并不包括静态路由,即使它是32位掩码的主机路由。所以路由器只给路由表中掩码为32位的主机路由映射标签,说白了就是只有本地32位掩码的环回地址能触发LDP来为其分配标签。可以通过改变MPLS的相关配置,让路由表中所有的路由、或者通过IP前缀列表指定的路由等,都能获得LDP分配的标签。在R2上进行如下配置,在MPLS视图中,输入命令lsp-triggerall。查看R1的LSP表,已经能看到从R2发来的12.12.12.0/30和23.23.23.0/24的LSP信息。*************************************************(由于做试验的原因,此前进行了多次引起路由表变化的操作,造成了对FEC标签的重新分配,所以现在看到的标签值跟之前的截图相比已经有所改变,但是不影响我们的学习标签分配的机制原理,可暂且忽略之。后面实验中也将出现对同一FEC的标签值,前后截图不一样的情况,也请忽略。)*************************************************此时R1的标签保持方式(LabelRetentionMode)为自由(Liberal),对于从邻居LSR收到的标签映射,无论邻居LSR是不是自己的下一跳都保留。而与之相对的,是保守标签保持方式(Conservative):对于从邻居LSR收到的标签映射,只有当邻居LSR是自己的下一跳时才保留。使用自由标签保持方式,LSR能够迅速适应路由变化;而使用保守标签保持方式,LSR可以分配和保存较少的标签数量。在本实验中,由于拓扑比较简单,未能模拟演示这2种方式的异同。这时候,如果在R2上配置一条去往3.3.3.3/32的真实静态路由,甚至再配置一条去往8.8.8.8/32的虚假静态路由,也能触发标签的分配(LabelDistribution)。此处涉及到知识点标签分配控制方式(LabelDistributionControlMode),后续讲解。在R1上看LSP表,可以看到已经收到R2发来的关于3.3.3.3/32和8.8.8.8/32这2个FEC的标签。即是说,开启了lsp-triggerall功能后,只要路由表里有生效的路由信息,R2都会为其分配标签(涉及标签分配控制方式LabelDistributionControlMode),然后马上发布出去(涉及标签发布方式LabelAdvertisementMode)。这里R2采用的标签发布方式,是下游自主方式DU(DownstreamUnsolicited):对于一个特定的FEC,LSR无须从上游获得标签请求消息即进行标签分配与分发。具有标签分发邻接关系的上游LSR和下游LSR之间必须使用相同的标签发布方式,否则LSP无法正常建立。在R1和R2初始协商LDP会话参数时,抓包可发现它们之间确实交换了标签发布方式。而且在设备上也可以通过命令displaymplsldpsession看出,在已成功建立的LDP会话中的LAM(LabelAdvertisementMode标签发布方式)标志下,显示的就是DU(DownstreamUnsolicited下游自主方式)。问题四:再探关于标签分配控制方式以下蓝色字体为引用教材:标签分配控制方式(LabelAdvertisementMode)分为两种:独立标签分配控制(Independent):LSR可以在任意时间向与它连接的LSR通告标签映射。这种方式可能导致在收到下游标签之前就向上游发布了标签。有序标签控制方式(Ordered):对于LSR上某个FEC的标签映射,只有当该LSR已经具有此FEC下一跳的标签映射消息或者该LSR就是此FEC的出口节点时,该LSR才可以向上游发送此FEC的标签映射。在设备上可以使用displaymplsldp命令,查看到当前配置的标签分配(控制)方式(LabelDistributionMode)为有序标签控制方式(Ordered),以及标签保持方式(LabelRetentionMode)为自有标签保持方式(Liberal)。由于在前面的步骤中我们在R2上开启了lsp-triggerall功能,其实相当于是更改了默认的标签分配方式,将Ordered(有序)方式改成了Independent(独立)方式;但是这点改变在使用上面的命令查看时却是看不出来的,只能通过检查相关配置发现。在lsp-triggerall开启的模式下,我们也可以看到,对于3.3.3.3/24和8.8.8.8/24这2个下一跳为R3的FEC,R2并不用等R3发来OUT标签就把自己的IN标签通告给了R1(重申一下,当前实验环境是,只有R1和R2进行了MPLSLDP配置并建立了邻居关系,R3上面是没配置MPLSLDP的)。而R1虽然收到了R2发来的FEC,但它自己却并没有对这2个FEC分配标签,主要原因是R1的路由表里面没有这2个路由。可参看之前实验步骤中的截图。当我们在R1上也把3.3.3.3/32的路由添加到路由表,使它的下一跳为R2,令其生效时,我们看到R1也对其分配标签了。查看此时R1的路由表中3.3.3.3/32的下一跳地址,跟标签分配表中该FEC的下一跳地址做对比,可以知道它们是一致的,下一跳都是12.12.12.12,出接口都是Ethernet0/0/0。在比对一致的情况下,设备会对该路由分配标签(不管是静态路由还是动态路由),就不限于之前只对直连主机路由分配标签了。为了验证这2张转发表同步的问题,我们在R1上试试看添加8.8.8.8/32的路由,下一跳并不是指向R2,而是故意错误地指向NULL0,看看R1是否会为其分配标签?结果显示R1是不对这条静态路由分配标签的。正是因为比对路由表和标签分配/转发表后,发现路由下一跳地址与FEC下一跳地址不一致。对8.8.8.8/32路由的下一跳修改为指向R2后,设备通过比对两张表的下一跳得知二者相同,于是该路由获得了LDP分配的标签。插曲:报文在一条不完整的LSP上进行传递,会发生什么?这时,对于去往3.3.3.3/32和8.8.8.8/32的2条FEC,形成了一条不完整的LSP:如果R1收到目的地址为3.3.3.3的数据报文,它将做MPLS格式的数据封装后进行标签交换转发;但是该报文到了R2以后,由于R2并没有此FEC的OUT标签,将无法继续做标签交换转发。由于没有去往下一跳的标签可以做SWAP,于是R2只好把MPLS标签头部去掉,MPLS报文转变成了IP报文,这时R2是如何处理的呢,是继续做IP转发还是将其丢弃?带着疑问继续我们的实验。我们首先在R3上增加去往1.1.1.1的静态路由配置,并确保R3与R1的loopback地址能相互ping通。在R1上也测试,能ping通R3。在R1去PingR3的同时,我们在R1的Ethernet0/0/0上抓包,发现R1在把目的地址为3.3.3.3的ICMP包发出去的时候,已经做了MPLS封装了。且标签值可见是一致的。我们继续在R2去往R3的接口Ethernet0/0/1上抓包,发现R2把ICMP报文发往R3的时候,已经是做纯IP的三层转发了。我们甚至可以看到R2先向R3发出的ARP报文,在找到了R3的MAC地址后,再把来自R1的ICMP报文转发出去。由此可见,R2的标签转发表中不存在下一跳标签的时候,先把报文的MPLS头部去掉,但是并不会立即丢
本文标题:MPLSLDP学习实验笔记(完整版)
链接地址:https://www.777doc.com/doc-2888934 .html