Neutron社区每周记（6.6~6.12）| OVN大战ODL、随机分配 IP能这么愉快地决定了吗？
OVN vs OpenDayLight
对 OpenStack 网络实现和 SDN有所了解的同学一般不会有这样的问题，因为 OVN 是单纯的实现一个云网络，目前支持 OpenStack，未来还可能支持别的 CMS 系统，而 OpenDayLight 是一个大而全的控制器，目标是整个网络资源进行抽象和编排，并不针对云平台。
不过随着 OpenDayLight Netvirt 项目、Neutron networking-odl 项目的日益成熟，越来越多做云的同学将目光投向了这个目前 SDN 领域几乎呼声最高的控制器——OpenDayLight，因此本周有人提问 OVN 和 OpenDayLight 的区别是什么？
Oleg Bondarev 发了一篇文档的链接，介绍了他之前恰好做过的 OVN 和 OpenDayLight 的比较：
首先，最重要的，项目目的完全不同：
| OVN | ODL | |
| Project Goal | OVN complements the existing capabilities of OVS to add native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. The design goal is to have a production quality implementation that can operate at significant scale. | The goal of the project is to accelerate the adoption of software-defined networking (SDN) and create a solid foundation for Network Functions Virtualization (NFV). ODL enables network services across a spectrum of hardware in multivendor environments |
其次，目前三层功能的实现也各有限制：
| Native L3 support | Supported. Limitations: no NAT at the moment (planned) | Supported. Limitations: no SNAT (planned according to answers in IRC) |
两者均有 DVR，但是 DHCP、Metadata 和安全组实现不同：
| DVR support | Native | Native |
| DHCP support | Legacy, native support is planned (no separate DHCP agent) | Legacy |
| Metadata support | Legacy | Native since Beryllium |
| Security Groups support | Native (ACL), OVS v2.5 required | Stateless(OVS 2.4 and below) and Stateful (with OVS 2.5).
Known bugs: |
负载均衡器和 Neutron Open vSwitch Driver 已支持功能上 ODL 略胜一筹：
| LBaaS support | Legacy | Native |
| Neutron API extensions support | agent
availability_zone binding dhcp_agent_scheduler network_availability_zone external-net extra_dhcp_opt extraroute net-mtu provider router qos quotas rbac-policies security-group subnet_allocation |
agent
address-scope allowed-address-pairs availability_zone binding default-subnetpools dhcp_agent_scheduler external-net extra_dhcp_opt extraroute multi-provider net-mtu network_availability_zone provider router security-group subnet_allocation quotas vlan-transparent |
关于 OVN 和 ODL 的架构比较、分布式与集中式的比较这里不再赘述，感兴趣的读者可以自行搜索相关资料，最后 Oleg 做了总结：
- OVN 目前看来距离生产可用还有一段差距，其需要较新版本的 OVS 可能也有一定风险。OVN 从设计目标上就可以看出来它的目标是实现二、三层的虚拟网络，这让它和其他 SDN 控制器完全不同；
- ODL 的使用远不止 OpenStack 这一处，它的目的是影响整个 SDN、NFV 业界。其与 OpenStack 对接的成熟度比 OVN 还是好一些的，但还是没有看到过投入生产、进行了严肃测试的用户案例
随机分配 IP？
有经验的 OpenStacker 知道 Neutron 的地址分配其实是轮询的，这样的好处是能够比较好实现，冲突好管理。最近一个 Patch（https://review.openstack.org/#/c/292207）实现了随机化的 IP 分配，然而正要合并临门一脚之际……
Gary Kotton 提出了质疑：你们怎么能改这个逻辑呢？这不是我以前的经验不就有问题了吗？我以前基于这一经验写的脚本不就有问题了吗？你们怎么能这样捏？
Carl Baldwin 并不买账：这一行为写入文档了吗？公开说明了吗？之前只是碰巧这么实现了，你们怎么能当真呢？随机化的 IP 能解决好多条件竞争问题，就这么愉快的决定了！
现在讨论还在继续……
OVS 与 MTU？
Neutron 的新版本提供了一个功能，叫做 MTU Advertise，目的是用户可以给虚拟机分配不同于默认的 MTU。例如虚拟机默认 MTU 是 1450，如果用户业务以大包为主，希望上 9000 MTU，那么通过 MTU Advertise 可以将从 tap、qbr、qvo 等整个链路的 MTU 都做一定调整。
然而 Ihar Hrachyshka 反映了一个问题，他说如果一个 OVS 桥上有多个 Port，而且这些 Port 的 MTU 不一致，那么 OVS 会以最小的 MTU 为准。这个行为来自 Linux bridging 的准则，同一个桥上的 Port 的 MTU 都应该是一致的。
然而 Eugene Nikanorov 回复说他并没有遇到问题。
MTU Advertise 到底是否能够正常使用？目前还没有定论。