王为，UnitedStack SDN 架构师，参与 OpenStack 研发两年，主要专注于网络领域，ArchSummit、PyCon 讲师，Neutron Trouble-shooting 项目 Steth 架构师
-------------------------------------------------------------------------
分享正文
今天和大家一起讨论下 VxLan 在 OpenStack 中的使用演变。大概会介绍 Neutron 的 L2 Pop 和 BaGPipe，早期的 VxLan 与现在的 MP-BGP E*** VxLan
我们先从一个比较简单的中小型企业的使用 Neutron 参考网络模型 OpenStack 使用场景来看。大概是这样的，计算节点上起 VTEP，通过 VxLan 跑数据平面，如果有企业内网通信的需求，那么可以用虚拟路由器做 L2 Gateway，但是问题很多。
简单说下原理，首先我们基于 OVS 实现的 VxLan 隧道由 Neutron 收集所有 Agent 来 建立 VxLan 隧道，然后 VTEP 因为不知道其后的 VIF 的地址，所以只能依赖 Flood & learn 来学习应该往哪个隧道转发。ARP 广播也没有机制实现代理，所以效率和 BUM 都成问题。另外企业用户常有和 BareMeta 或企业内部应用访问的问题，这时只能用 namespace 实现的软件路由器实现，效率和性能都很成问题。集中化的路由器更是问题很多。
总结一下：
VxLan 的具体问题后边补充，我们先说下目前的解决方案有什么
一些解决方案：
第三方软件方案：Nuage Networks, OpenContrail
社区改进：BaGPipe, L2 Population, DVR
硬件方案：Cisco, BigSwitch
先说一个比较少为人知的 BaGPipe，给一张图：
BaGPipe 的架构就不详细介绍了，可以用 devstack 搭一下体验一下，大致原理就是由单独的 BGP 软件运行 MPBGP 协议，与 RR 建立 Peer，交换可达信息。RR 可以是硬件设备，也可以是一些开源软件。
但是问题也是很明显的：
BaGPipe 不是一个在多个生产环境经过验证的软件
BaGPipe Agent 是否可靠
路由没有解决
那么我们来看下社区的正统实现：L2 Population + ARP Responder
主要方法就是由 Neutron Server 发布消息，OVS Agent 根据信息设置 fdb 和 tunnel。
三层的方法需要 DVR，DVR 文章很多了，不再赘述问题：
L2 Pop 强制影响了转发平面，对于一些网络自主行为无法支持例如虚 IP 的漂移
大量的广播消息，对消息队列有很强要求
DVR 问题也很多
回过头来，我们尝试从协议上把这个问题分析一下，下边要用 louis 大神的一些图
这是以 DCI 场景说明，在 Fabric 内跑 IGP，因为控制平面是中心化的，所以DCI效率很低，无法把广播尽量保持在本 DC 内，大家把路由信息发到一个统一控制平面上，再下发下去
因为没有广播控制（不传递host可达信息），所广播会像这样：
为了解决 VxLan 对组播的依赖，所以大家提出给予 HER 的方案，全称是 Head-end Replication，是一种广播/组播流量转成单播的方案。效果太简单了，根本问题是第一版的 VxLan 缺乏控制平面，只是单纯说 IP Fabric 传送就行了，不像现代的网络协议通过控制平面解决广播、Flood、一些检测等问题。
那我们来讨论 VxLan 2.0 MP-BGP E*** VxLan，其实核心思想主要是可达信息的互换，制定一个控制平面，具体可以看 RFC。
用图来看：
当 Leaf 获取后边 Host 信息时，上报到 RR，两个控制平面的 RR 相互交换可达信息：
RR 把汇聚的可达信息返回给 Leaf：
那么后边的转发就可以智能很多：
在我们的生产实践中，比较过几种方案，比如说 BGP 是不是必须得用 RR 反射路由？其实也不一定的，比如用 eBGP 来建立 Peer，每个 Leaf 有单独的 ASN，这样配置上可能会麻烦一些，但逻辑也很清晰，上面这几种方式我们可以总结一下：
再说下我们的一些生产经验，第一：交换机的控制器的控制平面性能问题很重要，因为 OpenStack 很多地方并发和实现并不安全。有些地方缺乏锁，特别是并发情况下，从 Nova 到 Neutron 都有。
第二个是数据库同步，从 OpenDayLight 到 DragonFlow 都在解决数据库同步问题，因为这个确实是核心问题。
第三个是控制器要考虑到一些特别情况，比如我们有时希望手动加入一些配置，这些配置可能是控制器无法加入的，比如做 DCI 时，因为控制器支持不够，需要手动在 VRF 加路由，那么要确定控制器不会直接把 VRF 清掉。
第四个是在可靠性上可能需要做一些牺牲，比如一个可靠的控制器可能需要确保配置确实下发下去了，OpenFlow based 的控制器一般没有确保流表下达的可靠性的。基于配置的控制器可以 get conf 确定 sync，再 save config，再 get config。这样可能会很花时间，反而带来很多问题，所以怎么解决这些问题是我们生产实践的一些核心问题，理论上的问题反而基本是很成熟的。
分享就到这里。
Q&A
Q1：是不是集中式控制比e***更合适？
A1：e*** 主要解决的是 vxlan 的效率问题，集中式控制器可能关系不那么大，但我们用的控制器其实是个配置管理器，所以集中式还是靠谱一些
Q2：添加vrf路由放到控制器里面做也可以吧，不需要在路由器上手动配置，控制器掌握一切
A2：是的，只是使用的控制器功能有些缺乏
Q3：干嘛让bgp搞这个
A3：就是解决VxLan的flood问题，特别是DCI场景
Q4：如何确定100%被正确下发了呢，假如没有收到的时候会不会还有其他情况导致？
A4：目前会在save conf 后 get conf 确定一把，但是这样效率很低，一个 port 的更新可能得几秒，所以这是将来要改进的地方。
Q5：问个低级问题，能用neutron直接对接硬件交换机做vxlan吗
A5：只需要通过netconf/api配置就可以了，比如实现一个对控制器的 mechanisim driver 到 neutron 里，由控制器下发配置
Q6：还是用控制器来管理网络设备，neutron调控制器吧
A6：那倒不需要、直接 neutron ML2 对 交换机就可以，交换机需要有对 ML2 compliant 的 driver，不必要有 ODL或任何SDN 控制器，不少厂商都支持 硬件 VTEP。
Q7：硬件估计确认配置下发成功更麻烦些
A7：控制器 如ODL 用 netconf 管理交换机 更统一些
Q8：用E***来实现VxLAN并且把VRF通过CLI或者Netconf注册到SDN控制器，这应该不难，难的部分是如何把VRF的配置做到从cloud manager管理下发到SDN控制器，在跨DC的场景中自动配置L3***的连接，同时能够复用PE peer的现有连接啊，主要用于multi tenancy, 不知道有没有类似项目这么做的呢？
A8：好像没有 我了解的DCI场景还是OTV多
