LISP基本实验（EID&RLOC都是IPv4，且只有一个xTR和一个MR/MS）

LISP第一次基础实验

实验内容：

Configure aSimple LISP Site with One IPv4 RLOC and One IPv4 EID

Configure aPrivate LISP Mapping System Using a Standalone Map Resolver/Map Server

前言：

LISP �C Routing in theCloud

LISP - A Next GenerationRouting Architecture
LISP �C A Routing Architecture, Not a Feature…

看到这几句英语大家肯定是不能尽知LISP是什么，但是大致可以知道，LISP是一个为云路由的协议，一个下一代路由技术，而不仅仅是一个特性。鄙人也是最近才听说这个协议，一了解到是个路由协议，忍不住心痒痒想试一试，否则难符路由曹的美名。

说它是下一代路由协议，其实在网上能找到的资料，能追溯到2009年，那也就是说这个协议其实已经诞生至少4年了，我在IE群里面咨询了一下，却只有少部分人听说过这个协议，知道的人也难说出一个所以然来，所以无奈只能自己着手，各种搜索也只能搜索到一些概念性的介绍，找不到具体项目实施，或者试验环境的搭建。

最后无奈只能找全英文的文档，甚至是RFC，再各种翻译工具的帮助下，对LISP略知一二，后来觉得进展太慢，想找一份实验文档来测试一下，无奈资料实在太少，我只能寄希望于cisco配置手册，可是刚开始没找到，舔着逼脸用蹩脚英语去给LISP support小组发邮件索要，不知道他们是没看见还是无视我这个呆逼，没有回，很不好意思的是，其实cisco官网就有，我就又开始了漫长枯燥的中英文化交流工作。

后来了解到这个协议虽然出现的时间很早，不过早期也只是一个构想或者说趋势，协议文档也知识只是draft，最早形成RFC也不知是哪年哪月，因为修改的时候也会把定稿时间修改掉，所以无法追究最早协议的诞生时间了。现在cisco自己是已经有很多部署成功的案例，不管是v4环境还是v6环境，在cisco的目标里，我们未来网络可能会使用这种协议来部署，当然这也不是一蹴而就的事情，所以也有LISP站点和非LISP站点互相通信的技术。

最早由于只是看了一点点概念性介绍，我一度以为这个协议没啥作用，慢慢的看到了技术文档，了解到LISP能实现的功能，我才感受到，协议的设计者才是大神，我们只是会配置，就算再了解也只是渣渣。从前在深入研究OSPF时被协议设计者的细节考虑震撼到有这种感觉，现在是被协议开发者的前卫思想和解决问题的思路所震撼。

那做这期文档，是希望大家也能快速上手这个协议，不需要再去翻阅枯燥难懂的英文资料（当然可能对于某些英语大牛来说其实这不是问题），和别人有谈资，吹吹牛，当然也许幸运，不久的将来大家就能用上，那就再好不过了。我决定不从干瘪无聊的名词解释和概念解析讲起，我们直接做一个实验，那么对于基本的LISP的工作就大致能了解了。这是第一期，可能会有第二期，具体看后面工作时间之余是否再有时间深入研究和挖掘，或者这份文档权当抛砖引玉，大家感兴趣可以自行研究和我探讨，这都是后话。

模拟环境解析：

废话太多，我们进入关于LISP的第一次实验测试，这次实验使用的命令不多，并且使用最少数量的模拟设备，搭建了一个非常简单的环境。先附上我自制的概念图：

首先强调本图版权所有盗版必究，当然我对此图的权威性不予保证，如有出错，算我丢人。因为这张图所示内容就我所看过的协议描述文档来说，并无整体出处，也就是说我没有看到有一张把这些内容都集成在一张图内的原图，虽然每一部分都有出处，且这也是抓包所看到的真实情况，但是也可能由于试验环境太小，或者研究太浅，管中未能窥得全豹，如同可能我们学过的基本物理学只是一种在地球特殊环境中的一种近似（未被证实，多年前有被提出过的一个理论）。不过尽信书不如无书，大家权当参考，你妹，我又跑偏了。

现在正式介绍一下这张图里面的内容，首先我们有两个分部，SITE A和SITE B，他们都只通过一根上行线路连接着一个运行商，我们要做的就是使得A和B内部的网络能够通信，当然我这里说的内部网络，不是指的私网网络，虽然我用私网地址模拟了。它也可以是公网网络，甚至可以是IPv6网络都行。现在我们忘掉公私网的概念，只当作它是两个网段，我们最终结果就是按照图中数据流走向，能够测试ping通，当然我忘记画回包数据走向了。

我们这个环境中还有一个Mapping System，它是我们能通信的关键，现实部署中它可能是一台服务器，我们这边只能使用路由器模拟，我们的大云就是我们的运行商也只用一台路由器模拟，那么我们的AB分部和MS/MR都只需要指一条默认路由到运行商，则整个网络环境可通信，图中其他内容我们在接下来的部分再解析。

最终试验环境：

