openstack-manuals/doc/install-guide/source/launch-instance-networks-selfservice.rst
Pranav Salunke de38f2767f install: Updates syntax for training labs parser.
Training labs parser will allow us to automatically parse RST code
to BASH. This BASH code in turn will be invoked by install-guides for
validating the install guides. To provide the correct information to the
parser for generating BASH code, there are a few changes required to the
RST syntax.

Introduces the following changes to RST syntax:

  - `.. end`

    This tag provides information for the parser to stop extracting the
    given block which could be code, file injection or configuration
    file edit.

  - `.. endonly`

    This tag provides information for the parser with the correct
    distro-switch logic for identifying distro-specific code.

    For .. only:: tags, it is better to avoid nesting. If nesting
    is not avoidable then it is preferable to add the .. endonly
    tag to close the outer block immediately.

  - Extra new lines in code-blocks

    Some commands in the code-blocks provides the expected output of the
    given command. This is not a BASH command which we want to run but
    rather some visual niceness for the users. These new lines provides
    the parser information to identify the end of the command. This
    basic logic would be something similar to find '\r\n' which at least
    for python means new empty line.

  - `mysql>`

    Introducing this operator for mysql commands. This could potentially
    be changed to `pgsql>` or similar for other SQL type databases.
    This allows the parser to identify mysql commands and then run
    them in mysql instead of in 'sh' or 'bash'.

  - `.. path`

    Introducing this tag to provide the parser with the information with
    the path of the configuration file. Using the description text for
    the same is not reliable since the description text may not be
    consistent.

This commit should ideally introduce all the syntax changes required for
the parser to convert the code-blocks in here to BASH code. These
changes should have no impact on the HTML output of the RST code.

Change-Id: I47830b1bc61c8b1a0f3350932d15aa3ce88fa672
2016-09-28 10:58:06 +02:00

10 KiB

Self-service network

If you chose networking option 2, you can also create a self-service (private) network that connects to the physical network infrastructure via NAT. This network includes a DHCP server that provides IP addresses to instances. An instance on this network can automatically access external networks such as the Internet. However, access to an instance on this network from external networks such as the Internet requires a floating IP address.

The demo or other unprivileged user can create this network because it provides connectivity to instances within the demo project only.

Warning

You must create the provider network <launch-instance-networks-provider> before the self-service network.

Note

The following instructions and diagrams use example IP address ranges. You must adjust them for your particular environment.

Networking Option 2: Self-service networks - Overview
Networking Option 2: Self-service networks - Connectivity

Create the self-service network

  1. On the controller node, source the demo credentials to gain access to user-only CLI commands:

    $ . demo-openrc
  2. Create the network:

    $ neutron net-create selfservice
    
    Created a new network:
    +-----------------------+--------------------------------------+
    | Field                 | Value                                |
    +-----------------------+--------------------------------------+
    | admin_state_up        | True                                 |
    | id                    | 7c6f9b37-76b4-463e-98d8-27e5686ed083 |
    | mtu                   | 0                                    |
    | name                  | selfservice                          |
    | port_security_enabled | True                                 |
    | router:external       | False                                |
    | shared                | False                                |
    | status                | ACTIVE                               |
    | subnets               |                                      |
    | tenant_id             | f5b2ccaa75ac413591f12fcaa096aa5c     |
    +-----------------------+--------------------------------------+

    Non-privileged users typically cannot supply additional parameters to this command. The service automatically chooses parameters using information from the following files:

    ml2_conf.ini:

    [ml2]
    tenant_network_types = vxlan
    
    [ml2_type_vxlan]
    vni_ranges = 1:1000
  3. Create a subnet on the network:

    $ neutron subnet-create --name selfservice \
      --dns-nameserver DNS_RESOLVER --gateway SELFSERVICE_NETWORK_GATEWAY \
      selfservice SELFSERVICE_NETWORK_CIDR

    Replace DNS_RESOLVER with the IP address of a DNS resolver. In most cases, you can use one from the /etc/resolv.conf file on the host.

    Replace SELFSERVICE_NETWORK_GATEWAY with the gateway you want to use on the self-service network, typically the ".1" IP address.

    Replace SELFSERVICE_NETWORK_CIDR with the subnet you want to use on the self-service network. You can use any arbitrary value, although we recommend a network from RFC 1918.

    Example

    The self-service network uses 172.16.1.0/24 with a gateway on 172.16.1.1. A DHCP server assigns each instance an IP address from 172.16.1.2 to 172.16.1.254. All instances use 8.8.4.4 as a DNS resolver.

    $ neutron subnet-create --name selfservice \
      --dns-nameserver 8.8.4.4 --gateway 172.16.1.1 \
      selfservice 172.16.1.0/24
    
    Created a new subnet:
    +-------------------+------------------------------------------------+
    | Field             | Value                                          |
    +-------------------+------------------------------------------------+
    | allocation_pools  | {"start": "172.16.1.2", "end": "172.16.1.254"} |
    | cidr              | 172.16.1.0/24                                  |
    | dns_nameservers   | 8.8.4.4                                        |
    | enable_dhcp       | True                                           |
    | gateway_ip        | 172.16.1.1                                     |
    | host_routes       |                                                |
    | id                | 3482f524-8bff-4871-80d4-5774c2730728           |
    | ip_version        | 4                                              |
    | ipv6_address_mode |                                                |
    | ipv6_ra_mode      |                                                |
    | name              | selfservice                                    |
    | network_id        | 7c6f9b37-76b4-463e-98d8-27e5686ed083           |
    | subnetpool_id     |                                                |
    | tenant_id         | f5b2ccaa75ac413591f12fcaa096aa5c               |
    +-------------------+------------------------------------------------+

