Neutron DVR两个问题的思考

两个问题

这一段时间研究Neutron DVR,即分布式路由 (Distributed Virtual Router)。当把南北向和东西向流程打通后,突然产生了两个问题,让我思索了很久,终于得到了比较令自己信服的答案,特此记录,分享给一同搞OpenStack的朋友们。如果有朋友觉得有错误,欢迎指出,一起探讨!

  • 为什么要引入与计算节点绑定的MAC
  • 为什么跨网段的东西向流量必须使用静态arp

1. 为什么要引入与计算节点绑定的MAC

1.1 什么是与计算节点绑定的MAC

首先说一下这个与计算节点绑定的MAC。我们知道,DVR的主要思想是将路由功能下发给所有的计算节点。从Linux实现的角度,就是每个计算节点都有一个namespace用来实现路由功能,而所有的计算节点的namespace中的虚拟网口都是一模一样的。DVR认为,这些namespace中的虚拟网口qr对其他计算节点应该是不可见的,因此,从Overlay发到其他计算节点的数据包中,如果源MAC是qr的,都会被替换成该计算节点的唯一MAC;如果目的MAC是qr的,都会被DROP。

与计算节点绑定的MAC在启用DVR之后会自动创建,并写入Neutron DB。通过neutron的配置文件可以指定这个唯一MAC的前缀。

1.2 Traffic Flow

L2 agent选择neutron-openvswitch-agent时,主要是由br-tunbr-int来确保该功能正常运作的。以跨网段的东西向流量为例,拓扑图如下:

拓扑图.jpg

从Instance 1发往Instance2的traffic flow:

  • Instance 1发往Instance 2的流量通过br-int的规则仍以NORMAL模式发送,在本地的namespace做路由,从br-tun准备发往Instance 2所在的计算节点。因为此时数据包的源MAC是Instance 2的默认网关qr-2的MAC,所以br-tun在数据包发出之前将源MAC修改为计算节点1的唯一MAC,即图中“1”的位置。
  • 穿过了Overlay Network,数据包到达计算节点2,此时不需要再经过该节点的namespace,从patch口由br-tun到达br-intbr-int流表中有规则被匹配:源MAC是计算节点1的唯一MAC且发往Instance 2。按常理讲,数据包应该是从Instance 2的网关发过来的,因此该规则的动作是:将计算节点唯一MAC改为Instance 2的网关qr-2的MAC,即图中“2”的位置。
1.3 是否有必要修改qr的MAC

为什么计算节点的namespace中的网口qr不能让别的计算节点看到?这里假设图中“1”位置处并没有修改源MAC,我们再走一遍traffic flow:

  • Instance 1发往Instance 2的流量通过br-int的流表规则仍以NORMAL模式发送,从br-tun准备发往Instance 2所在的计算节点。
  • 穿过的Overlay Network,数据包到达计算节点2,此时不需要再经过该节点的namespace,从patch口由br-tun到达br-intbr-int的规则不会被匹配,因为此时源MAC是qr-2的,因此会按照NORMAL模式发送,即按照MAC和端口转发,并且在MAC表中记下qr-2的数据是从patch口进来的

也就是说,此时图中1、2两个位置都没有进行数据包源MAC的修改,此时数据包还是可以到达Instance 2的。但,Instance 2再往Instance 1发的报文就会出问题,此时的traffic flow会是这样的:

假设Instance 2的arp表记住了qr-2的MAC,不需要再发送arp请求

  • Instance 2发往Instance 1的流量通过br-int的流表规则仍以NORMAL模式发送, br-int查看MAC表发现,qr-2的数据包应该从patch口发出,因此数据包不会在计算节点2的namespace做路由,而是进入br-tun

问题由此诞生。先不说br-tun的流表规则会把目的MAC是qr的流DROP,假设数据包可以到达计算节点1做路由,但这样的traffic flow显然已经丧失了DVR设计的初衷。

因此,与计算节点绑定的MAC是必须的。

2. 为什么跨网段的东西向流量必须使用静态arp

2.1 Traffic Flow

