Neutron社区每周记（5.30~6.5） DVR 里的那些事儿

本周的Neutron有哪些值得关注的新动态？merge了哪些patch？修复了哪个重要的Bug？...

Neutron里的DVR

1

集中式网络节点

传统的 Open vSwich Driver 实现的网关是集中式的，也就是说虚拟机跨子网的东西流量和通向外网的南北流量都是要回过网络节点这个中央节点的。如图：

这样的架构设计很可能在网络节点上生成数千或者更多的 namespaces 和 ports，这些对象在通过消息队列传递时，由于消息过大导致引起消息队列性能恶化，Neutron agent 处理消息时过慢等问题。

2

DVR场景

DVR 的基本思路就是讲网关分散到各个计算节点，计算节点上的虚拟机可以就近路由进行东西流量的通信，或者进行网络地址转化（NAT），目前除了将公网 IP 绑定在虚拟路由器上以实现虚拟机通外网（SNAT方式）以外，所有流量都实现了分布式。DVR 下的虚拟机东西流量数据路径如下：

虚拟机 FloatingIP 流量同样无需网络节点的参与，其数据路径如下：

3

DVR 场景下的 FloatingIP 『浪费』问题

在 DVR 之前，当虚拟机需要从外网进行访问时，需要两个 FloatingIP，一个用于路由器开启公网网关使用，另一个用于给虚拟机绑定 FloatingIP 使用。在 DVR 场景下，在上述的基础上，额外需要一个『network:floatingip_agent_gateway 』类型的 Port，进行路由，当然，这个 Port 是从外部网络（FloatingIP 池中的 IP 地址）中创建的。对此，社区最近有意通过这个 SPEC（https://review.openstack.org/#/c/300207/ ）解决这一问题。

4

DVR 下计算节点上 FIP namespace 的作用

在DVR场景之前，所有 FloatingIP 绑定在网络节点虚拟路由器的 qg 设备上，并且网络节点上所有的 qg 设备桥接在外部网桥上，从而实现 FloatingIP 的功能。在DVR 场景下，所有FloatingIP 绑定在计算节点虚拟机路由器的 rfp 设备上，rfp 是 Linux Veth 设备，该设备的另一端在 FIP namespace 中，FIP namespace 中的 fg 设备桥接在外部网桥上，实现 FloatingIP 的功能。那么，问题来了，对于 FloatingIP 的实现为什么不像CVR（Centralized Virtual Router ）中的那样（将 FloatingIP 直接绑定在 qg 设备上，而是将 FloatingIP 绑定在 router namespace 中，并且增加另外的 fip namespace ）呢？

主要原因是——节省物理交换机 MAC 表。在CVR场景下，网络节点的外部网桥上桥接着多个 qg 设备（FloatingIP 配置在 qg 设备上），那么在物理交换机的 MAC 表项可能是这样的（以网络节点在交换机上的 Port 以 2 举例）：

MAC Address

Port

MAC of qg12MAC of qg22MAC of qg32...2MAC of qgN2在 DVR 场景下，由于外部网桥上只有一个 Port （fg 设备），那么计算节点上联物理交换机的 MAC 表项可能是这样的：

MAC Address

Port

MAC of host1 fg2通过上述对比可知，在 DVR 场景下，节省了物理交换机的 MAC 地址表项。

5

Conversational Learning

在 Neutron 中，当来自未知的位置报文时，Neutron 通过 OVS 的 learn 动作可以实现对流的会话学习（Conversational Learning）。在 Open vSwitch 的 br-tun 网桥上，存在一条学习规则如下：