Create a router

Self-service networks connect to provider networks using a virtual router that typically performs bidirectional NAT. Each router contains an interface on at least one self-service network and a gateway on a provider network.

The provider network must include the router:external option to enable self-service routers to use it for connectivity to external networks such as the Internet. The admin or other privileged user must include this option during network creation or add it later. In this case, we can add it to the existing provider provider network.

  1. On the controller node, source the admin credentials to gain access to admin-only CLI commands:

    $ . admin-openrc
  2. Add the router: external option to the provider network:

    $ neutron net-update provider --router:external
    
    Updated network: provider
  3. Source the demo credentials to gain access to user-only CLI commands:

    $ . demo-openrc
  4. Create the router:

    $ neutron router-create router
    
    Created a new router:
    +-----------------------+--------------------------------------+
    | Field                 | Value                                |
    +-----------------------+--------------------------------------+
    | admin_state_up        | True                                 |
    | external_gateway_info |                                      |
    | id                    | 89dd2083-a160-4d75-ab3a-14239f01ea0b |
    | name                  | router                               |
    | routes                |                                      |
    | status                | ACTIVE                               |
    | tenant_id             | f5b2ccaa75ac413591f12fcaa096aa5c     |
    +-----------------------+--------------------------------------+
  5. Add the self-service network subnet as an interface on the router:

    $ neutron router-interface-add router selfservice
    
    Added interface bff6605d-824c-41f9-b744-21d128fc86e1 to router router.
  6. Set a gateway on the provider network on the router:

    $ neutron router-gateway-set router provider
    
    Set gateway for router router

Verify operation

We recommend that you verify operation and fix any issues before proceeding. The following steps use the IP address ranges from the network and subnet creation examples.

  1. On the controller node, source the admin credentials to gain access to admin-only CLI commands:

    $ . admin-openrc
  2. List network namespaces. You should see one qrouter namespace and two qdhcp namespaces.

    $ ip netns
    
    qrouter-89dd2083-a160-4d75-ab3a-14239f01ea0b
    qdhcp-7c6f9b37-76b4-463e-98d8-27e5686ed083
    qdhcp-0e62efcd-8cee-46c7-b163-d8df05c3c5ad
  3. List ports on the router to determine the gateway IP address on the provider network:

    $ neutron router-port-list router
    
    +--------------------------------------+------+-------------------+------------------------------------------+
    | id                                   | name | mac_address       | fixed_ips                                |
    +--------------------------------------+------+-------------------+------------------------------------------+
    | bff6605d-824c-41f9-b744-21d128fc86e1 |      | fa:16:3e:2f:34:9b | {"subnet_id":                            |
    |                                      |      |                   | "3482f524-8bff-4871-80d4-5774c2730728",  |
    |                                      |      |                   | "ip_address": "172.16.1.1"}              |
    | d6fe98db-ae01-42b0-a860-37b1661f5950 |      | fa:16:3e:e8:c1:41 | {"subnet_id":                            |
    |                                      |      |                   | "5cc70da8-4ee7-4565-be53-b9c011fca011",  |
    |                                      |      |                   | "ip_address": "203.0.113.102"}           |
    +--------------------------------------+------+-------------------+------------------------------------------+
  4. Ping this IP address from the controller node or any host on the physical provider network:

    $ ping -c 4 203.0.113.102
    
    PING 203.0.113.102 (203.0.113.102) 56(84) bytes of data.
    64 bytes from 203.0.113.102: icmp_req=1 ttl=64 time=0.619 ms
    64 bytes from 203.0.113.102: icmp_req=2 ttl=64 time=0.189 ms
    64 bytes from 203.0.113.102: icmp_req=3 ttl=64 time=0.165 ms
    64 bytes from 203.0.113.102: icmp_req=4 ttl=64 time=0.216 ms
    
    --- 203.0.113.102 ping statistics ---
    rtt min/avg/max/mdev = 0.165/0.297/0.619/0.187 ms

Return to Launch an instance - Create virtual networks <launch-instance-networks>.