TricircleDiscuzZone

通过 Neutron 实现的 VxLAN L2 网络

JunSik 的实验

为了自动化多区域 OpenStack 中的 VXLAN 网络，我们按照下图所示的方式在服务器内部配置虚拟网络。

为了连接多区域 OpenStack 实例，我添加了一个名为 "br-cap" 的额外网桥，并在该网桥上配置隧道端口。网桥 "br-cap" 由 ONOS SDN 控制器控制。为了自动化配置，我引入了基于模板的自动化概念。我定义了一种自定义模板格式来描述跨多个服务器的虚拟网络拓扑。然后我的工具通过 OVSDB 协议自动化配置 OVS 网桥和 VXLAN 端口，并调用 ONOS API 将 OpenFlow 规则下发到 "br-cap" 网桥。作为基本流规则，我们仅设置广播流规则，不设置细粒度的流规则。例如，当数据包从 br-int 抵达 br-cap 时，"br-cap" 会将数据包广播到所有隧道。

隧道终结点作为绑定细节的一部分

Kevin 在巴塞罗那设计峰会上的总结：http://lists.openstack.org/pipermail/openstack-dev/2016-November/107061.html

L2pop 动态计算信息以确定隧道终结点。这存在竞态条件（未处理乱序的隧道通知），并导致涉及查找代理表等许多复杂问题。这也会使集成外部设备变得非常困难，因为它们无法向代理通知其隧道终结点。

我们希望通过将隧道终结点添加到端口绑定数据模型中来正式化隧道终结点，就像其他封装细节（绑定段、分段 ID 等）一样。这将允许机制驱动程序基于最新的端口模型数据（通过推送通知传递）绑定端口，而无需基于代理，并允许与基于代理的端口无缝集成。L2pop 服务器端逻辑将消失，因为代理将仅基于端口模型上的最新数据设置转发条目，这些数据通过推送通知传递。

这需要在服务器端的端口绑定过程中进行一些更改，以便机制驱动程序将隧道终结点作为绑定细节的一部分提供。代理端也需要进行一些更改，使其隧道形成逻辑源自推送通知，而不是隧道和 fdb 通知。

=== flooding vteps in network (VTEP in network) ===

通过在本地 Neutron 中将其他 Neutron 中的远程 VTEP 添加到网络中，然后可以通过 VxLAN 将一个网络扩展到其他 OpenStack。当我们与 Kevin 在巴塞罗那峰会上交谈时，Kevin 认为（端口中的 VTEP）将是一个更好的解决方案。

https://review.openstack.org/#/c/282180/ {

     "network": {
       "status": "ACTIVE",
       "name": "net1",
       "admin_state_up": true,
       "tenant_id": "9bacb3c5d39d41a79512987f338cf177",
       "mtu": 0,
       "shared": false,
       "id": "4e8e5957-649f-477b-9e5b-f1f75b21c03c"
       "provider:network_type": "vxlan",
       "provider:segmentation_id": "1022",
       "provider:flooding_vteps":[
         {"ip_address":"192.168.1.1", "dstport": "5566"}
       ],
       "router:external":True
     }
   }