位置与标识分离——入向流量优化

前面聊过了一个数据中心站点内部的连接优化,也聊过了数据中心多个站点间的互联优化,那么还剩下一个问题就是用户如何通过Internet访问数据中心中的服务器/虚拟机了。其实这就是一个IP路由的过程,能够找到主机所在站点入口的路由器也就OK了。不过大二层网络主机经常要跨站点漂移,而且IP地址还不能变,那么按理来说这时公网应该把与这台主机的相关的流量路由到漂移后所在站点的出口路由器上。可是,现有的公网路由器是察觉不到的这些的,除非这台主机在公网上发布了32位的路由,迁移后导致全网的重收敛,不过这根本是不现实的。因此主机跨站点漂移后,公网用户的访问往往要先到达原来主机所在站点的路由器,再通过DC间的L2 Tunnel传输到主机漂移后所在的站点,引发了入站流量的迂回,或者说是出入站流量的不对称。这会严重地浪费DCI设备间的带宽,更为严重的是,这种流量不对称会触发防火墙等Middle Box的半连接逻辑,很可能会直接将流量丢弃。

这个问题的本质是因为IP是一种对链路进行寻址的技术,IP网络中路由汇聚的逻辑认为主机身份与其所在的物理位置是绑定的。为了解决这一问题,出现了很多的方案。HTTP重定向针对Web流量做了入向路径调整,不过应用场景也仅限于Web; RHI(Route Health Injection,路由健康注入)的思路是通过主动探测+发布不同metric的32位主机路由来解决这一问题,不过在现网上无法大规模的使用;GSLB(Global Sever Load Balance,全局服务器负载均衡)从DNS入手能够实现入向路径优化,目前已经得到了广泛的应用。上述几种方式都和网络虚拟化搭不上边儿,而LISP作为另一种入向流量优化方案,则体现了正宗的网络虚拟化思想。

1)LISP

LISP(Location Identifier Separation Protocol,RFC 6830),是一种IPinIP隧道技术,它保留了内部目的IP地址标识主机身份,并通过外层的目的IP地址标识主机所在位置,相当于将IP地址扩展到了64位,解决了32位IP地址无法解耦位置与身份的问题。

上图为LISP数据平面的封装。外层的IP地址称为RLOC(Routing Locator)地址,源RLOC用来标识ITR(Ingress Tunnel Router)作为源主机的位置信息,目的RLOC用来标识ETR(Egress Tunnel Router)作为目的主机的位置信息;UDP报头中,源端口号通过Hash得到通常用作ECMP,目的端口号为4341表示内部为LISP数据包;LISP报头内部的格式很有意思,不同标志位的置位/复位都影响着报头字段的含义——N位为Nonce启用位,V位为Map-Version启用位,两者不可同时置位,L位和I位分别为LSB位和Instance ID位,当L位置位时,LISP报头的后32位均作为Locator-Status-Bits,当I位置位时Locator-Status-Bits的高24位作为Instance ID,低8位仍然作为Locator-Status-Bits;Nonce用于RLOC探测,通过随机算法生成;Map-Version用来标识同一个EID-Prefix更新的先后顺序(具体请参考RFC 6634);Instance ID用来标识业务或者租户,ITR可以做VLAN/VNI对Instance ID的转换;Locator-Status-Bits用来标识RLOC的状态;内部的IP地址称为EID(Endpoint Identifier)地址,即为源/目的主机的IP地址,作为源/目的主机的身份信息。

LISP作为一种隧道技术,最为关键的就是EID对RLOC映射关系的学习。与TRILL、SPB通过周期性交互IS-IS来学习传输路由不同,LISP的地址学习是一种Pull/Push机制,仅当ITR不知道该如何针对内层EID封装外层RLOC时才会触发学习机制。学习的方法分为以下两种:第一种为ITR发送Map-Request消息直接询问目的EID所在ETR的RLOC地址,ETR收到后回复Map-Reply以通告EID-to-RLOC的信息。第二种为Data-Probe方式,ITR通过发送探针数据包来触发目的EID所在ETR的Map-Reply。ITR会缓存Map-Reply中的映射信息,下一次碰到相同目的EID的包直接进行封装转发。这里插一句,LISP 控制平面的报文也是通过UDP传输的,其格式如下图所示,目的端口号为4342。

