作者:Sammy Liu

第一部分 路由策略及路由表

第二部分 路由配置

第三部分 DVR Router & 安装和功能分析

第四部分 第四部分 DVR流程 & 网络包走向分析

 

第五部分

1. 代码分析

DVR 代码修改包括几部分:

DVR Router network namespace 的创建和删除

DVR Router 相关的 flows

DVR Router 的 ARP 表

1.1 DVR Router 相关 network namespace 的创建和删除

1.1.1 qrouter 在计算和网络节点上的删除和创建

对于每一个 DVR Router,在每个分布了和 router 连接的网段内的虚机的计算节点上,都会有一个 qrouter 实例。两种情况下会将一个 DVR Router 部署到一个 L3 Agent 上:

  • 当一个子网 subnet 被加入到一个 DVR Router 时,DVR Router 会被分布到所有包含在该子网内的虚机的计算节点上。
  • 计算节点上的 L3 Agent 会收到一个通知,它会配置 router
    OVS Agent 会将 router 的端口 plug 到 OVS Bridge 上,并且配置 flows

当一个虚机被创建,而且虚机所在的计算节点上不存在该虚机所在 subnet 连接的 DVR Router 时。

当与 DVR Router 相关的最后一个虚机被删除时,router namespace 会被从虚机所在的计算节点上删除。

1.1.2 snat 在网络节点上的创建和删除

创建:当设置 router 的 external gateway 时

删除:当删除 router 的 external gateway 时

1.1.3 fip 在 计算节点上的创建和删除

创建:当一个浮动 IP 被分配给一个虚机的时候,如果虚机所在的计算节点上 fip namespace 不存在,则创建它

删除:(1)当计算节点上最后一个使用浮动 IP 的虚机被删除后 (2)所有虚机的浮动 IP 被删除后

1.2 DVR MAC 地址

前面提到过,分布到多个计算节点上的 qrouter 的interface 的 MAC 地址都相同。这在传统的网络中是不允许的,在 neutron 网络中某些时候也会导致一些问题。Neutron的做法是会向每个计算节点分配一个唯一的 DVR Host MAC 地址。当使用了 DVR 的 OVS Agent 启动的时候,它通过 RPC 去从 neutron server 上申请该 MAC 地址。该 MAC 地址会被保存在 DB 中,与该计算节点强绑定。比如:

wechat7.6.1

当数据包离开 DVR Router 经过 br-tun 时,OVS flows 会将 DVR Router interface 的源 MAC 地址替换成该 MAC 地址。

wechat7.6.2

而 src mac 地址分别是 qrouter 上的作为默认各网段的默认网关的 mac 地址:

wechat7.6.3

因此,这里假设你不会将多个 DVR Router 连接到一个 subnet。当数据包达到该计算节点时,OVS flows 会将其源 MAC 地址替换成 VM gateway 的 MAC 地址。

DVR-MAC-ADDRESS 的更新是 neutron server 通过 RPC Notifier 做的。每当一个新的地址被分配后,它通知所有的 L3 Agent 节点做处理。

1.3 DVR OVS flows

使用 DVR Router 的计算节点上,br-int 和 br-tun 中的 flows 会有修改。具体请参见上文的 3.2.4 部分。

1.3.1 br-int flows 的主要修改

table 1: DVR_TO_SRC_MAC

table 0:LOCAL_SWITCHING

wechat7.6.4

 

1.3.2 br-tun flows 主要的修改

br-tun flows 的主要修改是增加了 table 1 和 9.

wechat7.6.5

对于将要离开本机的网络帧:

  • Table 1 (DVR process Table): 如果网络帧的 src mac 是本机 qrouter 上的 interface 的 mac 地址(dvr-router-intf-mac),将其修改为 DVR-compute-node-unique-mac,然后交给table 2 处理;其它的帧,交给 table 2.

wechat7.6.6

  • Table 2:单播帧转 table 20;多播帧转 table 22

wechat7.6.7

  • Table 20:将 vlan id 转化为 tunnel id,并根据处理进入本机的网络帧的时候学习到的 mac 地址和 tunnel port,查找网络帧的出口 tunnel port

wechat7.6.8

  • Table 22:将 vlan id 转化为 tunnel id,并泛洪到所有的 tunnel 端口

