117 lines
4.3 KiB
ReStructuredText
Raw Normal View History

=====================
DevStack Networking
=====================
An important part of the DevStack experience is networking that works
by default for created guests. This might not be optimal for your
particular testing environment, so this document tries its best to
explain what's going on.
Defaults
========
If you don't specify any configuration you will get the following:
* neutron (including l3 with openvswitch)
* private project networks for each openstack project
* a floating ip range of 172.24.4.0/24 with the gateway of 172.24.4.1
Derive IP ranges from new ADDRS_SAFE_TO_USE vars The switch to using subnetpools caused quite a bit of confusion because it didn't respect the value of FIXED_RANGE. This caused conflicts in the gate with it's default IPv4 value of 10.0.0.0/8. This patch does a few things to address the issue: * It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values to dervive from them by default. * This addresses the concern that was raised about implying that SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value for the operator specify a chunk of addresses that are safe to use for private networks without implementation implications. * Backwards compatibility is maintained by alloing users to override override all of these values. * The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24 * Because we want to be able to use subnetpools for auto allocated topologies and we want to be able to have a large chunk of instances on each network, we needed a little more breathing room in the default v4 network size. * SUBNET_POOL_SIZE_V4 default is changed from 24 to 26 * In conjuction with this change and the one above, the default subnetpool will support up to 16 64-address allocations. * This should be enough to cover any regular gate scenarios. * If someone wants a bigger/smaller subnet, they can ask for that in the API request, change this value themselves, or use a different network entirely. * FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE * This avoids the private subnet in the non-subnetpool case from being larger than /64 to avoid issues identified in rfc 7421. * Users can still explicitly set this value to whatever they want. This 'max' behavior is only for the default. * This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves tons of room for v6 subnetpools. Closes-Bug: #1629133 Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
2016-11-15 17:26:05 -08:00
* the demo project configured with fixed ips on a subnet allocated from
the 10.0.0.0/22 range
* a ``br-ex`` interface controlled by neutron for all its networking
(this is not connected to any physical interfaces).
* DNS resolution for guests based on the resolv.conf for your host
* an ip masq rule that allows created guests to route out
This creates an environment which is isolated to the single
host. Guests can get to the external network for package
updates. Tempest tests will work in this environment.
.. note::
By default all OpenStack environments have security group rules
which block all inbound packets to guests. If you want to be able
to ssh / ping your created guests you should run the following.
.. code-block:: bash
openstack security group rule create --proto icmp --dst-port 0 default
openstack security group rule create --proto tcp --dst-port 22 default
Locally Accessible Guests
=========================
If you want to make you guests accessible from other machines on your
network, we have to connect ``br-ex`` to a physical interface.
Dedicated Guest Interface
-------------------------
If you have 2 or more interfaces on your devstack server, you can
allocate an interface to neutron to fully manage. This **should not**
be the same interface you use to ssh into the devstack server itself.
This is done by setting with the ``PUBLIC_INTERFACE`` attribute.
.. code-block:: bash
[[local|localrc]]
PUBLIC_INTERFACE=eth1
That will put all layer 2 traffic from your guests onto the main
network. When running in this mode the ip masq rule is **not** added
in your devstack, you are responsible for making routing work on your
local network.
Shared Guest Interface
----------------------
.. warning::
This is not a recommended configuration. Because of interactions
between ovs and bridging, if you reboot your box with active
networking you may loose network connectivity to your system.
If you need your guests accessible on the network, but only have 1
interface (using something like a NUC), you can share your one
network. But in order for this to work you need to manually set a lot
of addresses, and have them all exactly correct.
.. code-block:: bash
[[local|localrc]]
PUBLIC_INTERFACE=eth0
HOST_IP=10.42.0.52
FLOATING_RANGE=10.42.0.52/24
PUBLIC_NETWORK_GATEWAY=10.42.0.1
Q_FLOATING_ALLOCATION_POOL=start=10.42.0.250,end=10.42.0.254
In order for this scenario to work the floating ip network must match
the default networking on your server. This breaks HOST_IP detection,
as we exclude the floating range by default, so you have to specify
that manually.
The ``PUBLIC_NETWORK_GATEWAY`` is the gateway that server would normally
use to get off the network. ``Q_FLOATING_ALLOCATION_POOL`` controls
the range of floating ips that will be handed out. As we are sharing
your existing network, you'll want to give it a slice that your local
dhcp server is not allocating. Otherwise you could easily have
conflicting ip addresses, and cause havoc with your local network.
Derive IP ranges from new ADDRS_SAFE_TO_USE vars The switch to using subnetpools caused quite a bit of confusion because it didn't respect the value of FIXED_RANGE. This caused conflicts in the gate with it's default IPv4 value of 10.0.0.0/8. This patch does a few things to address the issue: * It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values to dervive from them by default. * This addresses the concern that was raised about implying that SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value for the operator specify a chunk of addresses that are safe to use for private networks without implementation implications. * Backwards compatibility is maintained by alloing users to override override all of these values. * The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24 * Because we want to be able to use subnetpools for auto allocated topologies and we want to be able to have a large chunk of instances on each network, we needed a little more breathing room in the default v4 network size. * SUBNET_POOL_SIZE_V4 default is changed from 24 to 26 * In conjuction with this change and the one above, the default subnetpool will support up to 16 64-address allocations. * This should be enough to cover any regular gate scenarios. * If someone wants a bigger/smaller subnet, they can ask for that in the API request, change this value themselves, or use a different network entirely. * FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE * This avoids the private subnet in the non-subnetpool case from being larger than /64 to avoid issues identified in rfc 7421. * Users can still explicitly set this value to whatever they want. This 'max' behavior is only for the default. * This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves tons of room for v6 subnetpools. Closes-Bug: #1629133 Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
2016-11-15 17:26:05 -08:00
Private Network Addressing
==========================
The private networks addresses are controlled by the ``IPV4_ADDRS_SAFE_TO_USE``
and the ``IPV6_ADDRS_SAFE_TO_USE`` variables. This allows users to specify one
single variable of safe internal IPs to use that will be referenced whether or
not subnetpools are in use.
For IPv4, ``FIXED_RANGE`` and ``SUBNETPOOL_PREFIX_V4`` will just default to
the value of ``IPV4_ADDRS_SAFE_TO_USE`` directly.
For IPv6, ``FIXED_RANGE_V6`` will default to the first /64 of the value of
Derive IP ranges from new ADDRS_SAFE_TO_USE vars The switch to using subnetpools caused quite a bit of confusion because it didn't respect the value of FIXED_RANGE. This caused conflicts in the gate with it's default IPv4 value of 10.0.0.0/8. This patch does a few things to address the issue: * It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values to dervive from them by default. * This addresses the concern that was raised about implying that SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value for the operator specify a chunk of addresses that are safe to use for private networks without implementation implications. * Backwards compatibility is maintained by alloing users to override override all of these values. * The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24 * Because we want to be able to use subnetpools for auto allocated topologies and we want to be able to have a large chunk of instances on each network, we needed a little more breathing room in the default v4 network size. * SUBNET_POOL_SIZE_V4 default is changed from 24 to 26 * In conjuction with this change and the one above, the default subnetpool will support up to 16 64-address allocations. * This should be enough to cover any regular gate scenarios. * If someone wants a bigger/smaller subnet, they can ask for that in the API request, change this value themselves, or use a different network entirely. * FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE * This avoids the private subnet in the non-subnetpool case from being larger than /64 to avoid issues identified in rfc 7421. * Users can still explicitly set this value to whatever they want. This 'max' behavior is only for the default. * This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves tons of room for v6 subnetpools. Closes-Bug: #1629133 Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
2016-11-15 17:26:05 -08:00
``IPV6_ADDRS_SAFE_TO_USE``. If ``IPV6_ADDRS_SAFE_TO_USE`` is /64 or smaller,
``FIXED_RANGE_V6`` will just use the value of that directly.
Derive IP ranges from new ADDRS_SAFE_TO_USE vars The switch to using subnetpools caused quite a bit of confusion because it didn't respect the value of FIXED_RANGE. This caused conflicts in the gate with it's default IPv4 value of 10.0.0.0/8. This patch does a few things to address the issue: * It introduces the IPV4_ADDRS_SAFE_TO_USE and IPV6_ADDRS_SAFE_TO_USE values and adjusts all of the FIXED_RANGE and SUBNETPOOL_PREFIX values to dervive from them by default. * This addresses the concern that was raised about implying that SUBNETPOOL_PREFIX and FIXED_RANGE are equivalent when setting SUBNETPOOL_PREFIX=FIXED_RANGE by default. Now we have a new value for the operator specify a chunk of addresses that are safe to use for private networks without implementation implications. * Backwards compatibility is maintained by alloing users to override override all of these values. * The default for IPV4_ADDRS_SAFE_TO_USE uses /22 instead of /24 * Because we want to be able to use subnetpools for auto allocated topologies and we want to be able to have a large chunk of instances on each network, we needed a little more breathing room in the default v4 network size. * SUBNET_POOL_SIZE_V4 default is changed from 24 to 26 * In conjuction with this change and the one above, the default subnetpool will support up to 16 64-address allocations. * This should be enough to cover any regular gate scenarios. * If someone wants a bigger/smaller subnet, they can ask for that in the API request, change this value themselves, or use a different network entirely. * FIXED_RANGE_V6 defaults to a max prefix of /64 from IPV6_ADDRS_SAFE_TO_USE * This avoids the private subnet in the non-subnetpool case from being larger than /64 to avoid issues identified in rfc 7421. * Users can still explicitly set this value to whatever they want. This 'max' behavior is only for the default. * This allows IPV6_ADDRS_SAFE_TO_USE to default to a /56, which leaves tons of room for v6 subnetpools. Closes-Bug: #1629133 Change-Id: I7b32804d47bec743c0b13e434e6a7958728896ea
2016-11-15 17:26:05 -08:00
``SUBNETPOOL_PREFIX_V6`` will just default to the value of
``IPV6_ADDRS_SAFE_TO_USE`` directly.