diff --git a/doc/glossary/glossary-terms.xml b/doc/glossary/glossary-terms.xml index 806aefacdd..0cdcb1cb36 100644 --- a/doc/glossary/glossary-terms.xml +++ b/doc/glossary/glossary-terms.xml @@ -2056,8 +2056,8 @@ gateway - Hardware or software that translates between two - different protocols. + An IP address, typically assigned to a router, that + passes network traffic between different networks. @@ -2534,6 +2534,13 @@ instance. + + interface + + A physical or virtual device that provides connectivity + to another device or medium. + + interface ID @@ -3960,6 +3967,13 @@ instances among available hosts. + + router + + A physical or virtual network device that passes + network traffic between different networks. + + routing key @@ -4396,6 +4410,12 @@ possible. + + subnet + + Logical subdivision of an IP network. + + SUSE Linux Enterprise Server (SLES) diff --git a/doc/install-guide/figures/installguide_neutron-initial-networks.png b/doc/install-guide/figures/installguide_neutron-initial-networks.png new file mode 100644 index 0000000000..8b40d4c38b Binary files /dev/null and b/doc/install-guide/figures/installguide_neutron-initial-networks.png differ diff --git a/doc/install-guide/figures/installguide_neutron-initial-networks.svg b/doc/install-guide/figures/installguide_neutron-initial-networks.svg new file mode 100644 index 0000000000..44b4b7abbe --- /dev/null +++ b/doc/install-guide/figures/installguide_neutron-initial-networks.svg @@ -0,0 +1,621 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Network Interfaces + + Network Nodenetwork + + External Network Interfaceeth2: (unnumbered) + + Compute Nodecompute1 + + Tenant Virtual Network (demo-net)Subnet: 192.168.1.0/24 (demo-subnet)Gateway: 192.168.1.1 + + External Virtual Network (ext-net)Subnet: 203.0.113.0/24 (ext-subnet)Gateway: 203.0.113.1 + + Instance Tunnel Interfaceeth1: 10.0.1.21/24 + Network Interfaces + + External Physical NetworkSubnet: 203.0.113.0/24 + + + Instance Tunnel Interfaceeth1: 10.0.1.31/24 + Tenant Virtual Router (demo-router) + + Instance (demo1)Subnet: 192.168.1.0/24 (demo-subnet) + + External Physical RouterIP Address: 203.0.113.1 + + + + + + + + + + + Internet + + + External Physical Switch + + diff --git a/doc/install-guide/section_neutron-initial-networks.xml b/doc/install-guide/section_neutron-initial-networks.xml index 6f5347b0ca..9a5b3b2dba 100644 --- a/doc/install-guide/section_neutron-initial-networks.xml +++ b/doc/install-guide/section_neutron-initial-networks.xml @@ -5,153 +5,180 @@ xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:svg="http://www.w3.org/2000/svg" xmlns:html="http://www.w3.org/1999/xhtml" version="5.0"> - Create initial networks + Create initial networks + Before launching your first instance, you must create the + necessary virtual network infrastructure to which the instance will + connect, including the + external network + and + tenant network. + See . After + creating this infrastructure, we recommend that you + verify + connectivity and resolve any issues before proceeding further. + +
+ Initial networks + + + + + +
+
+ External network + The external network typically provides internet access for + your instances. By default, this network only allows internet + access from instances using + Network Address Translation (NAT). You can + enable internet access to individual instances + using a floating IP address and suitable + security group rules. The admin + tenant owns this network because it provides external network + access for multiple tenants. You must also enable sharing to allow + access by those tenants. - In these sections, replace SPECIAL_OPTIONS with any options specific to your OpenStack Networking plug-in choices. See here to check if your plug-in requires any special options. + Perform these commands on the controller node. + To create the external network: - Create the ext-net external network. This - network represents a slice of the outside world. VMs are not directly - linked to this network; instead, they connect to internal networks. - Outgoing traffic is routed by OpenStack Networking to the external - network. Additionally, floating IP addresses from the subnet for - ext-net might be assigned to VMs so that the - external network can contact them. Neutron-based services route the - traffic appropriately. - $ neutron net-create ext-net --router:external=True SPECIAL_OPTIONS + Source the admin tenant credentials: + $ source admin-openrc.sh - Create the associated subnet with the same gateway and - CIDR as EXTERNAL_INTERFACE. It - does not have DHCP because it represents a slice of the - external world: - $ neutron subnet-create ext-net \ - --allocation-pool start=FLOATING_IP_START,end=FLOATING_IP_END \ - --gateway=EXTERNAL_INTERFACE_GATEWAY --enable_dhcp=False \ - EXTERNAL_INTERFACE_CIDR - - - Create one or more initial tenants, for example: - $ keystone tenant-create --name DEMO_TENANT - See for further details. - See for - further details. - - - Create the router attached to the external network. This - router routes traffic to the internal subnets as - appropriate. You can create it under a given tenant: Append - --tenant-id option with a value of - DEMO_TENANT_ID to the - command. - Use the following to quickly get the - DEMO_TENANT tenant-id: - $ keystone tenant-list | grep DEMO_TENANT | awk '{print $2;}' - Then create the router: - $ neutron router-create ext-to-int --tenant-id DEMO_TENANT_ID - - - Connect the router to ext-net by - setting the gateway for the router as - ext-net: - $ neutron router-gateway-set EXT_TO_INT_ID EXT_NET_ID - - - Create an internal network for - DEMO_TENANT (and associated - subnet over an arbitrary internal IP range, such as, - 10.5.5.0/24), and connect it to the - router by setting it as a port: - $ neutron net-create --tenant-id DEMO_TENANT_ID demo-net SPECIAL_OPTIONS -$ neutron subnet-create --tenant-id DEMO_TENANT_ID demo-net 10.5.5.0/24 --gateway 10.5.5.1 -$ neutron router-interface-add EXT_TO_INT_ID DEMO_NET_SUBNET_ID + Create the network: + $ neutron net-create ext-net --shared --router:external=True + + + Like a physical network, a virtual network requires a + subnet assigned to it. The external network + shares the same subnet and gateway associated + with the physical network connected to the external interface on the + network node. You should specify an exclusive slice of this subnet + for router and floating IP addresses to prevent + interference with other devices on the external network. + Replace FLOATING_IP_START and + FLOATING_IP_END with the first and last + IP addresses of the range that you want to allocate for floating IP + addresses. Replace EXTERNAL_NETWORK_CIDR + with the subnet associated with the physical network. Replace + EXTERNAL_NETWORK_GATEWAY with the gateway + associated with the physical network, typically the ".1" IP address. + You should disable DHCP on this subnet because + instances do not connect directly to the external network and floating + IP addresses require manual assignment. + + To create a subnet on the external network: + + Create the subnet: + $ neutron subnet-create ext-net --name ext-subnet \ + --allocation-pool start=FLOATING_IP_START,end=FLOATING_IP_END \ + --disable-dhcp --gateway EXTERNAL_NETWORK_GATEWAY EXTERNAL_NETWORK_CIDR + For example, using 203.0.113.0/24 with + floating IP address range 203.0.113.101 to + 203.0.113.200: + $ neutron subnet-create ext-net --name ext-subnet \ + --allocation-pool start=203.0.113.101,end=203.0.113.200 \ + --disable-dhcp --gateway 203.0.113.1 203.0.113.0/24 -
- Plug-in-specific Neutron network options -
- Open vSwitch Network configuration options -
- GRE tunneling network options - - While this guide currently enables network - namespaces by default, you can disable them if you have - issues or your kernel does not support them. If you - disabled namespaces, you must perform some additional - configuration for the L3 agent. - After you create all the networks, tell the L3 agent - what the external network ID is, as well as the ID of - the router associated with this machine (because you are - not using namespaces, there can be only one router for - each machine). To do this, edit the - /etc/neutron/l3_agent.ini - file: - gateway_external_network_id = EXT_NET_ID -router_id = EXT_TO_INT_ID - Then, restart the L3 agent: - # service neutron-l3-agent restart - - When creating networks, you should use the - options: - --provider:network_type gre --provider:segmentation_id SEG_ID - SEG_ID should be - 2 for the external network, and just - any unique number inside the tunnel range specified before - for any other network. - - These options are not needed beyond the first - network, as OpenStack Networking services automatically - increment the segmentation ID and copy the network type - option for any additional networks. - -
-
- VLAN network options - - Some NICs have Linux drivers that do not handle - VLANs properly. See the - ovs-vlan-bug-workaround and - ovs-vlan-test man pages for more - information. Additionally, you might try turning off - rx-vlan-offload and - tx-vlan-offload by using - ethtool on the - DATA_INTERFACE. Another - potential caveat to VLAN functionality is that VLAN tags - add an additional 4 bytes to the packet size. If your - NICs cannot handle large packets, make sure to set the - MTU to a value that is 4 bytes less than the normal - value on the - DATA_INTERFACE. - If you run OpenStack inside a virtualized - environment (for testing purposes), switching to the - virtio NIC type (or a similar - technology if you are not using KVM/QEMU to run your - host VMs) might solve the issue. - - When creating networks, use these options: - --provider:network_type vlan --provider:physical_network physnet1 --provider:segmentation_id SEG_ID - SEG_ID should be - 2 for the external network, and just - any unique number inside the vlan range specified above - for any other network. - - These options are not needed beyond the first - network, as Neutron automatically increments the - segmentation ID and copies the network type and physical - network options for any additional networks. They are - only needed if you wish to modify those values in any - way. - -
-
-
+
+ Tenant network + The tenant network provides internal network access for instances. + The architecture isolates this type of network from other tenants. The + demo tenant owns this network because it only + provides network access for instances within it. + + Perform these commands on the controller node. + + + To create the tenant network: + + Source the demo tenant credentials: + $ source demo-openrc.sh + + + Create the network: + $ neutron net-create demo-net + + + Like the external network, your tenant network also requires + a subnet attached to it. You can specify any valid subnet because the + architecture isolates tenant networks. Replace + TENANT_NETWORK_CIDR with the subnet + you want to associate with the tenant network. Replace + TENANT_NETWORK_GATEWAY with the gateway you + want to associate with this network, typically the ".1" IP address. By + default, this subnet will use DHCP so your instances can obtain IP + addresses. + + To create a subnet on the tenant network: + + Create the subnet: + $ neutron subnet-create demo-net --name demo-subnet \ + --gateway TENANT_NETWORK_GATEWAY TENANT_NETWORK_CIDR + Example using 192.168.1.0/24: + $ neutron subnet-create demo-net --name demo-subnet \ + --gateway 192.168.1.1 192.168.1.0/24 + + + A virtual router passes network traffic between two or more virtual + networks. Each router requires one or more + interfaces and/or gateways + that provide access to specific networks. In this case, you will create + a router and attach your tenant and external networks to it. + + To create a router on the tenant network and attach the external + and tenant networks to it: + + Create the router: + $ neutron router-create demo-router + + + Attach the router to the demo tenant + subnet: + $ neutron router-interface-add demo-router demo-subnet + + + Attach the router to the external network by setting it as + the gateway: + $ neutron router-gateway-set demo-router ext-net + + +
+
+ Verify connectivity + We recommend that you verify network connectivity and resolve any + issues before proceeding further. Following the external network + subnet example using 203.0.113.0/24, the tenant + router gateway should occupy the lowest IP address in the floating + IP address range, 203.0.113.101. If you configured + your external physical network and virtual networks correctly, you + you should be able to ping this IP address from any + host on your external physical network. + + If you are building your OpenStack nodes as virtual machines, + you must configure the hypervisor to permit promiscuous mode on the + external network. + + + To verify network connectivity: + + Ping the tenant router gateway: + $ ping -c 4 203.0.113.101 +PING 203.0.113.101 (203.0.113.101) 56(84) bytes of data. +64 bytes from 203.0.113.101: icmp_req=1 ttl=64 time=0.619 ms +64 bytes from 203.0.113.101: icmp_req=2 ttl=64 time=0.189 ms +64 bytes from 203.0.113.101: icmp_req=3 ttl=64 time=0.165 ms +64 bytes from 203.0.113.101: icmp_req=4 ttl=64 time=0.216 ms + +--- 203.0.113.101 ping statistics --- +4 packets transmitted, 4 received, 0% packet loss, time 2999ms +rtt min/avg/max/mdev = 0.165/0.297/0.619/0.187 ms + + +
+