cookie=0xbf36e76cf0946b9e, duration=16123.771s, table=10, n_packets=419, n_bytes=40096, idle_age=10442, priority=1 actions=learn(table=20,hard_timeout=300,priority=1,cookie=0xbf36e76cf0946b9e,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1

向 table 20 中添加对返程包的正常转发规则，并且从 patch-int 送到 br-int。其中 learn 内的 table=20 说明是修改表 20 中的规则，后面是添加的规则内容； NXM_OF_VLAN_TCI[0..11]，匹配和当前流同样的 VLan 头，其中 NXM 是 Nicira Extensible Match 的缩写； NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[]，包的目的 MAC 跟当前流的源 MAC 匹配； load:0->NXM_OF_VLAN_TCI[]，将 VLAN 号改为 0； load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[]，将 Tunnel 号修改为当前的 Tunnel 号； output:NXM_OF_IN_PORT[]，从当前入口发出。

例如，一条学习到的流表如下：

cookie=0x9d7197dac63a0de6, duration=480.414s, table=20, n_packets=2, n_bytes=140, hard_timeout=300, idle_age=4, hard_age=4, priority=1,vlan_tci=0x0012/0x0fff,dl_dst=fa:16:3e:3b:63:15 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2

通过Conversational Learning 可以 cache 住流量，避免将流量发到不必要的 VTEP 上，虽然在一定程度上减少了不必要的广播，但是依旧没有将所有的广播流量抑制在本地。在DVR 中，通过 L2 population 减少不必要的隧道通信，优化网络流量，通过 ARP Responder 将 ARP 流量抑制在本地。

6

L2 population + ARP Responder

在没有 L2 population 之前，Neutron 实现的 VXLAN 是 full-mesh的，即：每个 VTEP 之间都建立 VXLAN 隧道，当遇到未知单播、广播时，如果 VTEP 没有 cache 过这条流，则会广播到所有 VTEP，造成严重的性能下降，为此，可以通过 L2 population 来提升网络效率。在没有打开 L2 population 之前，通信路径如下：

在打开 L2 population 后，再配合 ARP Responder，达到将 ARP 进行本地回复，流量走单播。通过 Open vSwitch Bridge br-tun 作为 ARP Responder，一条典型的流表规则如下：

cookie=0x9d7197dac63a0de6, duration=1231.235s, table=21, n_packets=417, n_bytes=17514, idle_age=44, priority=1,arp,dl_vlan=18, arp_tpa=4.4.4.10

（请求4.4.4.10的 ARP 请求）

actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[]（将源MAC地址放到目的MAC地址中）,

mod_dl_src:fa:16:3e:a8:98:3c,（更改源MAC为fa:16:3e:a8:98:3c）

load:0x2->NXM_OF_ARP_OP[],（ARP 回复）

move:NXM_NX_ARP_SHA[]->NXM_NX_ARP_THA[],（将ARP源MAC地址放到ARP的目的MAC地址中）

move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],（将ARP源IP地址放到ARP的目的IP地址）

load:0xfa163ea8983c->NXM_NX_ARP_SHA[],（ARP源MAC填充成fa:16:3e:a8:98:3c）

load:0x404040a->NXM_OF_ARP_SPA[],（将ARP源IP地址4.4.4.10）

IN_PORT（哪儿来的，回哪儿去）

一条通过 L2 Population 添加的流表如下：

cookie=0x9d7197dac63a0de6, duration=179342.098s, table=20, n_packets=0, n_bytes=0, idle_age=65534, hard_age=65534, priority=2,dl_vlan=18,dl_dst=fa:16:3e:60:6d:02 actions=strip_vlan,set_tunnel:0x16,output:2

Conversational Learning 和 L2 Population 都作用在了 OVS bridge br-tun table 20 上，那么，如果由于某些意外情况导致 L2 Population 无法正常下发流表，还可通过 Conversational Learning 的形式使得 OVS 以被动的方式（Conversational Learning）优化网络流向。

7

完全的 ARP 抑制

DVR 通过 ARP Responder + 虚拟路由器中的静态 ARP 达到 ARP 抑制。对于虚拟机的『同子网的跨宿主机通信或者同宿主机通信』，通过 ARP Responder 进行ARP 抑制。对于虚拟机的『跨子网通信或者外网通信』，虚拟机会将数据包发往自己的默认网关，通过虚拟路由器里的静态 ARP（在虚拟路由器中通过 ip n 或者 arp -an 查看），使得网关设备不发 ARP 广播。

8

DVR 存在的限制和问题

云平台的控制平面强制影响了数据平面。换句话说，一旦云平台的控制平面出现了消息丢失或者其他异常情况，数据平面就会收到影响（虚拟机的联通性）；由于 L2 population 需要通过消息队列通知虚拟机的可达信息（VTEP），在一定程度上加重了消息队列的负载；

