809 lines
46 KiB
XML
809 lines
46 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<section 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="section_networking-nova">
|
|
<title>Networking with nova-network</title>
|
|
<para>Understanding the networking configuration options helps you design
|
|
the best configuration for your Compute instances.</para>
|
|
<para>You can choose to either install and configure
|
|
<systemitem class="service">nova-network</systemitem> or use the
|
|
OpenStack Networking service (neutron). This section contains a brief
|
|
overview of <systemitem class="service">nova-network</systemitem>. For
|
|
more information about OpenStack Networking, see
|
|
<xref linkend="ch_networking"/>.</para>
|
|
<section xml:id="section_networking-options">
|
|
<title>Networking concepts</title>
|
|
<para>Compute assigns a private IP address to each VM instance. Compute
|
|
makes a distinction between fixed IPs and
|
|
<glossterm baseform="floating IP address">floating IP</glossterm>.
|
|
Fixed IPs are IP addresses that are assigned to an instance on
|
|
creation and stay the same until the instance is explicitly
|
|
terminated. Floating IPs are addresses that can be dynamically
|
|
associated with an instance. A floating IP address can be
|
|
disassociated and associated with another instance at any time. A
|
|
user can reserve a floating IP for their project.</para>
|
|
<note>
|
|
<para>Currently, Compute with
|
|
<systemitem class="service">nova-network</systemitem> only supports
|
|
Linux bridge networking that allows virtual interfaces to connect
|
|
to the outside network through the physical interface.</para>
|
|
</note>
|
|
<para>The network controller with
|
|
<systemitem class="service">nova-network</systemitem> provides
|
|
virtual networks to enable compute servers to interact with each
|
|
other and with the public network. Compute with
|
|
<systemitem class="service">nova-network</systemitem> supports the
|
|
following network modes, which are implemented as Network Manager
|
|
types:</para>
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term>Flat Network Manager</term>
|
|
<listitem>
|
|
<para>In this mode, a network administrator specifies a subnet.
|
|
IP addresses for VM instances are assigned from the subnet,
|
|
and then injected into the image on launch. Each instance
|
|
receives a fixed IP address from the pool of available
|
|
addresses. A system administrator must create the Linux
|
|
networking bridge (typically named <literal>br100</literal>,
|
|
although this is configurable) on the systems running the
|
|
<systemitem class="service">nova-network</systemitem> service.
|
|
All instances of the system are attached to the same bridge,
|
|
which is configured manually by the network administrator.</para>
|
|
<note>
|
|
<para>Configuration injection currently only works on
|
|
Linux-style systems that keep networking configuration in
|
|
<filename>/etc/network/interfaces</filename>.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>Flat DHCP Network Manager</term>
|
|
<listitem>
|
|
<para>In this mode, OpenStack starts a DHCP server
|
|
(<systemitem>dnsmasq</systemitem>) to allocate IP addresses to
|
|
VM instances from the specified subnet, in addition to
|
|
manually configuring the networking bridge. IP addresses for
|
|
VM instances are assigned from a subnet specified by the
|
|
network administrator.</para>
|
|
<para>Like flat mode, all instances are attached to a single
|
|
bridge on the compute node. Additionally, a DHCP server
|
|
configures instances depending on single-/multi-host mode,
|
|
alongside each <systemitem class="service">nova-network</systemitem>.
|
|
In this mode, Compute does a bit more configuration. It
|
|
attempts to bridge into an Ethernet device
|
|
(<literal>flat_interface</literal>, eth0 by default). For
|
|
every instance, Compute allocates a fixed IP address and
|
|
configures <systemitem>dnsmasq</systemitem> with the MAC ID
|
|
and IP address for the VM. <systemitem>dnsmasq</systemitem>
|
|
does not take part in the IP address allocation process, it
|
|
only hands out IPs according to the mapping done by Compute.
|
|
Instances receive their fixed IPs with the <command>dhcpdiscover</command>
|
|
command. These IPs are not assigned to any of the host's
|
|
network interfaces, only to the guest-side interface for the
|
|
VM.</para>
|
|
<para>In any setup with flat networking, the hosts providing
|
|
the <systemitem class="service">nova-network</systemitem>
|
|
service are responsible for forwarding traffic from the
|
|
private network. They also run and configure
|
|
<systemitem>dnsmasq</systemitem> as a DHCP server listening on
|
|
this bridge, usually on IP address 10.0.0.1 (see
|
|
<link linkend="section_dnsmasq">DHCP server: dnsmasq </link>).
|
|
Compute can determine the NAT entries for each network,
|
|
although sometimes NAT is not used, such as when the network
|
|
has been configured with all public IPs, or if a hardware
|
|
router is used (which is a high availability option). In this
|
|
case, hosts need to have <literal>br100</literal> configured
|
|
and physically connected to any other nodes that are hosting
|
|
VMs. You must set the <literal>flat_network_bridge</literal>
|
|
option or create networks with the bridge parameter in order
|
|
to avoid raising an error. Compute nodes have iptables or
|
|
ebtables entries created for each project and instance to
|
|
protect against MAC ID or IP address spoofing and ARP
|
|
poisoning.</para>
|
|
<note>
|
|
<para>In single-host Flat DHCP mode you will be able to ping
|
|
VMs through their fixed IP from the
|
|
<systemitem>nova-network</systemitem> node, but you cannot
|
|
ping them from the compute nodes. This is expected behavior.</para>
|
|
</note>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry>
|
|
<term>VLAN Network Manager</term>
|
|
<listitem>
|
|
<para>This is the default mode for OpenStack Compute. In this
|
|
mode, Compute creates a VLAN and bridge for each tenant. For
|
|
multiple-machine installations, the VLAN Network Mode
|
|
requires a switch that supports VLAN tagging (IEEE 802.1Q).
|
|
The tenant gets a range of private IPs that are only
|
|
accessible from inside the VLAN. In order for a user to
|
|
access the instances in their tenant, a special VPN instance
|
|
(code named <systemitem>cloudpipe</systemitem>) needs to be
|
|
created. Compute generates a certificate and key for the
|
|
user to access the VPN and starts the VPN automatically. It
|
|
provides a private network segment for each tenant's
|
|
instances that can be accessed through a dedicated VPN
|
|
connection from the internet. In this mode, each tenant gets
|
|
its own VLAN, Linux networking bridge, and subnet.</para>
|
|
<para>The subnets are specified by the network administrator,
|
|
and are assigned dynamically to a tenant when required. A
|
|
DHCP server is started for each VLAN to pass out IP addresses
|
|
to VM instances from the subnet assigned to the tenant. All
|
|
instances belonging to one tenant are bridged into the same
|
|
VLAN for that tenant. OpenStack Compute creates the Linux
|
|
networking bridges and VLANs when required.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>These network managers can co-exist in a cloud system.
|
|
However, because you cannot select the type of network for a
|
|
given tenant, you cannot configure multiple network types in a
|
|
single Compute installation.</para>
|
|
<para>All network managers configure the network using network
|
|
drivers. For example, the Linux L3 driver (<literal>l3.py</literal>
|
|
and <literal>linux_net.py</literal>), which makes use of
|
|
<literal>iptables</literal>, <literal>route</literal> and other
|
|
network management facilities, and the libvirt
|
|
<link xlink:href="http://libvirt.org/formatnwfilter.html">network
|
|
filtering facilities</link>. The driver is not tied to any
|
|
particular network manager; all network managers use the same
|
|
driver. The driver usually initializes only when the first VM
|
|
lands on this host node.</para>
|
|
<para>All network managers operate in either single-host or
|
|
multi-host mode. This choice greatly influences the network
|
|
configuration. In single-host mode, a single
|
|
<systemitem class="service">nova-network</systemitem> service
|
|
provides a default gateway for VMs and hosts a single DHCP
|
|
server (<systemitem>dnsmasq</systemitem>). In multi-host mode,
|
|
each compute node runs its own
|
|
<systemitem class="service">nova-network</systemitem> service.
|
|
In both cases, all traffic between VMs and the internet flows
|
|
through <systemitem class="service">nova-network</systemitem>.
|
|
Each mode has benefits and drawbacks. For more on this, see the
|
|
<citetitle>Network Topology</citetitle> section in the <link
|
|
xlink:href="http://docs.openstack.org/openstack-ops/content/">
|
|
<citetitle>OpenStack Operations Guide</citetitle></link>.</para>
|
|
<para>All networking options require network connectivity to be
|
|
already set up between OpenStack physical nodes. OpenStack does
|
|
not configure any physical network interfaces. All network
|
|
managers automatically create VM virtual interfaces. Some
|
|
network managers can also create network bridges such as
|
|
<literal>br100</literal>.</para>
|
|
<para>The internal network interface is used for communication
|
|
with VMs. The interface should not have an IP address attached
|
|
to it before OpenStack installation, it serves only as a
|
|
fabric where the actual endpoints are VMs and dnsmasq.
|
|
Additionally, the internal network interface must be in
|
|
<literal>promiscuous</literal> mode, so that it can receive
|
|
packets whose target MAC address is the guest VM, not the host.</para>
|
|
<para>All machines must have a public and internal network
|
|
interface (controlled by these options:
|
|
<literal>public_interface</literal> for the public interface,
|
|
and <literal>flat_interface</literal> and
|
|
<literal>vlan_interface</literal> for the internal interface
|
|
with flat or VLAN managers). This guide refers to the public
|
|
network as the external network and the private network as the
|
|
internal or tenant network.</para>
|
|
<para>For flat and flat DHCP modes, use the
|
|
<command>nova network-create</command> command to create a
|
|
network:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova network-create vmnet \
|
|
--fixed-range-v4 10.0.0.0/16 --fixed-cidr 10.0.20.0/24 --bridge br100</userinput></screen>
|
|
<para>This example uses the following parameters:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para><parameter>--fixed-range-v4-</parameter> specifies the
|
|
network subnet.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><parameter>--fixed-cidr</parameter> specifies a range of
|
|
fixed IP addresses to allocate, and can be a subset of the
|
|
<parameter>--fixed-range-v4</parameter> argument.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para><parameter>--bridge</parameter> specifies the bridge
|
|
device to which this network is connected on every compute
|
|
node.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section xml:id="section_dnsmasq">
|
|
<title>DHCP server: dnsmasq</title>
|
|
<para>The Compute service uses <link xlink:href="http://www.thekelleys.org.uk/dnsmasq/doc.html">
|
|
dnsmasq</link> as the DHCP server when using either Flat DHCP
|
|
Network Manager or VLAN Network Manager. For Compute to operate in
|
|
IPv4/IPv6 dual-stack mode, use at least <systemitem>dnsmasq</systemitem>
|
|
v2.63. The <systemitem class="service">nova-network</systemitem>
|
|
service is responsible for starting <systemitem>dnsmasq</systemitem>
|
|
processes.</para>
|
|
<para>The behavior of <systemitem>dnsmasq</systemitem> can be
|
|
customized by creating a <systemitem>dnsmasq</systemitem>
|
|
configuration file. Specify the configuration file using the
|
|
<literal>dnsmasq_config_file</literal> configuration option:</para>
|
|
<programlisting language="ini">dnsmasq_config_file=/etc/dnsmasq-nova.conf</programlisting>
|
|
<para>For more information about creating a
|
|
<systemitem>dnsmasq</systemitem> configuration file, see the
|
|
<link xlink:href="http://docs.openstack.org/juno/config-reference/content/">
|
|
<citetitle>OpenStack Configuration Reference</citetitle></link>, and
|
|
<link xlink:href="http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq.conf.example">
|
|
the dnsmasq documentation</link>.</para>
|
|
<para><systemitem>dnsmasq</systemitem> also acts as a caching DNS
|
|
server for instances. You can specify the DNS server that
|
|
<systemitem>dnsmasq</systemitem> uses by setting the
|
|
<literal>dns_server</literal> configuration option in
|
|
<filename>/etc/nova/nova.conf</filename>. This example configures
|
|
<systemitem>dnsmasq</systemitem> to use Google's public
|
|
DNS server:</para>
|
|
<programlisting language="ini">dns_server=8.8.8.8</programlisting>
|
|
<para><systemitem>dnsmasq</systemitem> logs to
|
|
<systemitem>syslog</systemitem> (typically
|
|
<filename>/var/log/syslog</filename> or <filename>/var/log/messages</filename>,
|
|
depending on Linux distribution). Logs can be useful for
|
|
troubleshooting, especially in a situation where VM instances boot
|
|
successfully but are not reachable over the network.</para>
|
|
<para>Administrators can specify the starting point IP address to
|
|
reserve with the DHCP server (in the format
|
|
<replaceable>n</replaceable>.<replaceable>n</replaceable>.<replaceable>n</replaceable>.<replaceable>n</replaceable>)
|
|
with this command:</para>
|
|
<screen><prompt>$</prompt><userinput>nova-manage fixed reserve --address <replaceable>IP_ADDRESS</replaceable></userinput></screen>
|
|
<para>This reservation only affects which IP address the VMs start at, not
|
|
the fixed IP addresses that <systemitem class="service">nova-network</systemitem>
|
|
places on the bridges.</para>
|
|
</section>
|
|
|
|
<xi:include href="section_compute-configure-ipv6.xml"/>
|
|
|
|
<section xml:id="section_metadata-service">
|
|
<title>Metadata service</title>
|
|
<para>Compute uses a metadata service for virtual machine instances to
|
|
retrieve instance-specific data. Instances access the metadata service
|
|
at <literal>http://169.254.169.254</literal>. The metadata service
|
|
supports two sets of APIs: an OpenStack metadata API and an
|
|
EC2-compatible API. Both APIs are versioned by date.</para>
|
|
<para>To retrieve a list of supported versions for the OpenStack
|
|
metadata API, make a GET request to
|
|
<literal>http://169.254.169.254/openstack</literal>:</para>
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254/openstack</userinput>
|
|
<computeroutput>2012-08-10
|
|
2013-04-04
|
|
2013-10-17
|
|
latest</computeroutput></screen>
|
|
<para>To list supported versions for the EC2-compatible metadata API,
|
|
make a GET request to <literal>http://169.254.169.254</literal>:</para>
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254</userinput>
|
|
<computeroutput>1.0
|
|
2007-01-19
|
|
2007-03-01
|
|
2007-08-29
|
|
2007-10-10
|
|
2007-12-15
|
|
2008-02-01
|
|
2008-09-01
|
|
2009-04-04
|
|
latest</computeroutput></screen>
|
|
<para>If you write a consumer for one of these APIs, always attempt to
|
|
access the most recent API version supported by your consumer first,
|
|
then fall back to an earlier version if the most recent one is not
|
|
available.</para>
|
|
<para>Metadata from the OpenStack API is distributed in JSON format. To
|
|
retrieve the metadata, make a GET request to
|
|
<literal>http://169.254.169.254/openstack/2012-08-10/meta_data.json</literal>:</para>
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254/openstack/2012-08-10/meta_data.json</userinput></screen>
|
|
<programlisting language="json"><xi:include href="../../common/samples/list_metadata.json" parse="text"/></programlisting>
|
|
<para>Instances also retrieve user data (passed as the
|
|
<literal>user_data</literal> parameter in the API call or by the
|
|
<literal>--user_data</literal> flag in the <command>nova boot</command>
|
|
command) through the metadata service, by making a GET request to
|
|
<literal>http://169.254.169.254/openstack/2012-08-10/user_data</literal>:</para>
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254/openstack/2012-08-10/user_data</userinput>
|
|
<computeroutput>#!/bin/bash
|
|
echo 'Extra user data here'</computeroutput></screen>
|
|
<para>The metadata service has an API that is compatible with version
|
|
2009-04-04 of the <link xlink:href="http://docs.amazonwebservices.com/AWSEC2/2009-04-04/UserGuide/AESDG-chapter-instancedata.html">
|
|
Amazon EC2 metadata service</link>. This means that virtual machine
|
|
images designed for EC2 will work properly with OpenStack.</para>
|
|
<para>The EC2 API exposes a separate URL for each metadata element.
|
|
Retrieve a listing of these elements by making a GET query to
|
|
<literal>http://169.254.169.254/2009-04-04/meta-data/</literal>:</para>
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254/2009-04-04/meta-data/</userinput>
|
|
<computeroutput>ami-id
|
|
ami-launch-index
|
|
ami-manifest-path
|
|
block-device-mapping/
|
|
hostname
|
|
instance-action
|
|
instance-id
|
|
instance-type
|
|
kernel-id
|
|
local-hostname
|
|
local-ipv4
|
|
placement/
|
|
public-hostname
|
|
public-ipv4
|
|
public-keys/
|
|
ramdisk-id
|
|
reservation-id
|
|
security-groups</computeroutput></screen>
|
|
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254/2009-04-04/meta-data/block-device-mapping/</userinput>
|
|
<computeroutput>ami</computeroutput></screen>
|
|
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254/2009-04-04/meta-data/placement/</userinput>
|
|
<computeroutput>availability-zone</computeroutput></screen>
|
|
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254/2009-04-04/meta-data/public-keys/</userinput>
|
|
<computeroutput>0=mykey</computeroutput></screen>
|
|
|
|
<para>Instances can retrieve the public SSH key (identified by keypair
|
|
name when a user requests a new instance) by making a GET request to
|
|
<literal>http://169.254.169.254/2009-04-04/meta-data/public-keys/0/openssh-key</literal>:</para>
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254/2009-04-04/meta-data/public-keys/0/openssh-key</userinput>
|
|
<computeroutput>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQDYVEprvtYJXVOBN0XNKVVRNCRX6BlnNbI+USLGais1sUWPwtSg7z9K9vhbYAPUZcq8c/s5S9dg5vTHbsiyPCIDOKyeHba4MUJq8Oh5b2i71/3BISpyxTBH/uZDHdslW2a+SrPDCeuMMoss9NFhBdKtDkdG9zyi0ibmCP6yMdEX8Q== Generated by Nova</computeroutput></screen>
|
|
|
|
<para>Instances can retrieve user data by making a GET request to
|
|
<literal>http://169.254.169.254/2009-04-04/user-data</literal>:</para>
|
|
<screen><prompt>$</prompt> <userinput>curl http://169.254.169.254/2009-04-04/user-data</userinput>
|
|
<computeroutput>#!/bin/bash
|
|
echo 'Extra user data here'</computeroutput></screen>
|
|
|
|
<para>The metadata service is implemented by either the
|
|
<systemitem class="service">nova-api</systemitem> service or the
|
|
<systemitem class="service">nova-api-metadata</systemitem> service.
|
|
Note that the <systemitem class="service">nova-api-metadata</systemitem>
|
|
service is generally only used when running in multi-host mode, as it
|
|
retrieves instance-specific metadata. If you are running the
|
|
<systemitem class="service">nova-api</systemitem> service, you must
|
|
have <literal>metadata</literal> as one of the elements listed in the
|
|
<literal>enabled_apis</literal> configuration option in
|
|
<filename>/etc/nova/nova.conf</filename>. The default
|
|
<literal>enabled_apis</literal> configuration setting includes the
|
|
metadata service, so you should not need to modify it.</para>
|
|
<para>Hosts access the service at <literal>169.254.169.254:80</literal>,
|
|
and this is translated to <literal>metadata_host:metadata_port</literal>
|
|
by an iptables rule established by the
|
|
<systemitem class="service">nova-network</systemitem> service. In
|
|
multi-host mode, you can set <option>metadata_host</option> to
|
|
<literal>127.0.0.1</literal>.</para>
|
|
<para>For instances to reach the metadata service, the
|
|
<systemitem class="service">nova-network</systemitem> service must
|
|
configure iptables to NAT port <literal>80</literal> of the
|
|
<literal>169.254.169.254</literal> address to the IP address specified
|
|
in <option>metadata_host</option> (this defaults to <literal>$my_ip</literal>,
|
|
which is the IP address of the <systemitem class="service">nova-network</systemitem>
|
|
service) and port specified in <option>metadata_port</option> (which
|
|
defaults to <literal>8775</literal>) in
|
|
<filename>/etc/nova/nova.conf</filename>.</para>
|
|
<note>
|
|
<para>The <literal>metadata_host</literal> configuration option must
|
|
be an IP address, not a host name.
|
|
</para>
|
|
</note>
|
|
<para>The default Compute service settings assume that
|
|
<systemitem class="service">nova-network</systemitem> and
|
|
<systemitem class="service">nova-api</systemitem> are running on the
|
|
same host. If this is not the case, in the
|
|
<filename>/etc/nova/nova.conf</filename> file on the host running
|
|
<systemitem class="service">nova-network</systemitem>, set the
|
|
<literal>metadata_host</literal> configuration option to the IP
|
|
address of the host where <systemitem class="service">nova-api</systemitem>
|
|
is running.</para>
|
|
|
|
<xi:include href="../../common/tables/nova-metadata.xml"/>
|
|
|
|
</section>
|
|
|
|
<section xml:id="section_enable-ping-and-ssh-on-vms">
|
|
<title>Enable ping and SSH on VMs</title>
|
|
<para>You need to enable <command>ping</command> and
|
|
<command>ssh</command> on your VMs for network access. This can be
|
|
done with either the <command>nova</command> or
|
|
<command>euca2ools</command> commands.</para>
|
|
<note>
|
|
<para>Run these commands as root only if the credentials used to
|
|
interact with <systemitem class="service">nova-api</systemitem>
|
|
are in <filename>/root/.bashrc</filename>. If the EC2 credentials
|
|
in the <filename>.bashrc</filename> file are for an unprivileged
|
|
user, you must run these commands as that user instead.</para>
|
|
</note>
|
|
<para>Enable ping and SSH with <command>nova</command> commands:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0</userinput>
|
|
<prompt>$</prompt> <userinput>nova secgroup-add-rule default tcp 22 22 0.0.0.0/0</userinput> </screen>
|
|
|
|
<para>Enable ping and SSH with <command>euca2ools</command>:</para>
|
|
<screen><prompt>$</prompt> <userinput>euca-authorize -P icmp -t -1:-1 -s 0.0.0.0/0 default</userinput>
|
|
<prompt>$</prompt> <userinput>euca-authorize -P tcp -p 22 -s 0.0.0.0/0 default</userinput> </screen>
|
|
|
|
<para>If you have run these commands and still cannot ping or SSH your
|
|
instances, check the number of running <literal>dnsmasq</literal>
|
|
processes, there should be two. If not, kill the processes and restart
|
|
the service with these commands:
|
|
command:</para>
|
|
<screen><prompt>#</prompt> <userinput>killall dnsmasq</userinput>
|
|
<prompt>#</prompt> <userinput>service nova-network restart</userinput></screen>
|
|
</section>
|
|
|
|
<section xml:id="nova-associate-public-ip">
|
|
<title>Configure public (floating) IP addresses</title>
|
|
<para>This section describes how to configure floating IP addresses
|
|
with <systemitem class="service">nova-network</systemitem>. For
|
|
information about doing this with OpenStack Networking, see
|
|
<xref linkend="section_l3_router_and_nat"/>.</para>
|
|
|
|
<section xml:id="private-and-public-IP-addresses">
|
|
<title>Private and public IP addresses</title>
|
|
<para>In this section, the term
|
|
<glossterm baseform="floating IP address">floating IP address</glossterm>
|
|
is used to refer to an IP address, usually public, that you can
|
|
dynamically add to a running virtual instance.</para>
|
|
<para>Every virtual instance is automatically assigned a private IP
|
|
address. You can choose to assign a public (or floating) IP address
|
|
instead. OpenStack Compute uses network address translation (NAT) to
|
|
assign floating IPs to virtual instances.</para>
|
|
<para>To be able to assign a floating IP address, edit the
|
|
<filename>/etc/nova/nova.conf</filename> file to specify which
|
|
interface the <systemitem class="service">nova-network</systemitem>
|
|
service should bind public IP addresses to:</para>
|
|
<programlisting language="ini">public_interface=<replaceable>VLAN100</replaceable></programlisting>
|
|
<para>If you make changes to the <filename>/etc/nova/nova.conf</filename>
|
|
file while the <systemitem class="service">nova-network</systemitem>
|
|
service is running, you will need to restart the service to pick up
|
|
the changes.</para>
|
|
<note>
|
|
<title>Traffic between VMs using floating IPs</title>
|
|
<para>Floating IPs are implemented by using a source NAT (SNAT rule
|
|
in iptables), so security groups can sometimes display inconsistent
|
|
behavior if VMs use their floating IP to communicate with other VMs,
|
|
particularly on the same physical host. Traffic from VM to VM
|
|
across the fixed network does not have this issue, and so this is
|
|
the recommended setup. To ensure that traffic does not get SNATed
|
|
to the floating range, explicitly set:</para>
|
|
<programlisting language="ini">dmz_cidr=x.x.x.x/y</programlisting>
|
|
<para>The <literal>x.x.x.x/y</literal> value specifies the range of
|
|
floating IPs for each pool of floating IPs that you define. This
|
|
configuration is also required if the VMs in the source group have
|
|
floating IPs.</para>
|
|
</note>
|
|
</section>
|
|
|
|
<section xml:id="Enabling_ip_forwarding">
|
|
<title>Enable IP forwarding</title>
|
|
<para>IP forwarding is disabled by default on most Linux
|
|
distributions. You will need to enable it in order to use floating
|
|
IPs.</para>
|
|
<note>
|
|
<para>IP forwarding only needs to be enabled on the nodes that run
|
|
<systemitem class="service">nova-network</systemitem>. However,
|
|
you will need to enable it on all compute nodes if you use
|
|
<literal>multi_host</literal> mode.</para>
|
|
</note>
|
|
<para>To check if IP forwarding is enabled, run:</para>
|
|
<screen><prompt>$</prompt> <userinput>cat /proc/sys/net/ipv4/ip_forward</userinput>
|
|
<computeroutput>0</computeroutput></screen>
|
|
<para>Alternatively, run:</para>
|
|
<screen><prompt>$</prompt> <userinput>sysctl net.ipv4.ip_forward</userinput>
|
|
<computeroutput>net.ipv4.ip_forward = 0</computeroutput></screen>
|
|
<para>In these examples, IP forwarding is disabled.</para>
|
|
<para>To enable IP forwarding dynamically, run:</para>
|
|
<screen><prompt>#</prompt> <userinput>sysctl -w net.ipv4.ip_forward=1</userinput></screen>
|
|
<para>Alternatively, run:</para>
|
|
<screen><prompt>#</prompt> <userinput>echo 1 > /proc/sys/net/ipv4/ip_forward</userinput></screen>
|
|
<para>To make the changes permanent, edit the
|
|
<filename>/etc/sysctl.conf</filename> file and update the IP
|
|
forwarding setting:</para>
|
|
<programlisting language="ini">net.ipv4.ip_forward = 1</programlisting>
|
|
<para>Save the file and run this command to apply the changes:</para>
|
|
<screen><prompt>#</prompt> <userinput>sysctl -p</userinput></screen>
|
|
<para>You can also apply the changes by restarting the network
|
|
service:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>on Ubuntu, Debian:</para>
|
|
<screen><prompt>#</prompt> <userinput>/etc/init.d/networking restart</userinput></screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>on RHEL, Fedora, CentOS, openSUSE and SLES:</para>
|
|
<screen><prompt>#</prompt> <userinput>service network restart</userinput></screen>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</section>
|
|
|
|
<section xml:id="create_list_of_available_floating_ips">
|
|
<title>Create a list of available floating IP addresses</title>
|
|
<para>Compute maintains a list of floating IP addresses that are
|
|
available for assigning to instances. Use the
|
|
<command>nova-manage floating create</command> command to add
|
|
entries to the list:</para>
|
|
<screen><prompt>#</prompt> <userinput>nova-manage floating create --pool nova --ip_range 68.99.26.170/31</userinput></screen>
|
|
<para>Use these <command>nova-manage</command> commands to perform
|
|
floating IP operations:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<screen><prompt>#</prompt> <userinput>nova-manage floating list</userinput></screen>
|
|
<para>Lists the floating IP addresses in the pool.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<screen><prompt>#</prompt> <userinput>nova-manage floating create --pool <replaceable>POOL_NAME</replaceable> --ip_range <replaceable>CIDR</replaceable></userinput></screen>
|
|
<para>Creates specific floating IPs for either a single address
|
|
or a subnet.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<screen><prompt>#</prompt> <userinput>nova-manage floating delete <replaceable>CIDR</replaceable></userinput></screen>
|
|
<para>Removes floating IP addresses using the same parameters as
|
|
the create command.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>For more information about how administrators can associate
|
|
floating IPs with instances, see
|
|
<link xlink:href="http://docs.openstack.org/user-guide-admin/content/manage_ip_addresses.html">
|
|
Manage IP addresses</link> in the <citetitle>OpenStack Admin User
|
|
Guide</citetitle>.</para>
|
|
</section>
|
|
|
|
<section xml:id="Automatically_adding_floating_IPs">
|
|
<title>Automatically add floating IPs</title>
|
|
<para>You can configure <systemitem class="service">nova-network</systemitem>
|
|
to automatically allocate and assign a floating IP address to
|
|
virtual instances when they are launched. Add this line to the
|
|
<filename>/etc/nova/nova.conf</filename> file:</para>
|
|
<programlisting language="ini">auto_assign_floating_ip=True</programlisting>
|
|
<para>Save the file, and restart
|
|
<systemitem class="service">nova-network</systemitem></para>
|
|
<note>
|
|
<para>If this option is enabled, but all floating IP addresses have
|
|
already been allocated, the <command>nova boot</command> command
|
|
will fail.</para>
|
|
</note>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="section_remove-network-from-project">
|
|
<title>Remove a network from a project</title>
|
|
<para>You cannot delete a network that has been associated to a
|
|
project. This section describes the procedure for dissociating it
|
|
so that it can be deleted.</para>
|
|
<para>In order to disassociate the network, you will need the ID of
|
|
the project it has been associated to. To get the project ID, you
|
|
will need to be an administrator.</para>
|
|
<para>
|
|
Disassociate the network from the project using the
|
|
<command>scrub</command> command, with the project ID as the final
|
|
parameter:</para>
|
|
<screen><prompt>#</prompt> <userinput>nova-manage project scrub --project <replaceable>ID</replaceable></userinput></screen>
|
|
</section>
|
|
|
|
<section xml:id="section_use-multi-nics">
|
|
<title>Multiple interfaces for instances (multinic)</title>
|
|
<para>The multinic feature allows you to use more than one interface
|
|
with your instances. This is useful in several scenarios:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>SSL Configurations (VIPs)</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Services failover/HA</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Bandwidth Allocation</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Administrative/Public access to your instances</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>Each VIP represents a separate network with its own IP block.
|
|
Every network mode has its own set of changes regarding multinic
|
|
usage:</para>
|
|
<figure>
|
|
<title>multinic flat manager</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata scale="40" fileref="../../common/figures/SCH_5007_V00_NUAC-multi_nic_OpenStack-Flat-manager.jpg"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<figure>
|
|
<title>multinic flatdhcp manager</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata scale="40" fileref="../../common/figures/SCH_5007_V00_NUAC-multi_nic_OpenStack-Flat-DHCP-manager.jpg"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
<figure>
|
|
<title>multinic VLAN manager</title>
|
|
<mediaobject>
|
|
<imageobject>
|
|
<imagedata scale="40" fileref="../../common/figures/SCH_5007_V00_NUAC-multi_nic_OpenStack-VLAN-manager.jpg"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
</figure>
|
|
|
|
<section xml:id="using-multiple-nics-usage">
|
|
<title>Using multinic</title>
|
|
<para>In order to use multinic, create two networks, and attach them
|
|
to the tenant (named <literal>project</literal> on the command
|
|
line):</para>
|
|
<screen><prompt>$</prompt> <userinput>nova network-create first-net --fixed-range-v4 20.20.0.0/24 --project-id $your-project</userinput>
|
|
<prompt>$</prompt> <userinput>nova network-create second-net --fixed-range-v4 20.20.10.0/24 --project-id $your-project</userinput></screen>
|
|
<para>Each new instance will now receive two IP addresses from their
|
|
respective DHCP servers:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova list</userinput>
|
|
<computeroutput>+-----+------------+--------+----------------------------------------+
|
|
| ID | Name | Status | Networks |
|
|
+-----+------------+--------+----------------------------------------+
|
|
| 124 | Server 124 | ACTIVE | network2=20.20.0.3; private=20.20.10.14|
|
|
+-----+------------+--------+----------------------------------------+</computeroutput></screen>
|
|
<note>
|
|
<para>Make sure you start the second interface on the instance, or
|
|
it won't be reachable through the second IP.</para>
|
|
</note>
|
|
<para>This example demonstrates how to set up the interfaces within
|
|
the instance. This is the configuration that needs to be applied
|
|
inside the image.</para>
|
|
<para>Edit the <filename>/etc/network/interfaces</filename> file:</para>
|
|
<programlisting language="bash"># The loopback network interface
|
|
auto lo
|
|
iface lo inet loopback
|
|
|
|
auto eth0
|
|
iface eth0 inet dhcp
|
|
|
|
auto eth1
|
|
iface eth1 inet dhcp</programlisting>
|
|
<para>If the Virtual Network Service Neutron is installed, you can
|
|
specify the networks to attach to the interfaces by using the
|
|
<literal>--nic</literal> flag with the the <command>nova</command>
|
|
command:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova boot --image ed8b2a37-5535-4a5f-a615-443513036d71 --flavor 1 --nic net-id=<replaceable>NETWORK1_ID</replaceable> --nic net-id=<replaceable>NETWORK2_ID</replaceable> test-vm1</userinput></screen>
|
|
</section>
|
|
</section>
|
|
|
|
<section xml:id="section_network-troubleshoot">
|
|
<title>Troubleshooting Networking</title>
|
|
<simplesect>
|
|
<!-- I think this would be better as a qandaset, what do others think? LKB-->
|
|
<title>Cannot reach floating IPs</title>
|
|
<para>If you cannot reach your instances through the floating IP
|
|
address:</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Check that the default security group allows ICMP (ping)
|
|
and SSH (port 22), so that you can reach the instances:</para>
|
|
<screen><prompt>$</prompt> <userinput>nova secgroup-list-rules default</userinput>
|
|
<computeroutput>+-------------+-----------+---------+-----------+--------------+
|
|
| IP Protocol | From Port | To Port | IP Range | Source Group |
|
|
+-------------+-----------+---------+-----------+--------------+
|
|
| icmp | -1 | -1 | 0.0.0.0/0 | |
|
|
| tcp | 22 | 22 | 0.0.0.0/0 | |
|
|
+-------------+-----------+---------+-----------+--------------+</computeroutput></screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Check the NAT rules have been added to
|
|
<systemitem>iptables</systemitem> on the node that is
|
|
running <systemitem>nova-network</systemitem>:</para>
|
|
<screen><prompt>#</prompt> <userinput>iptables -L -nv -t nat</userinput>
|
|
<computeroutput>-A nova-network-PREROUTING -d 68.99.26.170/32 -j DNAT --to-destination 10.0.0.3
|
|
-A nova-network-floating-snat -s 10.0.0.3/32 -j SNAT --to-source 68.99.26.170</computeroutput></screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Check that the public address (<uri>68.99.26.170</uri>
|
|
in this example), has been added to your public interface.
|
|
You should see the address in the listing when you use
|
|
the <command>ip addr</command> command:</para>
|
|
<screen><prompt>$</prompt> <userinput>ip addr</userinput>
|
|
<computeroutput>2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
|
|
link/ether xx:xx:xx:17:4b:c2 brd ff:ff:ff:ff:ff:ff
|
|
inet 13.22.194.80/24 brd 13.22.194.255 scope global eth0
|
|
inet 68.99.26.170/32 scope global eth0
|
|
inet6 fe80::82b:2bf:fe1:4b2/64 scope link
|
|
valid_lft forever preferred_lft forever</computeroutput></screen>
|
|
<note>
|
|
<para>You cannot <command>ssh</command> to an instance
|
|
with a public IP from within the same server because
|
|
the routing configuration does not allow it.</para>
|
|
</note>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Use <command>tcpdump</command> to identify if packets
|
|
are being routed to the inbound interface on the compute
|
|
host. If the packets are reaching the compute hosts but
|
|
the connection is failing, the issue may be that the
|
|
packet is being dropped by reverse path filtering. Try
|
|
disabling reverse-path filtering on the inbound interface.
|
|
For example, if the inbound interface is
|
|
<literal>eth2</literal>, run:</para>
|
|
<screen><prompt>#</prompt> <userinput>sysctl -w net.ipv4.conf.<replaceable>ETH2</replaceable>.rp_filter=0</userinput></screen>
|
|
<para>If this solves the problem, add the following line to
|
|
<filename>/etc/sysctl.conf</filename> so that the
|
|
reverse-path filter is persistent:</para>
|
|
<programlisting language="ini">net.ipv4.conf.rp_filter=0</programlisting>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Temporarily disable the firewall</title>
|
|
<para>To help debug networking issues with reaching VMs, you can
|
|
disable the firewall by setting this option in
|
|
<filename>/etc/nova/nova.conf</filename>:</para>
|
|
<programlisting language="ini">firewall_driver=nova.virt.firewall.NoopFirewallDriver</programlisting>
|
|
<para>We strongly recommend you remove this line to re-enable the
|
|
firewall once your networking issues have been resolved.</para>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>Packet loss from instances to nova-network server
|
|
(VLANManager mode)</title>
|
|
<para>If you can SSH to your instances but the network
|
|
to your instance is slow, or if you find that running certain
|
|
operations are slower than they should be (for example,
|
|
<command>sudo</command>), packet loss could be occurring on the
|
|
connection to the instance.</para>
|
|
<para>Packet loss can be caused by Linux networking configuration
|
|
settings related to bridges. Certain settings can cause packets
|
|
to be dropped between the VLAN interface (for example,
|
|
<literal>vlan100</literal>) and the associated bridge interface
|
|
(for example, <literal>br100</literal>) on the host running
|
|
<systemitem class="service">nova-network</systemitem>.</para>
|
|
<para>One way to check whether this is the problem is to open
|
|
three terminals and run the following commands:</para>
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>In the first terminal, on the host running
|
|
<systemitem>nova-network</systemitem>, use
|
|
<command>tcpdump</command> on the VLAN interface to monitor
|
|
DNS-related traffic (UDP, port 53). As root, run:</para>
|
|
<screen><prompt>#</prompt> <userinput>tcpdump -K -p -i vlan100 -v -vv udp port 53</userinput></screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>In the second terminal, also on the host running
|
|
<systemitem>nova-network</systemitem>, use
|
|
<command>tcpdump</command> to monitor DNS-related traffic
|
|
on the bridge interface. As root, run:</para>
|
|
<screen><prompt>#</prompt> <userinput>tcpdump -K -p -i br100 -v -vv udp port 53</userinput></screen>
|
|
</listitem>
|
|
<listitem>
|
|
<para>In the third terminal, SSH to the instance and
|
|
generate DNS requests by using the
|
|
<command>nslookup</command> command:</para>
|
|
<screen><prompt>$</prompt> <userinput>nslookup www.google.com</userinput></screen>
|
|
<para>The symptoms may be intermittent, so try running
|
|
<command>nslookup</command> multiple times. If the
|
|
network configuration is correct, the command should
|
|
return immediately each time. If it is not correct, the
|
|
command hangs for several seconds before returning.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>If the <command>nslookup</command> command sometimes
|
|
hangs, and there are packets that appear in the first
|
|
terminal but not the second, then the problem may be due
|
|
to filtering done on the bridges. Try disabling
|
|
filtering, and running these commands as root:</para>
|
|
<screen><prompt>#</prompt> <userinput>sysctl -w net.bridge.bridge-nf-call-arptables=0</userinput>
|
|
<prompt>#</prompt> <userinput>sysctl -w net.bridge.bridge-nf-call-iptables=0</userinput>
|
|
<prompt>#</prompt> <userinput>sysctl -w net.bridge.bridge-nf-call-ip6tables=0</userinput></screen>
|
|
<para>If this solves your issue, add the following line to
|
|
<filename>/etc/sysctl.conf</filename> so that the changes
|
|
are persistent:</para>
|
|
<programlisting language="ini">net.bridge.bridge-nf-call-arptables=0
|
|
net.bridge.bridge-nf-call-iptables=0
|
|
net.bridge.bridge-nf-call-ip6tables=0</programlisting>
|
|
</listitem>
|
|
</orderedlist>
|
|
</simplesect>
|
|
<simplesect>
|
|
<title>KVM: Network connectivity works initially, then fails</title>
|
|
<para>With KVM hypervisors, instances running Ubuntu 12.04
|
|
sometimes lose network connectivity after functioning properly
|
|
for a period of time. Try loading the <literal>vhost_net</literal>
|
|
kernel module as a workaround for this issue (see <link
|
|
xlink:href="https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/997978/">bug
|
|
#997978</link>) . This kernel module may also <link
|
|
xlink:href="http://www.linux-kvm.org/page/VhostNet">improve
|
|
network performance</link> on KVM. To load the kernel module:</para>
|
|
<screen><prompt>#</prompt> <userinput>modprobe vhost_net</userinput></screen>
|
|
<note>
|
|
<para>Loading the module has no effect on running instances.</para>
|
|
</note>
|
|
</simplesect>
|
|
</section>
|
|
</section>
|