openstack-manuals/doc/admin-guide-network/ch_limitations.xml
Diane Fleming 64b6c9261e Folder rename, file rename, flattening of directories
Current folder name	New folder name	        Book title
----------------------------------------------------------
basic-install 	        DELETE
cli-guide	        DELETE
common	                common
NEW	                admin-guide-cloud	Cloud Administrators Guide
docbkx-example	        DELETE
openstack-block-storage-admin 	DELETE
openstack-compute-admin 	DELETE
openstack-config 	config-reference	OpenStack Configuration Reference
openstack-ha 	        high-availability-guide	OpenStack High Availabilty Guide
openstack-image	        image-guide	OpenStack Virtual Machine Image Guide
openstack-install 	install-guide	OpenStack Installation Guide
openstack-network-connectivity-admin 	admin-guide-network 	OpenStack Networking Administration Guide
openstack-object-storage-admin 	DELETE
openstack-security 	security-guide	OpenStack Security Guide
openstack-training 	training-guide	OpenStack Training Guide
openstack-user 	        user-guide	OpenStack End User Guide
openstack-user-admin 	user-guide-admin	OpenStack Admin User Guide
glossary	        NEW        	OpenStack Glossary

bug: #1220407

Change-Id: Id5ffc774b966ba7b9a591743a877aa10ab3094c7
author: diane fleming
2013-09-08 15:15:50 -07:00

88 lines
5.6 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="ch_limitations">
<title>Limitations</title>
<para>
<itemizedlist>
<listitem>
<para><emphasis>No equivalent for nova-network
--multi_host flag:</emphasis> 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.</para>
</listitem>
<listitem>
<para><emphasis>Linux network namespace required on nodes running neutron-l3-agent
or neutron-dhcp-agent if overlapping IPs are in use: </emphasis>. 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:</para>
<itemizedlist>
<listitem>
<para>Linux kernel 2.6.24 or newer (with CONFIG_NET_NS=y in kernel
configuration) and</para>
</listitem>
<listitem>
<para>iproute2 utilities ('ip' command) version 3.1.0 (aka 20111117) or
newer</para>
</listitem>
</itemizedlist>
<para>To check whether your host supports namespaces try running the following as
root:</para>
<screen><computeroutput>ip netns add test-ns
ip netns exec test-ns ifconfig</computeroutput></screen>
<para>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.</para>
<para>If you need to disable namespaces, make sure the
<filename>neutron.conf</filename> used by neutron-server has the following
setting:</para>
<screen><computeroutput>allow_overlapping_ips=False</computeroutput></screen>
<para>and that the dhcp_agent.ini and l3_agent.ini have the following
setting:</para>
<screen><computeroutput>use_namespaces=False</computeroutput></screen>
<note><para>If the host does not support namespaces then the <systemitem class="service"
>neutron-l3-agent</systemitem> and <systemitem class="service"
>neutron-dhcp-agent</systemitem> 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.</para></note>
<para>If you run both L3 + DHCP services on the same node, you should enable
namespaces to avoid conflicts with routes :</para>
<screen><computeroutput>use_namespaces=True</computeroutput></screen>
</listitem>
</itemizedlist>
<itemizedlist><listitem>
<para><emphasis>No IPv6 support for L3 agent:</emphasis> The neutron-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.</para>
</listitem>
<listitem>
<para><emphasis>ZeroMQ support is experimental</emphasis>: Some agents, including
neutron-dhcp-agent, neutron-openvswitch-agent, and neutron-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.</para>
</listitem><listitem>
<para><emphasis>MetaPlugin is experimental</emphasis>: 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.</para>
</listitem>
</itemizedlist>
</para>
</chapter>