wechat7.6.9

对于进入本机的网络帧:

  • table 0:交给 table 3 处理
  • table 3:只允许目的网络为本机上的虚机所在的网络的网络帧,修改其 vlan id,转 Table 9

wechat7.6.10

Table 9 (DVR Learning blocker):如果 src mac 是 DVR-Unique-MAC,不做 mac 学习,转发到 patch-int;否则,转到 table 10 做 mac 地址学习

wechat7.6.11

Table 10:mac 地址学习,结果存到 Table 20

wechat7.6.12

注意:在 table 20 中,除了自己通过 mac 地址学习学到的 mac 地址外,还需要借助 l2population 。这就是为什么 DVR 依赖于 l2population 的缘故。没有使用的话,网络包无法发到正确的 tunnel interface。

具体设置 OVS flows 的代码在 setup_dvr_flows_on_integ_tun_br 函数中。更详细的说明可以参考官方文章(https://wiki.openstack.org/wiki/Neutron/DVR_L2_Agent)

1.4 qrouter 中的ARP 表

虚机 vm1 需要通过 ARP 获取两种 mac 地址:

  1. 当目标计算机(vm2)不在其同一个网段时,它需要获取默认网关的 mac 地址,这个将由 qrouter 直接相应 arp 请求。
  2. 当目标计算机(vm2)在其同一个网段时,它需要直接获取 vm2 的 mac 地址。这个应该仍然是通过 ARP 广播获得。简单的做法是使用 arp responder。

qrouter 在做完 vm1 的网络包的路由后,将网络包从 vm2 所在网段的 interface 上发出前,需要获取 vm2 的 mac 地址。而这个是通过它查询自身的 ARP table 获得的。这是 compute 1 上 qrouter netns 中的 ip neighbour 表:

wechat7.6.13

这里面可以看到大量的 PERMANENT MAC 地址。这是因为,L3 Agent 配置 DVR Router 的时候,它通过 RPC 从 neturon server 获取该 router 各 interface 的 subnet 中获取所有虚机的 MAC 地址。当一个 subnet 被加到 DVR Router 的时候,每个相关的 L3 Agent 都会被通知到,然后它通过 RPC 获取各 MAC 地址。当一个新的 port 被创建,或者 port 的 MAC 有更新的时候,所有相关的 L3 Agent 会被通知到去更新 ARP 表。

通过该由 L3 Agent 动态维护的 ARP 表,qrouter 就能直接查到它要通信的 interface 的 MAC 地址了,而不需要通过广播的方式去被动获取。具体原因是:

wechat7.6.14

大致的更新过程为:

  1. 每个L2 Agent 进程循环检查其管理的 port 的状态
  2. 当 port 状态由 down 变为 up 时,它通过 RPC 通知 neutron server 该变化,neutron server 然后发出 fanout 通知其他的 L2 agent 去添加 arp entry (add_arp_entry),再调用 ip neigh replace方法在 qrouter network namespace 中 增加一个 arp entry
  3. 当 port 状态由 up 变为 down 时,它通过 RPC 通知 neutron server 该变化,neutron server 然后发出 fanout 通知其他的 L2 agent 去添加 delete entry (del_arp_entry),再调用 ip neigh del 方法在 qrouter network namespace 中 删除该 arp entry

1.5 ip rule 和 route 操作

1.5.1 增加一个 internal subnet 时在 qrouter namespace 上:

(1)计算该 subnet  cidr(81.1.180.1/24)的 index 1359066113,作为新增 ip rule 的优先级和路由表的名称。

(2)增加 default gateway,运行 [‘ip route replace default via 81.1.180.17 dev qr-517bdba3-b1 table 1359066113]。这里的 81.1.180.17 正是 snat namespace 的 IP。

(3)增加 ip rule, 允许 [ip rule add from 81.1.180.1/24 lookup 1359066113 priority 1359066113]。这样就将该 subnet 中的虚机的网络帧转到 route table

(4)执行 ip netns exec qrouter-e8f12f7a-6938-4e65-88c4-97e4cb211b27 sysctl -w net.ipv4.conf.qr-517bdba3-b1.send_redirects=0

效果如下:

wechat7.6.15

这样,当虚机还没有配置浮动IP时,访问外网的话,网络帧的路线为:vm —- qrouter subnet 1 interface — SNAT  —- external port —– pc

因此,当 router 上连接有多个 subnet 时,qrouter 中也有相应数量的 ip rule 和 routing table:

wechat7.6.16

1.5.2 给虚机绑定浮动 IP 时在 qrouter namespace 中:

(1)增加 ip rule,通过运行 [‘add’, ‘from’, u’81.1.180.18’, ‘lookup’, 16, ‘priority’, 32768],其中,ID 16 为写死的,其优先级是从 32768 开始到 36768 这个区间内依次分配。

(2)在路由表 16 中添加路由项 default via 169.254.31.239 dev rfp-e8f12f7a-6。这使得虚机访问外网的网络包会通过 rfp-e8f12f7a-6 发到 169.254.31.239。而这个 IP 正是 fip 上 pfr 端口的IP。

在 fip namespace 中:

(1)增加 route:192.168.1.0/24 dev fg-6b744484-88  proto kernel  scope link  src 192.168.1.119。这使得访问外网机器的网络包能从  fg-6b744484-88 出去。

(2)增加 route:192.168.1.116 via 169.254.31.238 dev fpr-e8f12f7a-6。使得访问虚机的网络包会发给 169.254.31.238,进入 qrouter。这个 router 上的每个浮动 IP 有这么一条 route。

配置了两个浮动 IP 的情况下是这样的结果:

wechat7.6.17

这里能看到 qroute 的 ip rule 上,针对一个虚机/子网,有两条 rule,一条查路由表 16 到 fip,另一条查表到 snat。但是,在有浮动 IP 的情况下,前一条策略的优先级数值将小于后后一条的,这就决定了查路由表 16,数据包走 fip。

1.5.3 qrouter 的 main 路由表

main 路由表是为虚拟子网服务的,每个 subnet 对应一条路由规则,使得目的为每个 subnet 的网络包从指定的 qrouter 的 qr interface 上发出。

wechat7.6.18

2. Neutron 其它服务与 DVR

2.1 FWaas DVR

DVR 与传统的 FWaas 不兼容,因为它作用于neuron 网络节点上的 virtual router,过滤进出租户网络的网络包。传统的 FWaas 可以参考我的另一篇文章。

DVR 实现后,FWaas 需要做相应的修改。

官方文档在这里:

https://wiki.openstack.org/wiki/Neutron/FWaaS/FWaaS-DVR

Spec:https://review.openstack.org/#/c/106225/9/specs/juno/neutron-dvr-fwaas.rst

目标:FWaas 保持对 南-北流量做防火墙,而不影响东-西流量。

做法:Neutron 网络节点上的 FWaas Agent 安装在 SNAT network namespace 中;计算和网络节点上的 FWaas Agent 安装在 qrouter network namespace 中。

2.2 VPNaas DVR

Juno 版本中 VPNaas 不支持 DVR,只支持传统的 router。Kilo 版本中会实现 VPNaas 对 DVR  的支持。新的 VPN 服务只会在 dvr_snat 节点上的 snat namespace 上运行。

2.3 LBaas 与 DVR

两者之间没有相互依赖关系,所以 DVR 对 LBaas 没有影响。

总体情况:

wechat7.6.19

3. 后续版本中 DVR 开发

3.1 Kilo 版本中

  • VPNaaS 对 DVR 的支持
  • 从传统 router 迁移到 DVR router
  • 网络节点上 HA + DVR 支持
  • VLAN 支持

3.2 Liberty 版本中

  • L3 Agent 重构
  • 分布式 DHCP
  • 性能调优
  • 分布式 SNAT

从前两个章节也可以看出,Juno 版本才添加的 DVR 功能还很不完善,难以满足生产环境的使用要求,主要是因为它还不支持目前实际部署中应该很广泛的 VLAN 组网模式,以及无法解决 HA 和 DVR 共存的问题。可喜的是这两个主要问题会在 K 版本中解决,因此 K 版本中的 DVR 至少可以用来做测试用了。到了 L 版本,实现分布式 DHCP 和 SNAT,以及性能优化以后,离生产环境的要求基本就差不多了。

全文终

 

本文转载自:http://geek.csdn.net/news/detail/76034