Atom feed of this document

 Chapter 11. Limitations

  • No equivalent for nova-network --multi_host flag: Nova-network has a model where the L3, NAT, and DHCP processing happen on the compute node itself, rather than a dedicated networking node. OpenStack Networking now support running multiple l3-agent and dhcp-agents with load being split across those agents, but the tight coupling of that scheduling with the location of the VM is not supported in Grizzly. The Havana release is expected to include an exact replacement for the --multi_host flag in nova-network.

  • Linux network namespace required on nodes running quantum-l3-agent or quantum-dhcp-agent if overlapping IPs are in use: . In order to support overlapping IP addresses, the OpenStack Networking DHCP and L3 agents use Linux network namespaces by default. The hosts running these processes must support network namespaces. To support network namespaces, the following are required:

    • Linux kernel 2.6.24 or newer (with CONFIG_NET_NS=y in kernel configuration) and

    • iproute2 utilities ('ip' command) version 3.1.0 (aka 20111117) or newer

    To check whether your host supports namespaces try running the following as root:

    ip netns add test-ns
    ip netns exec test-ns ifconfig

    If the preceding commands do not produce errors, your platform is likely sufficient to use the dhcp-agent or l3-agent with namespace. In our experience, Ubuntu 12.04 or later support namespaces as does Fedora 17 and new, but some older RHEL platforms do not by default. It may be possible to upgrade the iproute2 package on a platform that does not support namespaces by default.

    If you need to disable namespaces, make sure the quantum.conf used by quantum-server has the following setting:


    and that the dhcp_agent.ini and l3_agent.ini have the following setting:


    If the host does not support namespaces then the quantum-l3-agent and quantum-dhcp-agent should be run on different hosts. This is due to the fact that there is no isolation between the IP addresses created by the L3 agent and by the DHCP agent. By manipulating the routing the user can ensure that these networks have access to one another.

    If you run both L3 + DHCP services on the same node, you should enable namespaces to avoid conflicts with routes :


  • No IPv6 support for L3 agent: The quantum-l3-agent, used by many plugins to implement L3 forwarding, supports only IPv4 forwarding. Currently, There are no errors provided if you configure IPv6 addresses via the API.

  • ZeroMQ support is experimental: Some agents, including quantum-dhcp-agent, quantum-openvswitch-agent, and quantum-linuxbridge-agent use RPC to communicate. ZeroMQ is an available option in the configuration file, but has not been tested and should be considered experimental. In particular, there are believed to be issues with ZeroMQ and the dhcp agent.

  • MetaPlugin is experimental: This release includes a "MetaPlugin" that is intended to support multiple plugins at the same time for different API requests, based on the content of those API requests. This functionality has not been widely reviewed or tested by the core team, and should be considered experimental until further validation is performed.

Log a bug against this page

loading table of contents...