Map-Reply中,外层的源IP地址填为ETR的RLOC地址,目的IP地址填为ITR的RLOC地址。而在Map-Request和Data-Probe中,外层的源IP地址填为ITR的RLOC地址,而目的IP地址则需要直接填为目的主机的EID地址。那么问题来了,Internet上的路由器只了解RLOC的拓扑,对EID的拓扑毫不知情,它们该如何路由这个用来学习地址的包呢?

标准的LISP对此并没有做出规范,而在LISP-AlT(RFC 6636)中给出了一种解决方法。LISP-AlT通过GRE建立隧道,通过BGP在所有参与LISP-ALT的路由器间建立邻居并分发EID-Prefix,以建立EID的拓扑。上述外层地址为目的主机EID,用于地址学习的包便可以在ALT网络中路由到ETR上了。

不过LISP-ALT这种方式有些复杂,一来要依赖于分布式的协议交互,二来还要维护ALT网络中EID的拓扑。相比之下LISP Map-Server Interface(RFC 6633)给出了另外一种集中式的地址学习机制,为此增加了Map-Resolver(MR)和Map-Server(MS)两种角色。LISP网络中所有ITR都会向MS进行EID-to-RLOC的注册,碰到未知的EID就向MR发送Map-Request,而非直接将目的IP填为目的主机的EID。MR再将其转发给MS,MS根据已知的EID-to-RLOC信息将该请求转发给最后注册该EID的ETR,由ETR完成最后的Map-Reply。这种方式虽然易于理解,不过部署起来也很麻烦,不仅要对MR和MS做额外的配置,还要手动为ITR指定MR和MS的地址。LISP-ALT和Map-Server Interface两种方式还可以进行混合的部署。

讲完了数据封装和控制平面,下面以Map-Request + LISP Map-Server Interface的学习方式为例,看一个LISP的具体转发实例。其中xTR表示集ITR与ETR为一体的LISP路由器。

通信流程如下顺序所示:DC xTR1发现主机1.0.0.1,向MS 3.0.0.2注册5.0.0.1-to-1.0.0.1的信息;Internet xTR下的客户6.0.0.1向5.0.0.1发送数据包;Internet xTR收到该数据包后,发现本地没有EID 5.0.0.1的映射信息,向MR 3.0.0.1发送Map-Request消息;MR将该请求转发给MS 3.0.0.2,MS转发给DC xTR1;DC xTR向Internet xTR回复Map-Reply消息;Internet xTR缓存下5.0.0.1-to-1.0.0.1的映射关系,后续数据包到来时,外层报头源/目的IP地址封为4.0.0.1/1.0.0.1,内层仍为6.0.0.1/5.0.0.1,向Internet发送该数据包;DC xTR1收到该数据包后,剥掉外层报头,最终发送给目的主机5.0.0.1。

从上述过程可以看出来,LISP说是对现有的Internet改动小,但是还是要求用户的接入网关为LISP xTR。为了实现LISP站点和非LISP站点之间的互通,需要PxTR(Proxy xTR)来为所有的非LISP站点的流量做代理隧道。这些流量遵循当前的IGP/BGP路由到达PITR,PITR再通过LISP封装完成入向流量的选路优化。关于LISP站点和非LISP站点互通的具体规范,有兴趣的读者可以参考RFC 6832。另外,RFC 6831还对LISP的多播进行了规范。

其实LISP的概念在很久之前就被提出了,不过由于LISP要对现网部分路由器进行升级,之前的需求也不是很迫切,所以产品一直没有成型。随着云计算和大二层网络技术的发展,位置与身份解耦的场景越来越明确,因此Cisco这几年抓紧推动了LISP的标准化进程,并在N7K上提供了对LISP的支持。近3年来LISP相关的IETF Draft非常多,其中绝大部分都是由Cisco推动的,可见LISP在Cisco未来的规划中是占据了一席之地的。

作者简介:
张晨,2014/09-至今,北京邮电大学信息与通信工程学院未来网络理论与应用实验室(FNL实验室)攻读硕士研究生。主要研究方向:SDN、虚拟化、数据中心
个人博客:sdnv.xyz
个人邮箱:zhangchen9211@126.com


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/16717.html
分享到:
相关文章
条评论

登录后才可以评论

张晨 发表于16-05-03
0