Frequently Asked Questions¶
Q: What are the key differences between ML2/ovs and ML2/networking-ovn?
| Detail | ml2/ovs | ml2/networking-ovn |
|---|---|---|
| agent/server communication | rabbit mq messaging + RPC. | ovsdb protocol on the NorthBound and SouthBound databases. |
| l3ha API | routers expose an “ha” field that can be disabled or enabled by admin with a deployment default. | routers don’t expose an “ha” field, and will make use of HA as soon as there is more than one network node available. |
| l3ha dataplane | qrouter namespace with keepalive process and an internal ha network for VRRP traffic. | ovn-controller configures specific OpenFlow rules, and enables BFD protocol over tunnel endpoints to detect connectivity issues to nodes. |
| DVR API | exposes the “distributed” flag on routers only modifiable by admin. | no “distributed” flag is shown or available on routers via API. |
| DVR dataplane | uses namespaces, veths, ip routing, ip rules and iptables on the compute nodes. | Uses OpenFlow rules on the compute nodes. |
| E/W traffic | goes through network nodes when the router is not distributed (DVR). | completely distributed in all cases. |
| Metadata Service | Metadata service is provided by the qrouters or dhcp namespaces in the network nodes. | Metadata is completely distributed across compute nodes, and served from the ovnmeta-xxxxx-xxxx namespace. |
| DHCP Service | DHCP is provided via qdhcp-xxxxx-xxx namespaces which run dnsmasq inside. | DHCP is provided by OpenFlow and ovn-controller, being distributed across computes. |
| Trunk Ports | Trunk ports are built by creating br-trunk-xxx bridges and patch ports. | Trunk ports live in br-int as OpenFlow rules, while subports are directly attached to br-int. |
Q: Why can’t I use the distributed or ha flags of routers?
Networking OVN implements HA and distributed in a transparent way for the administrator and users.
HA will be automatically used on routers as soon as more than two gateway nodes are detected. And distributed floating IPs will be used as soon as it’s configured (see next question).
Q: Does OVN support DVR or distributed L3 routing?
Yes, it’s controlled by a single flag in configuration.
DVR will be used for floating IPs if the ovn / enable_distributed_floating_ips flag is configured to True in the neutron server configuration, being a deployment wide setting. In contrast to ML2/ovs which was able to specify this setting per router (only admin).
Although networking-ovn does not expose the “distributed” flag of routers throught the API.
Q: Does OVN support integration with physical switches?
OVN currently integrates with physical switches by optionally using them as VTEP gateways from logical to physical networks and via integrations provided by the Neutron ML2 framework, hierarchical port binding.
Q: What’s the status of HA for networking-ovn and OVN?
Typically, multiple copies of neutron-server are run across multiple servers and uses a load balancer. The neutron ML2 mechanism driver provided by networking-ovn supports this deployment model. DHCP and metadata services are distributed across compute nodes, and don’t depend on the network nodes.
The network controller portion of OVN is distributed - an instance of the ovn-controller service runs on every hypervisor. OVN also includes some central components for control purposes.
ovn-northd is a centralized service that does some translation between the northbound and southbound databases in OVN. Currently, you only run this service once. You can manage it in an active/passive HA mode using something like Pacemaker. The OVN project plans to allow this service to be horizontally scaled both for scaling and HA reasons. This will allow it to be run in an active/active HA mode.
OVN also makes use of ovsdb-server for the OVN northbound and southbound databases. ovsdb-server supports active/passive HA using replication. For more information, see: http://docs.openvswitch.org/en/latest/topics/ovsdb-replication/
A typical deployment would use something like Pacemaker to manage the active/passive HA process. Clients would be pointed at a virtual IP address. When the HA manager detects a failure of the master, the virtual IP would be moved and the passive replica would become the new master.
See OVN information for links to more details on OVN’s architecture.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.