目前 DVR 场景无法使用 VIP 类应用，也就是说当使用 keepalived 等应用时，是不能创建DVR虚拟路由器的。原因是创建虚拟网卡并绑定 FloatingIP 时，Neutron 无法感知如何绑定该 Floatingip。

Neutron社区动态

Bi-weekly report

从本周开始，Neutron 官方社区将会每两周做一次报告。今天介绍下第一篇 Neutron 官方社区的报告。本次报告主要介绍了目前 OVO （Oslo VersionedObject）当前的进展，OVO 也是最近 Neutron 社区的工作重点。从 M 版开始，已经开始了 OVO 的相关工作，起初将 Neutron 最核心的三个资源（Port，Subnet 和 Network）作为 OVO的工作重点，但是进展不尽人意，因此不得不将工作分解，首先进行 interface object 相关的工作，随后在对其他资源进行 OVO 的相关操作。关于 OVO 的进度，社区的计划是在 Ocata 版 release 完成所有 Neutron 资源到 OVO 的迁移。Newton 版将是最后一个离线数据升级版本，话句话说，从 N 版以后，通过 OVO，将完成 Neutron Server 的无间断数据库升级。

Neutron Feature Matrix Implementation

本周还有一个值得关注的 patch 是关于 Neutron 的特性实现。在 Nova 中已经相关文档说明目前 Nova 支持的所有特性和兼容性测试报告（http://docs.openstack.org/developer/nova/support-matrix.html）。

社区中有人打算在 Neutron 中也实现类似的整理（https://review.openstack.org/#/c/324048/）。

使用 NeutronDbObject 时的并发问题

在使用 NeutronDbObject 时可能会产生并发问题，对此社区给出了两种解决方法：

基于 DB locks：优点是在 context 中对象绝对不会发生变化；缺点是可能会造成死锁（https://wiki.openstack.org/wiki/OpenStack_and_SQLAlchemy#MySQLdb_.2B_eventlet_.3D_sad）
不使用 locks，基于 version counter 。可以通过 SqlAlchemy version counter（http://docs.sqlalchemy.org/en/rel_0_9/orm/versioning.html）或者自行添加 version counter 来解决该问题，对于方式2，目前社区已经有 patch（https://review.openstack.org/#/c/303966/）在解决，相关的 SPEC 和 BUG 在 https://review.openstack.org/#/c/225995 和https://bugs.launchpad.net/neutron/+bug/1516195

对于 Neutron Server 的并发问题，通过 Tooz （https://github.com/openstack/tooz）也可解决，不过在部署上会带来一些难度（Zookeeper 、 Redis等）。

networking-SFC 对 NSH 的支持

networking-SFC 目前已支持用户指定 data path SFC 的封装机制，NSH （Network Services Headers）也将会是下一个支持的封装选项。但目前由于 OVS 本身并没有支持 NSH ，所以在一定程度上导致了 networking-SFC 对于 NSH 的支持。

但是，Neutron 项目的 PTL Armando 指出，Neutron 作为一个开源项目，有一系列的开源软件构成， OVS 只是其中之一，如果有其他开源项目可能做到支持 NSH ，肯定也是欢迎的。

上周 Neutron 社区 merged 的主要 patches

修复了当给非 gateway port 绑定 floatingip 时bug：（https://review.openstack.org/#/c/292318）
对于 BP - routed-networks，支持当创建 port 时aware segment（https://review.openstack.org/#/c/314815）
废弃了 oslo cache （https://review.openstack.org/#/c/290305/）
修复了在创建 dvrha interface 时的bug（https://review.openstack.org/#/c/307526/）

关于作者

苌智：SDN 工程师，2015年1月加入 UnitedStack有云，专注于虚拟网络和 SDN 方向，OpenStack Neutron 社区活跃贡献者。

云计算－OpenStack－开源

关注“UnitedStack有云”

了解开源云资讯

精品技术库：https://www.ustack.com/about/blog/

企业联系人邮箱：marketing@unitedstack.com

有云，世界更精彩