OVS agent: 使用 python 绑定代替 ovs-ofctl 命令¶
https://blueprints.launchpad.net/neutron/+spec/ovs-ofctl-to-python
问题描述¶
OVS agent 使用 ovs-ofctl 命令来编程流。虽然可行，但存在一些缺点
提议的变更¶
与其每次都调用 ovs-ofctl，不如使用 Ryu SDN Framework (“Ryu” [2]) 提供的 OpenFlow python 库 (“Ryu ofproto 库” [3]) 来编程 OVS。这种方法已用于 ofagent [4]，并证明有效。
计划
实现细节
OpenFlow 版本
OVS agent 当前使用 OpenFlow 1.0。新的基于 Ryu 的驱动程序将使用 OpenFlow 1.3，原因如下。基于 ovs-ofctl 的驱动程序将继续使用 OpenFlow 1.0，并使用当前使用的完全相同的流。
OpenFlow 1.3 提供了一些对 OVS agent 可能有用的功能。例如，ofagent 使用元数据来实现“本地 VLAN”隔离。OVS agent 可以这样做。
与更新的版本（如 OpenFlow 1.3）相比，Ryu ofproto 库对 OpenFlow 1.0 的 API 并不复杂。它工作良好，但仅提供较旧的 API [13]。
OpenFlow 1.3 与最新版本的 Open vSwitch 配合良好。Open vSwitch v2.0.0 引入了 OpenFlow 1.3 支持，Open vSwitch v2.3.0 默认启用了它。
OVS-agent 本身配置交换机以使用适当的 OpenFlow 版本。无需额外的操作员调查。
发行版中的 Open vSwitch 版本
XenAPI
XenAPI 集成需要更新。
当前 OVS agent 使用特殊的 rootwrap [14] [15] 来代理来自 neutron 节点到 dom0 的 ovs-ofctl/ovs-vsctl 请求。此提案取代了 ovs-ofctl 的使用。此提案不更改 ovs-vsctl 部分。
由于我们可以假设 neutron 节点和 dom0 之间的 IP 可达性 [20]，一个简单的 set-controller 命令应该足以教 OVS 相应 neutron 节点的 IP 地址（从而嵌入的 OpenFlow 控制器）。
OVS-agent 将具有一个新的选项来指定侦听 OpenFlow 连接的地址和端口。
Nicira 扩展 (NX)
当前 OVS agent 在多个地方使用 Nicira 扩展来实现 OpenFlow 1.0。即使使用 OpenFlow 1.3，其中一些仍然需要这些扩展。
以下是 OVS agent 使用的 Nicira 扩展列表。Ryu>=3.18 支持所有这些扩展。
Learn 操作
Local ARP responder 大量使用 Nicira 扩展
Load
Move
NXM_NX_ARP_SHA
NXM_NX_ARP_THA
从长远来看，可能用 ofagent 的基于数据包传入的实现完全替换它会更干净。这样，就不需要使用 Nicira 扩展了。
以下 Nicira 扩展将由 OpenFlow 1.3 原生等效项替换。
Tunnel 支持
Resubmit 和表
OpenFlow 通道建立
当前，每次调用时，ovs-ofctl 命令都会通过 unix 域套接字连接到交换机。相反，此蓝图建议 OVS agent 侦听本地 TCP 端口，例如 127.0.0.1:6633，并等待交换机连接到该端口。TCP 是 OpenFlow 通道的典型传输方式，并消除了 rootwrap 的需要。这与 ofagent 当前的工作方式相同。
为了使上述工作，需要配置交换机以连接到该端口。OVS agent 可以在启动时通过访问 ovsdb 来相应地配置交换机。
典型代码更改示例
当前代码
br.add_flow(priority=2, in_port=in_port, actions="output:%s" % out_port)
使用 Ryu
match = ofpp.OFPMatch(in_port=in_port) actions = [ ofpp.OFPActionOutput(port=out_port) ] instructions = [ ofpp.OFPInstructionActions(ofp.OFPIT_APPLY_ACTIONS, actions) ] msg = ofpp.OFPFlowMod(dp, priority=2, match=match, instructions=instructions]) self.send_msg(msg)
如您所见，Ryu 版本是对 OpenFlow 协议的直接表示。
备选方案¶
与其让 OVS agent 切换到 OpenFlow 1.3，不如改进 Ryu 的 OpenFlow 1.0 支持。这将最大限度地减少 neutron 中的更改。然而，考虑到 OpenFlow 1.0 的有限功能，这不是一个有吸引力的选择。
将 ofagent 合并到 OVS agent 中。这将带来一些额外的 ofagent 改进，包括剧烈的流表设计更改 [5] 和基于数据包传入的本地 arp responder [7]。如果我们想长期合并这些代理，同时保持 ofagent 的“尽可能避免 OVS 特定功能”属性，那么这个选项将是最直接的，并大大减少总的工作量。如果选择此路线，适当的步骤可能是
将缺乏 DVR、canary 表等功能的端口迁移到 ofagent
假设保持 OVS-agent 的兼容性更重要（对吗？），恢复在 ofagent 中删除的功能。（br-ex 支持等）
一旦 ofagent 具有功能奇偶校验，就用它替换 OVS-agent。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
节点上的本地用户能够连接到代理正在侦听的 OpenFlow 端口，并尝试混淆代理。然而，由于本地管理网络被认为是安全的，因此这不是一个问题。
如果需要，可以使用 TLS 保护 OpenFlow 通道。Open vSwitch 和 Ryu 都支持 TLS [12]。在这种情况下，我们需要引入一些代理选项来指定证书。
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
与 rootwrap 和 ovs-ofctl 命令相比，每个 FlowMod 的开销会更小。
IPv6 影响¶
无
其他部署者影响¶
OVS agent 需要 Ryu SDN Framework 才能工作
开发人员影响¶
OVS agent 的开发人员需要熟悉 Ryu ofproto 库 API，而不是 ovs-ofctl 命令流语法。
社区影响¶
无
实现¶
负责人¶
- 主要负责人
yamamoto
- 其他贡献者
kakuma
工作项¶
请参阅“Proposed Change”部分。
依赖项¶
无
测试¶
如果需要，更新并改进现有的测试。
Ryu SDN Framework 将需要用于 gate 作业。
需要为新驱动程序提供实验性/非投票作业。
Tempest 测试¶
现有的 tempest 测试应该可以按原样工作。
功能测试¶
如果需要，更新并改进现有的测试。
目前正在进行针对驱动程序的函数测试 [18]。欢迎提出建议。
API 测试¶
无
文档影响¶
用户文档¶
需要记录指定侦听 OpenFlow 连接的地址/端口的新选项。它将由 XenAPI 集成使用。
如果我们要支持其他传输方式，例如 TLS，则需要更多选项
指定传输的选项
传输特定的参数。例如，TLS 的证书
开发人员文档¶
很高兴了解如何调试 OpenFlow 流的一些说明
即使切换到建议的基于 Ryu 的驱动程序，您今天仍然可以使用 ovs-ofctl 命令等进行调试。
Ryu 具有将 OpenFlow 消息 JSON 序列化的功能 [21]。它可能对日志记录目的有用。