所以最终我们实验模拟拓扑图如下：（狂笑，说了那么多，其实就是下面这破拓扑）

R1模拟SITE A，R2模拟SITE B，R4模拟MS/MR，R2模拟ISP。底层环境使用默认路由指向R2，则R1、R3、R4使用连接R2的接口的地址是可以互相通信的，网段规划使用12、23、34这样的地址表示设备间网段，最后一位使用设备名，当然R1和R3上使用回环口模拟各自内网地址。地址规划和默认路由配置如下：

当然我们环境比较小，使用默认路由就可以使得各个节点网关出口可通，如果环境再复杂一点就是在我们R2模拟的运行商环境中有非常多的设备，甚至可能跨过多个AS，不过我们只需要SITE A和SITE B能访问MS/MR服务器，并且使用出口地址能互通就行，所以运行商网络现在不在我们关心范围之内，所以模拟环境简化掉了。

好的，接下来开始配置我们的新协议LISP，读李斯坡，首先我解释一下，我们实验的最终目的就是两个节点内部地址必须互相通信，那怎么通信呢，其实如果都是公网IP地址的话，最简单的办法就是通告到共网上，但是这样要求网关路由器有承载巨型路由表的能力，在互联网条目超过50w条的情况下这是一个挑战，当然我们寄希望于ipv6地址的重新规划的时候，cisco工程师说，即使迁移到ipv6也并不是就能完全解决这个问题的，所以这不是一个好办法。那学过隧道的同学应该知道这里可以通过隧道来完成，使用手工隧道，把以内部地址为源和目标的ipv4数据包再封装进以出口网关地址作为源和目标的ipv4报头内，也能完成任务，那我们LISP最后的实现方式就是类似隧道的模式，但是我们的站点到站点隧道是需要写隧道的源和目标的，也就是说网关的连接ISP的地址是固定的，但是对于很多公司来说，租用的地址是变化的，所以不好实现，但是我们LISP就可以很好的解决这个问题。它可以动态的学习到网关的出口地址。

我们先看一下SITE A和SITE B的配置，配置如下：

我们可以发现其实两台设备的配置命令是一样的，我稍微解释一下命令的作用，有一些名词大家暂时还不能理解，我们下次文档再说明。

接下来我们看一下MS/MR上的配置，配置如下：

其实现在配置已经完成，可以测试ping通：

可以看到丢了两个包之后就通了，我们通过抓包的结果看下如何通信的：

可以看到这就是三个！的来源，三个echo-reply，点开看下request和rely的报文内容：

上图是echo-request，我们的源是172.16.1.1目标是192.168.1.1，但是呢我们这个报文是封装在另外另外一个IP报头内部的，最外部的目标ip是23.23.23.3，源是12.12.12.1，非常类似于我们隧道的通信方式，但是多了几层报头，从外往内数，依次是：IPv4报头（以外网接口地址为源目）、UDP（目标端口lisp-data：4341）、LISP报头、IPv4报头（ping包真正的源目）、ICMP。

那么相信回包的格式也是一样，只是源目IP地址置换，不管是内层还是外层，如下图：

那我们是如何获取到目标的外网出接口地址呢，我们检查一下前面的报文，发现如下图：

发现有一个Map-Request，是为了去请求192.168.1.1/32这个地址的什么内容的，而且是一个什么封装了的报文，我们点开看看里面的相信内容，如下所示：

很明显这也是一个双IPv4报头的报文，那很明显外层源地址为12.12.12.1，目标也毋庸置疑是24.24.24.4，因为我只知道24.4，我配置了24.4作为我的MR，就是我会去向MR请求如何去往远端的EID（即远端内网地址），而且这个请求应该是由ITR发送的。

在上面的请求报文内，也是多层报头，依次是：IPv4（出接口到MR）、UDP（lisp-control源目标端口号都是4342）、LISP、IPv4（源数据流源目）、UDP（lisp-control）、LISP。

那我们检查一下R4收到Map-Request之后做了什么动作呢，因为在上上图中没有发现有R4的回包，在R2和R4之间的连线，抓包部分内容示意如下：

奇怪，为什么会有两个关于192.168.1.1的Map-Request报文呢，难道收了两遍？为了保证请求成功R1给R4发了两个么，可是之前R1的抓包没有显示出两个，点开看详细报文如下：

如上图，第一个是R1发给我的没错，和前面某张截图显示内容一样，但是继续看：

在上图中，可以明显的看到，这个报文是由R4发给R3的，也就是说我们的MR将这个报文发送给了SITE B，也就是R3，帮助R1将这个Map-Request转发给了R3，因为我的MR再查了MS的数据库知道，192.168.1.1是属于SITE B的EID，其实我很疑惑，因为MR本身就已经知道R3的出接口地址了，照理来说直接回复给R1就行了，可是实验现象很明显不是这样的，那这个问题我们留待下次再讨论，我们这次主要分析清楚通信过程。

