Browse code
add networking write up for devstack
This explains the current state of networking in devstack, and a
couple of scenarios that people might want to try out for local
testing.
Change-Id: I2be35f4345bf9306c981ef6f0186b48da7d06772
Sean Dague authored on 2016/08/12 20:21:59Showing 3 changed files
| ... | ... |
@@ -120,7 +120,8 @@ Going further |
| 120 | 120 |
------------- |
| 121 | 121 |
|
| 122 | 122 |
Learn more about our :doc:`configuration system <configuration>` to |
| 123 |
-customize devstack for your needs. |
|
| 123 |
+customize devstack for your needs. Including making adjustments to the |
|
| 124 |
+default :doc:`networking <networking>`. |
|
| 124 | 125 |
|
| 125 | 126 |
Read :doc:`guides <guides>` for specific setups people have (note: |
| 126 | 127 |
guides are point in time contributions, and may not always be kept |
| 127 | 128 |
new file mode 100644 |
| ... | ... |
@@ -0,0 +1,97 @@ |
| 0 |
+===================== |
|
| 1 |
+ DevStack Networking |
|
| 2 |
+===================== |
|
| 3 |
+ |
|
| 4 |
+An important part of the DevStack experience is networking that works |
|
| 5 |
+by default for created guests. This might not be optimal for your |
|
| 6 |
+particular testing environment, so this document tries it's best to |
|
| 7 |
+explain what's going on. |
|
| 8 |
+ |
|
| 9 |
+Defaults |
|
| 10 |
+======== |
|
| 11 |
+ |
|
| 12 |
+If you don't specify any configuration you will get the following: |
|
| 13 |
+ |
|
| 14 |
+* neutron (including l3 with openvswitch) |
|
| 15 |
+* private project networks for each openstack project |
|
| 16 |
+* a floating ip range of 172.24.4.0/24 with the gateway of 172.24.4.1 |
|
| 17 |
+* the demo project configured with fixed ips on 10.0.0.0/24 |
|
| 18 |
+* a ``br-ex`` interface controlled by neutron for all it's networking |
|
| 19 |
+ (this is not connected to any physical interfaces). |
|
| 20 |
+* DNS resolution for guests based on the resolv.conf for you host |
|
| 21 |
+* an ip masq rule that allows created guests to route out |
|
| 22 |
+ |
|
| 23 |
+This creates an environment which is isolated to the single |
|
| 24 |
+host. Guests can get to the external network for package |
|
| 25 |
+updates. Tempest tests will work in this environment. |
|
| 26 |
+ |
|
| 27 |
+.. note:: |
|
| 28 |
+ |
|
| 29 |
+ By default all OpenStack environments have security group rules |
|
| 30 |
+ which block all inbound packets to guests. If you want to be able |
|
| 31 |
+ to ssh / ping your created guests you should run the following. |
|
| 32 |
+ |
|
| 33 |
+ .. code-block:: bash |
|
| 34 |
+ |
|
| 35 |
+ openstack security group rule create --proto icmp --dst-port 0 default |
|
| 36 |
+ openstack security group rule create --proto tcp --dst-port 22 default |
|
| 37 |
+ |
|
| 38 |
+Locally Accessible Guests |
|
| 39 |
+========================= |
|
| 40 |
+ |
|
| 41 |
+If you want to make you guests accessible other machines on your |
|
| 42 |
+network, we have to connect ``br-ex`` to a physical interface. |
|
| 43 |
+ |
|
| 44 |
+Dedicated Guest Interface |
|
| 45 |
+------------------------- |
|
| 46 |
+ |
|
| 47 |
+If you have 2 or more interfaces on your devstack server, you can |
|
| 48 |
+allocate an interface to neutron to fully manage. This **should not** |
|
| 49 |
+be the same interface you use to ssh into the devstack server itself. |
|
| 50 |
+ |
|
| 51 |
+This is done by setting with the ``PUBLIC_INTERFACE`` attribute. |
|
| 52 |
+ |
|
| 53 |
+.. code-block:: bash |
|
| 54 |
+ |
|
| 55 |
+ [[local|localrc]] |
|
| 56 |
+ PUBLIC_INTERFACE=eth1 |
|
| 57 |
+ |
|
| 58 |
+That will put all layer 2 traffic from your guests onto the main |
|
| 59 |
+network. When running in this mode the ip masq rule is **not** added |
|
| 60 |
+in your devstack, you are responsible for making routing work on your |
|
| 61 |
+local network. |
|
| 62 |
+ |
|
| 63 |
+Shared Guest Interface |
|
| 64 |
+---------------------- |
|
| 65 |
+ |
|
| 66 |
+.. warning:: |
|
| 67 |
+ |
|
| 68 |
+ This is not a recommended configuration. Because of interactions |
|
| 69 |
+ between ovs and bridging, if you reboot your box with active |
|
| 70 |
+ networking you may loose network connectivity to your system. |
|
| 71 |
+ |
|
| 72 |
+If you need your guests accessible on the network, but only have 1 |
|
| 73 |
+interface (using something like a NUC), you can share your one |
|
| 74 |
+network. But in order for this to work you need to manually set a lot |
|
| 75 |
+of addresses, and have them all exactly correct. |
|
| 76 |
+ |
|
| 77 |
+.. code-block:: bash |
|
| 78 |
+ |
|
| 79 |
+ [[local|localrc]] |
|
| 80 |
+ PUBLIC_INTERFACE=eth0 |
|
| 81 |
+ HOST_IP=10.42.0.52 |
|
| 82 |
+ FLOATING_RANGE=10.42.0.52/24 |
|
| 83 |
+ PUBLIC_NETWORK_GATEWAY=10.42.0.1 |
|
| 84 |
+ Q_FLOATING_ALLOCATION_POOL=start=10.42.0.250,end=10.42.0.254 |
|
| 85 |
+ |
|
| 86 |
+In order for this scenario to work the floating ip network must match |
|
| 87 |
+the default networking on your server. This breaks HOST_IP detection, |
|
| 88 |
+as we exclude the floating range by default, so you have to specify |
|
| 89 |
+that manually. |
|
| 90 |
+ |
|
| 91 |
+The ``PUBLIC_NETWORK_GATEWAY`` is the gateway that server would normally |
|
| 92 |
+use to get off the network. ``Q_FLOATING_ALLOCATION_POOL`` controls |
|
| 93 |
+the range of floating ips that will be handed out. As we are sharing |
|
| 94 |
+your existing network, you'll want to give it a slice that your local |
|
| 95 |
+dhcp server is not allocating. Otherwise you could easily have |
|
| 96 |
+conflicting ip addresses, and cause havoc with your local network. |