L2 agent选择neutron-openvswitch-agent时,主要是由namespace内部配置静态arp表来响应Instance 1的arp请求报文。以跨网段的东西向流量为例,拓扑图如下:

拓扑图.jpg

从Instance 1发往Instance 2的traffic flow:

  • Instance 1与Instance 2不在同一网段,因此数据包通过br-int的流表规则最终仍是以NORMAL模式发送,到达namespace中的qr-1
  • L3 agent通过从Neutron DB获取其他实例port对应的IP/MAC关系,写入namespace的静态arp表中。Instance 1的默认网关qr-1经过路由,由qr-2根据arp表将数据包发送到Instance 2,即图中“+”位置。其余的部分与前面是一样的,省略。
2.2 为什么一定要使用静态arp

为什么不能向legacy_router模式或者同网段一样发送arp请求?通过手动将namespace中的静态arp删掉发现无法获取到Instance 2的MAC,原因是在图中2的位置,arp请求报文会命中br-int规则:源MAC是计算节点1的唯一MAC但并不是发往Instance 2,该规则的动作是:DROP,即图中“2”的位置是不会有arp请求报文发到Instance 2的。

静态arp和所有计算节点br-int的流表规则都说明一件事:跨网段东西向流量必须使用静态arp。对比之下,同网段东西向流量可以使用arp请求来获取对端的MAC,总觉得匪夷所思。

假设放开静态arp和br-int流表的限制,让arp请求报文到达Instance 2,看看会有什么问题:

  • Instance 1与Instance 2不在同一网段,因此数据包通过br-int的流表规则最终仍是以NORMAL模式发送,到达namespace中的qr-1qr-2发送arp请求报文,询问Instance 2的MAC。arp请求从br-tun准备发往所有的计算节点。因为此时数据包的源MAC是Instance 2的默认网关qr-2的MAC,所以br-tun在数据包发出之前将源MAC修改为计算节点1的唯一MAC,即图中“1”的位置。
  • 穿过了Overlay Network,数据包到达计算节点2,从patch口由br-tun到达br-int。在图中“2”位置发出,源MAC修改为Instance 2的网关qr-2的MAC。
  • Instance 2回复arp请求,将发往默认网关qr-2。数据包通过br-int流表规则最终仍是以NORMAL模式发送,从MAC表查询得知,目的MAC为qr-2的应发往namespace

问题由此诞生。目的MAC为qr的数据包只能在计算节点内部,不能发送到其他计算节点,否则还是会引起br-int的混乱。所以,就算跨网段的东西向流量允许发送arp请求,发送arp请求的namespace也永远收不到arp回复报文。

因此,跨网段的东西向流量必须使用静态arp。


后面有时间会补充ovs流表作为证据

推荐阅读更多精彩内容

  • 当搭建完openstack之后,在创建instance之前,第一件事情就是创建network,一个经典的流程如下:...
    ximitc阅读 739评论 0 0
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 124,512评论 18 136
  • 一、高可用集群 (一)提升系统高可用性的解决方案:冗余(redundant) 工作模式active/passive...
    哈喽别样阅读 1,265评论 2 5
  • 装载自http://sdnhub.cn/index.php/openv-switch-full-guide/ 1 ...
    ximitc阅读 4,525评论 0 11
  • 大家好,我是姹紫嫣红,拥有健康的体魄,美丽青春的容颜,养育健康聪明的子女,这是我们每个人的梦想。 但是随着各种慢...
    辣妈姹紫嫣红阅读 67评论 0 0
  • 当使用SDWebImage的时候,如果图片url里面包含空格,或者逗号,就不能加载 解决方法:
    linbj阅读 144评论 0 0
  • 梧桐zyd阅读 235评论 0 3
  • 抄袭是颗种子,如果本身已被炒熟丧失生命力,或者没有给予生长环境,那永远只是颗等待死亡的抄袭豆子。 没有种子,凭空几...
    青涩神话阅读 209评论 0 1
  • 琦趣之电脑很坑的设计 三年级的琦宝,开始加了信息课,这几天主要讲电脑的基本功能。今天学了回收站的作用,中午...
    jwyyw雯阅读 94评论 0 1