按照上面的现象就是，我们的Map-Request发到了R3上，那R3应该回复一个Reply什么的才像话吧，这不是路由协议说好的么，有请求必须有应答啊，那猜测应该直接回复给R1吧，因为我已经知道是R1要请求和R1的出接口地址，怎么知道的？看R4发给R3的Request报文详细内容如下：

很明显在最下面我已经知道了请求者的RLOC地址（Route Locator Address），所以直接由R3把Reply回复给R1就好了，那我们也再去看一下R1收到的Reply的情况，如下图：

那么如上图，上面一个Map-Reply就是由R3直接回复给R1的，报头信息如下：

那我们又如何知道这个Reply是告诉我们去往192.168.1.1的呢，这个不用担心，在报文的内容里面会包含，在最内层的LISP的报文内容里面就能清楚的看到，如图：

所以当R1收到这样的Map-Reply时，就能知道如果要去往192.168.1.1，需要重新封装一个报头目标地址是23.23.23.3，源地址自然使用R3能访问到的12.12.12.1，即RLOC地址。

以上就是我们从172.16.1.1去往192.168.1.1时，要经过的几个报文交互，总结起来就是，R1向自己的MR（R4）发送Map-Request，R4知道192.168.1.1是在R3上，于是将这个Map-Request发送给了R3，R3收到之后知道R1要使用EID给自己的EID（192.168.1.1）发送数据包，则向R1的RLOC地址（12.12.12.1）回复一个Map-Reply，R1收到之后数据包就能被类似于隧道的方式封装并发送出去了，就是报头多了好几层，详见前面截图。然后再接着R3要使用EID给R1的EID回包，所以也会向R4发送Map-Reply，R4转发给R1，R1回Map-Reply给R3，R3则能将应答包发送出来，所以最后测试ping通。所有的请求和应答报文前面就截取过，现在再给大家看一下：

上图中就是R1发出去一个Map-Request，收到一个Map-Reply，收到一个Map-Request，回应一个Map-Reply，这就是我们通信的过程中交互的几个报文，其实就是最早流程图所示：

上图实在太帅，爱不释手，就算是错的也爱不释手，XD，不过刚刚的所有报文是符合该流程的。那我们这里其实还有一个报文，我们前面说就算外网出接口是动态获取地址的也适合这个环境，不信大家自己测试，只需要把XTR上的配置关联自己的接口号而非固定地址，详见前面配置部分。那为何能检测到动态地址呢，我们的XTR或者确切的说应该是由ETR发送一个叫做注册消息，将当前的RLOC地址和EID地址关联发送到MS上。如下图可以看到很多的Map-Register：

根据前面的时间间隔，可以知道这个注册消息是60s发送一次。

那说到这里如果大家还是不太理解什么是XTR，我解释一下，XTR=ITR+ETR，也就是又是ITR又是ETR，这两种分别有两个功能，一般来说一个路由器上都会使用两种功能，所以一个出口路由器就叫做XTR。MS就是用来收集我们的注册消息的，知道XTR上面的RLOC（外网地址）和EID（内网地址）的映射关联。MR是用来接收请求消息和转发请求消息的。一般来说MS/MR在做实验室也可以部署在一台路由器上。所以总结一句话，ETR发送注册消息给MS，ITR发送请求给MR，MR通过查询MS的数据库，知道请求应该转发给谁，然后由真正的目标XTR回应Reply给源XTR。

LISP查看部分命令：

最后我们的通信完成，那么再使用几条查看命令，查看一下我们LISP协议的内容。

首先先在我们的MS上看一下都有哪些站点向我注册了，如下图：

当然也可以查看具体站点的信息，命令show lisp site name site-name如下两图：

那我们再去XTR上看看有什么内容可以检查一下的，比如检查下本地数据库：

本地的eid还可以通过lig self eid-table default查看，如下图所示：

还可以检查一下转发信息，比如本地的eid和远端eid，R1R3都有只选取R1截图：

或者查看本地的map-cache，也能看到大致一样的信息，如下图：

基本情况就这些，还可以直接show lisp看一下，内容很少：

那这里还看到一个lisp ID，那是因为我们是可以配置进程号的，也截取给大家看下：

以上就是第一次LISP实验的全部内容，希望大家有所收获。

对了，关于实验必须使用的特定IOS，还有本次我自己的拓扑的gns3也共享出来，懒得配置或者还不怎么明白有什么配置的可以下载直接打开，记得修改IDEL值，非常卡，链接: http://pan.baidu.com/share/link?shareid=4152855068&uk=3307602948提取密码:k2ls

或者你想收藏本文档，可以下载PDF版链接:http://pan.baidu.com/share/link?shareid=650136969&uk=3307602948 提取密码:cosa 文档打开密码：sovand

最后有打个广告求人气：http://unclecao.1kapp.com/鄙人的个博，有点丑请海涵。

还有一个用来做图床的51cto站点：http://callme35004.blog.51cto.com/

最后感谢大家阅读本文档，点赞狂魔请用玉玺，恭喜发财。

2013-09-24 16：40

Uncle Cao

本文出自 “曹五柳” 博客，谢绝转载！